Schema updates are important task and it is necessary for applications Operations systems etc. Active directory Schema updates can be done ahead of time or it can be done with installation of first operating system or the application ( most of the time )
In cases where schema updates needs to be done separate ahead of time , you would need to build step by step upgrading schema implementation plan. After extending schema you would need to make sure , existing applications would continue to work.
Testing Active Directory Schema updates can be trick task as schema updates are “One Way” meaning the schema updates needs to get done on your domain controller holds the schema master FSMO role from there it gets replicated to all other domain controllers within the Active directory forest environment. Time to time Active directory engineers will recommend stopping inbound and outbound AD replication on the Schema Master Role holder DC and believing this would prevent schema changes getting replicated to rest of the domain controllers within the environment. Which in reality buys you “Nothing or very little” . When you realize your critical legacy application is no longer functioning due to recent schema updates, your only option is to perform Forest Level recovery and this will be a “surgery” in term of getting everything up and running and especially large environments. The domain controllers you shutdown will only buy you recovery time “recover from your backup , active directory database” and you will still have to deal with having old .DIT , SysVOL etc. to replicate rest of the domain controllers and deal with FSMO roles.
If you are not familiar with process check out my previous article “ Active Directory From Total Lost Disaster Recovery Basic Steps.” and make sure you have developed restoring Active Directory from total lost white paper for your environment.
in order to perform AD recovery You need to understand the BurFlag keys and what they do and how to Perform an authoritative SYSVOL restore Set BurFlags to D4 or none authoritative restore D2 and understand the crucial difference in between.
We will extend the schema from windows 2008 R2 to windows 2012 R2. We will document steps and verify the schema version change.
- Log onto your existing windows 2008 R2 Server via RDP ( Remote Desktop Services) with your domain administrator privileges and provide your credentials when prompted.
- In order to extend the schema you will need to be member of Schema Admins security group.
- After successful logon , click start and on the search menu type PowerShell and press enter.
- On the PowerShell window type
On the PowerShell window type the following one liner PowerShell to find out the current schema version
|Get-ADObject (Get-ADRootDSE).schemaNamingContext -Properties objectversion|
let’s explore the schema version numbers
Schema versions :
- 69 = Widows 2012 R2
- 56 = Windows 2012
- 47 = windows Server 2008 R2
- 44 = Windows Server 2008
You will need adprep folder to perform the schema updates."adprep" folder is located within windows 2012 R2 install CD , under support folder, copy "adprep" folder onto C drive of the domain controller ( windows 2008 R2)
From C:\Temp\adprep folder we will start executing adarep to perform schema updates.
Adprep /? Will show all available options;
Adprep /ForestPrep and press enter , you will need to type letter "C" to confirm and start the schema upgrade.
Schema changes will get done on the schema master first and from there it will get replicated to your other domain controllers. You can use "netdom" to find out the domain controller holds the schema master role and remember there is only one schema master per active directory forest.
Now run the Domain Prep
Now we need to run the PowerShell to get the Schema object version 69 = Widows 2012 R2