- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
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.
Group Policy should refresh on its own without you having to manually run gpupdate.exe on every computer. Running the command manually is a great way for testing or to make sure a user/computer gets the change immediately, but shouldn’t be a necessity on every system. If gpupdate.exe hangs or generates an error, you may need to move on to the Event Log.
Gpresult.exe is a
great invaluable tool for troubleshooting Group Policy that has been improved in Windows 7 and Windows Server 2008 R2. The output of gpresult.exe contains a wealth of information like what GPOs are applying to the computer/user, if the GPO was filtered, if the GPO is empty, whether or not the computer is on a slow link, security group memberships, OS version, site name, roaming and local profile locations, which DC the policy was retrieved from, and much more. Basically, gpresult.exe takes the RSoP data and turns it into something that a human being can actually read.
If you’re running the latest and greatest, you can run gpresult.exe /h nameofyourreport.html and get a pretty HTML report about what GPO’s are applying to the current user that looks just like the Setting tab in the GPMC. You may notice that the Computer area will be blank. Run the same command with an Elevated Command Prompt to see the Computer Area.
gpresult HTML output
If you don’t want pretty reports or want the output as text, you can run gpresult.exe with different options to get the output in text. The /r option will give you a pretty limited report that includes everything except the actual settings that are being applied. Personally, I like the verbose output with the /v option. By default, the output will be shown in the Command Prompt window. You can run gpresult.exe /v >> verbose_output.txt to save the output into a text file. If you want total information overload, /z provides “super-verbose” information.
gpresult verbose text output
Resultant Set of Policy (Logging)
Resultant Set of Policy (Logging) is available in the GPMC by right-clicking on a user or computer object, click All Tasks, and click Resultant Set of Policy (Logging). I personally prefer running gpresult.exe on the client side. RSoP Logging requires that the management station that you’re using have the ability to communicate with the remote computer which isn’t always available in every environment. Even if I don’t have physical access to or the ability to remote control the computer, I can have the end user email me the output of gpresult.exe for troubleshooting. I’ve even known people to stick a script on the computer that the user just has to click on to get the output without any pesky command line typing. RSoP Logging also gives the same output as RSoP planning, so it can be a little hard to look at. The output of gpresult.exe is much easier to look at and search.
So now you know you have a problem and you have enough information to hopefully track it down. First, did the GPO apply? And, if it wasn’t, was it denied? You can get some of this in the Event Log, but it is usually easier to check your gpresult.exe output since both pieces of information should be there. If it didn’t apply or got denied, check the Event Log for more information about why the GPO didn’t apply or was denied. The potential number of possible possibilities you’ll see there are too great to discuss here, but you should get something good enough to search for online to resolve the problem. The typical causes are things like the Security Filtering, link not being enabled, GPO Status may have user or computer disabled, and issues with WMI filtering.
If the GPO did apply, but you’re missing settings, try a gpupdate.exe just to see if the client hasn’t refreshed. You’ll also want to refer to the gpresult.exe output here too. You may have a system on a slow link, a setting that isn’t applicable to the current OS, another setting taking precedence, loopback processing that is disabling the setting, or client side extension (usually Group Policy Preferences or third-party products) problems. If the output from gpresult.exe doesn’t tell you where the problem is, the Event Log should.
In the next post I will discuss Group Policy Active Directory problems.