Tag Archives: Lab

Active Directory: Built a mirror lab before?

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.

Technology Spotlight: Windows Server 2012, what does it mean to me?

By Robert Meyers

The release of WS12 is going to have a major impact on all of us who implement and manage Windows environments. There are major changes and we are all going to learn them or go the way of the dinosaur.  As someone who grew up in CP/M, trust me: it can be done.  So what are the big standouts on changes that I am going to have to worry about?

First off we have the interface, and for the first time since Windows NT 4, we have a major interface overhaul.  And I mean a major overhaul.  To me it seems like an amalgamation of Windows 2000, 3.0 (yes, 3.0) and Windows Phone 7.  Does it work?  Yes.  Do I consider the look somewhat hideous?  Yes.  Could I get used to it? You bet.

PowerShell V3 for the win. When you add domain functionality you get a link that lets you output the settings.  These are actually an output of a PowerShell script.  PowerShell is now everywhere… as it should be.  The days of DOS, PowerShell V1, PowerShell V2, Quest PowerShell and VBS being mixed everywhere is done.  When servers are 2012, PowerShell V3 rules the roost and renders the others inconsequential.  Now, if you are a VBS guy, well, as a CLI guy, I feel for you… but get over it.

While I am going to skip talking about all the incredible new features of 2012, let me just set one expectation: Active Directory Domain Serveries 2012 is a massive upgrade.  Not a minor update like 2008 R2, where you received great functionality with hideous management so people just ignored it.  No, you gain everything.  Features, functionality and most of all usability; Server 2012 has it all in the new version of Active Directory.  Think of all the pain we have all gone through trying to convert from Quest PowerShell to PowerShell V2 AD Cmdlts?  Well everything you do now is shown with its PowerShell syntax.

I really want to go over the new functionality like the new virtualization safe domain controller cloning or the death of the USN rollback… but let’s not get ahead of ourselves.  Download the OS and install it.  It took me 30 minutes to download, install and configure Active Directory.  How long do you want to wait to lab yours?

Technology Spotlight: System Center 2012 Unified Installer, Disaster?

By Robert Meyers, MCITP

As we have all waited with baited breath, Microsoft System Center 2012 has been released.  Now that it has been out for a few months and I have been done both lab and production installs, and our team has done more of the same, it is time to discuss some of these new products.  So where better to start than the new and improved installer?

Microsoft writes, “System Center 2012 – Unified Installer is a tool that provides a single-user-interface experience for the installation of [all] seven System Center 2012 components, including all prerequisites and Microsoft SQL Server 2008. Unified Installer provides a means of distributed installation from a central point using the existing component Setup.”  Does that sound awesome?  You bet.

Now how many people here have heard the old saying that Microsoft only gets things right on the third incarnation?  Let’s just say this is not the third incarnation.  After speaking with multiple System Center implementers there seems to be a problem.  We all are averaging only about 50% success rate in installing the suite with this tool.

So, if you are in a lab environment, give it a try.  If you are implementing it without a schedule, give it a try.  When this works it is like a dream.  When it doesn’t… it is nearly impossible to troubleshoot.  So, if it doesn’t, you may have your work cut out for you.

So my take on the System Center 2012 Unified Installer? This product is an unmitigated disaster and an unfulfilled dream.  Microsoft, please fix it.


Tech tip:

When importing software into SCCM, check IT Ninja and see if they already researched all the switches for you.  You may be able to save days of work in minutes.  Just remember, share here when you discover new techniques.