Exchange 2010 Service Pack 2 Upgrade Failed – FIXED!

17 02 2012


I was doing a spot of consultation recently. I received an urgent call about a serious issue a client was having with an attempted installation of Exchange 2010 Service Pack 2. What should have been a routine update quickly became a catastrophic failure of all Exchange related services causing major problems with all aspects of mail and mail access for the users.

I got on the scene and took a good look around. It’s a single site, single Exchange server, separate domain controller, all servers running Server 2008 R2. I documented all that appeared inconsistent and wrong against my reference machine, running a working version EX 2010 SP1.

As you’ll see, much of IIS was hosed and this is where the main thrust of the work was centred after determining whether or not SP2 had even installed correctly. What follows are my findings and my course of action over 3 days of concentrated diagnosis and troubleshooting to get them back online and to really try to get to the root cause of the issue so that we may learn from the lesson. At the expense of a short and punchy article, I’ve gone into much more granular detail of what happened. I feel, in this situation, more information is of greater value under the circumstances and certainly, the devil really is in the detail. In this case Exchange 2010 was installed on D:\ and this was originally a fresh installation of Exchange 2010 into the environment, not a migration from a previous version.


  • EMC down
  • Exchange Management Shell (EMS) down
  • Mail transport down
  • Did Service Pack 2 even install? Partially install? Or not install at all?
  • OWA down internally and externally
  • ActiveSync down
  • AutoDiscover down


  • A lot of the symptoms appeared to be centred on client access and IIS, notwithstanding a mailbox database in a “status unknown” state and multiple stopped services.
  • When I checked the Exchange Server setup log I discovered that the installation/application of SP2 had errored out because of a service problem. Here’s the excerpt from the log:

[02/12/2012 21:15:49.0269] [1] [ERROR] The following error was generated when “$error.Clear();

if (get-service MSExchangeServiceHost* | where {$ -eq “MSExchangeServiceHost”})


restart-service MSExchangeServiceHost


” was run: “Service ‘Microsoft Exchange Service Host (MSExchangeServiceHost)’ cannot be started due to the following error: Cannot start service MSExchangeServiceHost on computer ‘.’.”.

[02/12/2012 21:15:49.0269] [1] [ERROR] Service ‘Microsoft Exchange Service Host (MSExchangeServiceHost)’ cannot be started due to the following error: Cannot start service MSExchangeServiceHost on computer ‘.’.

[02/12/2012 21:15:49.0269] [1] [ERROR] Cannot start service MSExchangeServiceHost on computer ‘.’.

[02/12/2012 21:15:49.0269] [1] [ERROR] The service cannot be started, either because it is disabled or because it has no enabled devices associated with it

[02/12/2012 21:15:49.0270] [1] [ERROR-REFERENCE] Id=BridgeheadRoleSetterComponent___115c1108e99e4560bd2c03c0fec99908 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup

[02/12/2012 21:15:49.0270] [1] Setup is stopping now because of one or more critical errors.

[02/12/2012 21:15:49.0270] [1] Finished executing component tasks.

[02/12/2012 21:15:49.0321] [1] Ending processing Install-BridgeheadRole

[02/12/2012 22:19:30.0147] [0] End of Setup

