Extending the schema – notes from the field

Reading Time: 6 minutes

Now … the day had come, your forest schema has to be extended with some new attributes and classes. You are sweating, You are feeling dizziness (…) my goosh, my precious schema (…). That’s the case with many people – need to extend the Active Directory schema makes them ill or in best case not very confident about whole thing. I was lately involved in the task of extending the schema in Windows 2000 forest with Windows 2003\Exchange 2003 extensions when I’ve dealt with customer doubts about such procedure, and now I’m observing few related questions on the newsgroups and also activedir.org list. So I decided to put here few thoughts about it and advices from my experience and also gathered in discussions with others.

Is a schema modification critical? Depending on the type of modifications – If you are only updating some attributes or changing values in the attributes it is not very dangerous if You know what You are doing. Bad attribute value can broke your directory depended applications, I can imagine that also put some troubles into Your AD. But in most cases such modifications can be easily reversed and backing up correct values even simply with ldifde.exe before any changes can save You some time on recovery.

But what troubles are more are changes which are adding attributes and classes to the schema. Why? Because we are not able to perform authoritative restore of a schema in a case of failure. In Windows 2000 there is no other way to recover from damaged schema other then performing whole forest recovery procedure, in Windows 2003 You can defunct the part of the schema but not remove it completely. So yes, extending the schema is serious operation – but operations on open heart are too, we just need to know how to deal with it.
What we have to do when we are going to extend our schema?

First, perform the overall health check of Active Directory infrastructure. What I mean by health check:

  • check if Your replication is working OK, You can use any tool but repadmin with /replsum option is a good start. Do the command :
    repadmin /replsum / bysrc /bydest /sort:delta

    in your domain and check every error indication. This should also give You an overview how long full replication cycle in Your AD environment is taking.

  • check DC’s event logs for serious errors. You can find LogParser useful for this task if you don’t have any other tools deployed.
  • check free place on DC’s hard drives. Be sure that there is some free space on a disc containing DIT file.
  • check the consistency of SYSVOL volume and check FRS health state. FRSDiag as well as other tools can be helpful here.

If everything looks OK in your environment lets try to prepare for the worst case which is a forest recovery in the case of failure in schema extension and replicating this after failure to other DCs in the forest. There is Microsoft document Best Practices: Active Directory Forest Recovery which describes this topic. It was create for Windows 2000 but it is valid for Windows 2003 as well (I hope we will get a new version someday). As a part of preparation to DR procedure we can do what follows:

  • take backup of at least two DCs from every domain in the forest, this can be done even with ntbackup utility. Be sure to verify the backup after it was created.
  • select at least one DC in each domain which will act as a recovery server. Recovery server will be switched off from the network before doing the operations on the schema, and if something go wrong can be used to recover from the failure and restore the forest. What we have to do before turning it off is we have to ensure that recovery servers can properly resolve DNS names among each other and that there are direct replication links between them which will allow replication to take place.

I hope that nobody will have to use these backup mechanisms but it’s better to be prepared then suffer.

If we are prepared let’s go to the final phase which is preparing the environment and doing actual work. I strongly recommend to do a schema operations in the separated network segment. This will protect us from accidental replication of failed schema definition across the forest. In many documents, like this one from Microsoft we can find information that we can only disable outbound replication instead of putting schema FSMO machine into separated environment. But it is not whole true – if You disable the replication You can still force replication with repadmin command (/sync /force or /syncall can override this) other tool, so using this option is not giving You full protection.

What are the pros and cons of both approaches? If You will move Schema FSMO to the separated site You will notice error messages in the network and on the separated DCs during the time when DCs will be in separated network segment. But we have air gap between the upgrade site and live environment which protects us from the mistakes.
. When we are using the option to disable outbound replication we are not getting any error messages but replication can still be forced by someone.

If we are doing schema operations in separated network segment we have to move there two DCs, because schema master has to contact second DC on the network to start perform its role. If You are done with all this pre-upgrade stuff You can go with a process which is:

  1. Turn off server designated as a recovery servers and move two DCs to the separated segments. Check connection, replication link and other things between these DCs. One of them has to be a Schema master.
  2. Make upgrade of the schema on the schema FSMO
  3. Verify schema extensions incorporated in the step 1. In most cases thiis can be done with ADSIEdit or LDP.exe by checking some values and attributes or just existence of the new attributes and classes. In bigger environment it is good to prepare some kind of script or tool which will check every DC in the forest for selected data.
  4. If everything went OK and verification from previous step indicates the success connect second DC in the separated segment back to the network and replicate the changes.
  5. If previous point was completed successfully in most cases You are ready to plug these DCs back to the live (production) environment.
  6. Replicate changes in the real, production directory.

If something will fail in these procedure before replicating data from separated segment of the network You can always decommission DCs from these segment in the real AD and forget about them (re-install). If something will broke the schema in a bad way during the replication in production environment you are in the bad situation of recovering the forest to the point in time before it. Here our recovery servers can be quite useful.
If everything looks OK in the event logs, our services are still working and we still have our jobs – we can go and have a party with friends.

