Extending AD Schema

I've got a Forest/Domain running at 2003 with Server 2008 domain controllers. I want to add my first 2008 R2 domain controller, so I need to extend the forest/domain schema.

On the off chance the Schema extension goes poorly, what's the offical backout prodedure for such a thing? Restore the DC with the Schema Master role from backups? Unplug my "non role holding DC" during the process so it doesn't get the changes and then if it goes badly just turn off the main DC and sieze it's roles? I've heard of both, but I've never known of anyone doing either. And it's like pulling teeth on Technet to find out what the proper procedure is.

1) Definately backup your FSMO holders, particularly system state. You can use ntbackup.2) Use DC/Replication tools to test health of the environment to make sure everything is good to go.then3a) Backup ALL other domain controller system states.and/or3b) Disconnect all other domain controllers.

I've done just 1,2 and 3a before. Never did 3b. In case of 3a, if schema gets corrupt, restore and rebuild...

That's pretty much what I do as well. Don't yank the network connection from the Schema master, it likes to be able to still talk to other machines during the process even though it won't be doing outbound replication thanks to step #2.

For what it's worth I've never seen a MS provided schema extension fail.

When they do the schema update they chew up certain numbers (sorry I forget the right term for them)Generally done in pairs. I've had a case where a vendors schema extension used up 3 of them so the update wouldn'tcompletely take. MS has two spare sets put aside from earlier version of Exchange (there is a KB on it) but I hadto get support to dig me up a couple of extra overs and above that. Thankfully it only happened in the dev domain, prodtook quite happily.

I'm doing Exchange SP2 extension in prod when I get back to work on Monday, dev went smoothly.[edit]

I dug up the case. It was the LinkID that had been used up by another vendor.11900 and 11901 are reserved for problems and also 1138 - 1177. But as always if you run into this I'd double check with MS prior to playing around. I'd also make a note of which ones you've used.

Under 2003 it used to be set the primary to itself and then set the secondary and tertiary to be two other DC's, usually the same for all others.

In our last couple ADRAP's the best practice has changed to set the primary and secondary DNS to be the same servers for everyone, and then set the tertiary DNS server to be the local DC's IP or 127.0.0.1 (we use 127.0.0.1, but that will cause dcdiag.exe to report failures when it does DNS tests, even though DNS functionally will work fine in this config) - so essentially the reverse of the 2003 best practices.

By no means is that a hard and fast rule, but if you have a large number of DC's in your environment (like we do) it does ensure DC SRV records are always updated on the same server which minimizes replication conflicts. Keeping localhost or the local IP as the third entry ensures DNS stays functional in the event network connectivity to the primary and secondary DC's is lost.

When they do the schema update they chew up certain numbers (sorry I forget the right term for them)Generally done in pairs. I've had a case where a vendors schema extension used up 3 of them so the update wouldn'tcompletely take. MS has two spare sets put aside from earlier version of Exchange (there is a KB on it) but I hadto get support to dig me up a couple of extra overs and above that. Thankfully it only happened in the dev domain, prodtook quite happily.

I'm doing Exchange SP2 extension in prod when I get back to work on Monday, dev went smoothly.[edit]

I dug up the case. It was the LinkID that had been used up by another vendor.11900 and 11901 are reserved for problems and also 1138 - 1177. But as always if you run into this I'd double check with MS prior to playing around. I'd also make a note of which ones you've used.

For what it's worth I've never seen a MS provided schema extension fail.

Myself either, but I also avoid any 3rd-party schema extensions like the plague.

Why? LDAP is intended to be extensible. AD is not *really* LDAP (it's a mutated x500 which can be viewed through LDAP/ADSI but if you are changing LDAP specific properties (adding objects or editing existing objects) and make sure you are using OIDs properly you should have no problems. We've added a lot of custom fields etc to our forests and I have not seen any issues.

IMO most "scheme extension problems" are actually replication issues that existed before trying to change the schema.

That's pretty much what I do as well. Don't yank the network connection from the Schema master, it likes to be able to still talk to other machines during the process even though it won't be doing outbound replication thanks to step #2.

For what it's worth I've never seen a MS provided schema extension fail.

For what it is worth, these steps worked fine. The Schema upgrade went fine, no issues.