Now Available: Updated Release of Exchange 2013 RTM CU2

Published Jul 29 2013 02:55 PM 32.2K Views

On July 12th, we announced that Exchange Server 2013 RTM CU2 contained an issue that could result in the loss of public folder permissions when the public folder mailbox is moved between Exchange 2013 databases. Initially, we indicated that an interim update (IU) would be available via Microsoft Support to resolve this issue. However, after receiving your feedback, we decided to generate a new build of Exchange 2013 RTM CU2 that includes the fix for the issue.

The new build number of Exchange 2013 RTM CU2 is 15.0.712.24. You can download the new build from the Download Center.

Installing/Upgrading to Exchange 2013 RTM CU2 (712.24)

As always, we recommend you test updates in a lab environment that closely mirrors your production environment prior to deploying in your production environment.

If you have not deployed Exchange 2013 RTM CU2, you can follow the steps outlined in the Upgrading/Deploying Cumulative Update 2 section in the Exchange 2013 RTM CU2 announcement article.

If you have already installed Exchange 2013 RTM CU2 (712.22), you can simply execute setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms from a command line to upgrade your servers to the 712.24 build; alternatively you can upgrade via the setup user interface. Attempting to uninstall the 712.22 build will result in the complete uninstall of the server and is not recommended.

Important: Regardless of whether you are using modern public folders, we strongly recommend upgrading to this build of Exchange 2013 RTM CU2. Any security updates released for CU2 will be dependent on this build.

We deeply regret the impact this updated release has on our customers and as always, we continue to identify ways to better serve your needs through our regular servicing releases.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Not applicable

"Any security updates released for CU2 will be dependent on this build."

Oy vey.

Not applicable

No schema changes since 712.22, correct?

Not applicable

Are there new UM language packs available for CU2 or do we just use the UM language packs from CU1?

Not applicable

Quick Lab Test shows that this also fixes my problem with lost root folder permission on mailbox moves in CU2 ( suspected it to be the same cause as the PF permission problems and seems to have been).

Guess i'll have to deploy this to production as soon as there is some free time on my schedule...

Thanks Exchange Team! IMHO you're doing a good job so far (especially since CU1)

Not applicable

Will the fix be included once again in CU3, or you have to re-run new CU2? I'm not using PF right now, but in case I would it good to know in the future


Not applicable

Frank P, there is no change in schema from 712.22

Greg, yes these fixes will be included in CU3.

Not applicable

Great.. this update fixed the problem in my lab!

Maybe on future posts.. someone can post a link to all previous product updates and their versions.. this would make it easier for us to update consistency and verification scripts..

Otherwise.. great update!


Not applicable

@Frank P. - Correct, there are no schema changes or AD preparatory changes between 712.22 and 712.24.

@da3246 - Our plan is to release the UM language packs later this week.

@Greg1.Greg2 - Anything included in CU2 will be included in CU3.


Not applicable

Keep in mind that the bug below is still present in the updated CU2, so you will have to reconfigure your virtual directories again if you've disabled FBA before.

"The FBA page is displayed when a user accesses OWA or ECP to log on to Exchange Server 2013"

Not applicable

I have two test servers with separated roles, CAS on server1 and MBX on server2. The newly released CU2 has been successfully installed on both servers (twice on the CAS just to make sure) but the AdminDisplayVersion was only updated on the MBX server. Is anyone else seeing this behavior?  Both servers were rebooted.

[PS] C:>Get-ExchangeServer mn* | FL Name,ServerRole,AdminDisp*

Name                : MNEX2

ServerRole          : Mailbox

AdminDisplayVersion : Version 15.0 (Build 712.24)

Name                : MNEX1

ServerRole          : ClientAccess

AdminDisplayVersion : Version 15.0 (Build 712.22)

Not applicable

Does this build provide a different transport agent interface from the one in the first CU2 build? I think you already know that the agent interface is breaking with every new build. It would be a disaster if two different CU2 builds had incompatible interfaces.

I am currently unable to immediately test this so I would appreciate if someone answers me.

Not applicable

@Mitch MN - I updated my dedicated CAS2013, dedicated MBX2013, and combination CAS2013/MBX2013 servers and all three now display AdminDisplayVersion : Version 15.0 (Build 712.24).

