Where does GPO info get pulled from?

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 :( *

"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.

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

Mahesh

Hi,

Refere below link for Group Policy processing and precedence
http://technet.microsoft.com/en-us/library/cc785665(v=ws.10).aspx

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
http://technet.microsoft.com/en-us/library/dd277394.aspx
http://technet.microsoft.com/en-us/library/cc784268(v=ws.10).aspx

Hi,

Check this

Hope this will clarify your query

Group Policy Basics - Part 2: Understanding Which GPOs to Apply
http://blogs.technet.com/b/musings_of_a_technical_tam/archive/2012/02/15/understanding-the-structure-of-a-group-policy-object-part-2.aspx

Hope that helps :)

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.

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"

http://gpoguy.com/group-policy-forums/topic/discrepancies-between-gp-rsop-on-replicated-domain-controllers/

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

Mahesh

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.

FYI im preparing a document with the answers I found here:

http://gpoguy.com/group-policy-forums/topic/where-is-gpo-info-being-pulled-from/#post-5478

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? :)

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?

Mahesh

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...

No one was able to tell me exactly where those settings were pulled from.