Imagine this scenario; you have deployed an Exchange 2013 or Exchange 2016 Cumulative update successfully in your environment and you think that all is fine. However you then receive an unpleasant surprise when you go to verify the details of the Exchange Schema and Exchange AD object versions. You can review the process to review the Exchange AD Objects and Schema in addition to the different build levels you will encounter in this post for Exchange 2013.
The below example illustrates the issue with a scenario based around Exchange 2013 CU15. Since CU15 was already installed onto Exchange 2013, it is a fair expectation that all of the AD attributes are at the CU15 level. However this is not the case.
The 6 Mistakes To Avoid With Exchange 2013 CU Command Line Installations * were not the underlying cause of this issue, though #6 in the list may produce similar symptoms.
Existing Exchange Environment
The below is an Exchange 2010 and Exchange 2013 lab. It currently has Exchange 2010 SP3 and Exchange 2013 CU15 deployed. We can verify this by looking at the server information returned by the Get-ExchangeServer cmdlet and also Add/Remove programs on the Exchange 2013 server itself:
Get-ExchangeServer | Select-Object Name, ServerRole, AdminDisplayVersion
As expected, if we look at the list of installed programs on the Exchange 2013 server, we can see that CU15 is indeed present. The correct build number of 1263 is also displayed in both the Get-ExchangeServer cmdlet and also the list of installed programs. Note that Exchange 2010 does not state the actual build installed, and a different process is needed to determine the Exchange 2010 build.
Now that we have established that Exchange 2013 CU15 is installed, let us verify the information held in AD to ensure that it also reflects the CU15 build. We can use the DSQuery commands in the aforementioned post to perform this step. There are some other ways also listed in the post, so feel free to use the method you prefer.
The below screenshot shows the DSQuery commands to verify the AD Schema and associated Exchange objects. The objects we are reviewing are
-
msExchproductId
-
rangeUpper
-
MESO objectVersion
-
Org objectVersion
Note that the msExchproductId has a value of 15.00.1178.004.
Hmm. Is that really the msExchproductId value of Exchange 2013 CU15?
No, it is the CU12 build number as listed in the Exchange 2013 schema post.
You may be asking is this really the same server where the above images are taken from? Yes it is. The below image has the two windows overlaid so you can see that both are from the same machine.
Correcting AD Objects
In order to compare the AD object values, we will manually execute all of the steps to prepare Active Directory and domains. The steps involve running setup.exe with the the below commands
-
PrepareSchema
-
PrepareAD
-
PrepareDomain
This will prepare the schema, prepare Active Directory and finally prepare the domain[s] which have Exchange objects. In this lab there is a single domain in the forest so only one domain has to be prepared. The AD information will be reviewed after each step.
First up, we will run PrepareSchema. We will follow the notes in the mistakes to avoid post, and run the commands in an elevated cmd prompt.
Step 1 - PrepareSchema
From an elevated cmd prompt the PrepareSchema command is executed:
setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema
Note that the msExchProductID value remains the same, and has not changed. Also there have been no schema updates in the last few Exchange 2013 CUs, so in this example it is not expected to see those values be incremented.
Step 2- PrepareAD
Next Active Directory is to be prepared. The below command was issued from an elevated cmd prompt:
setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD
Note that the command has completed successfully, and as indicated with the red arrow below, the msExchProductId value has been changed from the previous value of 15.00.1178.004
The msExchproductId attribute now has the expected value of 15.0.1263.005. This is the expected build for CU15.
Step 3 – Prepare Domain
Finally the Domain was prepared to complete the third of the manual setup steps.
setup.exe /IAcceptExchangeServerLicenseTerms /PrepareDomain
The reported values have not changed from the above.
To summarise:
After running /PrepareAD all is now as expected with the Exchange object information, and the planets are aligned.
Bootnote
This is an interesting issue to unpack. It first raised its head in the Exchange 2013 CU9 timeframe. In Exchange 2013 CU9, a new setting was added to control where sent messages were stored. This was the MessageCopyForSentAsEnabled parameter on the Set-Mailbox cmdlet. In some cases, there were reports that this new parameter was not present on CU9 based systems; this was reviewed in the Exchange 2013 CU9 MessageCopyForSentAsEnabled Missing post.
At the time of writing this post, there have been no AD Schema changes in Exchange 2013 since CU7. This raised an issue with the installer which expected to see AD schema changes in order to fire all of the setup steps. Exchange 2010 Service Packs always contained AD schema changes, as that was the only opportunity to make such changes in that version of Exchange. TechNet documents the changes to the Exchange 2013 schema in Exchange 2013 Active Directory schema changes. Note that there are no changes listed after Exchange 2013 CU7. In the case of the missing MessageCopyForSentAsEnabled parameter, this was due to the new RBAC definition not being imported during the CU9 setup.
In order to ensure that such issues do not happen, we need to review if there are schema changes and plan accordingly. The command[s] to prepare the AD environment should be manually executed and verified in advance. This is the recommended practise anyway. By running the preparation command[s] in advance, it allows AD to replicate the changes to all DCs and for the replication to be verified. Additionally in larger organizations, the Exchange administrator will not have the necessary rights to execute the commands, and assistance will be required from the AD team. This will need to be logged as a change, and the standard change management process followed.
For this reason I would recommend that the Exchange /PrepareAD command to manually prepare AD is executed before the first installation of any new Exchange CU when there are no schema changes.
Should schema changes be required, then the setup commands to prepare the schema and also AD should be manually executed as documented on TechNet.
Note that the it is not sufficient to only look at the CU you will install. You must also factor in the currently installed Exchange schema, and determine if there are schema changes between it and the CU you wish to deploy. We can illustrate this with two upgrade examples.
- The starting environment is Exchange 2013 CU12, which will be upgraded to CU 15. In this example, there are no schema changes.
- The starting environment is Exchange 2013 CU6, which will be upgraded to CU9. In this example there are schema changes.
Cheers,
Rhoderick
* – There are now 7 issues mentioned in the 6 Mistakes To Avoid With Exchange 2013 CU Command Line Installations post. You get one extra bonus one nowadays!
