In this series of six parts, I will show you how to prevent and solve Group Policy problems. In this first part, I will outline why communication with your users is important.

Group Policy is a great tool that can make your life a lot easier as a systems administrator. But, what do you do when computers or users aren’t getting the correct policies? In this series, we’ll take a look at things you can do to prevent problems, common problems people have with Group Policy, and steps you can take to troubleshoot misbehaving Group Policy.

“An ounce of prevention is worth a pound of cure.” — Benjamin Franklin. Those words definitely ring true for deploying new Group Policy settings. There are a number of things you can do before deploying changes that may cost you some time up front, but will definitely save you time and grief down the road.

(more…)

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.

I can’t stress enough how important it is to test out your new Group Policy settings before you start pushing them out to end users. How do you know they will work correctly in the real world if you haven’t tested them in a controlled lab setting first?

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.

(more…)

Group Policy settings are not applied? In this third part of our Group Policy troubleshooting series you will learn how to identify the source of the problem.

So you’ve got computers or users with Group Policy problems. Where do you start? Troubleshooting any problem is usually a process of elimination. A lot of people want to run directly to the Event Log of the computer having the problem. Before jumping on the first computer where Group Policy is not applied, I suggest asking a few questions first so you can eliminate possible causes. A little detective work up front can make tracking down the actual problem much easier and may save you some time digging through logs.

Is this a local system or a remote (probably VPN-connected) system?

Some policies behave differently depending on whether a user/computer is connected directly to a LAN or remotely over a slower connection. For a remote user, the computer may have identified the connection as a slow link and may not be enforcing all settings properly. Additionally, some settings like Folder Redirection and scripts only run during a reboot and may require pre-logon VPN access to network resources like file servers or they won’t run. If the user is connected remotely, you may need to recommend that they connect to the VPN prior to logging into AD so their policy can process.

(more…)

Client issues are often cause for Group Policy problems. In part 4 of this series, I will discuss tools such as gpupdate and gpresult which helo you to tacke these problems.

When all else fails, reboot!

There are a few changes in Group Policy that require a reboot for the computer or a logoff/logon for the user. If you have clients that go long periods without rebooting or users that just lock their computers at the end of the day, this could be why some policies aren’t updating. If you’re deploying software to computers, using Folder Redirection, or have startup/shutdown scripts, you’ll need your computers to restart occasionally. The same goes for logon/logoff scripts, if you’re relying on scripts in your policy for changes, users will need to actually log out on occasion to get changes. If you can, time your policy changes that require a reboot with Patch Tuesday since the computers will, most likely, reboot to apply patches.

Wait… or run gpupdate

Group Policy refreshes every 90 minutes with a randomized offset of 30 minutes. If you change a policy right now, it could be as much as 2 hours before all of your clients get the policy. (Depending on how long Sysvol replication takes in your AD (or if you have a DC on the other side of a slow connection), it could possibly be longer.) If you made the change an hour ago and clients aren’t getting the setting, that’s completely normal. On the client, you can run gpupdate.exe to update changes that have been made to Group Policy. Running a gpupdate.exe /force will ignore any processing optimizations and reapply all of the Group Policy. Or, you can just keep on waiting until all of your computers complete their regular refresh.

(more…)

Of course, Group Policy relies on Active Directory. Part 5 in your Group Policy troubleshooting series covers typical Active Directory problems that prevent Group Policy from working properly.

DNS

If you’ve gotten to the point where it looks like Active Directory (AD) is the problem, you’re most likely looking at some kind of replication issue. By far, the most common cause of AD replication problems (short of failed DCs) is DNS. Are you using AD integrated DNS? Are your DCs pointing to each other for DNS? Are the firewalls between each DC open on the correct ports?

Event Log

So the obvious place to look first is the Event Log. If you’re having replication problems, you’ll have errors in the Event Log, most likely a lot of them. Take a look here first for anything actionable.

GPOTool

GPOTool.exe is a handy utility that Microsoft puts into the Microsoft Product Support Reports suite of utilities. It is buried a bit, but after extracting the executable before installing the tools, GPOTool.exe can be found in your computer’s temp.

Running GPOTool.exe from one of your DCs without any switches will run through all of your GPOs and verify that your Group Policy Templates and Containers are synced and consistent across all of the DCs. You can also use the /gpo option if you just want to check one specific GPO.

(more…)