To cut to the chase- bottom line- schema rollback = forest recovery. --Additional detail
All due respect to Carl's link and it's author, that is not the party line from MSIT any longer, they do not recommend taking the SM offline and as noted in the blog comments, some updates fail unless there is successful replication, PDCe is reachable etc. You will actually find a lot of the links to the older guidance on MS sites mentioned in various blogs and forums are now defunct(AKA 404) I saw Brian Puhl (Directory Services Manager in MSIT or some such title at the time) make a presentation at DEC (now TEC) 4 years ago to that effect and it is repeated and reinforced by the MS DS Product Team every year. He actually had a big red x over the "How MSIT does Schema Updates" blog posting on one of his slides. >From that slide- 1. Admin stare & compare, documentation review, understand the changes! 1. Deploy in a test environment that resembles the production domain 1. Follow change control process for notification, scheduling, etc... 1. Install Do's Communicate with the other services about what you're doing Test and Document so you know what it's supposed to do Don'ts Try to prevent the data from replicating out Install the schema, until you are SURE that you want it Think that your "backout plan" is anything less than a forest restore Notes: We took it off and revising it, because "in the before time" we would pull servers off the network, change replication topologys, and do all this crazy work... and then we found that we were way too late in the process...we should have been focusing our FUD BEFORE we ever pulled the trigger...if you want to extend the schema, but "aren't sure", then you shouldn't be doing it in the first place... 1. Stare and compare - this is how we ended up finding out that Exchange was granting itself the right to manage replication - if you don't know what the prep's are doing (and it's not always all documented by MS or every other app provider) then you don't know what's in your directory - and finding out after the fact is a major hassle 2. No, ours isn't EXACT, but from the schema, security, and GPO perspective it's a match 3. The 240,000 mistake 4. If you've done your "due diligence", then pull the trigger on the damn thing and let it go Comment by Laura Hunter from a thread on this topic on activdir back then- http://www.activedir.org/ListArchives/tabid/55/view/topic/postid/26689/Default.aspx 03/24/2008 3:40 PM It's actually worth noting that the MSIT guidance in that webcast is a bit outmoded (unsurprising, with it being 2 years old and all.) At Brian's "How MSIT does..." chat at DEC a few weeks ago, the current prevailing wisdom at MSIT on schema mods is as follows: * Decide what you want to do * Understand the ramifications of it * Test it * Test it again * Do it. (But do it with the understanding that the recovery from a bad/unwanted schema mod is, make no mistake, a -full forest recovery-.) In terms of taking the Schema Master offline/stopping outbound repl/other similar gyrations, the curent MSIT thinking seems to be "We don't do that anymore", as this seemed to be adding much unnecessary FUD around the prospect of schema mods. Does this mean that the advice from 2 years ago doesn't work anymore? I would say not, and if it's a process that your org is comfortable with then for my part I would further say 'go with God'. I'm just reporting on the latest takeaway from "How MSIT does...", as it's different from what was being advocated in the link listed by Ken. From: Webster [mailto:[email protected]] Sent: Friday, June 08, 2012 1:04 PM To: NT System Admin Issues Subject: Re: Schema upgrade/rollback http://blogs.technet.com/b/janelewis/archive/2009/05/12/schema-what-is-the-best-practise-for-updating.aspx Carl Webster Consultant and Citrix Technology Professional http://www.CarlWebster.com<http://www.carlwebster.com/> From: David Lum <[email protected]<mailto:[email protected]>> Reply-To: NT Issues <[email protected]<mailto:[email protected]>> Date: Friday, June 8, 2012 2:32 PM To: NT Issues <[email protected]<mailto:[email protected]>> Subject: Schema upgrade/rollback In this day and age of VM's, what would be the simplest way to test and possibly roll back a schema extension? Would this work? Power down all DC's Snapshot schema master Power up schema master Extend schema Smoke test If there are failures revert to snapshot If all checks out OK power up remaining DC's ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
