GPResult does just what the name implies – it is a command that runs on the client machine to display results of some of the things going on with Group Policy. Primarily we use this command to verify whether a particular GPO is successfully applying to a computer or user, but there is quite a bit more information inside the GPResult output that is interesting to take a look at.

Here is a screenshot of gpresult /r from my LAPTOP1 machine, currently logged on as the Jordan user:

Here are descriptions of some of the useful information listed inside GPResult:

• Connected over a slow link: We will discuss slow links later in Detecting Slow Links section, but sometimes when troubleshooting users who are connected remotely, determining whether they are connected via a slow link can be essential information.
• Group Policy slow link threshold: Another useful piece of info regarding slow-link detection is the current threshold that Windows uses for determining whether the user is on a slow or fast link.
• Last time Group Policy was applied: As it states, this will show you the date and timestamp of the last successful Group Policy refresh. When troubleshooting whether settings are processing correctly on a client computer, this stamp can be noted, then reviewed again after running a GPUpdate command. If the timestamp has updated itself, you know Group Policy is processing information successfully and in real time.
• Group Policy was applied from: It displays which Domain Controller was pulled from the last set of Group Policy information. If you are getting unexpected results on your workstation, perhaps one of your DCs is out of date, or out of sync with the rest of the environment.
• Applied Group Policy Objects: In my experience, this is the most commonly visited section of GPResult data. Here you will find a list of the GPOs that have been applied to your machine or user account. This is your verification on whether a particular GPO is being successfully applied.
• The following GPOs were not applied because they were filtered out: This is not simply a list of all GPOs that did not apply to the user or computer (because that could be an enormous list), but a list of GPOs that would have successfully applied, except that some kind of specific filtering criteria blocked them from applying. When you see GPOs listed in this section, it means the user or computer account does reside in an OU to which these GPOs would have normally applied successfully. However, something about the GPO settings has stopped that from happening. There are three different reasons as to why they could be blocked:
  • Denied (Security): The user or computer has been specifically denied permissions to apply this GPO. This happens when a GPO's Security Filtering is configured to only apply to a certain set of users or groups, and your user or computer is not part of that group. Therefore, the policy would have applied to you based on OU membership, but not based on the additional filtering criteria defined inside Security Filtering. This would also happen if you have modified the Delegation tab of a GPO in order to create a specific Deny rule, disallowing particular objects from receiving these GPO settings.
  • Not Applied (Empty): This is displayed when a GPO attempted to apply to you, but there were no settings to apply. This could mean that the GPO is set to Disabled, or it could mean that just half of the GPO is set to Disabled. Remember that we have the ability to disable either User Configuration or Computer Configuration settings on any given GPO, and if the GPO is actually empty without settings or half of that GPO is blocked, you may see it listed as Empty.
  • Not Applied (Unknown Reason): This is a catch-all for any other reasons why a GPO might not be applying. I find that this most often happens when Block Inheritance is affecting the application of these GPO settings. Such is the case for the preceding screenshot.