Active Directory schema extensions now a feature of every Exchange update

Exchange administrators first became aware of the application’s need to extend the Active Directory schema when Exchange 2000 switched from its own directory service to embrace the new enterprise-capable X.500-like service launched with Windows 2000. It all seems so long ago now yet every time an update comes along that requires a modification of Active Directory, brows are furrowed and teeth gnashed for no good reason.

Windows 2000 operated in a very different world. Networks tended to be slower, more fallible, and less accommodating to distributed applications. Replication solved the problem of making sure that domain controllers remained updated, even if, in some deployments, replication was “spotty” and not altogether reliable. But we got on with life because Active Directory replication was a black art.

Exchange 2000 was the first major server application to exercise and extend Active Directory. Many new object classes and attributes had to be added to the schema to make Active Directory suitable for Exchange, a fact that caused bother in companies where the directory and email teams might not have been the same. Deploying Exchange required preplanning and access to the schema master, and replication absolutely had to work to ensure that Exchange could be deployed across the organization. Hard words and some hurt feelings often ensued. Microsoft realized the difficulties early on and attempted to keep schema updates to an absolute minimum, usually only for major new releases and service packs.

Some lingering artefacts of Exchange 2000 remain in the product’s relationship with Active Directory. The code name for Exchange 2000 was “Platinum”, so we have ms-Exch-Schema-Version-Pt, where “Pt” refers to Platinum, the object in Active Directory that is updated by the Exchange installation program with the version number of the schema each time it is extended.

The situation is very different today. Every cumulative update for Exchange 2013 has extended the schema and the trend can be expected to continue. Unlike in the past where schema updates were usually linked to the release of major new functionality (the reason why updates only happened for new versions and service packs), the advent of role-based access control (RBAC) in Exchange 2010 means that schema updates are often required to accommodate changes to role groups and role definitions.

Cmdlets are added or removed and parameters adjusted or deprecated to expose new functionality to authorized users, and schema updates are necessary to implement those RBAC changes.

But RBAC is not the only component that forces schema updates. New features often require new objects or attributes to be defined and these have to be captured in Active Directory. 

There’s no sign that the rapid pace of change experienced since Exchange 2013 embraced the new servicing model will slow. As new features appear in quarterly cumulative updates, you can expect them to trigger quarterly schema updates. Given the kind of servers and networks operating today, the schema updates are usually painless and unnoticed, especially in small organizations where the email administrator is also in charge of Windows. If you run Setup to install a cumulative update, have the necessary privileges, and the schema master is close at hand, Setup will cheerfully extend Active Directory without a pause.

Organizations that like to exert more control over schema updates for fear that an update might impact other applications will probably take a more measured approach than simply letting Setup do its thing. Testing a cumulative update before deployment into production is always recommended and schema updates are part of that work.

Fifteen years after the release of Windows 2000 it is interesting how an operation that was once so carefully controlled has become so banal. Isn’t it true that different elements of technology often start off with a touch of fear before becoming the norm?

Follow Tony @12Knocksinna