Building Your Own Group Policy Virtual Lab

It's a been a long time since I wrote anything about Group Policy.  I'm sure some of you are happy about that, and maybe wish I'd take even longer, but oh well.  You must endure the torture that my second-rate writing brings to unsuspecting eyeballs and those with challenged mouse clicking fingers.

Lot's of folks are skiddish (not Yiddish, an entirely different thing) about practicing and learning about Group Policy in a "safe" and protected environment.  Some will simply create a few "test" OU's and test user and group accounts in their production Active Directory environment.  That's risky.  It can actually be downright "stupid-dangerous".  Two words that go together like bacon and eggs, Tom and Jerry, politics and lying, and a few others.  The key word is "tatooing", which can render your environment, in technical terms: fucked up beyond all repair (that's FUBAR).

The better, smarter, safer way to go is using a virtual environment.  If you haven't used a virtual machine setup before, maybe you've just read and heard about the concept, it's very easy.  VERY easy indeed.  And not only cheap, but FREE.  I have to assume that if you're working with Group Policy, then you have an Active Directory environment nearby.  If you have Active Directory, then chances are you have Windows Server handy.  You are ready to go.

1. Install a Virtual Machine product.  There are several free products to choose from, including VMware Player, Sun VirtualBox, and the ubiquitously sucky-ass VirtualPC from Microsoft, among others.  I prefer VMware Player or VirtualBox.  If you can afford VMware Workstation that's a better option since it supports "snapshots", which are very VERY helpful.
2. Create your Virtual Machines.  You will need at least one Windows Server VM and at least one or two Windows client VM's.  For our examples, and because I **LOVE** Group Policy Preferences (or GPP's), I will recommend Windows Server 2008 or 2008 R2, and Windows 7.  If you need to support XP in your environment, then by all means: add a Windows XP VM to your mix.
3. Prepare the Virtual Machines.  Go ahead and install the operating systems and name the computers and install any/all updates.  I also recommend downloading any utilities like Admin Tools, Resource Kits, Sysinternals tools, and so on.  Be sure to consider item #4 during this step as well.
4. Be Careful with Network Settings!  While you are building each VM, you can leave the network setting to "bridged" or "NAT", so that you can download updates and utilities, etc.  But before you make the jump to creating the AD domain environment, move all your VM's into a private virtual network.  This is VERY important!  I won't dive into the procedure for this because it's best left to the documentation for your chosen product.  It's not difficult.
5. Promote the first AD Domain Controller.  Go ahead and add the AD Domain Services role and run DCPROMO to create the first domain controller.  Make sure you are running in a private virtual network first!!  If you use Windows for DHCP management be sure to disable the built-in DHCP service provided by the virtual machine software.  Document the settings!  The Forest/Domain names, IP addresses, server names, admin and DSRM recovery passwords, etc.  After the DC is promoted and rebooted, be sure to give it some time to settle in, then run through your diagnostics to make sure it is operating properly.
6. Join Desktop VM's to the Virtual Domain.  Set up each desktop VM and join them to the new domain.  Make sure they join properly and everything connects together.  This will feel like putting together a playset for your kids.
7. Snapshot or Backup.  If you have VMware Workstation make snapshots of each VM to provide a fall-back restore point so you don't lose all the work you've done to this point.  If you don't have snapshots available, you can simply power down each VM (using the internal "Shutdown" not just killing the VM) and copy the pertinent config and disk files to another location.  The intent here is to avoid losing all the work you've done.  If you screw up your lab, or the physical host crashes, you can rebuild and get your lab back to this point in time and save yourself a lot of pain.
8. Start Playing.  Now that you've got your lab up and running, and you have the safety net of a backup or snapshot, you should be ready to start trying things out.

As a standard practice, I recommend installing RSAT on one of your Windows 7 VM's so you can manage AD and Group Policy features from a desktop, rather than relying on logging into a DC every time.  This is usually more realistic.  It's not usually recommended to constantly log into a DC to do daily check-ups and modifications unless you have to.  This is especially true if the DC has other roles on it like File/Print, Web services and so on.

Even though you are in a VM environment, it is still a good idea to create test OU's and test user accounts, test groups, test computers, shares, and so on.  This offers you additional layers of safety.  It's easier to blow off a bad GPO configuration against a test OU and test accounts, than it is to recover the entire VM environment.

The scope and scale of your virtual environment is only limited by two things: disk space and memory.  Those are both limited by budget.  If you have the budget to expand your disk storage capacity (and redundancy) and add memory, do it.  It's worth it if you intend on making this a serious project.  There is no such thing as too much memory or storage capacity.  The more you have available, the more you will consume.  That's a fact of nature.

If you have enough resources available you can expand your environment and your testing to include things like sub-domains, multiple forests, multiple sites and site link replication, DNS configurations, DHCP scopes and options, VLAN's and so on.  You can also add other products to your environment such as Sharepoint/MOSS, System Center products like Config Mgr, SCOM, DPM, as well as Exchange, WSUS, and other products (not to mention scripting and non-Microsoft products).  It's also perfect for practicing those topics for your upcoming certification exam that you may not even have in your production environment.

But I digress.

The point of this article was to help with building a virtual lab to work with Group Policy.  I got a little sidetracked, but hopefully in a good way.  I hear from people all the time that say they are hesitant to practice with Group Policy settings for fear of breaking their environment or creating a mess they might have to dig their way out of (adding yet more work to their already busy day).  Having a virtual environment allows you to try things and not impact your real environment, so you can move ahead without the worries.  Take an afternoon, stay after work, or a weekend morning, and build your virtual lab.  It'll pay off for you, I promise.