Assessing the impact of schema changes

Microsoft Active Directory is a hierarchical database of objects that represent the physical entities (computers, users, groups, sites, subnets, and so on) that make up a network. These objects are specific instances of classes, and a class consists of a collection of different attributes. Classes and attributes are formally defined in the schema.

As Active Directory has evolved as a platform with the release of each new version of Windows Server, Microsoft has added new functionality (mostly new classes and attributes) to the schema. The table below shows the schema version number for each release of the Windows Server platform:

Table 1

You can determine your schema version using the Get-ADObject cmdlet of Windows PowerShell. As an example, here’s the output from running the command on a domain controller running Windows Server 2012 R2:

PS C:\> Get-ADObject (Get-ADRootDSE).schemaNamingContext -Properties objectversion

DistinguishedName : CN=Schema,CN=Configuration,DC=contoso,DC=com
Name              : Schema
ObjectClass       : dMD
ObjectGUID        : 10ba87a8-5d3b-48b2-8691-9ceb056f9c64
objectversion     : 69

When a new version of Windows Server comes out and you want to upgrade your domain controllers, you must extend your Active Directory schema to the latest version. The question then arises: Will there be any possible impact to my existing infrastructure if I extend the schema? For example, could extending the schema affect any of my line-of-business applications?

This is a serious question for two reasons:

• Extending the schema is a forest-wide action. In other words, it can potentially affect everything (computers, users, groups, sites, subnets, and so on) in your Active Directory forest.
• Applying schema extensions is an irreversible action that cannot be undone.

All this reminds me of the line that Sir Laurence Olivier uttered as he was preparing his dental tools to interrogate Dustin Hoffman in the movie Marathon Man:

Is it safe?

What’s the answer then? Is it safe to simply flip the switch and extend the schema of your existing Active Directory environment as each new version of Windows Server is released?

The official answer

It would be helpful if Microsoft included a short note like the following with each new release of Windows Server:

“The schema extensions that are included in this new release just add a few new classes and attributes, and they should not have any impact on your existing applications and services.”

If they did this we could all breathe a sigh of relieve and simply flip the switch to extend our Active Directory schema.

Unfortunately (and perhaps for good reason) Microsoft has never provided a statement like that. So the “official” answer to the question of whether it’s safe to upgrade your schema is that there is no official answer from Microsoft on this matter.

Great. This means we need to fall back on the wisdom of crowds. So let me share a few tips I’ve received from my colleagues with regard to this issue.

Advice from the field

Most application issues caused by schema changes are a result of poor coding practices in the development of the application. For example, if a vendor does any of the following when building their application, unexpected problems may result when the Active Directory schema is extended:

• The application checks for the Active Directory schema version and has a dependency of some kind on the schema version.
• The application requires the administrator to manually specify the root object identifier (OID) during setup and configuration of the product.
• The application includes its own extensions to the Active Directory schema but these extensions may have implemented improperly or might conflict with or even block future schema changes from Microsoft. Examples of improper implementation of schema changes can include such things as duplicate IODs, duplicate schema-id GUIDs, wrong syntax for attributes, missing must-contain attributes, missing may-contain attributes, and so on.

That last point is the big culprit but it only applies to enterprise applications that modify the Active Directory schema. Unfortunately, most vendors of such applications do not clearly document what changes their application will make to the schema when you deploy the application in an Active Directory environment. But then Microsoft itself is guilty in this area because they generally don’t clearly document what schema changes are introduced with each new version of Windows Server. To be precise, they may document such changes but the resulting documentation may be anything but comprehensible–see for example their documentation of schema changes introduced in Windows Server 2012. And for Windows Server 2012 R2 they haven’t even published such raw information yet–the only available source of such info is the “Combined Active Directory Schema Classes and Attributes for Windows Server” documentation. You can also find explanations of the different schema classes and what they are used for on MSDN.

The way forward

What should you do then about this issue when you are contemplating extending the Active Directory schema by deploying domain controllers running a new version of Windows Server? At a minimum you should probably do the following:

1. Review the documentation of all your enterprise line-of-business applications to find out whether any of them have introduced any updates to your schema when they were deployed. Contact the application vendors when necessary to inquire concerning this if their documentation makes no mention of any schema changes.
2. Build a test environment that mirrors your production environment and includes all the applications identified as having schema updates in the previous step.
3. Extend the schema of your test environment to the latest version of Active Directory and deploy domain controllers running the latest version of Windows Server.
4. Test test test.

You can also make use of tools like SchemaAnalyzer to export and compare Active Directory schemas with different versions of Windows Server and different enterprise applications installed. SchemaAnalyzer was included with the ADAM tools of Windows Server 2003 R2 and is included in Windows Server 2008, see this link. While I haven’t tried using SchemaAnalyzer with the latest version of Windows Server, it may still be useful. There’s also a windows PowerShell script named ADSchemaExtensionConflictAnalyzer.ps1 you can use to analyze application schema extensions (LDF files) against your current production schema. This script can be used to generate reports on any errors, conflicts, or other conditions that may cause problems when the application is deployed in your environment. You can download this script from the TechNet Gallery.

If you do find that a third-party application you’re considering deploying in your environment is likely to conflict with schema changes associated with upgrading your domain controllers to the latest version of Windows Server, all is not lost. You might consider deploying Active Directory Lightweight Directory Services (AD LDS) and proxying authentication for your application to Active Directory Domain Services (AD DS). This is actually not a bad idea at all for a new Active Directory deployment an organization is considering because deploying AD LDS like this can allow you to keep your Active Directory schema “pristine” i.e. free of third-party customizations, and ultimately this will reduce the change of problems and increase the supportability of your environment–at least from Microsoft’s perspective. For more information on this approach, see the following:

• http://technet.microsoft.com/en-us/magazine/2008.12.proxy.aspx?pr=blog
• http://www.theidentityguy.com/articles/2010/5/17/using-proxy-authentication-across-trusts.html
• http://technet.microsoft.com/en-us/library/cc794836%28WS.10%29.aspx

and similar articles.

The good news

While all of this sounds pretty frustrating, there’s actually a silver lining–updating the Active Directory schema has actually gotten much less hazardous with recent versions of Windows Server. For example, when Windows Server 2003 R2 added the iNetOrgPerson class to the base schema this caused problems for customers that had Windows Services for UNIX 2.0 deployed because the schema extensions for SFU conflicted with some of the 2003 R2 schema extensions. The schema updates for Windows Server 2003 R2 also included extensions designed to make the Active Directory schema map more closely to the Lightweight Directory Access Protocol (LDAP) standards as defined by RFC 2307. This was probably implemented so that third-party LDAP applications and Active Directory could interoperate better, but again the result was problems being experienced by some mixed Linux/Windows environments. Fortunately, beginning with Windows Server 2008 Microsoft has begun restricting their Active Directory schema updates to only custom (i.e. Microsoft not industry standard) schema changes, which has reduced the chance of third-party schema extensions conflicting with Active Directory ones. So the main thing you need to concern yourself in most cases is third-party applications that extend your Active Directory schema.