The default refresh interval for group policy is 90 minutes with an additional 0 to 30 minute random offset. You can also manually trigger a policy refresh by running
gpupdate. Note: The refresh interval on domain controllers is only 5 minutes (with no offset).
The refresh process checks if any of the policies assigned to a computer have changed (each policy has a version number that is incremented when a policy is modified). If no policies have changed, the refresh process completes without applying any updates to the computer. If at least one of the policies has changed, all policies assigned to the computer are reapplied (in priority order from lowest to highest). You can also force all policies to be reapplied by running
gpupdate /force (the equivalent process occurs automatically every 16 hours).
I used to think that when a group policy was reapplied to a computer, each corresponding registry entry was refreshed via a single
RegSetValue operation. I've since learnt that the update process actually requires two operations; the registry value is first deleted via a call to
RegDeleteValue, and then set via a call to
RegSetValue. Furthermore, if two policies implement the same setting, after the corresponding registry value is deleted, two RegSetValue operations are called; the first sets the value from lowest priority policy, and the second sets the value from the highest priority policy. This again, is different from what I expected; I had assumed that only the value from the "wining policy" would be applied.
This approach raises an interesting point - as the update process is non-atomic, and not (as far as I know) transactional - there will be a period of time (however brief) when the update process will yield incorrect values.
The process varies slightly for registry values configured via group policy preferences. If a preference is configured with an action of 'update', the registry entry will be updated in-place (via a single RegSetValue operation). If the preference is configured with an action of 'replace', it will be deleted and then set. And if a preference is configured with an action of 'replace' and with the option to 'remove this item when it is no longer required', two RegDeleteValue operations will be requested (obviously, only the first succeeds) prior to calling RegSetValue. I assume the first delete operation is initiated as the policy is effectively removed and reassigned, and the second operation forms part of the 'replace' action.
Another key difference between traditional group policy settings and group policy preferences is that preferences are always reapplied during a background policy refresh (and by running
gpupdate) - even if a policy has not changed.