Exchange 2013 Security Update MS13-061 Status Update

Published Aug 14 2013 09:41 AM 26.7K Views

Late last night we became aware of an issue with MS13-061 security update for Exchange Server 2013. Specifically, after the installation of the security update, the Content Index for mailbox databases shows as Failed and the Microsoft Exchange Search Host Controller service is renamed.

For those that have already installed the MS13-061 security update for Exchange Server 2013, we already have KB 2879739 that provides the steps on how to resolve this issue. However, due to this issue and that it affects all Mailbox server installations, we have decided to pull the MS13-061 security update temporarily.

Note: This issue does not occur in Exchange 2010 or Exchange 2007. You can proceed with testing and deploying Exchange 2007 SP3 RU11, Exchange 2010 SP2 RU7, and Exchange 2010 SP3 RU2.


If you have already installed MS13-061 security update on your Exchange 2013 servers, we recommend following the steps in KB 2879739 to resolve the issue.

If you have not installed MS13-061 security update on your Exchange 2013 servers, we recommend not proceeding with the update at this time. To mitigate the security vulnerability, we recommend following the workaround steps identified in the Vulnerability Information – Oracle Outside in Contains Multiple Exploitable Vulnerabilities section in Microsoft Security Bulletin MS13-061.


Q: What is the impact of this security vulnerability?

A: Please see the information contained within the MS13-061 Security Bulletin.

Q: I am about to upgrade from CU1 to CU2, will I be affected?

A: No, this issue does not occur when upgrading to a cumulative update. This issue only occurs when patching a .msi installation via a .msp file.

Q: Why does this issue occur with installing a .msp file?

A: During the Exchange 2013 installation (.msi installation), the service is created, the Data Folder Location registry key is created and during a post configuration step, the registry key is populated with data and the service name is rebranded. During the .msp installation, these settings are reverted back to their original installation values prior to the post-configuration step.

Q: If I follow the steps identified in the workaround, will I have issues in the future?

A: Following the steps identified in KB 2879739 will resolve the issue and not cause any future problems.

Q: What happens if I uninstall the security update?

A: You will need to follow the steps identified in KB 2879739, otherwise your search infrastructure will be broken.

Q: Why didn’t you recall the update rollups for Exchange 2010 and Exchange 2007?

A: Both Exchange 2010 and Exchange 2007 utilize a different indexing architecture and, as a result, are not impacted.

Q: How was this issue not detected in Exchange Online if Exchange Online is always receiving fixes before on-premises customers?

A: Exchange Online does not deploy .msp patches into the environment; instead, Exchange Online deploys new full builds of the product (cumulative updates, if you will) on a regular release cadence. As a result, Exchange Online was not impacted by this issue.

Q: How was this issue not detected in your on-premises deployments?

A: Unfortunately, this security update did not get deployed into our dogfood environment prior to release.

Q: You have told us time and time again that you were going to improve your testing procedures, and yet each time you have to tell us that you missed something. When will it end?

A: We will work very hard to regain your trust and confidence. With that said, we have recently made the decision to delay the release of Exchange 2013 RTM CU3 by several weeks to ensure that we have enough run time testing within our dogfood environment. Also, we will ensure that all patches are deployed in our dogfood environment prior to release going forward.

We will continue to make improvements in our release cadence and testing methodologies over time to ferret out these issues. These changes may mean that our once a quarter release cadence for Exchange 2013 may change.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Not applicable

If I may start trolling: not impressed at all..

Not applicable

Saved again by not installing patches right away...

Not applicable

Here we go again & again & again.

QA guys at Microsoft are sleeping in the Cloud.

Come on guys focus on giving your Exchange On-Premises customers good patches.

Not applicable

@Bob On-Prem Customers = 2nd Class Citizens

Not applicable

I can understand producing updates can be complex but you introduced these measures to improve quality, you're not following them and you're letting us down! It's really disappointing, and leaves us wondering what real mileage there is left in MS Exchange On-Premises as you don't really seem to want us as customers. Obviously you want us to move to your cloud, but we don't want to do that!

Not applicable

Just to clarify ? is Office 365 vulnerable to this exploit or was it patched ?

Not applicable

I'm seriously losing faith in your ability to deliver a stable ready-for-production product.  There are no excuses anymore for this kind of quality.

I am embarrassed for you.

Not applicable

If we're using FOPE/EOP, is it protecting us against this threat?

Not applicable

Q: How was this issue not detected in your on-premises deployments?

A: Unfortunately, this security update did not get deployed into our dogfood environment prior to release.

Blah, blah, blah.........blah, blah.

Not applicable

