locked
extending the schema on detached schema master DC RRS feed

  • Question

  • hello,

     

    as usually happens when a deployment involves extending the schema, the IT management is concerned that something might be wrong resulting in a botched AD. They require a working procedure to fully rollback it in case something goes wrong.

    as pointed out in the following article (http://support.microsoft.com/kb/241594/en-us) the schema cannot be restored authoritatively.

    some have come up with a workaround (well explained here: http://www.pcreview.co.uk/forums/thread-1453388.php and here: http://www.tech-archive.net/Archive/Windows/microsoft.public.windows.server.active_directory/2005-01/1172.html): move the schema master to a freshly installed DC, bring it off the network and extend the schema. If the operation is a success, bring it back to the network and allow the schema to replicate. If not, format the machine and seize the schema master FSMO on another DC on the network.

     

    I tried to reproduce this procedure on a test lab (fresh DC, schema master FSMO + GC) but the OCS schema extension (via lcscmd) failed. Schema extended just fine with the DC connected to the rest of the test netwok.

     

    My guess is that the schema master FSMO and GC wouldn't be enough to perform the schema extension.

     

    Has anybody succesfully tested a similar procedure?

     

    thank you

    doulouz

     

     

    Friday, September 5, 2008 1:42 PM

All replies

  • I've tested Schema updates in lab by performing the steps above, by using P2V processes, and a couple other routines.  Anytime I've ever seen problems it was always related to the fact that the offline lab has some AD related issues due to the process of trying to duplicate the environment in the first place.  Realistically you'll end up spending a lot of time trying to create a duplicate lab, as if you have multiple sites, domains, tree, etc you need to clean up a lot of that stuff in the offline version.  Also, you can never duplicate the intricacies of the actual production environment, so odds are that whatever problem you might possibly run into in the production forest would not appear in a stripped down test forest anyway.

     

    But not once have I seen a problem caused by extending a production Schema for Exchange or OCS or other MS products.  This is a fairly safe procedure that seems to scare some IT management, probably due to the irreversible nature of it.

     

    Also, regarding the process above, I would never pull a DC offline, make changs, and then add it back to the network later on to replicate those changes.  What you should do in that scenario is to deploy a new DC, take offline, seize roles, apply Schema updates, etc.  If it works, then great, kill that box, remove it from the prod DC by cleaning the metabase up with the NTDSUTIL so that the server is removed compeltly from AD.  Then simply perform the Schema updates on the production network as instructed by the guide.

    Friday, September 5, 2008 1:57 PM
    Moderator
  •  

    Jeff,

    i think i'll stick to your last advice, if the management will allow me to do so

     

    thank you for now.

    D

    Friday, September 5, 2008 2:04 PM