In the initial versions of Exchange, there was no Active Directory. In this land before time, Windows NT directory services was available and Primary Domain Controllers and Backup Domain Controllers ruled the roost. Exchange 4.0 to 5.5 maintained a separate directory in Exchange over and above the Windows NT directory. This all changed with the advent of Active Directory and Exchange 2000. I will not mention the Active Directory Connector due to unhappy memories, but that was the process to integrate and transition to Exchange 2000 and Active Directory. This was 17 years ago, so as you can see AD integration is not a new thing. As part of the integration it is required that the Active Directory schema is updated to support Exchange. One aspect of this is to add the required AD schema modifications which make AD aware of the Exchange different properties. Microsoft documents the changes that are made to the Active Directory (AD DS) when the AD DS schema is updated.
In previous versions such as Exchange 2003, 2007 and 2010 the Exchange service pack and RTM media were the only methods that could be used to extend the schema. In Exchange 2013 and 2016 the servicing model was changed and it is possible that a Cumulative Update (CU) can make AD DS schema changes. Note that not all CUs contain schema changes. For example you can find the below on TechNet:
Exchange 2016 Active Directory schema changes
Exchange 2013 Active Directory schema changes
Exchange 2010 Active Directory Schema Changes
While the AD DS schema extension process is mandatory and cannot be avoided, many customers wish to really dive into the details of what is being modified. They have a desire to verify exactly what is changed in the schema themselves...
We can use a tool from AD LDS (ADAM) to diff and compare two AD DS schemas. Let's look at this process, and compare the Exchange 2016 CU2 and Exchange 2016 CU4 AD DS schemas. The overall process typically looks like:
-
Use LDIFDE to capture the initial AD DS schema
-
Update AD DS schema to new Exchange CU
-
Use LDIFDE to capture the updated AD DS schema
-
Diff the two schemas using ADSchemaAnalyzer
This post performs the process in a test lab. Everyone has a test lab so they are able to test and validate items like this, right?
Note that there are scripts on the Interwebs that can list out the date modified on the AD DS attribute. The below does allow a comparison to be made between two specific schemas.
Lab Config
In this lab, there is a single Domain Controller running Windows 2008 R2. The Domain Function Level (DFL) and Forest Function Level (FFL) are both Windows 2008. While old, this is currently supported for Exchange 2016 and is for a separate upcoming post. In the below image you can see the DNS namespace which was used – Wingtiptoys.ca as shown by the configuration naming context.
There is a single Exchange 2016 server which was prepared and installed using PowerShell. The base Windows 2012 R2 OS components were installed, .NET 4.5.1 and UC Managed API.
After each of these, the server was restarted. Exchange 2016 CU2 was then installed to create the Exchange organisation and deploy the first Exchange 2016 mailbox server. The command executed was:
Setup.EXE /IAcceptExchangeServerLicenseTerms /OrganizationName:Wingtiptoys /Roles:Mailbox
Use LDIFDE to Capture the Initial AD DS Schema
Now that we have the base CU2 environment up and running, we can then export out a copy of the schema to a file.
On a suitable DC, open up an elevated cmd prompt and generate the export file using LDIFDE.
The syntax needs to be edited to match your AD, and should look something like the below:
LDIFDE –F filename -d "cn=schema,cn=configuration,dc=domain,dc=com"
This is the command used in the lab, where the export is to a file called CU2.ldf at the root of the C: drive.
LDIFDE –F C:CU2.ldf -d "cn=schema,cn=configuration,dc=wingtiptoys,dc=ca"
(Note that some of the dots were snipped out in the image to save on screen space)
Update AD DS schema to New Exchange CU
Now we can update the AD DS schema to the new Exchange CU.
setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema
Use LDIFDE to Capture the Updated AD DS Schema
Now we repeat the LDIFDE export process to export out the updated schema. The command syntax is the same, though you will likely want to use a different file name.
This is the command used in the lab, where the export is to a file called CU4.ldf at the root of the C: drive.
LDIFDE –F C:CU4.ldf -d "cn=schema,cn=configuration,dc=wingtiptoys,dc=ca"
(Note that some of the dots were snipped out in the image to save on screen space)
Diff the Two Schemas Using ADSchemaAnalyzer
To get the ADSchemaAnalyzer we need to install the required AD DS LDS component onto a server. This could be a different server in Exchange environment, or outside of it. We just need to copy over the two export files to the server where AD LDS was installed. In the example above this was CU2.ldf and CU4.ldf.
We do not need to install the full AD LDS role, just the LDS RSAT tools. This can be done using Server Manager or PowerShell.
Or if you desire to use PowerShell, Add-WindowsFeature RSAT-ADLDS or Install-WindowsFeature RSAT-ADLDS can be used.
Add-WindowsFeature RSAT-ADLDS
This server is the Windows 2008 R2 DC, so Add-WindowsFeature was used. The Add-WindowsFeature cmdlet has been replaced, starting with Windows Server 2012, by the Install-WindowsFeature cmdlet. For more information about Install-WindowsFeature in Windows Server 2012, see Install-WindowsFeature. For more information about Install-WindowsFeature in Windows Server 2012 R2, see Install-WindowsFeature.
NOTE: If using Windows 2008 R2, installing the AD DS LDS role, will install both the admin tools and also the LDS role. Windows 2012 onwards will not install the tools by default, you need to also install the RSAT element. If your cannot locate the ADSchemaAnalyzer.exe tool, please ensure that the corresponding RSAT tool was also installed.
If you did install the full role, we don't need to configure AD LDS it just needs to be installed for the purpose of this post.
Launch the ADSchemaAnalyzer by running C:\Windows\ADAM\ADSchemaAnalyzer.exe
From the File menu, chose Load Target Schema. The Load schema window appears. From here we click Load LDIF, and browse to select the target schema file. In our case this will be the CU4.LDF file.
Browse to find the target LDIF file, In this case we load up CU4.LDF.
Now we need to load up the base schema, From the File menu select to Load Base Schema, and click the Load LDIF button to browse to the file. In this case it will be the CU2.LDF file.
Clicking OK will then start the tool up on its review of the two schemas. You should see some detail initially along the bottom of the screen:
Expanding the attributes, and scrolling down to the msExchSchemaVersionpt shows that it is highlighted in red:
This attribute was modified with the Exchange CU4 setup routine.
Viewing the properties of the attribute shows rangeUpper:
This should be familiar to you, as it is one of the documented values.
Viewing Added Attributes
We can then expand, and review the elements listed under the nodes. However, this can be a lot of scrolling to find out what changes. Note the different icons used below for two of the Exchange attributes. They do not jump out, and it involves a lot of scrolling.
Can't See Trees Because of The Forest
Active Directory puns aside, having to do all of that scrolling can be a pain. It may be easier to hide mutual elements that are present, so that we can focus on the differences. To do this, set the option below from the Schema menu.
Then when we expand the Attributes area, the two changed attributes stand out.
Comparing Results
If we compare the above information from the ADSchemaAnalyzer tool with the official documentation we can see that the two are aligned.
Exchange 2016 CU3 Active Directory schema changes
Cheers,
Rhoderick