[02/12/2012 22:19:30.0147] [0] **********************************************

  • When I got the EMC back up and running (see below) I could run the Exchange Best Practice Analyser and indeed there were Critical Issues. Client Access, Hub transport, Mailbox Roles showing not configured. BPA recommending run setup again.
  • Browsing to: 443 (https) in most all Exchange related virtual directories In IIS Manager, below the Default Web Site, produced errors and inconsistencies.
  • Testing connectivity to Active Sync from the Internet using Exchange Remote Connectivity Analyser produced multiple failures and errors.
  • Multiple 2280 errors in the Application Log from IIS-W3SVC-WP stating “The Module DLL D:Program Files\Microsoft\Exchange Server\V14\Client Access\OWA\auth\exppw.dll failed to load”.
  • Multiple 1310 warnings from APS.NET 2.0.50727.0 documenting configuration errors along the following application paths;
    • D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Sync
    • D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover
    • D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS
  • Multiple 5139 warnings in the System Log from WAS stating, “A listener channel for protocol ‘http’ in worker process ‘740’ serving application pool ‘DefaultAppPool’ reported a listener channel failure”.



  • When trying to open EMC I got:
    • “Initialization Failed” The following error occurred while attempting to connect to the specified exchange server ‘’: The attempt to connect to using “Kerberos” authentication failed: connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more info, see the about Troubleshooting help topic.
  • Multiple ‘red text’ errors when opening EMS. Apologies for the lack of detail here, I failed to get the screen grab.


  • Using a separate production Exchange 2010 server as a reference machine, I discovered the web.config file from D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell\ to be missing complete paths.
  • Over 200 path entries were displaying file:///%ExchangeInstallDir% compared to what it should read which is file:///D:\Program Files\Microsoft\Exchange Server\V14\ followed by bin\name of the DLL.
  • I replaced all those bad entries with the correct ones using MS Visual Studio.
  • EMC now throws a new “ConsoleInitialization.ps1” error stating;
    • “ConsoleInitialize.ps1″ is not recognized as the name of a cmdlet”.
  • ConsoleInitialization.ps1 should be located along the install path in the D:\Program Files\Microsoft\Exchange Server\V14\RemoteScripts folder. I discovered that my ConsoleInitialization.ps1 file had been renamed ConsoleInitialization.ps1.txt! I renamed it to .ps1 and after I waited a few minutes, I launched EMC and it opened up first time just fine. Along the way, I verified that MSExchangePowerShellAppPool was running under the correct “LocalSystem” identity in IIS Manager. Once into EMC, I was able to access and run an Exchange BPA Health Check as above. EMS was fixed too!



  • No mailflow
  • Outlook disconnected from Exchange
  • Mailbox database and Public Folder database status showing unknown
  • Microsoft Exchange Mail Submission service stopped
  • Microsoft Exchange Search Indexer stopped
  • Microsoft Exchange Replication service stopped


  • Start Microsoft Exchange Mail Submission service
    • Check EMC for mounted Mailbox database – mounted!
    • Outlook clients – connected!
    • Mailflow – working!


REMEMBER: Since 2007, whenever it comes to a Service Pack, it’s not going to install some updates or a patch. It completely uninstalls the previous version keeping the configuration and installs the new version. So what’s meant to happen here is the SP2 installer uninstalls SP1 and tries to install SP2. In this case, our BPA Health Check scan describes that for some reason, the SP2 installation was not completed for 3 roles; Mailbox, Client Access and Hub Transport.

ALSO REMEMBER: The first thing that happens when running SP2 setup is that the schema will be extended. In our case, we’re not sure if our installation was a success or not. A quick check of the configuration partition with ADSIEDIT on the DC will confirm this.

  • ADSIEdit > Connect to > Naming Context > Configuration
    • Configuration > CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=OrganizationName
    • If the schema has been extended for SP2, you should see CN=AddressBook Mailbox Policies. This was not here in earlier versions of Exchange. Ours is here, so we are confirmed on the schema update.


  • Do a Get-ExchangeServer | FL to check and verify;
    • AdminDisplayVersion: Version 14.2 (Build 247.5)
    • Server Role: Mailbox, ClientAccess, HubTransport.
    • The EMC is confirmed as showing the same Version 14.2 (Build 247.5) for all roles.

Clearly there’s something wrong because the shell output is saying its running SP2, yet the BPA Health Check scan says otherwise and IIS is broke! Let’s check the registry and the binaries.

  • Open up registry editor to check registry entries as follows
    • HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\MailboxRole
      • ConfiguredVersion is showing
      • UnpackedVersion is showing
  • HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\ClientAccessRole
    • ConfiguredVersion is showing
    • UnpackedVersion is showing
  • HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\HubTransportRole
    • UnpackedVersion is showing
    • There’s also a Watermark entry here too, meaning we may need to run SP2 setup again.
    • Check and verify the version numbers of the following binary files;
      • Store.exe:
      • Eseutil.exe:
      • Isinteg.exe:

The mailflow is working fine. We can see that the service pack upgraded successfully because the binary files show 14.2, however the registry was not modified. We can conclude that the BPA Health Check scan was displaying Critical Issues just because of these registry keys.

  • Just to be on the safe side, we’ll dismount the database and do a copy backup of both Mailbox DB and Public Folder DB .edb files. We’ll also export a backup copy of the registry for good measure before we proceed.
  • Now, we’re going to copy the unpacked version and paste it into the configured version leaving the watermark in the HubTransportRole registry key intact. Then let’s reboot the server.
  • When the server comes back, we’ll verify all MS Exchange and related services are started. All is good except our MS Exchange Service Indexer is not started and attempts to start it produced “Error 1068”. I checked its dependencies and discovered Microsoft Search (Exchange) was not started so I set it to “Manual” Startup type and started it. I could then successfully start the MS Exchange Search Indexer service.
  • I verified mailflow. All was good.
  • Mailbox, Client Access and Hub Transport were all showing the correct version 14.2 in EMC.
  • I checked the Configured Version vs. Unpacked Version numbers in the Registry as above and they matched for Mailbox and Client Access. However, the watermark was still present in the HubTransportRole key with an additional “Action” key and the versions did not match. I deleted the Watermark and Action keys and modified the Configured Version with the Unpacked Version. I rebooted the system.
  • The system came back, I verified mailflow. I ran a BPA Health Check Scan – NO CRITICAL ISSUES!



  • OWA errored out with “Server Error in ‘/owa’ Application”. Followed by;

<!– Web.Config-configurationfile –>



<customErrors mode=”Off”/>



  • Numerous 2280 error events in the Windows Application Log from IIS-W3SVC-WP as I mention in my initial findings. Further examination of the \OWA virtual directory Modules revealed that exppw was missing.
  • Multiple repeated 1310 warnings in the Application Log from APS.NET 2.0.50727.0 documenting configuration errors as follows;
    • Could not load file or assembly ‘Microsoft.Exchange.Security, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified. (D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\sync\web.config line 1601)
    • Could not load file or assembly ‘Microsoft.Exchange.Security, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified. (D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS\web.config line 2392)
    • Could not load file or assembly ‘Microsoft.Exchange.Security, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified. (D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover\web.config line 940)
  • Multiple 5139 warnings in the System Log from WAS, as above.


  • Let’s begin by tackling the 2280 Application Log errors i.e. the missing exppw registered module in IIS.
    • IIS Manager > servername\Sites\Default Web Site\owa > Modules  > Configure Native Modules
    • Check exppw > Ok
    • Module Type should be set to Native
    • Entry Type should be set to Local
    • CMD > iisreset
  • Now we’ll address the 1310 Application Log warnings. Knowing what we know already about bad file paths in web.config files, I started with an examination of web.config files for the other Exchange services and sure enough, they were bad. There is a web.config file for each and every virtual directory. The same bad path entries as before with web.config from the ClientAccess\PowerShell directory were persistent with all of the following:
    • ClientAccess\owa\web.config (supporting the owa virtual directory)
    • ClientAccess\sync\web.config  (supporting the Microsoft-Server-ActiveSync virtual directory)
    • ClientAccess\Autodiscover\web.config (supporting the Autodiscover virtual directory)
    • ClientAccess\ecp\web.config (supporting the ecp virtual directory)
    • And ClientAccess\exchweb\EWS\web.config (supporting the EWS virtual directory)

I began by running the same operation on all 5 web.config files, as we did for the PowerShell web.config file, and replaced those bad path entries as above.

  • After completion: CMD > iisreset
  • Browsing OWA and the Default Web Site :443 (https) from IIS Manager now produced a blank page.
  • Following on from the amendments to the web.config files, we’re now accompanied by 1105 and 1334 errors in the Application Log from MSExchange ActiveSync and ASP.NET respectively.
  • A check of the IIS > servername> Worker processes revealed missing processes;
    • We should have 6 running in total.
    • Part of the problem is that DefaultAppPool and MSExchangeOWAAppPool are missing.
    • After a refresh, DefaultAppPool comes in and stays in a starting state.
  • We need to get these worker Processes straightened out. Time to have a look at applicationHost.config from C:\Windows\System32\inetsrv\config\.
    • This file is the root file of the IIS configuration system. It defines Application Pools as well as all sites, applications, virtual directories and global defaults for the web server settings.
    • Check and verify that the following line is listed under globalModules:

<add name=”exppw” image=”D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll” />

  • Checked and verified.
  • Now we’ll take a backup and then remove the owa folder from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files.
  • Now let’s check the advanced properties of the DefaultAppPool in IIS Manager > servername> Application pools;
    • Check and verify the Identity under Process Model is set to LocalSystem > Ok
    • Refresh and check IIS > servername> Worker processes
      • DefaultAppPool – RUNNING!
      • MSExchangeOWAAppPool – RUNNING!
  • We still cannot browser OWA. It’s still taking us to a blank page.
  • Next, we’re going to reset the OWA virtual directory.
    • First, let’s take a backup of the IIS config.
    • Navigate to C:\Windows\System32\inetsrv and run the following command;
      • Appcmd add backup IISBACKUP
  • Next use EMC > Server Config > Client access > Reset Virtual Directory;
    • Browse to owa (Default Web Site), Next, Next, Reset
  • Next do a CMD > iisreset
  • Browse to OWA – WORKING! Internally and externally.
  • Verify login to OWA using the Domain Admin – all good
  • Verify login using other users – not working.
  • Other (standard) users are not able to login to OWA but the Domain Admin is. This points to a permissions issue on the server.
    • Check and verify permissions on the owa\auth virtual directory
      • Authenticated Users should have Traverse Folder / execute file permission.
      • On our server, Authenticated Users have only Read permission.
  • Change permission for Authenticated Users <not inherited> to Traverse Folder / execute file only.
    • Standard users still not able to login to OWA.
  • Explore to D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess and check security permissions
    • Add Authenticated Users with default permissions; Read & execute, List folder contents and Read.
  • Verify External and Internal URLs are present and correct and set Authentication to User name only in EMC
    • EMC > Server > Client Access > Outlook Web App > properties of owa (Default Web Site)
      • General
      • Authentication: User name only and set to logon domain.
  • CMD > iisreset
  • Test login to OWA with standard user with username only – WORKING!



  • iPhones not synching.
  • Testing connectivity to Active Sync from the Internet using Exchange Remote Connectivity Analyser produced multiple failures and errors.
  • Multiple 1105 and 1334 errors in the Application Log from MSExchange ActiveSync and ASP.NET respectively.


  • Verify Basic Authentication is the only enabled authenticating method under IIS > Default Web Site > Microsoft-Server-ActiveSync > Authentication.
  • Verify HTTP is not being redirected under IIS > Default Web Site > Microsoft-Server-ActiveSync > HTTP Redirect.
  • Verify that we’re getting an appropriate challenge when attempting to browse Microsoft-Server-ActiveSync and that HTTP Error 401.1 – Unauthorized is the response.
  • We’re now going to delete and re-create the Active Sync virtual directory.
    • First, we’ll backup the IIS config with CMD > Appcmd add backup IISBACKUP run from the C:\Windows\System32\inetsrv directory.
    • Second, we’ll reset the virtual directory, this time with the EMS
      • Remove-ActiveSyncVirtualDirectory -Identity “servername\Microsoft-Server-ActiveSync (Default Web Site)”
        • ‘Y’ to confirm
        • Verify with the virtual directory is gone from IIS with a quick refresh
      • New-ActiveSyncVirtualDirectory
        • Verify with the virtual directory is back in IIS again with a quick refresh
  • Test connectivity to Active Sync from the Internet using Exchange Remote Connectivity Analyser manually specifying the FQDN of the server.
    • Better results than before, but failing on a FolderSync command
  • Restart the IIS Admin Service.
  • Restart World Wide Web Publishing Service.
  • Check and verify in the Windows Application Event Viewer that the recurring 1105 and 1334 errors have STOPPED!
  • Verify External and Internal URLs are present and correct under EMC > Server > Client Access > Exchange ActiveSync > properties of Microsoft-Server-ActiveSync (Default Web Site).
  • Browsing to internal URL from internal client to Microsoft-Server-ActiveSync producing “503 Service Unavailable”.
  • Time to check the web.config file from D:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\sync
    • Paths entries are correct, something else is wrong with the file.
  • Time to restore web.config from the web.config.bak file. After we restore from the .bak file we must replace the bad file:///%ExchangeInstallDir% path entries that have restored along with it with the good file:///D:\Program Files\Microsoft\Exchange Server\V14\, just like we did earlier.
    • Move web.config file to the desktop.
    • Copy and paste a copy of web.config.bak located in the \sync folder to the \sync folder.
    • Rename web.config.bak to web.config.
    • Replace the bad paths with good ones using Notepad++.
  • Restart the IIS Admin Service.
  • Browsing to Microsoft-Server-ActiveSync via IIS Manager producing “503 Service Unavailable”.
  • A quick check of Application Pools in IIS Manager showed MSExchangeSyncAppPool not started.
    • Right-click MSExchangeSyncAppPool > Start
  • CMD > iisreset.
  • Browsing to Microsoft-Server-ActiveSync via IIS Manager now produced an appropriate challenge. The same is true from the Domain Controller and a client workstation.
  • Test connectivity to Active Sync from the Internet using Exchange Remote Connectivity Analyser manually specifying the FQDN of the server producing good results – FIXED!
  • Finally, a quick check on the client side confirmed that the iPhones were syncing again.


  • It’s worth re-iterating here that, according to my information, this happened because of an attempted upgrade from Service Pack 1 to Service Pack 2. It’s still not known for certain what truly caused the problems that led to the aftermath. I was informed that the person who performed the upgrade was advised by the installer to remove all server roles for IIS 6, which strikes me as weird. He did so before re-installing them. This was second hand information I gathered before I got involved and we’ll never know exactly what was done.
  • Antivirus – this is probably the most important lesson here. Symantec Endpoint Protection was installed on this machine prior to Service Pack 2. This may well have contributed to the cause. Antivirus software blocks Exchange from accessing the registry and its own files. It’s recommended to always use ‘Exchange aware’ antivirus. If not, then it may be possible to define exclusions to Exchange files. Check with the AV vendor.



26 responses

22 02 2012

Hi Highland,

First of all great post. It really saved me. I Followed it step by step, and it solved most of my problems. Unfortunately, the part of activesync still ain’t working. I’m still getting the events 1105 and 1334. After checking with MRCA I’m getting an error :

“Attempting the FolderSync command on the Exchange ActiveSync session.
The test of the FolderSync command failed.
Tell me more about this issue and how to resolve it

Additional Details
Exchange ActiveSync returned an HTTP 500 response.”

And MSExchangeSyncAppPool is getting to a stopped state.

Been trying to fix it, but still no luck 😦

22 02 2012
Stuart Le Fevre

Hello Barak,

Glad this was of use to you.

“Tell me more about this issue and how to resolve it”
You’re getting a FolderSync command failed because you do not have working MSExchangeSyncAppPool. Remember what an Application Pool actually is, it’s a set of ‘set-aside’ resources for a particular web application.

You’re still getting 1105 and 1334 errors. Assuming you do not have a good running Worker Process for MSExchangeSyncAppPool and assuming your applicationHost.config file is intact, verify that your Process Model > Identity is set to LocalSystem in the MSExchangeSyncAppPool advanced properties.

You may need to remove the microsoft-server-activesync folder from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files, taking care to back it up first. When I did this with my OWA directory along the same path, it re-created itself and, after an F5 refresh of the IIS server, I had 6 good Worker Processes. I could then reset the OWA virtual directory from EMC and, after an IISreset, I could browse to OWA. I’m just saying, if you follow the same logic with your microsoft-server-activesync folder, it may come back online. Also, if this happened as a result of an Exchnage Service Pack installation, get on the phone to Microsoft asap. They should help you for free.

