Blog: Exchange 2013

A few months ago, I installed the latest Exchange 2013 Cumulative Update that was available (CU14) on the Exchange cluster. Shortly after everything was brought back online, I noticed that the Content Index state was marked as failed. Trying to re-seed the content index from another database server wasn’t working either. I tried going through the process to completely rebuild the content index (stop the Exchange search services, delete the content index folder, restart the services) and it seemed to work as the crawling process took 12-16+ hours.

Unfortunately, it never did finish. I kept seeing errors in the event log that made it seem like crawling would finish, but there was a final process that continued to fail time and time again. The Exchange search services would crash constantly, restart, and crash once more – each time failing to bring the content index online.

It turns out that this was a known issue with Microsoft Exchange 2013 CU14 (as well as Exchange 2016 CU3). Microsoft has committed to providing the fix in the next CU, but until then there wasn’t really a workaround. The biggest impact this failure had was that searching public folders was a lot more difficult. You could go through the Advanced Find features and do a search that didn’t access the index, but the instant searches would fail to find anything.

CU15 was released in December and resolves this particular issue (among other issues that may have popped up in the last 3 months).




Exchange users could connect to their mailboxes (OWA and Outlook), but any attempt to send email resulted in the message being stuck in the Drafts folder (when using OWA) and the Outbox (when using Outlook). The Exchange submission service would never see the email and attempt to send it. All users could receive email without any issues. The most common reasons for this type of problems are DNS, IPv6, and firewall. However, all of these were investigated extensively and no issues were found. The issue was resolved by unmounting the Exchange database, restarting the Microsoft Information Store service, and remounting the Exchange database. Afterwards, all email in user mailboxes that was “stuck” was queued for delivery.


If the Active Directory security groups that are created during the initial install of Exchange 2013 get removed unintentionally, they can be recreated by running the setup /prepareAD command. This is pretty well documented, but be sure to use the setup files from the most recent version of Exchange installed in the environment. If the Exchange environment is made up of mixed builds, always use the most up-to-date build for running the setup /prepareAD command. Cumulative update builds count as well, not just service packs.