Testing Schema Updates
25/05/13 14:08 Filed in: Windows
How do you test schema updates in your systems?
====
It’s an incredibly hard subject to fully qualify really but at a basic level you need to know what happens when you apply a schema update to your system. Like I say, I’ll go in to the ins/outs in upcoming articles - but a very basic level it’s a good start to have a copy of your system to work from for testing purposes.
Performing Schema updates on your live Active Directory - from a change control perspective it can fill you with fear can’t it? It’s one of the few functions that are forest wide, and effectively irreversible (bar a forest restoration process).
To be absolutely fair, they very rarely go wrong - and even when they do, hardly anybody notices. What’s going to go wrong? A system breaks in the middle of the update? Usually you can just run the update again and let it finish. The biggest risk is from ineffectual planning. I mentioned a while ago that a friend of mine had rather unfortunately committed a schema update to their live systems without doing the prep for a previous edition - and of course, this negated their ability to implement the platform they wanted. It wasn’t unrecoverable - but it was … a little stressful to do. Editing your schema is not for the light hearted. I’ll happily dive in on a demo or test platform - but live? I’d avoid that at all costs. Article here for example on removing an Exchange 2013 domain prep:
Removing an Exchange 2013 Schema Prep
It gives you an idea of what’s involved anyway.
I spend a lot of my time designing and being involved in the implementation of Microsoft Lync - and that always involves a schema update. I’m always slightly surprised at most company’s attitudes to schema updates. Pretty much 90% of them think ‘pah, what’s the worse that could happen’…and continue on regardless. A high percentage of them have little idea of what’s involved if it goes wrong.
My bigger clients usually have at least thought about it - some of them even tested recovery of the forest.
From a consultative point of view, I always try and include the ramifications of what’s about to happen with the recovery routes - I.e. attribute/schema updates, and how hard it is to roll back. On a tangent for a second - I get why a lot of techs see change control as a pain, and slowing down their day job - I try and look at it another way - it’s transference of risk and responsibility. If you make completely clear what is being done, what the risk is, and what the recovery method is - the decision to go ahead is with the business, not with the tech. As long as you’re broadly right you’ve made the business able to make a reasonable business decision against risk.
Anyway, I’m getting ahead of myself. Testing of schema updates, and forest recovery, are fairly key to any system really - and on that front I’m surprised by how many companies don’t do it. I suppose in some ways that goes to show how general reliable it is. I’ll be producing a number of articles on how to risk-assess, protect, and recover from schema updates - and this is just one of those base articles. There’s a lot of noise on the best ways of doing this out there though - so would be interested in what people think.
Let’s look at how you can create a copy of your Active Directory for testing purposes. It’s simple enough to do - and there’s a few ways of doing it. Firstly, let’s cover how to create a replica by implementing a new domain controller, synchronising it, then physically removing it and seizing the FSMO roles on that unit.
You can read about that process here:
Duplicating Active Directory for a Test Environment
Some people don’t like this method as they think it’s risky and a little dirty - and I kind of get why they would think that. It’s also possible to do a normal forest recovery type restore, and we’ll look at that next….
blog comments powered by Disqus