While recently attempting to install an Exchange Cumulative Update in a customer’s Exchange environment, I had some issues with performing the schema update. I always find it much easier to perform the schema updates from the server which will have either the new Cumulative Update (CU) or the new Exchange Server version installed on it. This is because all the prerequisites are already installed or available, including AD management tools, .NET Framework version, server roles and features and source software. I can’t tell you how many times I’ve attempted to use another server to perform the Exchange schema and AD preparation, only to be halted by a missing prerequisite. You can bet the change process to install the prerequisite is more trouble than it’s worth.
Anyway, it turns out this customer’s Exchange server was in a different site from the Schema Master. With the increasing use of hybrid cloud, it’s becoming more common to see Exchange servers in a different site to the AD Flexible Single Master Operation (FSMO) roles. As a result, we had no choice but to run the schema update from a server in that site. Problem number one solved.
NOW FOR PROBLEM NUMBER TWO!
As the schema update progressed a little further, we encountered another error; this time indicating a problem with permissions. After establishing that the account being used had all the required permissions, we turned to the install log files. The logs indicated the issue was with the Domain Controller (DC) in use. To work around it we tried to force the use of a local DC (by using the /domainController switch) but we received an error indicating the Schema Master must be used. Using the same command to force the use of the DC with the Schema Master FSMO role failed with the permission error again. Did anyone say, “around in circles?!”
After some further troubleshooting, we found that the Schema Master was not a Global Catalogue (GC) server, and this was causing the permissions error during the schema update. The obvious fix for this is to configure the Schema Master as a GC. Unfortunately, it wasn’t that simple because the server which held the Schema Master FSMO role also held the Infrastructure Master FSMO role. When the DC holding the Infrastructure Master FSMO role is a GC, all the DC’s in the environment must also be GC’s! It seems I’d ventured down a rabbit hole!
WHAT NEEDS TO BE DONE?
After walking the customer through the issue and the options available, we decided the best course of action was to configure all their DC’s as GC’s, including the Schema Master. The customer also had the option to migrate the Infrastructure Master FSMO role to another server, but to simplify administration in this scenario and to ensure consistent responses, designating all domain controllers as GC’s eliminates the concern about which domain controllers can respond to GC queries. Once the Schema Master was configured as a GC – hoorah success! The required AD and schema updates successfully completed, and the CU installed without any further issues.
As organizations move their critical infrastructure out of their own data centers and into the cloud, it’s even more important for anyone looking to perform Exchange AD preparation tasks to have a clear understanding of the underlying AD infrastructure, including the configuration of AD sites and the location of all FSMO roles.
As always, feel free to reach out if you have questions or comments.