It's almost like On Premise customers of Microsoft's products are becoming the equivalent of food tasters for the King.

Not applicable

And what about this statement from Brian in the comments section of the CU2 security update/RU2 update blog post:

Steve Mossberg 13 Aug 2013 11:45 AM #

Brian, are these CU's/RU's getting tested? It appears that new bugs are created with each new fix. We are almost better off not apply the fixes. Any comments?

Brian Day [MSFT] 13 Aug 2013 11:49 AM #

@Steve, no we blindly release code and let you test it for us. ;) j/k I will defer to the last few Q&A bullets in Ross' previous article here for commentary on testing. Short answer is, absolutely we do.


This is in contradiction - to say the least - to the acknowledgement in the Q&A above that the fix wasn't tested in MS's own environment....

Not applicable

Oh dear. I was toying with the idea of installing the update on all my servers last night but changed my mind. I'm glad I waited!

Not applicable

Appreciate the honesty, but as Frank points out this blatantly contradicts Brian's Day from Microsoft's comment from the other blog post.

Not applicable

After the NSA PRISM news companies in the US & outside of the US are NOT going to the Public Cloud.

So let's all focus on the Exchange 2013 On-Premises with GOOD patches, come on Microsoft.............

Not applicable

Good hell. ANOTHER UPDATE gets pulled? How many is this now? 4v1, then it was 4v2, then it was 4v3. 5v1 then it was 5v2. CU2 was pulled. Now critical updates are being pulled? I'm sure I'm missing others. You're just now working to regain our trust and confidence? You've been constantly blundering updates for the past 6 months now.

Not applicable

These things seems to happen very often, especially to Exchange and SharePoint product teams ... it is really disheartening ... we started patching only the most extremely critical holes ... if Microsoft cannot properly test updates/upgrades with all of it's resources, how can it really be expected that we can test them enough before deploying?

Not applicable

I stopped patching a year ago, after Ex2010 SP2 RU4 there were so many bugs ... I haven't got the time and the infrastructure to test everything. our environment has to be stable. thats the most important thing!

Not applicable

Microsoft should STOP imitating Apple and it's products and should focus again on the business consumers!

We want stable and reliable software solutions (like Exchange Server used to be between 2000 and 2009) and not pseudo cool and hip products which run like an old, beat up car.

Not applicable

@Frank, yup I certainly am owed a plate of crow to eat on that comment. It's as of Mr. Murphy himself came down and struck me. Feel free to swing by and harass me at MEC for it. I am both embarrassed and shocked to see what transpired here in this particular situation.

Not applicable


I suggest that you follow vendor recommendation and apply  this fix in your dogfood system as described in:

“For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software …”

With one modification if I may … “You should test it on non-production system first”.

It seems that there is a fundamental flaw in the process as this “tiny” patch in no way should result in such a mess. Also, I understand that CU approach is under review. Yes pushing on prem customers to update every 12 weeks is not such a great idea after all.

In my opinion for all on prem, unless you have no choice stay with what works, or go to Office365 and relax.

Not applicable

I'd like to know all the names of the managers you plan to fire that did not direct their staff to run this fix through your test environment.

Not applicable

Things just happened. Hope the Exchange 2007/2010 patch will be good enough....

Not applicable

Yeah, right.  MEC = the Microsoft Excuses Conference.

Not applicable


Yes they do ...

The Difference Between Confidence and Arrogance is ...... ?

Not applicable

Sorry to say, but what are your engineers up to ? Ross you look like a Lion leading a pack of donkeys.  

Not applicable

I agree with most of the negative comments especially the one about on-premise customers.  We're still considered customers right?

Not applicable

Thank you for being honest and we really do appreciate your team's hard work.

But just want to say that over the years we've been conditioned, as Exchange admins, to sit back and wait a few days/weeks before installing RU's because there's a very good chance the RU will break something major.  Hopefully you guys will take the lessons learned from all the "RU v2" incidents and up your game.

Not applicable

Pretty sure they are currently spending 50% of their time in "lessons learned" meetings...

Not applicable

I'm also getting this: MSExchangeFastSearch event id 1010. No connection could be made because the target machine actively refused it  ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

Cant' activate passive databases any more....

Not applicable

On one hand we need to always update to the latest CU or service pack in order to maintain our support with Microsoft. However, all of the recent patches break things. For example, the latest CU2 patch appears to have broken OWA redirects and password resets in addition to a whole host of other bugs we are finding. Pulling the previous patch due to PF issues and then less than a week later another show-stopping bug. It's madness. Simply madness. And now we find out that Microsoft doesn't even test the patches internally first. Not even critical ones. Get out of town.

