MS13-061 causes search controller headaches for Exchange 2013

Update 9:41AM (Pacific) 14 August: Microsoft has temporarily removed MS13-061 to fix the problem reported here. If you already have the update, you can install it and fix the problem afterwards as described below.

Update 9:08AM (Pacific) 27 August: Microsoft has released an updated MS13-061 for Exchange 2013 RTM CU1 and Exchange 2013 RTM CU2. 

Yesterday Microsoft issued a set of security fixes, including a critical patch (MS13-061) that affected Exchange 2013, Exchange 2010, and Exchange 2007. The Exchange product group duly released roll-up updates for Exchange 2007 SP3 (RU11), Exchange 2010 SP2 (RU7) and Exchange 2010 SP3 (RU2). All was well for Exchange 2013 RTM CU2 because the new servicing model is designed to allow security patches to be applied to a server without requiring Exchange to be updated. All was well in the world.

Until, of course, a bug appeared. In this case, the application of MS13-061 messes with the settings for the Microsoft Exchange Search Host Controller service. This service controls how the Search Foundation interacts with Exchange mailbox databases to create their content indexes. The bug renames the service (not serious) and removes the path to the data directory used by the service (very serious) and the dependency that the service has on http (again serious). All in all, not a good situation for a mailbox server that depends on the content indexes for functions such as eDiscovery searches.

MS13-061 has installed successfully on every server to which I have applied the fix. No indication is given that a problem has been left behind so it’s easy to assume that a fully functioning and secure server is now in place. However, if you examine the properties of mailbox databases through the Exchange Administration Center (EAC) or by running the Get-MailboxDatabaseCopyStatus cmdlet, you’ll see that the content indexing status for the database is reported as “Failed”. In addition, the Microsoft Exchange Search Host Controller service is not to be found because it is renamed “Host Controller service for Exchange”. This service is not running.

The fix is described in KB2879739 and involves a number of changes to the system registry on all affected servers.

Use Regedit to navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftSearch Foundation for Exchange
Note that the DataDirectory value is empty. You need to update the value with the correct data path for the content indexing service. If you install Exchange on drive C:, it’s likely that the path is:

C:Program FilesMicrosoftExchange ServerV15BinSearchCeresHostControllerData

After updating the value, move to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHostControllerService. Two changes are necessary here. First, change the display name of the content indexing service by overwriting the DisplayName value to “Microsoft Exchange Search Host Controller”. This change restores the value to what it was before MS13-061 was applied.

Next, create a new multi-string value called DependOnService. Add “http” to the value data to ensure that the content indexing service knows that http is a dependency.

After the registry changes are made, restart the Host Controller service for Exchange service (the name change won’t be effective until you reboot the server but this is not necessary for the service to function).

Once the service restarts, it will begin to rebuild the content indexes for the mailbox databases on the server. Depending on the size of the databases, it could take a little while before their status changes from Failed to Healthy.

The problem doesn't affect the roll-up updates released for Exchange 2007 or Exchange 2010.

I just wonder who decided to change the name of the Host Controller service without understanding the consequences of their action. What software engineer thought it a good idea to mess around with registry settings and then never bothered to make things right again? It’s maddening that yet another problem with an Exchange patch, albeit a security patch this time round, has slipped through Microsoft’s much-vaunted testing and validation process. Once again, this problem proves the wisdom of thoroughly testing every patch that Microsoft releases before introducing it anywhere near a production server, even if that patch fixes a security problem.

I wish, I really wish, Microsoft could get its testing processes right before they released code to paying customers. It’s sad and depressing that the world’s biggest software company can’t get the simple things right.

Follow Tony @12Knocksinna