By Robert Meyers
Do you have a lab? Specifically, do you have an Active Directory lab? Do you need a lab? Hint: the answer is yes. The modus operandi for the industry has been simple: salvage your old equipment and build an ad hoc lab. Times have changed and that now begs the question: is that really good enough? Nope. It wasn’t back in the day, and it certainly isn’t today.
So let’s get down to business and look at what you need for your lab. One thing any IT professional will agree is that building a lab is an essential part of preparing for a variety of tasks such as an Active Directory transition, an Active Directory migration, Novell Migration, schema changes and the list goes on. Anything that changes your current settings in Active Directory beyond a single account should always hit the lab first. The lab is there so you can do a dry run, practice and validate any process. It is a lab environment. If it blows up, you get the experience gained from rebuilding it.
So a lab should closely mirror the production environment (in every way that is feasible). While it is not feasible to completely mirror production’s many application servers and enterprise computing platforms, it should be as close as possible and account for the business critical applications, at least include a small sampling of those servers. It should also have workstations if you use workstations.
Without a close replica of the production environment organizations cannot successfully plan for potential show stopping events from infrastructure changes. Think of the results from a schema extension preventing a domain upgrade (I have seen these). Think of a time configuration error that is allowing domain controllers to lose synchronization (these are common). Think of a large PowerShell script import of thousands of groups being imported to the wrong OU (stopped this before).
Any process that has an impact on your current Active Directory environment should be tested.
An implementation of a new lab cannot account for the “history” or breadth of the production environment. This includes some of the following examples: schema extensions over time, upgrades of operating systems, administrative changes in functionality, and current policies in effect, and anything you don’t see in a DCDIAG. Everyone agrees that implementing a lab environment using the concept of “mirroring”, or as close to a mirrored environment as possible is crucial to a successful implementation of an upgraded or migrated environment.
There are many strategies for implementing a lab environment but they all have their own caveats to plan for in order to avoid disaster. The best mirror methodology is to introduce a new domain controller in a production domain, replicate all data, remove the domain controller and place it in the lab environment, and then perform metadata cleanup on both the production and lab environments. This gets you a copy of the real environment. In the production environment the metadata cleanup would remove existence the newly promoted DC to avoid replication failures. In the lab environment the metadata cleanup would involve removing all existence of the missing domain controller in the forest. The cleanup consist of seizing FSMO roles, NTDSUTIL being used to clean up the metadata and then going through and manually pruning each side from the other.
There is a major risk for this best of breed lab. The lab environment must be guaranteed to never touch the production environment. If this were to occur, two separate domain controllers would attempt to assume the FSMO roles and would cause all sorts of issues… think best possibility would be USN rollback and dire replication issues. As such, while a lab environment is essential, there are many preventative tasks that must be performed to ensure the lab environment never is in contact with the production environment. This should be locked down by all available security measures. A very critical security concern is if the lab environment is a virtualized environment. Domain controllers are only as secure as the server in which they run on.
I always recommend using a dedicated Hyper-V V3, VMware vCenter Lab Manager or VMware ESXi environment. Please note that this security is essential, as if a VHD or VMDK files end up in production they can potentially cause a true full scale outages and additionally security risks.
Scared yet? Should be. Well this best of breed, is the best of breed but it needs to be done methodically.
Going to give it a try? Good!
Now everyone, let’s work together to make the new IT modeus operendi: just say no to “blowing up” your Active Directory.