Once you start using Group Policy to distribute settings around to many client computers, it will quickly become important to be able to view the settings and policies that have or have not been applied to specific computers. Thankfully, there is a command built right into the Windows operating system to display this information. There are a number of different switches that can be used with this command, so let's explore some of the most common ones that I see used by server administrators.
We have a number of GPOs in our domain now; some are applied at the top level of the domain and some are only applied to specific OUs. We are going to run some commands on our Server 2016 web server in order to find out which GPOs have been applied to it and which have not.
Let's use the gpresult command to gather some information on policies applied to our server:
- Log in to the web server, or whatever client computer you want to see these results on, and open up an administrative Command Prompt.
- Type
gpresult /rand press Enter. This displays all of the resultant data on which policies are applied, and are not applied, to our system. You can scroll through this information to get the data that you need.
- Now let's clean that data up a little bit. For instance, the general output we just received had information about both computer policies and user policies. Now we want to display only policies that have applied at the User level. Go ahead and use this command:
gpresult /r /scope:user.
- And if you aren't a huge fan of looking at this data via a command prompt, never fear! There is another switch that can be used to export this data to HTML format. Try the following command:
gpresult /h c:gpresult.html. - After running that command, browse to your
C:drive and you should have a file sitting there calledgpresult.html. Go ahead and open that file to see your gpresult data in a web browser with a nicer look and feel.
The gpresult command can be used in a variety of ways to display information about which Group Policy Objects and settings have been applied to your client computer or server. This can be especially useful when trying to determine what policies are being applied, and maybe even more helpful when trying to figure out why a particular policy hasn't been applied. If a policy is denied because of rights or permissions, you will see it in this output. This likely indicates that you have something to adjust in your Links or Security Filtering in order to get the policy applied successfully to your machine. However you decide to make use of the data for yourself, make sure to play around with the gpresult command and get familiar with its results if you intend to administer your environment using Group Policy.
One additional note about another command that is very commonly used in the field. Windows domain joined machines only process Group Policy settings every once in a while; by default they will refresh their settings and look for new policy changes every 90 minutes. If you are creating or changing policies and notice that they have not yet been applied to your endpoint computers, you could hang out for a couple of hours and wait for those changes to be applied. If you want to speed up that process a little, you can log in to the endpoint client computer, server, or whatever it is that should receive the settings, and use the gpupdate /force command. This will force that computer to revisit Group Policy and apply any settings that have been configured for it. When we make changes in the field and don't want to spend a lot of time waiting around for replication to happen naturally, we often use gpupdate /force numerous times as we make changes and progress through testing.
I tend to prefer gpresult to view the policies that are currently applied to a computer that I am working on, but it's not the only way. You may also want to check out RSOP.MSC. This is a tool that can be launched in order to see a more visually stimulating version of the policies and settings that are currently applied to your computer. Check out the details here: