News Stay informed about the latest enterprise technology news and product updates.

Microsoft pulls Exchange update, testing processes in question

After identifying an issue with Exchange 2013, Microsoft pulled a security update. The company's quarterly update schedule is now in jeopardy.

Microsoft has backtracked on a critical update in the latest Patch Tuesday fixes after not testing the update in its own environment before its release.

The company said it became aware of the problem in security update MS13-061, an update for Exchange Server 2013, the evening that August's Patch Tuesday updates were released.

When installing the update, customers reported problems with the Search Host Controller service and the mailbox databases Content Index. This issue rears its head for end users when accessing mail via the Office Web App (OWA) on servers running Exchange 2013. Because Outlook caches search on the desktop, desktop Outlook users wouldn't see the problem.   

"Unfortunately, this security update did not get deployed into our dogfood environment prior to release," Microsoft said in a blog post addressing the problem.

"It's the latest in a long line of cock-ups," said Tony Redmond, an Exchange MVP based in Ireland.

Noting that Microsoft had promised a refined servicing model for Exchange 2013, Redmond said "it fell flat on its face."

One security expert expressed concern about how IT will react going forward.

"Each time a patch breaks something, it gives IT a reason to pause and say 'should I really go that quickly?'" said Wolfgang Kandek, CTO at Redwood Shores, Calif.-based IT security firm Qualys Inc.

But Kandek said delaying can mean disaster for IT as some holes in software can be quickly exploited.

Microsoft said it would delay the Exchange 2013 RTM CU3 release to make sure there will be plenty of time to test it in a dogfood environment, signaling that the quarterly cadence for Exchange updates is in jeopardy.

"It's in doubt because they simply can't test," said Redmond.

The company also said all future patches will be deployed in its own environment before they are released.  

Microsoft recommends that admins not install MS13-061. If admins have already installed the update, the company posted a workaround in which admins can update the affected registry in Exchange Server 2013.

"I hope Microsoft will come out with a good post-mortem, explaining exactly what happened," said Kandek.

The update rollup doesn't affect Exchange 2007 or Exchange 2010 because they have a different indexing architecture. The rollup also doesn't apply to Exchange Online.

The issue also did not impact Exchange Online because it does not deploy .msp patches into the environment. Instead, the cloud version of Exchange deploys new full builds of the product on a regular release cadence.

Dig Deeper on Exchange Server setup and troubleshooting

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I'm not surprised that something fell through the cracks. Everyone is pushing to meet deadlines or new target date releases. Quality control fails to do proper testing and the company suffers and so do the end users. I know as a programmer sometimes it's the simple 1 or 2 line fix we put in without testing, that we think can't go wrong, usually causes a problem. It may be a black-eye for Microsoft in this case but I'm glad they fessed up to it. A little damage control never hurts.
Although this story was published over a year ago, I couldn't help but think of it last week when Microsoft said it would delay this month's Patch Tuesday security update for Exchange Server vulnerabilities because of problems that appeared after the update's installation:

Do you think pulling problematic updates before they're released instead of pulling them after they're released is a sign of what Microsoft plans to do in the future?
I feel that pulling them before they can be exploited is the best. If it is made public then they try and pull it, it comes down to timing. How how have systems been vulnerable to the exploit before we can resolve the "patch" issue.