Where does GPO info get pulled from?


I have a quick question concerning GPO

1) On a Domain PC, logged in locally, I run GPUPDATE /force.  I open up gpedit.msc

-Does the displayed info shown get pulled from the local pc's registry right?  This info is strictly on the local level and none of it is pulled from the DC via gpupdate right?

2) On a Domain PC, logged in using a domain user account, Run GPUPDATE /force.  I open up gpedit,msc.

-Does the displayed info shown get pulled from the registry that was changed by the domain policy that is controlled by the domain controller?

Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

OasisEEConnect With a Mentor Author Commented:
The bottom line question is where is the info pulled from when opening up gpedit.msc
Ive put together a document that discusses this and more.

How Group Policy Is Run - Example: running gpupdate.exe /force on a domain joined PC

Step 1) The local GPO is *mostly* applied from c:\windows\system32\grouppolicy. However, anything under computer COMPUTER CONFIG\WINDOWS SETTINGS\SECURITY SETTINGS is not stored in the file system and is configured LIVE on the system.

Step 2) GPO Linked to sites is applied overruling Local GPO.  The PC ultimately pulls GPO settings from SYSVOL on the authenticating server.  There are a series of complicated steps that the GP client goes through and some settings are actually stored in AD (some policies areas actually store their settings as objects within AD, usually under CN=<GPO GUID>, CN=Policies, CN=System)

Step 3) GPOs linked to domains are applied overruling GPO linked to sites.(again ultimately from SYSVOL)

Step 4) GPOs linked to organizational units are applied overruling GPO linked to domains. (again ultimately from SYSVOL) (this does not include Password policies)


1) Domain PC, Logged on locally, gpedit.msc - The settings seen here are *mostly* applied from c:\windows\system32\grouppolicy.  However, anything under computer COMPUTER CONFIG\WINDOWS SETTINGS\SECURITY SETTINGS is not stored in the file system and is configured LIVE on the system.  

2) Domain PC, Logged on as Domain User, gpedit.msc - Info is pulled from the same locations as mentioned in #1  (When you are viewing gpedit.msc, it doesn’t matter who you are logged in as (domain or local users), what you see will be the same under COMPUTER CONFIG.

3) Running Group Policy Management Console on a DC - When viewing Domain based GPOS, GP Editor would pull the info displayed from SYSVOL or AD


A) RSPO.msc has been deprecated after vista.  According to the GPO experts to view GPOs that are currently running use the GPMC tool "Group Policy Results"

B) "I tend to like the GPMC GP Results report better but gpresult.exe is supposed to return the same information, albeit in a different format. I’ve not always found that to be the case, frankly, so I prefer the GPMC version." - gpoguy

Here is an older document that discusses where GPO is stored
Nathan PSystems ArchitectCommented:
My understanding, is that if you log in locally, running GPUPDATE /force does very little, as you'll be asking as a local user for updates, so it may not get much in the way of an update.

Also, logged in as a local user, you still should see the COMPUTER level GPO's applied to your machine, as they should have been previously applied by the Domain.

Once you log in as a domain user, and run gpupdate /force, the new GPO's that affect your PC should update into your registry, and then running gpedit should read your registry..

*all of this answer is based on what I think is happening, I don't have documented proof :( *
Cliff GaliherConnect With a Mentor Commented:
None of the above. Running gpedit on a workstation opens the local policy. That is a distinct object, just like a group policy is an object in AD. It does NOT query the registry, and it does not tell you whether the policy was properly applied or enforced. Since it is an object, it does not matter whether you view it with a domain account or local account, as long as the account has permissions to read the policy file. It will simply show what settings were  set up. So gpudate will also have no effect.
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

"It does NOT query the registry" - oh yes it does. Most GPOs are registry settings. Change the registry and you will see it reflected in gpedit and vice versa.
Cliff GaliherConnect With a Mentor Commented:
You are correct that most settings in a policy change an underlying registry setting. But they are enforced by a windows service that runs and processes the policy file, so that editing the registry doesn't inadvertently change the policy itself. You can, if you have appropriate permissions, change the registry directly, but then the service will undo your changes on its next pass. Those settings are stored in a separate policy file. That policy file is what gpedit queries, not the registry.
If that were true, please explain the following behavior (which you can quickly reproduce, here: OS: win8.1 pro, non-domain joined).
1) open regedit, walk to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ->readout cachedlogonscount which should have the value 10
2) open gpedit and walk to compconf - windows sett. - secsett. - locpol. - secopt. - Interactive logon: Number of previous logons to cache (in case domain controller is not available) and read out the value... again 10.
3) Now change the registry value to 9
4) reopen gpedit... you guess what comes
5) do gpupdate /force /target:computer
6) reopen gpedit ->still at 9.
Really very good and tricky question.
Wheather you change domain \ local policy, changes will be stored in registry only.
Gpedit.msc is just local GP editor showing only local policy settings and some settings may be grade out in user and computer configuration depending upon winning \ applied domain polices.
You need to run either gpresult or rsop.msc after you run gpupdate /force if you want to view changes \ resultant policies and their settings.
Additionally domain polices will always take precedence over local polices if conflict occurs.
For ex. domain level password policies.

1st case:
On domain joined machine even if you logged on with local user, still computer is part of domain and before user logon, computer is already logged on domain and domain polices (Computer Specific) are already applied on that.
In this case if you run gpupdate /force, domain policies will not be updated for user since you have logged as local user on local computer but domain computer policies will refresh.

2nd case:
On domain joined machine when you logged on as domain user and run gpupdate /force, both domain user and domain computer policies will refresh.

Hope that helps

SandeshdubeySenior Server EngineerCommented:

Refere below link for Group Policy processing and precedence

Instead of gpedit you can run rsop.msc and check which policy is applied and from which GPO.You will get the GPO name if it is applied from domain.http://www.howtogeek.com/116184/how-to-see-which-group-policies-are-applied-to-your-pc-and-user-account/

More on GPO see this
VirastaRUC Tech Consultant Commented:

Check this

Hope this will clarify your query

Group Policy Basics - Part 2: Understanding Which GPOs to Apply

Hope that helps :)
OasisEEAuthor Commented:
Thank you all for your input.  Ill be checking every link everyone posted.  I'll be posting a follow up today with what I find.
OasisEEAuthor Commented:
Just an update to this question.  I found that RSOP can be unreliable.  Here is the info concerning this:

"RSOP tells you what the GPOs “should” have delivered. It doesn’t validate that they have been delivered (or that they haven’t been modified externally). Also, as you’ve discovered in that KB article, rsop.msc as a tool is kind of unreliable for certain settings. gpresult.exe is better, but frankly, I like using GPMC’s GP Results report, because it’s visually easier to use"

RSOP can be used to identify basic GPO application functionality issues post which your advanced troubleshooting will start such as gpresult etc
When group policy trouble shooting starts, you just run rsop.msc on pre vista sp1 computers or even on win7 machines with user logged as an administrator, you immediately come to know even group polices are applying or not.
If group polices are applying both computer configuration and user configuration icons looks OK, but if there is any problem with GPO (may be computer subnet is latched to wrong site or netbios name resolution with DC got blocked due to some wrong dns entries etc), then computer and user configuration icons both shows some yellow mark on them.

What I mean to say, RSOP can tell you that wheather computer and users are eligible to apply basic GPOs or not ? and you can use RSOP as basic \ first troubleshooting tool.
RSOP is always running in logging mode to show already applied GPOs only.

I agree that GPResult has more capabilities than RSOP but you should not ignore RSOP basic use.
GP result report can be run through client computers as well by below command
gpresult /h <path to html file>
This wil give you html formatted proper report

OasisEE, I wonder how that new "finding" fits in here.
How should we proceed, what is still unanswered?

Btw: I believe that the author you quote is wrong. rsop is not what "should have applied" but what applied. gpresult uses the same data. What "should" have applied is shown by gpo modeling.

What gpresult can do for you in addition to rsop is show the group policy preference items.
OasisEEAuthor Commented:
FYI im preparing a document with the answers I found here:


Which I will post here once I'm done.  The RSOP info was only an update since its something that people will use when doing their troubleshooting so I figured it would be helpful.  Since its a deprecated product, it shouldnt be used.
I see.
By the way, let me quote you: "Tried asking this on Experts-exchange but didnt get any good answers and/or conflicting ones". - So why didn't you ask any further here if you saw conflicts/unclarities/answers being "not good"? Why "run" to Darren? :)
OasisEEAuthor Commented:
I wasn't 100% sure that what I was getting here was either incorrect or correct.  I do know that the answers weren't solid enough for me to take action on.  I decided to ask someone who ONLY does GPO hoping for a more solid answer, which I pretty much got.  GPO is not so straight forward it seems.  There seems to be a lot of very technical documents on it but reading a wall of text that MS put out wasn't that feasible.  I was hoping for shorter explanations.  Hopefully what I'm whipping up can enlighten anyone else who finds themselves in the same position.
Unless you mention your exact requirements, we can't help you.

The original question is answered by various experts as appropriate.

Sorry to say but Now really I don't understand what question is left and what answer you expecting please?

VirastaRUC Tech Consultant Commented:
Understanding Group Policy Processing

Group Policy processing is a complex set of interactions involving many pieces of your Windows® and Active Directory® infrastructure. At a high level, there are two parts to Group Policy processing. The first is called Core, or Group Policy Infrastructure processing. In this phase, a Windows Group Policy client queries its closest domain controller to determine what the link speed to the DC is, where it lives in the Active Directory hierarchy (that is, which site, domain, and OU the client is a member of), and which GPOs apply to the computer or currently logged-on user. (It's important to note that in this context a client could be a server or workstation participating in an Active Directory domain.) Once the list of GPOs has been created, the next phase kicks in—Client-Side Extension (CSE) processing. During the CSE phase, each registered CSE processes the list of GPOs that have implemented settings in its area. For example, the Registry or Administrative Template CSE runs first in all cases and processes all GPOs that apply to the given computer or user and that have implemented registry policy within them.

The list that follows details the steps the Group Policy processing cycle goes through, including network interactions between the client and domain controller. It's important to remember that Group Policy applies to both computers and users. Therefore, each time policy processes—for example during a background refresh of Group Policy—the cycle I enumerate below will be repeated for both the computer and the currently logged on user account on a given system, since each can have a different set of policies applying to them. When this happens, Windows actually performs the processing cycle simultaneously for both computer and user, with each cycle running on a different thread within the Group Policy engine process. (The Winlogon process for Windows 2000, Windows XP, and Windows Server® 2003, and the Group Policy Client service in Windows Vista® and Windows Server 2008.)

Processing a GP is a six-step procedure:

1.The client performs Internet Control Message Protocol (ICMP) slow-link detection to a domain controller in its site to determine link speed. In Windows Vista, the use of ICMP for slow-link detection is replaced by the Network Location Awareness (NLA) service.
2.The client reads CSE status information from its local registry to determine which GPOs were processed last.
3.The client uses LDAP to search the gpLink attribute in Active Directory on each container object within its location in the Active Directory hierarchy—first at the OU level (including all nested OUs), then at the domain, and finally at the Active Directory site level. From the results of this search, it builds a list of GPOs that must be evaluated for processing.
4.Each GPO is then searched in Active Directory to determine whether the client (user or computer) has the necessary permissions to process it. Its version number, the path to the Group Policy Template (GPT) portion of the GPO in SYSVOL, and what CSEs are implemented in that GPO are also evaluated.
5.The client then uses the Server Message Block (SMB) protocol to read the contents of the GPT and get the GPO's version number from the gpt.ini file. The version numbers in the Group Policy Container (GPC) and GPT are one factor that is used to determine whether a GPO has changed since the last processing cycle.
6.Each CSE runs in the order that is registered under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions, and processes the GPOs that implement that CSE if the GPO has changed since last processing cycle (as determined during core processing). Each CSE also logs Resultant Set of User Policy (RSOP) data to Windows Management Instrumentation (WMI) during each refresh, if available.

Courtesy - TechNet Blog http://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx

Hope that explains everything...
OasisEEAuthor Commented:
No one was able to tell me exactly where those settings were pulled from.
All Courses

From novice to tech pro — start learning today.