Active Directory Schema upgrade procedure - with back-out plan
The aim of the procedure in this post is to avoid you to dig around the technet to rebuild it. It’s written for Exchange 2010 SP1 here, but can easily be adapted for any product schema updates by replacing the Exchange 2010 SP1 values and links !
AD Schema upgrade procedure with verifications (can be adapted as a general procedure by changing the Exchange 2010 SP1 references and values)
Perform Exchange server 2010 SP1 schema extension, the full procedure list is available online at https://technet.microsoft.com/en-us/library/bb125224.aspx :
1. Confirmation that the “Back-Out Plan” (see below) has been prepared.
2. Logon to the Domain Controller holding the Schema Master FSMO role using a credential that belongs to the Schema Admins security group and Enterprise Admins security group.
3. Dump the current schema into a file for comparison. From a command prompt, run the command: Ldifde -f Before_Schema_Update.ldf -d "cn=schema,cn=configuration,dc=domain,dc=root"
Important note : although the following step technically works, blocking AD replication by any means is not recommended, and not supported by Microsoft. As my colleague and AD expert Tanner Slayton comments (taking his words as these are complete and meaningful), Microsoft Best Practices are to test the upgrade in a Lab, ensure that a tested and well-documented Disaster Recovery plan is in place (e.g. including a detailed authoritative restore procedure of the AD to recover a previous good AD state in an unlikely case of corruption during the schema update), validate the schema extensions using Step 6. below for example, and ensure all DC's are healthy and replicating properly.
<***update**** Unsupported and not recommended... test in a lab, document DR plan, rely on this DR plan in case of schema update issue **********>
4. Ensure no replication from this Domain Controller is going to replicate to other server until Schema Extension is completed and verified:
a. Disable Outbound Replication on the server
i. At a command prompt, run the command: “repadmin /options +DISABLE_OUTBOUND_REPL” without the quotation marks.
ii. Unplug the physical network connection to ensure no communication could occur with other domain controllers.
<***update**** Apart from the above "+disable_outbound_repl" steps and the below "-disable_outbound_repl" on Step 8., the remainder of the article remains well supported **********>
5. At a command prompt, run the command “setup /PrepareSchema” from the folder where the Exchange 2007 SP3 installation files are located.
6. If there is no error during the schema extension, then verify the current schema version.
a. Open ADSIEdit and check the Schema version located in:
CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC <root domain>
Attribute: rangeUpper
For Exchange server 2010 SP1, the value should be “14726”
b. In the same ADSIEdit session, check the ObjectVersion location in:
CN=<your organization>, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain
Attribute: ObjectVersion
For Exchange server 2010 SP1, the value should be “13214”
c. Dump the current schema into a file and compare with the one obtained in step 3. From a command prompt, run the command: Ldifde -f After_Schema_Update.ldf -d "cn=schema,cn=configuration,dc=domain,dc=root"
d. Compare the content in the file Before_Schema_Update.ldf and After_Schema_Update.ldf to ensure proper extension is completed. For a list of schema changes applied by Exchange server 2010 SP1 is available online at https://msdn.microsoft.com/en-us/library/dd877014(EXCHG.140).aspx
7. If the schema extension is unsuccessful or error was encountered during the extension, perform back out procedure for Schema Extension.
<***update**** Unsupported and not recommended... test in a lab, document DR plan, rely on this DR plan in case of schema update issue **********>
8. If schema extension is successful and verified
a. re-enable Outbound Replication on the server
i. At a command prompt, run the command: “repadmin /options -DISABLE_OUTBOUND_REPL” without the quotation marks.
ii. Re-connect the network cable
<***update******* Apart from the "+disable_outbound_repl" steps on Step 4. and the above "-disable_outbound_repl" on Step 8., the remainder of the article remains well supported **********>
9. Force replication of Active Directory
10. Allow time for replication to be completed before execution of this step. At a command prompt, run the command “setup /PrepareAD” from the folder where the Exchange 2010 SP1 installation files are located.
11. For every domain that you have Exchange servers deployed and users having Exchange mailboxes, run the command “setup /PrepareDomain” .
***Update: The below back-out procedure takes into account the steps used to disable replication above, which are not supported and not recommended by Microsoft any more.
Instead, the recommended Back-Out plan procedure is to have a well-documented and tested DR procedure including an authoritative restore procedure in case of AD corruption.
Back-out plan Procedure (never had to use it but it’s a parachute/belt/mattress to sleep well)
In case of incomplete schema extension or getting error during the schema extension, to avoid for any partial update of the schema to be replicated to other Domain Controllers, we must follow the steps below:
1. Power off the current Domain Controller that we’re working with, i.e. the current Schema master.
2. Go to another Domain Controller in the same domain, and seize the Schema Master FSMO role:
a. Logon to the Domain Controller using a credential that has Enterprise Administrator privilege
b. Click Start, click Run, type ntdsutil in the Open box, and then click OK.
c. Type roles, and then press ENTER.
d. Type connections, and then press ENTER.
e. Type connect to server <servername> , and then press ENTER, where <servername> is the name of the domain controller that you want to assign the FSMO role to.
f. At the server connections prompt, type q, and then press ENTER.
g. Type seize Schema Master.
h. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.
3. Perform meta data clean up to remove the domain controller we use for Schema Extension, this is to ensure non partial schema extension get replicated:
a. Stay logon to the same server with the same credential as in step 2
b. Click Start, click Run, type ntdsutil in the Open box, and then click OK.
c. Type metadata cleanup, and then press ENTER.
d. At the metadata cleanup prompt, type remove selected server <ServerName> where <ServerName> is the distinguished name of the domain controller whose metadata you want to remove, in the form of cn=ServerName,cn=Servers,cn=SiteName,cn=Sites,cn=Configuration,dc=ForestRootDomain
e. To verify that the server was removed, type list servers in site, and then press ENTER. Ensure that the domain controller that you wanted to be removed is no longer displayed in the command output.
f. At the metadata cleanup: and ntdsutil: prompts, type quit.
Important: If the domain controller that was removed was also a DNS server, ensure that references to it are removed from the Name Servers tab in the DNS console. To do this, open the DNS console using another DNS server in the domain (dnsmgmt.msc), and then click the domain name under Forward Lookup Zones. Remove any references to the domain controller that was removed from the domain.
4. Clean up all DNS record related to the old Schema Master server
5. Format the old Schema Master machine, reinstall Operating System, Reset computer account for the old server name, join back into the domain and prompt to Domain Controller and Global Catalog if that was its old configuration.
Full documentation of how to clean up the Active Directory after an unsuccessful demotion of Domain Controllers, which is similar to the situation we have here, is available online at https://support.microsoft.com/kb/216498.
Comments
Anonymous
January 01, 2003
Doh! - Perform Exchange server 2010 SP1 schema extension, the full procedure list is available online at http://technet.microsoft.com/en-us/library/bb125224.aspx : That is for 2013 not 2010Anonymous
January 01, 2003
Hi Frank, In fact among other tasks, /PrepareAD verifies that the schema has been updated and that the organization is up to date by checking the ObjectVersion property in Active Directory from this AD object which is the one indicating the schema preparation level : >>> CN=<your organization>, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> If not, the /PrepareAD will include the /PrepareSchema or /PS. Source : technet.microsoft.com/.../bb125224(v=exchg.141).aspx But /PrepareAD will also set the ObjectVersion but from this AD object which is the one indicating the Domain preparation level : >>> Microsoft Exchange System Objects container under DC=<root domain>. There are indeed two "ObjectVersion" parameter, one for the overall schema, and one for the domain preparation version. Cheers, Sam.Anonymous
March 15, 2013
I believe you have a mistake in your plan. OjbectVersion isn't upgraded until setup /prepareAD is run.Anonymous
September 23, 2013
@Frank : you're right, I made a mistake in the ObjectVersion check chronology, will make the change asap, thanks again !