Demystifying AD Schema Extensions for Exchange

Now most people who have been around Active Directory (AD) will understand about the AD schema and that some applications like Exchange, Lync, etc make updates to this schema.  However not everyone is intimately familiar with AD, so let’s start at the beginning…

Active Directory 101

Microsoft introduced Active Directory back in the Windows 2000 days.  It is built on the standard Lightweight Directory Access Protocol (LDAP).  In simple terms it is a database, and like all databases there needs to be something that describes what is stored inside the database.  In AD this is called the schema.  It defines the objects (or classes), their properties (or attributes) and the relationships between objects.  When you install the first domain controller then it will create a standard set of objects/attributes/relationships (or schema) as defined by Microsoft.

In the base schema there is a person object and this person object has attributes like givenName, sn (surname), initials, etc. and it even has some attributes that sounds like mail related attributes including mail and proxyAddresses.  If you want to install Microsoft Exchange, then Exchange needs to add a lot of object and attributes.  For example to the person object it adds loads of attributes starting with msExch as well as targetAddress.  These allow for additional information to be stored with a person that allows Microsoft Exchange to provide much more advanced functionality.

Updating the AD Schema

When getting ready to install Exchange, the first step in the process is to get Active Directory ready for Exchange.  If your organization has a split model, so that AD is managed by a different group than Exchange, then this step is often done by a different group of people, and the first question asked is generally “how safe is it to update the schema?”

Now if you’d asked me this question back when we were on Windows 2000, I’d have said well you need to be sure that you have a good backup for AD.  These days though the risk of a schema update from a Microsoft product breaking AD is very very slim.  Schema updates don’t ever delete objects or attributes they only add new ones or in some special cases update attributes and relationships.  In fact in the 20 or so years I’ve been working on the Microsoft stack I have yet to see one issue with schema updates where it has rendered AD useless.

So looking specifically at Exchange, what are the steps…?

1. Prepare for a schema update

Before you do a schema update, always check that replication around your domain controllers is working well.  Simply running repadmin and dcdiag on each DC and verifying that there are no replication issues is a good habit to get into.

2. Decide how you are going to install Exchange

If you are responsible for Exchange and AD (or you can convince the AD team to grant you the rights) then I’d get an account with Domain Admin, Enterprise Admin and Schema Admin rights and then just run Exchange setup on the first Exchange server in the forest.  Setup will run the remaining steps to update the schema as part of its process.

If AD is managed by another group and they want to update the schema for you then keep reading.

Note: Microsoft used to recommend things like isolate the schema master and run the schema update on there, and if all works well then reconnect the schema master, otherwise seize this role elsewhere.  However nowadays that guidance is no longer given (MS are all about simplification, remember when they used to recommend empty root domains or a separate set of replication NICs on Mailbox servers… ah those were the days…)

3. Setup.exe /PrepareSchema

This is the first stage in preparing the AD schema for Exchange.  You need Enterprise Admin and Schema Admin rights to perform this step.  Normally you’d run this actually on the schema master as a best practice.  This will add the Exchange classes, attributes and relationships into the Schema partition

4. Setup.exe /PrepareAD

This is the second stage in preparing the AD schema for Exchange.  This stage defines the Exchange Organization name, if you’ve not already had a previous version of Exchange installed.  You can only have one Exchange Organization per AD forest and it cannot be changed afterwards, so choose wisely…  Luckily you don’t see this organization name very often and it is generally hidden from non-administrative users.  You need Enterprise Admin rights to perform this step.  Don’t do this step until the changes from PrepareSchema have replicated (or ensure you’re using the same DC for these changes)  This will add the Exchange services into the Configuration partition and it will prepare the current domain for Exchange by adding various groups and permissions.

5. Setup.exe /PrepareAllDomains or /PrepareDomain

This is the final stage in preparing the AD schema for Exchange.  You need Enterprise Admin rights to use PrepareAllDomains or Domain Admin right for PrepareDomain (as well as Organization Management if this is a domain that was added after Exchange was already deployed)  This will prepare all domains or the specified domain for Exchange by adding various groups and permission.

Rolling back…

Another question asked by AD guys is how can you roll back.  The official answer is you can’t, however AD is just a directory so there is always a way back…  You’d have to manually unpick the Schema Changes that Exchange made though so it definitely isn’t for the fainthearted and not something I have ever tried myself, but I have heard MS Support having done this in one extreme case where the AD Schema somehow got updated twice…

Here is the list of changes that Exchange makes to AD

Summary

Exchange schema changes are here to stay and they are becoming more prevalent.  Most CU updates now require schema updates so you need to get this process working smoothly in your organization in order to keep up with the security updates.