1.Is there a change planned to the upgrade cycle where we can have more time to test and iron out all these bugs? This forced N-1 upgrade support is just not sustainable with the amount of shoddy patches being released. We can't update our servers every quarter and watch things break.

2. Since TechNet is going away, how can we continue to test Exchange without having to pay over 6000? The free and/or online labs don't include Exchange 2003 or 2007 and you can't download them anymore, which is most of what my customers are upgrading from. We also cannot test any complicated scenarios. We can't even test forest trusts and certificates.So, how does the Exchange team envision people deploying Exchange if we can't download and test the software adequately?


Not applicable

@B. Barnes, you are not required to be on the N or N-1 CU to be in a supported Exchange 2013 configuration. We will support older CUs, but for example we may issue an individual security update for CUs older than that. The wording used in the original Exchange 2013 servicing model blog article could have been clearer in that regard.

Not applicable

I'm missing a 'not' in the above comment. It should have said "...but for example we may not issue an individual security update for CUs older than that."

Not applicable


Thanks for responding. Let me say that your messages aren't coming through clear at all. I was told by a MS representative that only the latest (CU2) and the previous version (Cu1) were supported. If a customer was running RTM, then as soon as CU2 was released, that customer was required to upgrade. You are telling me something completely different. It's not just the blog that is confused or your own customers, it's also your own internal staff as well. So, what exactly is supported now and what isn't? Is there a proper link?

I would also appreciate it if you could address my TechNet retirement concerns as well. What does the Exchange team plan on doing for their Exchange certified administrators in order to enable them to continue to support migration and other efforts? The new solutions proposed by the TechNet team are inadequate, do not include previous sw, or are too costly to maintain. Perhaps you could address our concerns in a follow up blog post?


Not applicable

I hope M$ provides free support to resolve fallout from batch security updates.

Not applicable

@B. Barnes, feel free to send any MS employee telling you that my way. My alias is brianday for them to find me. I am not familiar enough with the current TechNet situation and what we have available for labs so I'll withhold comment for now.

Not applicable

Does this affect exchange 2003 on premises customers?

(you never know that's why I'm asking:))

Not applicable

too bad cause exchange is a great product seriously

but its starting to "fail" like a good German car with lousy service

Not applicable

Per the KB/security bulletin, Exchange 2003 does not have the outsidein code and thus is not impacted

Not applicable

B. Barnes is right, only CU1 and CU2 (aka n-1 and n) are in support.  There's no patch for Exchange 2013 RTM for example.  If you are on RTM you must upgrade to at least CU1 in order to install this security update.  

Not applicable

@So now I'm confused, that falls in line exactly with the process I mention above. We may not issue security updates for more than N-1 back (which is RTM in this case), but the code is still _very_ much supported. If you were to call support for RTM they would certainly work with you and not force you to upgrade to CU1 to troubleshoot an issue. They may however suggest you upgrade if the issue you called in about is a known-fix in an already released CU. If however you felt a certain security update released for N or N-1 was something you need, then at that point you would need to upgrade to at least N-1. Being under 'supported' does not mean the same thing as a guarantee for patches to be released. We still support Exchange Server 2003 SP2, but there have been no new updates for it in a long time.

Not applicable


So since security updates are only released for N and N-1 code, then by default we can't run Exchange code older than that. We cannot present to our management that we have no ability to deal with security updates. Therefore in order to run Exchange in-house,

we are now limited to the current version and one version back. We're forced to upgrade everything at least twice a year if not sooner. This appears to be the only way to be in "best practice".

I'm still very much confused as to what we need to do in order to be successful. It seems like we are being offered a catch-22. We either deal with no security updates or we are forced to update to buggy and unproven (remember, MS isn't even testing this

code now themselves) code base?

If you are not familiar with the TechNet issue, please let me enlighten you. Over 9300 admins have signed this petition. You should read the comments as it will affect all of Microsoft's Exchange administrators.


Not applicable

sometimes I ask myself

who are these creatures:)

it was a joke:)

guess I shouldn't leave my day job eh


Exchange2003 not impacted  

16 Aug 2013 1:10 PM


Per the KB/security bulletin, Exchange 2003 does not have the outsidein code and thus is not impacted


Not applicable

Support for earlier version of CUs and Exchange is there, just be prepared to update if your issue requires that you apply CU in order to solve it. As far as what Microsoft partners are saying ... well this is another topic. They seem to be confused with fundamentals ... Before you listen to any use your search engine ...

