I ran into an issue where I had an Exchange 2013 Server that needed to be updated to the most recent CU. I’ve done this plenty of times before, but this particular update gave me trouble. The step it was failing on was the AD Prep and the Schema Prep. I confirmed my user account is a domain admin and a schema admin. I tried running the update again and was presented with the same error.
Attempt #1: Exchange CU Wizard (On Exchange Server)
Through my troubleshooting, what I found was that because the Exchange server was in a different AD Site than the Domain Controller that held all the FSMO roles, it wouldnt allow the Exchange CU wizard perform the necessary Schema updates and AD updates that it required.
If the wizard, wouldnt work, perhaps I could run the commands manually to get it to work. I was met with the same failure. Applying an Exchange CU had never been so difficult before.
Attempt #2: AD Prep (On Schema Master)
So, those commands needed to be run on the Domain Controller itself. So, I took the following steps to make it happen.
- Run the command “NET USE Q: \\exchange\C$\source” (source being the directory where you stored all the CU files)
- Run the command “CD Q:” to change your working directory to the drive you just mapped
- Run the command “.\setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms” to first run the Schema Prep
- Remember, you do need to make sure the account you are using the run the command is an Enterprise Admin and Schema Admin.
- Run the command “.\setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms”
- Note: I was working with a single AD Domain, so I didnt need to run the /PrepareDomain
- Verify that both commands run successfully!
Once you have completed this step, you dont have to continue on with using the commands for the unattended CU install. Instead, if you are more comfortable with it, you can launch the Exchange CU Wizard again and it should pass the precheck for the Schema and AD Prep steps.
Updating the Schema for a domain needs to be done on a server that is in the same AD Site as the Schema Master. It also needs to have the RSAT-ADDS-Tools feature on the server, which makes the Schema Master itself an easy choice from which to do the update. I learned that using an account with the appropriate permissions may not be the real issue, even when presented with an error that claims to be the result of a permissions issue.