MS13-061 causes search controller headaches for Exchange 2013

Oh dear, oh dear, oh dear... All seemed to be going well for the new Exchange 2013 servicing model when Microsoft released security fix MS13-061. The patch installed without requiring Exchange to be updated, but then we discovered that the patch messes with some settings of the content indexing service which requires administrators to apply some registry fixes to make everything well again.

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_MACHINE\SOFTWARE\Microsoft\Search 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 Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data

After updating the value, move to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HostControllerService. 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

Discuss this Blog Entry 4

on Aug 15, 2013

It's important to know that a mailbox database in a DAG will not failover if the content index is not healthy. This has a more far reaching impact than just eDiscovery not working.

Even after the mess is cleaned up, you will be unable to failover databases in a DAG until the CI is rebuilt. As you mentioned in your article, that can take a while.

The most troubling part of this is the fact that Microsoft did not test these updates in their Dogfood lab prior to release. Check out the details and comments in

on Aug 15, 2013

@expta, actually the -SkipClientExperienceChecks switch for the Move-ActiveMailboxDatabase cmdlet allows you to switchover a database with a bad content index to another copy. I used this method to switchover a database from a DAG member that had the bad MS13-061 update installed on it yesterday. It's not perfect, but it works. See (and see my commentary from today about the failure of Microsoft to test their code before deployment at

on Aug 15, 2013

And of course, EAC doesn't use the skip switches (there are a few) so it won't allow you to failover a database. This has to be done from EMS.

on Aug 15, 2013

You are correct. I should have written "you will be unable to automatically failover databases in a DAG until the CI is rebuilt."

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.


Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×