We seem to confuse functionality and security. You can have functional product that is not secure and I think this is what Brian is telling us here. Many customers already sacrificed security for functionality and stability. What good is secure system that is at risk every 3 months. This is why we have so many still running Exchange 2003, Office 2003 and Windows XP, or people stop applying patches, or use 3rd party product to secure Exchange. If you have LOB application that requires Exchange you are left with no choice really.

Few years ago I remember the notion of slowing down development and focusing on security and quality … I cannot speak for all IT Pros, but let us focus on security and Microsoft can focus on quality of the product. If you published documentation of changes/updates/enhancements like IBM does for Domino Fix Packs many of the problems could be potentially avoided.

Personally I don’t even understand why we complain … what other options we have?

Not applicable

@B. Barnes:

I'm glad someone else is having issues with the OWA redirects in CU2 as I had a support ticket open with MS for nearly 3 weeks with that issue without it being resolved, in our case it affected the redirect to mailboxes on Office 365. In the end as I had students coming back on Campus I installed all new exchange servers with CU1, migrated all of the mailboxes to the CU1 servers and removed the CU2 servers.

The guys asked me for a heap of logs off the upgrade servers despite the fact I did a brand new installation in a new forrest directly with CU2 and had exactly the same problem so it wasn't related to the upgrade.

Fortunately the loss of Technet trials for testing isn't an issue for me as were an educational institution with MSDN as well but it was clearly poorly thought out.

Jas :)

Not applicable

Had a lot of issues with the latest update. After installing CU2 on an RTM Exchange 2013 system:

1. The POP service was sending out the wrong certificate. As crazy as that sounds, POP clients were getting the NetBIOS name of the cert rather than the certificate that was assigned the "P" services. Had to =$null the server certificate and edit the ehlo response of the pop service in order to assign the correct cert. This was working fine in RTM and broke in CU2.

2. OWA redirects broke. I believe we now have to manually delete the web.config file and re-set the redirects. That seemed to fix it. Hopefully there is a better answer.

3. The move-mailbox process introduced a new bug. You have to edit the conf file for the migration parameters to avoid processing delays. Someone set the default to timeout 480 times (each timeout taking 2-3 minutes). You have to set this value to 1.

4. During the move process we had to manually verify the log status of each move due to Exchange 2013 not cleaning up the source Exchange 2007 mailbox correctly. Fortunately the log showed that the AD switched correct, so we just cleared the move request for those users manually.

5. Once the update installed, we never could get Exchange 2013 to ever send back to Exchange 2007. We ended up doing a cutover migration of the mailboxes and the mX at the same time. Never did resolve that issue.

6. The public folder replication, of course, had problems. The PF migration always seems to have problems. We ended up just manually exporting and re-importing via the Outlook client.

7. Delegate automatic mailbox assignment appears to have stopped working. The clients do not automatically assign the mailboxes in the Outlook pane after ~60 minutes. Manually adding the mailbox appears to work.

8. Troubleshooting was made very difficult in some cases due to Microsoft now integrating ipv6 into their client, transport, and storage layers. Breaking the standard TCP/IP and/or ISO models really makes troubleshooting IP/NS issues much, much tougher.

There were other various minor issues.

Some questions:

a. The users hate the look and feel of the new OWA. They complain about the whiteness, non-3d look, and general lack of customizability. Adding a little row of "theme" across the top is not sufficient. Is there additional themes and/or color choices planned? Is that coming in SP1 or before?

b. The ECP appears pretty stark and lacks a number of critical features that must be done via PS. The admins really felt it was" a step backward" to go to Exchange 2013 from 2007. Their words. They also felt the ECP wasted half the space on the screen and was "way too white" as well as the OWA. Is the ECP going to be enhanced?

c. Where did all the cool neat GUI tools that were in the old Toolbox go and where is the BPA now? Are they ever coming back to Exchange 2013?



          - S....

Not applicable

Please see my article about fixing OWA redirects.

Not applicable

Guys, could you please take a look at ? It's not related to this article, but I'd appreciate a comment from a developer.

Not applicable

@Evgeniy, that does not appear to be a valid local portion of the SMTP address format. I'll respond more in your thread.

Not applicable

"In the Exchange world, this means that we deploy extremely early version of Exchange in production starting with a few mailboxes, hundreds of mailboxes, then working with MSIT to move thousands of mailboxes - and eventually deploying to the entire company."

Whoops, looks like you don't do what you preach.

Not applicable

I would like a clear explanation of why Microsoft is now not testing software before releasing it to the public.

This revelation is complete and utter bullshit and I think heads should roll.

Version history
Last update:
‎Jul 01 2019 04:14 PM
Updated by: