Recently, I was upgrading an Exchange 2010 environment to Service Pack 3. I ran into a slew of different errors.
Five in fact.
Every time I fixed one, another pesky one cropped up.
Very frustrating!
Lots of research and troubleshooting later I was able to get it going. With Service Pack 2 going end of life back on April 8th I wanted to pass that knowledge on.
This article offers a comprehensive guide to the errors I received and how to fix them.
Tip: For a step-by-step guide on how a service pack should behave check out this article.
Readiness Check Fails – IIS 6 WMI Compatibility
This is the first error I received. It was during the readiness check. Thankfully it is very easy to fix.
To fix:
- Open Server Manager.
- Select Roles.
- Scroll down to the Web Services (IIS) section and click the Add Roles Services link.
- Click Next.
- Scroll down to Management Tools >> IIS 6 Management Compatibility section.
- Select IIS 6 WMI Compatibility.
- Click Next.
- Click Install.
- Click Close.
At this point, I was able to proceed past the readiness checks. Unfortunately, that was not the end of the problems for me.
The following roles aren’t current: AdminToolsRole
Strangely, all of these remaining errors revolved around the Mailbox role. My CAS and HUB transport roles installed without a hitch. The next error is below.
This server role can't be installed because the following roles aren't current: AdminToolsRole This server role can't be installed because the following roles aren't current: MailboxRole
It seems strange to get this error about not being current. Especially when that is the very thing we are trying to do.
It is also possible to get this error on the ClientAccessRole and HubTransportRole as well. The fix is the same.
Thankfully, this fix was easy and I have to give kudos to Erdal Ozkaya for writing about this on his blog.
To fix we need to go into the registry.
- Open the Registry Editor.
- Navigate to HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\AdminTools
- Make sure the ConfiguredVersion matches the UnpackedVersion.
( In my case the unpacked version number was correct for SP3. My configured version reported SP1. ) - If you have String Keys for Action and Watermark, right click on these and select Delete.
- Click Yes to confirm.
-
Repeat steps 3 and 4 for these registry keys:
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\ClientAccessRole
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\HubTransportRole
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\MailboxRole - Reboot your server.
- Rerun SETUP.
All clear?
Sadly, I wasn’t.
Mailbox Role Failed: Cannot bind argument to parameter ‘Identity’ because it is null.
If you had the last error then chances are you have this one too.
Mailbox Role Failed Error: The following error was generated when "$error.Clear(); if ($RoleCreatePublicFolderDatabase) { $publicDB = get-PublicFolderDatabase -Server:$RoleFqdnOrName -ErrorAction SilentlyContinue; $DB = get-MailboxDatabase -Server:$RoleFqdnOrName -ErrorAction SilentlyContinue; ...edited for length... } " was run: "Cannot bind argument to parameter 'Identity' because it is null.". Cannot bind argument to parameter 'Identity' because it is null.
The fix is a continuation of what we did in the Registry for the last error.
You may notice from my last screenshot, my MailboxRole was missing a ConfiguredVersion key. That’s our problem.
To fix:
- Open Registry Editor.
- Navigate to HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\MailboxRole.
- Right-click in the right pane and select New >> String Value from the context menu.
- Type ConfiguredVersion for the name.
- Double-click ConfiguredVersion and set the value to match the UnpackedVersion.
( In my case this is 14.3.123.4. ) - If you have String Keys for Action and Watermark, right-click on these and select Delete.
- Reboot your server.
- Rerun SETUP.
Just when I thought I might be out of the woods -ERRR! New error.
Virtual Directory ‘PowerShell’ Already Exists
Error: The following error was generated when "$error.Clear(); $vdirName = "PowerShell (Default Web Site)"; $proxyVdirName = "PowerShell-Proxy (Default Web Site)"; $InternalPowerShellUrl="http://" + $RoleFqdnOrName + "/powershell"; $vdir = get-PowerShellVirtualDirectory -server $RoleFqdnOrName -DomainController $RoleDomainController | where { $_.Name -eq $vdirName }; $proxyVdir = get-PowerShellVirtualDirectory -server $RoleFqdnOrName -DomainController $RoleDomainController | where { $_.Name -eq $proxyVdirName }; ...edited for length... The virtual directory 'PowerShell' already exists under 'EXCHANGE.SKARO.LOCAL/Default Web Site'. Parameter name: VirtualDirectoryName
For some reason, it didn’t like the existence of the PowerShell and PowerShell-Proxy Virtual Directories in IIS. The fix was simple. Delete those virtual directories. It’s ok. Setup will recreate them for us.
Here is how:
- Open IIS Manager.
- Expand your server name.
- Expand Sites.
- Expand the Default Web Site.
- Right-click the PowerShell virtual directory and select Remove from the context menu.
- Click Yes to confirm
- Repeat steps 5 and 6 for the PowerShell-Proxy virtual directory.
- Next open ADSI Edit.
- Right-click on the top-level node, ADSI Edit, and select Connect To...
- From the Select a well-known naming context drop-down select Configuration.
- Expand Configuration <server name>
- Expand CN=Configuration <domain suffix>
- Expand CN=Services
- Expand CN=Microsoft Exchange
- Expand CN=<domain name>
- Expand CN=Administrative Groups
- Expand CN=Exchange Administrative Group (FYDIBOHF23SPDLT)
- Expand CN=Servers
- Expand CN=<server name>
- Expand CN=Protocols
- Select CN=HTTP
- In the right pane select CN=PowerShell-Proxy (Default Web Site) and select Delete from the context menu.
- Click Yes to confirm.
- Repeat steps 22 and 23 for CN=PowerShell (Default Web Site).
- Reboot your server.
- Rerun SETUP.
That’s got to be the end of it right?
Sadly, no.
Couldn’t resolve the user or group Discovery Management
This is a problem with the Discovery Search Mailbox. For whatever reason the error below reports that it can not find it.
The following error was generated when "$error.Clear(); $name = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]:: DiscoveryMailboxUniqueName; $dispname = [Microsoft.Exchange.Management.RecipientTasks.EnableMailbox]:: DiscoveryMailboxDisplayName; $dismbx = get-mailbox -Filter {name -eq $name} -IgnoreDefaultScope -resultSize 1; if( $dismbx -ne $null) { ...edited for length... } " was run: "Couldn't resolve the user or group "SKARO.LOCAL/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.". Couldn't resolve the user or group "SKARO.LOCAL/Microsoft Exchange Security Groups/Discovery Management." If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust. The trust relationship between the primary domain and the trusted domain failed.
Now, some blogs say to simply disable this Discovery Search Mailbox.
Here is the command. Run from EMS.
C:\> Disable-Mailbox -Identity "DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}"
Unfortunately, I had to take it one step further. Disabling the mailbox alone was not enough. I then had to go into Active Directory Users and Computers and delete the user account as well.
Once removed I was then able to get through the entire SETUP.
No more errors! Woot!
However, we do need to recreate the Discovery Search Mailbox. This is actually a simple process.
Open a command prompt. Change to the folder where you unpacked SETUP and run the following command.
C:\> SETUP /PrepareAD
Successful output will look like this.
We still need to enable the Discovery mailbox. Issue the following command from EMS.
C:\> Enable-Mailbox -Identity "DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}" -Discovery
To make sure this worked run this command.
C:\> Get-Mailbox -Filter { RecipientTypeDetails -eq "DiscoveryMailbox" }
You should get an output similar to the following.
We are done!
Scooby Mystery: One thing I noticed on the original Discovery account was the lack of a space between Mailbox and the opening curly bracket. PrepareAD recreated the account with a space. Have you guys seen this?
Was this article helpful to you? Leave a comment to let us know!
djack says
I ran into this error, and it was due to the fact that the discovery account was disabled due to the password not meeting the required policy. I reset the password and enabled the account and it worked.
spankwire says
I have Exchange 2010 SP2 (not with latest updates) and I plan to connect it to Edge Transport (with SP3 and with latest updates) which is located in DMZ. All necessary ports have been opened on TMG 2010 but there is always error: EdgeSync service cannot connect to this subscription because of error No EdgeSync credentials were found for Edge transport server NameOfServer.Something on the local Hub Transport server. Remove the Edge subscription and re-subscribe the Edge Transport server . I tried removing subscription and adding it again but same error over and over again. Am I missing something or just doing something wrong?
Jesse says
This was great!
Mehmet Gündüz says
YOU SAVED MY DAY && YOU MADE MY DAY:D THANK YOU SOOO MUCH!
WN says
Thanks for the article you are God Send Nice
photonn says
Thanks! Your findings on the Discovery shit failure saved us a lot of time.
Gina says
this spost helped me. I was about to leave the upgrade project.
You may also face this error when beinning the upgrade.
http://www. slsmk.com/exchange-2010-error-applying-service-pack-setup-previously-failed-while-performing-action-install/
Erick says
Thanks
Rafael says
Thank you man .. As of May 2016 and this article still just hitting on the nail. Saved my night ! almost 15 hours trying to fix the discovery thing. Dang !
Tony M. says
Saved my day! Thanks for this excellent write up!
henk bakker says
Saved my day, had to migrate 2003 exchange to a new 2012 server with exchange 2010.
Gareth Gudger says
Glad to help!
RK says
I put off installing this service pack for two years just because of all the reported errors–and Microsquish has done nothing to fix them?!? What garbage. If I have to do this much fiddly crap to get it working, maybe I should save five grand and install an open source freebie.
Gareth Gudger says
95% of the time the upgrades go without a hitch (even more-so in 2013). I just got unlucky in this one environment and had all 5 come up. I see the Discovery Mailbox error come up on occasion, but the others are quite rare.
S. Porter says
Super helpful, got me through my exchange SP3 upgrade! Stupid DiscoverySearch Mailbox- I also had to delete the AD account. Thanks again for posting this!
Gareth Gudger says
Glad to be of service.
Sam says
Thanks Gareth – Signed someone fumbling around with a blind fold on
Barney says
Hi Gareth,
Great article – I had all the issues you mentioned going from SP1 to SP3, now on SP3 thanks to you.
Cheers,
Barney
Gareth Gudger says
Glad to help! Thanks for sharing.
Sean K. says
Thank you for taking the time to post this! In my case it was just one error (PowerShell directory already exists), but your post was invaluable. Great job!
Gareth Gudger says
Glad to be of assistance Sean!
Ashley Hoffmeister says
What did you do for the piece where your configured and unmatched version were different? Change them manually? I am seeing that on mine.
Ashley Hoffmeister says
Got it all sorted. What a pain this was! I had some issues with the PowerShell afterwards, but got that fixed too. Thanks for the helpful article!
Gareth Gudger says
Glad to be of assistance Ashley! Be sure to check out the rest of the site.
Hasanat (@m_hasanat) says
Hi, a very helpful article. But the error I received while upgrading my mailbox server is quite different.
Kindly have a look below and advise:
{
Mailbox Role
Failed
Error:
The following error was generated when “$error.Clear();
buildToBuildUpgrade-ExsetdataAtom -AtomName SystemAttendant -DomainController $RoleDomainController
” was run: “An error occurred with error code ‘3221685221’ and message ‘Overlapped I/O operation is in progress.’.”.
An error occurred with error code ‘3221685221’ and message ‘Overlapped I/O operation is in progress.’.
Click here for help… http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.3.123.3&e=ms.exch.err.Ex88D115&l=0&cl=cp
Elapsed Time: 00:01:36
Management Tools
Cancelled
Finalizing Setup
Cancelled
}
As per TechNet blog, I uninstalled antivirus, disable windows firewall and gave full security permissions to everyone for C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\address and tried again but again got same error.
Before mailbox, I successfully upgraded CAS&HUB server without any warning / error.
Request and appreciate your kind guidance to come out of this situation.
Thanks.
Gareth Gudger says
Hey Hasanat,
Glad you like the article.
Check the answer at the bottom of this forum. They reported changing the RPC Locator Service to Automatic and then restarted the Exchange box.
http://forums.msexchange.org/Upgrading_to_Exchange_2013_SP3_failed/m_1800570372/tm.htm
Hasanat (@m_hasanat) says
Thanks Gareth, I tried your suggestion but again got the same error. Appreciate if you could kindly review error details once again and advise me to come out of this situation.
Carl Jones says
Recently did the SP3 upgrade and it blew away my Exchange Powershell (EMS). Only one of the three ps1 files were in the exchange bin directory. Moved the files into the bin directory from the setup directory manually. There were still a couple of powershell snapins missing. Had to edit the registry to add the missing snapins. What a mess!
Gareth Gudger says
Yikes. Haven’t had to do that yet. Thanks for the heads up Carl. Let me know if you write a blog post on that experience.
Oscar Vazquez says
gracias por el aporte!!! me sirvió un monton!!!
Mohamed Sameer says
Dear bro..
this article is life saving for many people like me….thanks for sharing your knowledge. saved a lot of time for me….well dome..appreciated.
thumps up
Gareth Gudger says
Always happy to pass along any knowledge.
Raymond R.A. Rothengatter says
Great Article! Seems like just the last puzzle pieces to get the mail server up and running again after the whole night puzzling piece by piece getting closer every step (had a lot of issues allready at the Client Access Role part…) before coming to the Mailbox Part.
Raymond R.A. Rothengatter says
And it did solve the issue, up and running since 9:00 🙂
Gareth Gudger says
Awesome! Glad to help.
Charles @ErrorTools says
Its funny how running any of these upgrades cannot be just straightforward. You have to fix this and that error before you can get anything working smoothly. Thanks for the guide, saved me some hassle 🙂
Gareth Gudger says
Glad to help. Most of the time the upgrade goes smoothly. The most common error I see is the one regarding the Discovery Search Mailbox.