How to extend AD schema without replicating to other servers

Hi guys,
In this post I’m going to talk about a safer way to extend Active Directory Schema – if you have to.
Let me start by stating this – I’m in the business for quite some time, I’ve extended the schema many times – for Exchange upgrades, for Domain upgrades, for lync and etc…. each and every one of the upgrades was successful without any problems.
But, from time to time I get the question from clients – what if anything goes wrong? How can I be sure that the process is safe?

As you all probably know – extending the schema is irreversible! You can’t just undo this.
Many of you probably think that if anything goes wrong they can simply just do an Authoritative Restore of the Active Directory, and that will solve their problem. Wrong! Authoritative Restore does not restore Schema to an older version. It does, but it restores it with orphaned objects, and that means that other DC’s in the domain will just ignore that Schema Version. The proper way to restore an Active Directory Schema is by removing all Domain Controllers from the network, installing one from scratch, restoring the SystemState on that server and then running Authoritative Restore on that new DC. Then just installing new DC’s…

You can read more on the subject on that Technet page:
to quote:
“Only the domain and configuration domain directory partitions can be marked as authoritative. The schema cannot be authoritatively restored because it might endanger data integrity. For example, if the schema was modified, and then objects of the new or modified classSchema object were created, subsequent authoritative restore might replace the new or modified classes causing serious data consistency problems.”

So the question is – how can I make sure that I have a way back if anything goes wrong?
Well in a case a client of mine wants to be 100% sure that he can revert the process, here’s what I do:
1. If I have more than one Domain Controllers, I take the DC that holds the Schema Master FSMO role, and disable outbound replication on him. To do it, simply run the following command:
Repadmin /Options *SchemaMasterName* +Disable_Outbound_Repl
2. If I have more than two Domain Controllers, additionally to disabling the outbound replication I also shutdown one of the DC’s.

Why do I do it?
1. If the Schema extension process went wrong, because I’ve disabled the outbound replication on that DC, other DC won’t get that Schema update. I will then remove that Domain Controller from the network, Seize the Schema Master role on one of the other DC’s and that’s it 
2. In the situation where I have more than two DC’s, additionally to be able to seize the role, I will also have the ability to completely remove the all Domain Controllers – but the one that was down. Since he was turned off, he didn’t get any replication, I can simply turn all DC’s of (and destroying them) and turn on that remaining DC and working from there.

If everything went well, and the extending of the Schema ended well (and it will!) I can simply remove the flag that disables the outbound replication by running the following command:
Repadmin /Options *SchemaMasterName* -Disable_Outbound_Repl

And making sure that all Domain Controllers are replicated by running the following command:
Repadmin /SyncAll /e /A

If I had a DC shutdown before the process I will only turn it on only after I made sure that the replication to the other DC’s went well – and in fact you can leave him off for a couple of days. Just to make Sure!

What do you think about this post?