Share via

Schema - What is the Best Practise for Updating ?

  • Article

This has been a question that has come up with several of my customers recently. Therefore I thought this would be a good topic to discuss. Modifying the Schema is something that is a necessary action prior to carrying out installation of Directory Enabled Applications whether they are Microsoft or 3rd Party. Plus of course if you are looking to Migrate from 2000, 2003 to 2008 you will need to firstly undertake a Schema Updates. Each Schema update whether it is big all small should have a consistent approach in dealing with it. This is because of the potential impact it has on your Active Directory if it goes wrong. Therefore great attention to detail should be applied to both process and procedure.

Check List for Good Practise for Schema Updates Process and Application.

Process and Procedure

Create a highly Structured Process to Schema Updates this involves;

  1. Validation and Justification of the Update – Remember this is a one time procedure affecting the entire Forest.
  2. What type of change is this (Update, Modification,Depreciation)
  3. What is the Risk ?
  4. Ensure if this is a customized update that you obtain a valid of .LDIF files to analyze with complete documentation
  5. Have complete explanation of the update written and approved
  6. Have a list of Roles and responsibilities for the Schema Update
  7. Is this schema update an update that is really required ?
  8. Is this the only way to effect your change ?
  9. Check whether base schema already has attributes or objects in it.
  10. Staging of Schema Changes (Pre-Production Forest to Production Forest). to test this out to ensure there are no problems thoroughly first.

One approach of sever that has worked for myself and colleagues with customers is as follows;

Suggested Schema Update Physical Process

1. Add new DC

2. Allow to replicate

3. Transfer Schema role to new DC

4. Allow to replicate

5. Check its replicated and the fact that this DC holds this role has replicated throughout the Forest

6. Make sure you have a verified backup of at least one Domain Controller per Domain in the Forest prior to the Schema Update.

7. Isolate the new DC (remove network cable) and to ensure it is not replicating due to accidential re-insertion of the cable

 Repadmin /options <dcname> <+/-> <DISABLE_INBOUND_REPL/DISABLE_OUTBOUND_REPL

8. Update schema

9. If the Schema update is verified as being OK allow to replicate by reversing the Steps in step 7.

10. Transfer role to old DC and remove new Domain Controller

11. if not OK , destroy DC and remove it from config and DNS (metadata cleanup)

There are other approaches. For example by doing the schema update on the Server that holds the role and not introducing a New Domain Controller into the Forest for just this action. Both ways I have worked with successfully.

The key to the success of a Schema Update is to ensure you THOROUGHLY test it prior to deployment in a pre-production environment. Plus also ensure the update is well written and checked prior to deployment on the Domain Controllers.

I recommend watching the WebCast on this subject see below for link. Also the picture below is a screenshot from the verification process MSIT go through prior to applying a Schema Update to our Live Environment.

FLowControl

Some Excellent References for this are;

https://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032381512&CountryCode=US

How Microsoft does IT: Structured Active Directory Schema Management at Microsoft

https://technet.microsoft.com/en-us/library/bb687810.aspx

 https://blogs.technet.com/btrst4/archive/2004/10/13/242064.aspx

Comments

  • Anonymous
    January 01, 2003
    I totally agree that it is best practice do a schema extension offline. However you should keep in mind that more and more applications do not allow this. Two examples: 1) Exchange comes with an integrated setup which does a domain and forest prep which cannot be executed when your schema master is offline.
  1. LCS 2005 schema update needed the PDC to be reachable. What you can do in such cases is to bring one DC offline during the update which keeps the former schema and to disable outbound replication on the schema master. In cases where you can do an offline schema update you should also consider to separate more than one DC from the network so that you can quality assure that the new schema can be replicated to partners.