You have to remember also that extending the schema with new attributes can cause synchronization of GCs in the forest which may involve additional network traffic – depending on the number of objects this can be significant amount of traffic on the network.

Regarding specific case which is preparing Windows 2000 domain to incorporate Windows 2003 in the network with Exchange 2000 (I think this is very common scenario). Before going with Windows 2003 /forestprep you have to update lDAPDisplayName for three attributes introduced by Exchange 2003 (see ldif file content listed below). This will prevent creating of mangled attributes in Your schema (about mangled attributes and detailed information on how to avoid them You can find in KB314649).

dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace:LDAPDisplayName
LDAPDisplayName: msExchAssistantName


dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchLabeledURI


dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchHouseIdentifier


dn:
changetype: Modify
add: schemaUpdateNow
schemaUpdateNow: 1

To make this change You have to allow write update for a schema through registry changes described in KB216060. This operation is not so critical as extending the schema with new attribute and classes, and even if You forgot it and mangled attributes occur in Your network can be easily fixed with InetOrgPersonFix.ldf file from Windows 2000 InetOrgPerson Kit. Just remember to do it before going with extending the schema for Windows 2003 in the networks with Exchange 2000.

After making this change and replicating it among the forest one can go with Windows 2003 and Exchange 2003 /forestprep operations. Can we do them both or it should be done separately. As in many cases it depends what the person who is doing it prefers. I was doing this both operation one after another and then replicating it among the forest, as well as doing windows 2003 forestprep, replicating it in the forest and then doing Exchange forestprep. It worked fine in both cases, so do as it is suitable for You.

Everything what I wrote above is a common knowledge repeated all the time in the books and on the Internet. So why people are still not very sure how to deal with a schema extensions procedure? IMO this is because they are also hearing everywhere that if they will screw up their schema they will end up with broken AD, and are not very familiar with procedures how to do schema extensions to protect from such situation.
One thought also comes to my mind when I recall all my engagement and topics from the forums – it looks like most of the companies doesn’t have prepared DR plan for forest recovery, and very often also DR procedures and backups for domain controller are not in place or are not verified in the lab. It’s not very good situation – when You are not prepared You don’t know how to act in case of emergency, then panic factor comes into play and it’s easy to make something what will really hurt Your AD. It’s just for consideration for anybody who is taking care about business critical infrastructures, and AD is in most case the example of such infrastructure.

This post turned to be little longer post then expected, but I hope it is useful. I not I hope that comments will make it very useful.

One thought on “Extending the schema – notes from the field”

  1. Tomek, great post! At first when you said people think “my precious” you sounded like Golem from lord of the rings 😉 Are schema extensions critical – you bet your bottom dollar they are, you don’t want to do something that corrupts (which is difficult but possible) your schema, or replicates through out the organization. I must say though we provide the schema and the tools and methods to extend that’s one of the reasons you have a scalable LDAP directory so that you can have custom objects living in your environment. When it comes to schema changes we have some good documents that can help prevent the rest of the organization having the “bad” changes replicated to them. We first recommended turning the Schema FSMO off, then we figured out that from environment to environment this had different effects we then (and still do) recommend either disabling outbound replication (*Note – other FSMO roles and/or services on the Schema FSMO need to be taken into account before you do this) or setting the delayed outbound replication on your schema FSMO. One thing I notice customers do sometimes is following best practices and then forgetting to re-enable outbound replication when they are happy with the schema changes (how are the changes suppose to replicate ;)), I know you cover this in your blog and that you say that you can still force replication but then that is a conscious decision performed by someone. Disabling and enabling outbound replication is a process that should be documented and only authorized personal should have access and authority to process that command. If someone forces the replication then nothing except switching the schema FSMO off will save you….. I agree with you the replication check is a good one and one that many forget. Current or reoccurring replication problems have been the cause of many schema modifications going wrong. Just to mention some other tools (to check your FRS) 1. UltraMon 2. MOM 2005 Tomek full points to you for remembering the backup, many people say they have or say they will backup and when push comes to shove and they are under pressure they forget this fundamental step. The one thing to do (provided you have the resources) is test the backup, you can use virtual machines or other mechanisms but often I have been called into a situation where something has gone wrong only to find that the backups where “there” but didn’t work (and neither did the backups for the previous month) 😉 Just remember you still have to be part of the Schema Admins (even after enabling the schema updates in the reg ;)) *NOTE:- and Schema Admins DOES NOT mean going and changing ACE’s one the ACL for the Schema NC!!! (I know this sounds obvious but I have had this before!!!) You are 100% correct in saying "IMO this is because they are also hearing everywhere that if they will screw up their schema they will end up with broken AD, and are not very familiar with procedures how to do schema extensions to protect from such situation." You know Tomek, if you screw up anything you will have to fix it 🙂 that’s what people don’t understand, we do provide readme’s, books and KB’s for customers to understand and read through what to do, and now you have provided this really good article which is a great summary for everyone. The schema is your FRIEND its there to be extended, its there to help you “blue print” new objects. Like everything else RTFM. Good post once again my friend!!! Carlos Magalhaes

Comments are closed.