Schema – What is the Best Practise for Updating ?

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.


Some Excellent References for this are;

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

Comments (8)
  1. Anonymous says:

    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.

    2) 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.

  2. Anonymous says:

    Great post! Thanks.

    Just in case you want to check if replication completed on all DCs after schema update you can easily use Powershell:…/check-objectversion-on-all-domain-controllers-after-schema-update-with-powershell

  3. As this is great post I would add just one comment to #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 (…)

    If this DC will be isolated you have to make sure that it will replicate with its partner before schema will be extended as otherwise it will refuse this operation. Because of that sometimes two DCs are being isolated in separated network, which gives you additional opportunity to check replication between those two before going with it forest wide.

    Second command is about repadmin usage: remeber that this will not prevent replication if admin will request it, for example with /force option. So make sure that all people with such privileges knows that they should not do this at this time.

    As this is valid approach it is more common that schema changes are being incorporated on-line after testing in lab environment and doing AD health check before operation. But it depends …

  4. James Carter says:

    This   article is very much useful  as I think. The description is too good. I was looking  for such article. I have read a similar  article here ".…/active-directory-schema&quot; which is very helpful also

  5. rosenthal says:

    Dealing with legal battles can be very problematic. Time can really be one of your biggest competitors. Complete fair settlements may take even up to a year just to be achieved. Do you think you have that much amount of time to spend?
    the venus factor reviews

  6. ewrwerew says:

  7. rrewwrewree says:

Comments are closed.

Skip to main content