Hope this helps.

22 02 2012

Hi Stuart,

I’m glad to see your reply. I’m also glad to say that I’ve managed to solve this issue in the last couple of minutes, before i saw your reply.

The solution:

Getting back to event log -> application, and still getting the event ids 1105 and 1334, I’ve noticed the following line:
“Please make sure the node, ” in the web.config file has a valid directory path. Mobile phones won’t be able to successfully connect to Exchange ActiveSync until this issue is resolved.”
After several retries, of recreating the activesync virtual folder, thinking i did something wrong, I got back to that line in the event 1105, and the schema cought my eyes.So I went to the web.config of the activesync virtual folder and searched for the string “SchemaDirectory”. The key value has you see in the next quotes is in the same format as you said needed to be replaced but without the “file:///” prefix:

So I changed it to full path, again without the “file:///” prefix:

After that I started the MSExchangeSyncAppPool in the IIS.
That did the trick.

I’m happy to say my server is up and running.

Again I would like to say thank you very much for you post.


22 02 2012
Stuart Le Fevre

Yes, you’re welcome. Glad you got it sorted.

How did it break originally? Did you install SP2 or something?


22 02 2012

Yes I upgraded to sp2. It was my second server upgrade. The first server was upgraded without any issues.

5 03 2012
Darren Kamnitzer

I just wanted to say, that I really appreciate it when techs post solutions to difficult problems. I upgraded my 2 Exchange 2010 servers to Sp2, and the main one had no problems. The second one, had all the problems exhibited in this article, and the step by step procedures fixed all of them. However, like Barak, my Sync still didn’t work until I found the same web.config issue he mentioned. Everything is great now. Thanks again!

6 03 2012
Stuart Le Fevre

Great Darren. Glad you got some value from this.

19 03 2012

I’ve tried to upgrade my Exchange server 2010 to my Exchange server 2010 SP2. Actually I forgot to prepare Active Directory and domains. Then upgrading halt at Hub Transport Role 45% and recovery also halting at the same place. So my exchange server is at the middle now (didn’t upgraded to SP2 and didn’t recover to original version). To use for the time being, I’ve to replace “file:///%ExchangeInstallDir%” with “file:///C:\Program Files\Microsoft\Exchange Server\V14\” as for workaround. I would be much appreciated if you could help me out.

19 03 2012
Stuart Le Fevre

Are you sure the Schema has not already been extended? If you tried to install SP 2 under the context of a member of the Schema Admins group, the installer should have prepped AD for you. Verify this with ADSI Edit on the DC.

Read again carefully through my post under the section SERVCIE PACK 2 INSTALLATION – SUCCESS OR FAIL.

You can force Exchange to start the installation from scratch by removing the watermark from the registry. Remember and do a reg backup first. Also, don’t be afraid to call MS on this since a service pack upgrade issue may be free.

20 03 2012

Hi Stuart,

