Repairing Exchange Discovery Mailboxes

I went to perform a Discovery Search on our Exchange 2010 server for the first time since installing the server. Naturally, there was a problem. When trying to create a search using the Exchange Control Panel (ECP) the response was an error and the search could not be saved. My first thought was to make sure the arbitration accounts were setup and had the correct permissions. So, in the Exchange Management Shell I ran the command get-user -arbitration which showed the system mailboxes were in an inconsistent state:

This fix for this problem is to delete the system accounts and recreate them. The following steps are what I did to recreate the system accounts.

  1. In Active Directory Users and Computers delete the following accounts:
    • FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
    • SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
    • SystemMailbox{1f05a927-f5af-4646-bf20-4a3a41282c07}
      NOTE: The last account may be different but, should start with “1f05a927”
  2. Open a Command prompt change directory to the setup files for Exchange. On my server this was located in:
    C:\Program Files\Microsoft\Exchange Server\V14\Bin
  3. Run the command: setup.com /preparead. This will recreate the system accounts.
  4. In the Exchange Management Shell run the following commands:
    • Enable-Mailbox –Arbitration –Identity “FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042”
    • Enable-Mailbox –Arbitration –Identity “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}”
    • Enable-Mailbox –Arbitration –Identity “SystemMailbox{1f05a927-f91e-4cc2-b79a-00f3c790c250}”
      Note: last account name will be different. Copy-and-paste name from AD Users and Computers.
  5. Still in the EMS run the following commands to set the display name and quota on the Federated mailbox:
    • Set-Mailbox –Arbitration –Identity “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}” –DisplayName “Microsoft Exchange”
    • Set-Mailbox –Arbitration –Identity “FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042” –ProhibitSendQuota 1MB

After rebuilding the accounts the commands get-user -arbitration and get-mailbox -arbitration should report no errors:

The complete error I was encountering was:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>get-user -arbitration
Name RecipientType
—- ————-
SystemMailbox{1f05a927-f5af-4646-bf20-4a3a4128… UserMailbox
WARNING: The object AP.local/Users/SystemMailbox{1f05a927-f5af-4646-bf20-4a3a41282c07} has been
corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d82… UserMailbox
WARNING: The object AP.local/Users/SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} has been
corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa… UserMailbox
WARNING: The object AP.local/Users/FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 has been
corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.

Additional Resources:

http://social.technet.microsoft.com/wiki/contents/articles/5317.recreate-and-enable-missing-arbitration-user-accounts-and-mailboxes-in-exchange-server-2010.aspx

Block Google ads in AdBlock Plus

Recently, it has come to light that the developers of the super popular Firefox plugin AdBlock Plus have been taking money by some sites to exempt their ads from being blocked. Probably, the most notable contributor to the plugin developers is Google. The reasons and ramifications have been discussed on several sites like TechCrunch, The Verge, and at Search Engine Watch.

Fortunately, this behavior can be reversed by changing the settings in the AdBlock Plus plugin. The following depicts how:

That’s it! Browsing bliss restored.

It is easy to get angry that such a useful plugin is being eroded due to companies with deep pockets but, we (me and you) have to ask ourselves “how much did we pay for the plugin?” It would not surprise me if in a couple of years the option to block the whitelisted ads will disappear. However, it is my hope that there will be an option to donate to a small amount (5.00 – 10.00 per year) to enable to ability to block whitelisted ads.

 

 

Check php.ini for syntax errors

In the middle of setting-up a new webserver on a Windows Server 2008 machine using IIS7 and PHP 5.4 I ran into a problem that had me stumped for a short time. Though not something that is done frequently setting-up PHP on a Windows server is something that I am well-versed in doing. I know of the most common stumbling blocks and how to get around them – especially on Windows machines.

A common issue for those new to PHP is the php.ini file. Most problems can be attributed to editing the wrong one (albeit a more common problem years ago). This morning I was editing the php.ini on my new server using my normal routine: copy the supplied production version, open the php.ini file on my existing server, and making the new version match as close as possible. The only problem was it appeared the PHP was ignoring the timezone setting in the PHP.

Warning: phpinfo(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone ‘UTC’ for now, but please set date.timezone to select your timezone. in C:\Websites\AP-WWW\pinfo.php on line 2

I was willing to ignore this warning for the time being but, I was also experiencing a problem with MySQL. I was getting the following error: Fatal error: Call to undefined function mysql_connect(). I checked the usual cause – the location of the php.ini file and made sure I was editing the correct file:

I checked the file permissions, folder permissions, rebooted the server, etc. No matter what I did I kept getting the warning that PHP was assuming UTC for the timezone and displayed the lack of a setting for date.timezone in the php.ini file:

The most common cause I could find was to a misspelling of the timezone or using quotes on the line in the php.ini file. This seemed unlikely since I had copied-and-pasted the value from PHP.net’s website and from the php.ini file from my current PHP server.

Fortunately, the source of my frustration was easily identified when I went to compare the information by phpinfo() in a browser to the information displayed in the PHP CLI. From a DOS command window I ran the command php -i which displayed the following error:

When I looked at line 810 of the php.ini file I immediately saw the problem on line 809:

Fixing the error on line 809 and restarting IIS allowed PHP to recognize the timezone setting and eliminated the error connecting to MySQL:

Beware 32bit and 64bit ODBC Data Source Administrators

While creating an SSIS Package in SQL Server 2008 R2 I ran into a problem with an “architecture mismatch between the driver and the application” when trying to use a DSN as a new connection.

It turns out this is the result of the differences between 32-bit and 64-bit drivers. When creating data source names using the ODBC Data Source Administrator (Control Panel > Administrative Tools > Data Sources (ODBC)). Apparently when you run this tool on a Windows 2008 R2 server (64 bit) you are running the 64 bit version of this tool which only recognizes 64 bit drivers. SSIS is expecting 32 bit DSNs using 32 bit drivers (I think – this is still sinking in).

The fix to this is to create 32 bit DSNs. To do this you need to run the ODBC Data Source Administrator located here:

C:\Windows\SysWOW64\odbcad32.exe

One caveat is that you cannot create DSNs with the same name – e.g. “MyReportDB” – in both the 32 bit and 64 bit Data Source Administrator applications. I named mine “MyReportDB_32” and “MyReportDB_64”. I also created shortcuts to both Data Source Administrator applications changing their names to reflect the 32 or 64 bit version.

The 64 bit version of the ODBC Data Source Administrator is located here:

C:\Windows\system32\odbcad32.exe

The following images show the difference of the Drivers tab in the Data Source Administrator applications. This is the 64 bit version of the tool:

And this is the 32-bit version – notice there are alot more drivers:

Hopefully this will save some time for others!

The complete error I was encountering was:

Test connection failed because of an error in initializing provider. ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Drive and Application

 

Many thanks go John DaCosta for his helpful explanation on his blog!