Not applicable

Guys, please provide an answer as to whether the issue as described in is fixed with this CU?

Not applicable

when will you fix the ler to lido bug?

it has been in exchange since exchange server 2010 sp2... still no fix?

i know its a Portuguese problem but it takes about 2 minutes of your time.


Not applicable

So, the news is another Microsoft Exchange update and another round of "fixing the bugs"?

Is this news or something? Every since the disaster that was Rollup 4 and 5 I thought releasing buggy CU code and expecting it to have problems and/or be recalled was simply the new modi operandi at Microsoft.

Did I get that wrong?

Not applicable

@Glibglob - This is an issue specifically with Outlook 2007.  There are no plans to address this issue from the Outlook side given that Outlook 2007 is no longer in mainstream support.


Not applicable

@DEVAXTATOR - This will be fixed in CU3.


Not applicable

Set localmachine to unrestricted and nothing else in Powershell Execution Policy otherwise this update will fail and break Exchange. The MS KB article is wrong.... again.

Not applicable

FYI: Applying this updated CU2 over a CU1 Exchange cleared the HTTP redirect settings we had in IIS.

Not applicable

we applied the new cu2 last night to our 3-node DAG.  mailflow completely stopped and transport (hub and frontend) kept reporting inconsistent/inactive in the event viewer, even though get-servercomponentstate shows active for everything.  reboots of all members seems to have kicked things into gear again, but only a few emails have trickled through so far.  loving it!

Not applicable

Any chance that the permission bug for the PF's that's fixed in v2 is also fixing the permission issue with forwarding external Calendar invites to others? re:  We weren't having this problem with our OnPrem server on CU1, but have been since CU2v1.

Not applicable

all indications so far is that the new and improved cu2 just ate 12 hours of email.  fabulous.

Not applicable

Hi Ross,

Just found this issue on the forums.


That article says - The new build number of Exchange 2013 RTM CU2 is 15.0.712.24

We have one Windows 2013 server with Mailbox and CAS on the same server.

Using the ecp - Exchange Admin Center   >   Servers,...we see  Mailbox, Client Access Version 15.0 ‎(Build 712.24)‎

We sent an email.

See this in the headers.

Received: from ... with Microsoft SMTP Server (TLS) id 15.0.712.24; Thu, 1 Aug 2013 09:01:10 -0400

Received: from  ... with mapi id 15.00.0712.012; Thu, 1 Aug 2013 09:01:09 -0400

The SMTP part says   15.0.712.24   ---  OK

The MAPI part says 15.00.0712.012      -- why "012" ?

Is that indicate a problem with the install,...or it is OK to proceed to production


What are your thoughts?

Not applicable

Installed CU2v2, same as v1, can't forward a Calendar meeting.  My users and myself get an [0x80070005-00000000-00000000] in the NDR.  In OWA, it at least tells you "Error: You don't have the permissions required to send messages from this mailbox. "

Not applicable

where is the tracking log explorer gui, cu3??

Not applicable

@Dame Luthas - This is not an issue.   Build numbers for specific components only change when changes are made.  So in that case the MAPI component was last changed in the .12 build.  


Not applicable

@Korbyn - the issue with forwarding the calendar meeting is a known issue and is targeted to be addressed in CU3.


Not applicable

@Ross - it's stuff like this that baffles me as to why the Microsoft group went to full installs of the CU's with no option to rollback.  I would be going back to CU1 right now if I could.  Users are pissed off as they're forwarding meeting invites all the time.  I'll be adopting a policy of only deploying CUn-1, and wait for everyone else to break their stuff.  Unfortunately if everyone starts doing that, we'll end up back here again.  Internally, isn't MS deploying these builds before they're released?  I'm sure MS staff are forwarding meetings all the time, or is MS not eating their own dog food anymore...

Not applicable

"Internally, isn't MS deploying these builds before they're released?  I'm sure MS staff are forwarding meetings all the time, or is MS not eating their own dog food anymore."

Ouch. Of course Microsoft installed and used the updates themselves before releasing the code to us. That's the "right" thing to do, so of course Microsoft did that. Nobody would be dumb enough to have their customers experience the update issue before they have had time to iron things out internally. Honda engineers and company employees actually drive the cars before they sell them. Of course Microsoft dog foods all of their own products. Ballmer probably has this exact same issue going on right now when he forwards calendar items too.

They have to be at least on CU1 right now because that is their mandated support model for other companies as well. Once the new CU is released, only it is supported and the previous version. That means RTM Exchange 13 is not supported anymore and nobody at Microsoft is still running it.

Exchange team, that's correct information, right? Someone back me up here.

Not applicable

Exchange 2013 continues to be a disappointment. Why is it that this public folder issue (which probably affects only a small percentage of users) results in a new CU2 build, whereas this calendar forwarding issue (which affects everyone and was already broken in CU1) will not be addressed until CU3? Moreover, you are strongly recommending even those who don't use public folders to upgrade our servers to this new build even when it offers no benefits whatsoever, only a waste of time, risk of something going wrong and again having to correct all the settings that go wrong in the upgrade.

Also, can you finally fix that damn Discovery Search Mailbox issue that has been plaguing us since 2010 (the one where you have to delete this mailbox before the upgrade or you will get an error).

Not applicable

Since installing CU2 I am getting daily server crashes as highlighted in the forums -

The only solution proposed is to disable the health monitoring service which seems to stop the crashes, but what I am loosing by doing that and any chance of fixing the issue?

Not applicable

@Adamf83, rather than disabling that service, try recreating the health mailbox.  You can safely delete and recreate health mailboxes. Be aware that any local Managed Availability probes that are using the these mailboxes will fail until the Microsoft Exchange Health Manager is restarted.  Once that service is restarted, it will recreate any mailboxes that it needs.  Hopefully that will resolve your issue.

Not applicable

per Gerard's comment, can we get an explanation as to why this PF issue warranted an entire new build (that we MUST install to even be supported!) and the calendar forwarding bug does not?

Not applicable

@Gerard/pesos, this Public Folder issue was security related due to possible accidental data disclosure and our Public Folder feature crew fully understood the issue and necessary code changes to fix it. Customer security and data health are one if our #1 priorities. While this may seem to be a low use feature to many enterprise customers right now it is actually a heavily used feature by hosting providers outside of O365 whom are utilizing Exchange 2013.

Not applicable

I installed two new servers (1x CAS & 1x MBX) with latest CU2 (build 15.0.712.24). Microsoft Exchange Health Manager service does not start automatically after reboot.

Event Viewer System log:

Event ID:      7000

Level:         Error


The Microsoft Exchange Health Manager service failed to start due to the following error:

The service did not respond to the start or control request in a timely fashion.

Event ID:      7009


A timeout was reached (30000 milliseconds) while waiting for the Microsoft Exchange Health Manager service to connect.

Event Xml:

No problem manually starting Microsoft Exchange Health Manager service. When you set the service to ‘Automatic (Delayed Start)’ it starts fine after each reboot.

See also:

I think MS should investigate this.

Not applicable


Can you please fix the Exchange 2013 issue described in this forum please :

It’s really problematic in production… CU2v2 don't fix anything related to this issue...

Not applicable

I've been extensively troubleshooting this for the last couple weeks and have not found information much online.  We have a single exchange 2013 server with outlook anywhere enabled, using externally and internally.  In designing this I initially used for both external and internal but that was causing all sorts of authentication problems.  After reading this article - I changed them to their current values and everything is operating smoothly other than public folders.  Internally on the EXCH provider autodiscover hands out the external hostname for public folders, I've set the internal and external url's for all the virtual directories and server value for the EXCH provider, in the xml for autodiscover it still hands out '<PublicFolderServer></PublicFolderServer>', yet still hands out the proper internal hostname for mail.  When I try to expand "All Public Folders" from any user, with any permission set, regardless of outlook client version, I see "Cannot expand the folder.  Microsoft Exchange is not available.  Either there are network problems or the exchange server is down for maintenance.  (/o=ORGNAME/ou=Exchange Administrative Group (FYDIBOHF232SPDLT)/cn-Configuration/cn=Servers/cn=<SOMEGUID>".  The GUID is different depending on the database the user's mailbox store is in, this leads me to believe that the old hostname is still lingering somewhere. I installed CU2 last week and after the first reboot public folders were working, but 5 minutes later they were not.  In an effort to get to resolve this I also found that one of the mailbox databases was not being indexed properly so I deleted the index, and the a full crawl of the DB was successful.  I've completely nuked the entire PF structure a couple times now and I still get the same error no matter what.  In my eyes this fix should be as simple as changing that value in the autodiscover.xml file, but it is not present.  Is this populating the xml from the object model or referencing the service connection point?  I have no autodiscover DNS records configured, only an mx record.

In the CAS logs I see:

rop::WrongServer+"Redirected: alternate server requested, suggested new server"

The other strange issue that has come out of the wood work in the last few days is rules are putting mail into completely random folders.  This started to happen right around the same time that I re-crawled the mailbox databases.

Not applicable

I know exchange 2013 hasn't been on the market that long but it really seems like an immature product, I find that I often have to reference 2010 information to troubleshoot this.  It seems like right after I enabled outlook anywhere, it all started going to crap.  The documentation on autodiscover DNS settings is really not informative, same with the info around exchange 2013 service accounts, I feel I may have a security issue lingering but with no documentation around how my service accounts should be established I don't really know where to continue troubleshooting.

Not applicable

Is Delegated rights working in CU2 v2? Is it an undocumented fix?

Currently "Send as ..." for new messages does not work at all for users migrated to 2013. Works fine in webmail.

Not applicable

Update regarding: Microsoft Exchange Health Manager service does not start automatically after reboot

Exchange Health Manager service has not been started after reboot with event viewer IDs 7000 & 7009. However, after some time (10-15 minutes), Exchange Health Manager service automatically starts. I've tested this with Windows 2012 & Exchange 2013 CUv2. So, this seems to be a (small) issue.

Not applicable

How Exchange 2013 became RTM with all these enormous issues, even still after CU2v2 is beyond me.  Ball = dropped.

Not applicable

Any change there will be a hotfix for the forwarding/Calendar meeting issue? [0x80070005-00000000-00000000] in the NDR.  Or do we have a tentative date on when CU3 will be released?

Not applicable

@Briam (and others), if you are impacted by any particular issue I strongly suggest opening a case with support. This is one of the ways we can (let us assume it is a true code defect) judge the impact of a particular issue and help triage if/when different it should be fixed compared with others we may already be working on. If one person opens a case and then everyone they talk to on Internet message boards sits back and waits to see the outcome it does not provide us with the same data if everyone impacted were to open a case. Leaving comments on this blog is nice and we certainly read all of them, but it does not provide us the full impact view if you were to open a support case. With a case we gather/track additional data linked back to the same issue such as affected customers, seats affected, etc... to help triage against the other work items.

Regarding the meeting forwards item Briam mentions, I would not expect a public hotfix. The Exchange 2013 servicing model only releases Cumulative Updates (on roughly a quarterly basis) and stand-alone security updates. This particular item would not fall under the security update category.

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


btw, we did open a case with MS support. The first one resulted in a no-charge bug find for the move mailbox issues. The POP issue took 3 MS engineers over 8 hours to finally find, and again we weren't charged due to it being classified as a bug. The redirect and other issues we spent hours looking for on the Internet and asking peers and the methods (ex. delete the web.config?) seem really outlandish.

I'd say at least 24 hours were wasted trying to resolve bugs. We put in 2 calls to Microsoft PSS in order to fix bugs. The customer still isn't completely satisfied, but that's mostly because they hate the look and feel of OWA. The end-users are telling management they feel it's a step backwards from Exchange 2007. Crazy.

Not applicable


After I apply CU2 not I'm in trouble.

Accessed the EAC Permissions admin roles edit "Recipient Management" Roles + "Reset Password" and Save.

After adding the role "Reset Password" and Save the seguente message appeared:


You do not have access to create, change, or remove the "Reset Password-Recipient Management" management role assignment. You must be assigned the delegating role assignment to the management role or its parent in the hierarchy without a scope restriction. "

I tested in a staging environment that is not with CU and cosigo add this Role normally.

Is that a problem?

Not applicable


I'm having trouble installing CU2 on 2 servers MBX, only those others successfully installed