CN=AddressBook Mailbox Policies is there. Get-ExchangeServer show “Version 14.0 (Build 639.21), ServerRole show “Mailbox, ClientAccess, UnifiedMessaging, HubTransport” and in EMC show “Version 14.0 (Build 639.21). Actually I did try re-run the recovery after removing Watermark but halting the same. Fortunately I did full VSS backup through Window Server Backup before SP2 upgrade. Can Exchange Application restore option restore back to previous version?

20 03 2012
Stuart Le Fevre

Ok, so you’re going from Exchange 2010 RTM to SP2.

Not sure what you mean by Exchange Application restore option Tin.

Cross-check your Get-ExchangeServer info against the versions of your Store.exe, Eseutil.exe and Isinteg.exe binaries and your registry keys per my post to determine to what extent your installation has failed (or not).

You’re original query was that you forgot to prep AD, so now we know something else is wrong. Take this info to MS as a service pack installation issue and they may assist free of charge. Good luck!

25 04 2012

Instead of searching for “How to install Exchange 2010 SP2 on Multiple Roles”, I started searching for “Exchange 2010 SP2 Upgrade Failed” which led me to here!

I don’t know how to express my feedback, but I can say one thing – it’s an excellent post! One of the best troubleshooting documentation that I ever seen before!

26 04 2012
Stuart Le Fevre

That’s excellent news. I’m glad my experience was of some use to you!

14 05 2012
Michal Svehla

Hi Stuart,

thank ou very much for your guide, you help me found way how to solve my broken SP2 installation. My situation was almost same like yours, same errors in event logs, but EMC still present SP1 version of Exchange – even I made your recomended changes in registry.

Finally I delete all keys related to unpacked version of Exchange and all watermarks keys and changed current version keys to SP1 ( after that I was ready to make recovery install ( /m:recoverserver) of SP2 and my server goes up.

Thank you again

15 05 2012
Stuart Le Fevre

Great Michal! Glad you got it fixed.

14 05 2012

Im stuck, where do I copy the unpacked version from and paste to where?

15 05 2012
Stuart Le Fevre

If, like mine, your ConfiguredVersion is showing and your UnpackedVersion is showing, then at this stage of the procedure, you would copy and paste the value data from Unpacked to Configured.

15 05 2012

Stuart, Great post. Just spent a whole week trying to get my setup to upgrade one of my mailbox servers to sp2. deleting and recreating the reg keys fixed it and now everything is working! Thanks again!

16 05 2012
Stuart Le Fevre

That’s cool Seb. Glad you found it helpful!

2 09 2012
Wayne Erratic

Hi Stuart, I had the exact same issue with the primary exchange server in one of our larger sites, using this guide I was able to fix these issues in 5 hours and have mail flow restored before users got to work. Interestingly my Exchange Transport Service would not startup. It was permissions to the registry keys diagnosed via the Event Viewer. Because of this article i was able to bring the exchange server back from the brink. I have never seen a solution documented so thoroughly. Keep up the great work!

25 09 2012
Stuart Le Fevre

Excellent news Wayne and thank you for you kind words!

10 10 2012

I have faced a similar issue today. The symptoms were that the ExchangePowerShellAppPool would crash everytime the Exchange PowerShell was started. This was eventually traced to the KerbAuth.dll file not being registered correctly. The module in IIS was pointing to the wrong location. Once this was corrected the whole system started working correctly.

3 11 2012
Matt P

Hi Stuart, awesome post, really saved by bacon after a 2010 SP2 installation advised it had completed successfully – apparently not all of it!
My issues were exactly the same, all but the more detailed active-sync problems as after I reset the directory permissions it was OK.

28 11 2012

This is my first time visit at here and i am genuinely happy to
read all at single place.

19 01 2013
Colin Slaughter

Excellent post. I also want to say that this post helped me solve a failed Exchange 2013 repair.

20 01 2013
Stuart Le Fevre

Awesome news. Glad I could be of some assistance.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: