Troubleshooting Group Policy – Part 2: Test and deploy

You test your Group Policy changes before you push them out, right? This second part of six shows you how you can test Group Policy settings before you deploy them.

Author
Recent Posts

Kyle Beckman

Kyle Beckman works as a systems administrator in Atlanta, GA supporting Office 365 in higher education. He has 17+ years of systems administration experience.

Creating a Group Policy test environment

In larger environments, IT departments may have a Test Active Directory Forest just for testing things like Group Policy. Unless you’re applying Group Policy to thousands or tens of thousands of computers, that may be overkill for your organization. Here’s what I typically do to test:

In my Active Directory (AD) organization, I like to keep a “Test” Organizational Unit (OU) that mimics a typical OU for a department. In that OU, I keep the same sub-OU layout, a few test user accounts, and test computers (usually virtual machines) where I can put any of my test Group Policy before I make it available to end users.

Within the Group Policy Management Console (GPMC), it is very easy to make copies of Group Policy Objects (GPOs) by going to the Group Policy Objects container in the Group Policy Management Console (GPMC), right-click on the GPO, choose Copy, and then right-click again, and choose Paste. I usually make a copy of the original GPO and include “TEST” in the name and link it inside of my Test OU. This gives me an OU where I can make changes to my policy without causing problems for existing users or computers.

GPMC with Test GPOs

Should I use physical computers for testing Group Policy or virtual machines? Personally, I prefer to test with VM’s. Why? If you mess up and lock down a computer to the point that it becomes unusable, you may have to re-image the computer. With a VM, you can rely on snapshots to go back in time without having to spend time or effort fixing the problem. Just be aware that if you decide to use Microsoft Virtual PC, the Undo Disks functionality is limited to rolling back to the last state of the VM. If you’re running Hyper-V, that is typically my choice for VM testing. If not, you can either spend the money for VMware Workstation or get VirtualBox for free.

Test real world scenarios

When you test your new policies, ensure that you’re also testing against computers and/or users that had the old policies applied and that have been in use by real people. In a lab setup, operating systems have this habit of having cleanly applied images that have never been used. User accounts and the files and settings that account have access to are pristine and haven’t been customized or changed. Some user policies can be affected by previous settings in the user’s profile. The biggest place where this happens is Folder Redirection. You’ll want to make sure that the settings that you’re changing take both new logons and existing logons into consideration. A good way to do this is to have some users that can test your changes when you’re almost ready to roll them out to everyone.

Stage changes

Depending on the change you’re making, you may not want to roll it out to every user or computer at the same time. For major changes, I usually like to drop a few user and/or computer objects into the Test OU and allow those objects to run for a few days. In addition to being a good way to test how the change works in the real world, it gives me the chance to see if anything is going to break or cause problems for end users before the change is rolled out to everyone. It is much easier to deal with a few unhappy customers that are having problems than a lot!

“Dog food” your Group Policy

As an IT department, I highly recommend “eating your own dog food.” From a Group Policy perspective, that means that you should have the same GPO’s applied to your day-to-day user account and computer that all of the other users in the organization are getting. It should also mean that new policies should get applied to you first. The quickest way to see how a Group Policy change will impact end users is to use it yourself every day. How do you know that a particular script makes logons slow if it doesn’t apply to you every day? How do you know that the screensaver timeout is too low unless you’re constantly having to log back in because you have the setting, too? How do you know that disabling certain settings hamper a user’s ability to work unless you have to deal with the same issue?

Resultant Set of Policy (Planning)

I’m mentioning the RSoP in Planning mode last because I personally have never gotten much usage out of it. In Active Directory Users and Computers, you can right-click on a User or Computer object, click All Tasks, and click Resultant Set of Policy (Planning) to see how policies will apply to users and computers. RSoP Planning will let you pick a user and computer and then select options like Site, slow network, Loopback mode, group memberships, and WMI filters to see what policies will be applied to a user and computer.

RSoP Planning Wizard

The problem? The output that you’re given makes it impossible to see the results of your policies. You’ll have to manually dig through everything. It is probably quicker to have a VM, drop it into your Test OU, and just test out the policies yourself to see if you’re getting the results you want. The gpresults.exe tool (which we’ll get to in a later article) gives much easier to read results.