when I click on the setup of the CU it does not appear the console startup CU2 seems that sits in the background and does not display the console unique event that appears is:

Log Name:      Application

Source:        Windows Error Reporting

Date:          19/08/2013 16:22:04

Event ID:      1001

Task Category: None

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      ucb-mail03.IASD.ORG


Fault bucket -565208806, type 5

Event Name: E12

Response: Not available

Cab Id: 0

Problem signature:

P1: c-RTL-AMD64

P2: 15.00.0712.017

P3: ExSetupUI

P4: ExSetupUI

P5: M.E.S.E.SetupWizard.PopulateWizard

P6: M.E.S.ExSetupUI.AssemblyLoadFileNotFoundException

P7: a60d

P8: 15.00.0712.017



Attached files:





These files may be available here:


Analysis symbol:

Rechecking for solution: 0

Report Id: 9ff645a1-0904-11e3-940b-00155d1401bc

Report Status: 0

Hashed bucket: 2ba6fcf45e51a3cf74510a728c350384

Event Xml:

<Event xmlns="">


   <Provider Name="Windows Error Reporting" />

   <EventID Qualifiers="0">1001</EventID>




   <TimeCreated SystemTime="2013-08-19T19:22:04.000000000Z" />




   <Security />






   <Data>Not available</Data>




























Any suggestion?


Leonardo Almeida

Not applicable

Finally found out the solution to allowing Exchange 2007 to receive e-mail from Exchange 2013.

Apparently there is another bug that requires you to create new receive connectors in order for the communication to work between 2013 and 2007. The default connectors won't work right "out of the box" anymore.

Not applicable


Another error.

[08/21/2013 18:42:45.0812] [0] Starting Microsoft Exchange Server 2013 Cumulative Update 2 Setup

[08/21/2013 18:42:45.0812] [0] **********************************************

[08/21/2013 18:42:45.0815] [0] Local time zone: (UTC-03:00) Brasilia.

[08/21/2013 18:42:45.0815] [0] Operating system version: Microsoft Windows NT 6.2.9200.0.

[08/21/2013 18:42:45.0819] [0] Setup version: 15.0.712.24.

[08/21/2013 18:42:45.0822] [0] Logged on user: IASDucbadmin.

[08/21/2013 18:42:45.0940] [0] Command Line Parameter Name='sourcedir', Value='C:UsersucbadminDesktopuc2'.

[08/21/2013 18:42:45.0940] [0] Command Line Parameter Name='mode', Value='Upgrade'.

[08/21/2013 18:42:45.0975] [0] RuntimeAssembly was started with the following command: '/sourcedir:C:UsersucbadminDesktopuc2 /mode:Upgrade'.

[08/21/2013 18:42:47.0212] [0] The following roles are installed: BridgeheadRole ClientAccessRole UnifiedMessagingRole AdminToolsRole

[08/21/2013 18:42:47.0432] [0] [ERROR] The system cannot find the file specified. (Exception from HRESULT: 0x80070002)

[08/21/2013 18:42:47.0434] [0] Unable to load assembly from file C:WindowsTempExchangeSetupMicrosoft.Exchange.Setup.GUI.dll using setup arguments /sourcedir:C:UsersucbadminDesktopuc2./mode:Upgrade, source directory is C:UsersucbadminDesktopuc2, target directory is C:WindowsTempExchangeSetup and Exchange is installed True.

Any Suggestion?


Leonardo Almeida

Not applicable

I followed official migration documentation and pre-created .csv file and Public Folder mailboxes on Ex13 side. After I initiate New-PublicFolderMigrationRecuest (command line also form documentation) I received following error:

Couldn't connect to the target mailbox.

    + CategoryInfo          : NotSpecified: (:) [New-PublicFolderMigrationRequest], RemoteTransientException

    + FullyQualifiedErrorId : [Server=SERVER,RequestId=2cb57218-5814-40ec-b25f-4cc1dbe3662d,TimeStamp=8/25/2013 4:06:

   55 PM] AC30D5DA,Microsoft.Exchange.Management.RecipientTasks.NewPublicFolderMigrationRequest

    + PSComputerName        : SERVER.domain

I'm using custom public folder mailbox names, not "Mailbox1", "Mailbox2" as in examples, does it present any issues?

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