16

I'm on Windows 10 Pro. I noticed that when I apply some policies via gpedit, the corresponding entries are created in the registry. If I undo, the entries are removed from the registry as well.

So I expected it to work the other way around too, but if I manually set the same policy via registry, the corresponding gpedit entries still show as "not configured".

Am I missing something? is the gpedit policy something more than a registry entry? so... where are they stored?

0

2 Answers 2

21

Since the changes you make in the group policy editor affect what you see in the registry, it's perfectly logical to assume that the reverse is also true. However, it doesn't work that way.

Local group policy settings (which is what I believe you are referring to in your post) are stored in registry.pol files located in C:\Windows\system32\GroupPolicy. These files overwrite the corresponding keys in the registry every time the system performs a group policy refresh. The editor never actually reads the registry to see what settings it contains.

A group policy refresh is triggered whenever one of the following events occurs:

  • At a regularly scheduled refresh interval (every 90 minutes by default)
  • A user logon or logoff event (user policy only)
  • A computer reboot (computer policy only)
  • A manually triggered refresh via gpupdate
  • A policy refresh command issued by an admin from the domain controller (if the computer is domain-joined).

It's important to remember that if the computer is domain-joined, domain policies will be applied after the local group policy files are processed (meaning that some settings may get overwritten by domain policy). You will not be able to see domain policies in the local group policy editor.

6
  • Nice rundown (+1). I'd only add that gpupdate /force may work more reliably sometimes.
    – dxiv
    Mar 26, 2017 at 7:23
  • 5
    @dxiv; That happens because the system caches policy and tries to apply only settings that have changed since the last time a refresh was done. /force makes it reapply all settings. It seems more reliable because you usually only do a gpupdate when you have a problem, and that problem is usually because the cache is bad :-)
    – Wes Sayeed
    Mar 26, 2017 at 7:28
  • N.B. C:\Windows\system32\GroupPolicy is a hidden folder
    – Foo
    Jun 1, 2022 at 8:22
  • PERFECT, very valuable information!
    – MrCalvin
    Feb 21, 2023 at 6:07
  • 1
    @MrCalvin; The files you see in that directory are the cached copies of the domain policies that apply to your machine. If they are identical to the copy on the domain controller (or if a DC can't be reached), then they are reapplied from that cache during a group policy refresh instead of downloading them again. Doing a gpupdate /force flushes that cache and re-downloads all policies from the DC.
    – Wes Sayeed
    Feb 24, 2023 at 22:21
9

It works like this for three reasons:

  • Group Policy is designed with "pushing" from an Active Directory domain controller in mind. Machines are not intended to control policy back to the domain controller.

  • The notion of policies and Active Directory was developed in a time when dial-up connections were very common and broadband was not. For registry changes to mirror back to a domain controller in this situation would probably consume a lot of very limited bandwidth, and situations where systems would only occasionally talk to a domain controller through dial-up sessions here and there were not unheard-of in the NT4 days I believe.

  • You probably noticed a lot of the policies have a setting "Not Configured", "Enabled", or "Disabled." Group Policy has the "Not Configured" setting to allow the local setting to remain untouched by policy. This specifically means you, an application, or a local administrator can modify the relevant registry entries and a policy won't change it. You may not want to control every aspect of the system through policy.

So the local registry and a group policy don't sync from machine->AD by design. The local group policy in gpedit.msc works the same way even though it's not syncing to any domain controller.

5
  • 2
    I think your second point, while technically correct, is of minimal import. AD and Windows domains in general were never intended to be used over dialup lines in the first place, only LANs. Your other points are however spot-on. Mar 25, 2017 at 23:49
  • 1
    I just recall that you can or could specify "SMTP" as a protocol somewhere for AD sync ...
    – LawrenceC
    Mar 25, 2017 at 23:50
  • SMTP? Simple Mail Transfer Protocol? That's a mail transport layer, it doesn't have anything to do with dialup vs LAN. it was probably something else. SLIP or PPP, maybe? Mar 26, 2017 at 0:02
  • 1
    This is what i was referring to: technet.microsoft.com/en-us/library/cc961766.aspx
    – LawrenceC
    Mar 26, 2017 at 0:21
  • But that doesn't specify dialup, just an application-layer protocol used over whatever is providing your IP connectivity. "Replication protocol used by Active Directory replication over IP transport" - see, it's not an IP provider of its own. For a dialup connection that would be PPP or SLIP. Mar 26, 2017 at 1:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .