Group Policy sync delay when moving to different OU

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've run into a group policy synchronization issue that I'm hoping someone can provide some insight on (and maybe a workaround). The problem is that when I move the machine account to a different OU and wait for the domain controller to receive the change, the new group policy will not sync down to the workstation for about an hour (even if I try to force a synchronization with gpupdate or secedit). Here are the steps to reproduce the problem

1. Boot up a test workstation and logon to the network (Windows 2000 or Windows XP).
2. Create a vbScript on this test workstation that contains the following code.
' Show the distinguished name of the workstation:
Set oAd = CreateObject("ADSystemInfo")
MsgBox oAd.ComputerName, vbInformation, "Computer Name"
3. On a different workstation, open the AD Users and Computers and move the machine to a different OU that has different group policies applied.
4. On the test workstation, run the script to display the distinguished name of the computer until it shows the machine has moved to the new OU
(this can take up to 5 minutes in my environment because we have multiple domain controllers).
5. On the test workstation run "Secedit /refreshpolicy machine_policy /enforce" (if Windows 2000) or "Gpupdate /Force" (if Windows XP).
6. Check the registry and you will find that the group policies for the new OU of the computer have not synchronized down.

I've found that advancing the time of the test workstation 1 hour and running gpupdate or secedit again (even without the /force or /enforce switches) correctly synchronizes the group policy for the new OU. I added the "UserEnvDebugLevel" to the registry and reran this test and found that even though the script correctly detects the new distinguished name (using the ADSystemInfo object) that whatever is controlling the group policy synchronization is still using the old one. It acts as though it is caching this information and only rechecks the distinguished name of the machine once an hour.

I'm assuming this issue could happen if I were to move the user account to a different OU as well. Does anyone know of a way to force a policy update when the machine or user account has moved. If not, are there a registry setting that show what the distinguished-names of the machine and the user were when group policy was last synchronized. This would allow me to at least detect the problem in my scripts until the hour has passed and group policy synchronized properly. I've found "HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Distinguished-name" under Windows XP but have not found the equivalent setting on Windows 2000 and have not found the equivalent settings for the user's distinguished name.

Andy
 
I'm also facing a similar problem. In my case
(1) I have an OU called CO_ROOT, under which there are 15 different OUs that groups various users according to their departments
(2) CO_ROOT had a group policy called CO_REDIRECT_USERS_FOLDERS configured to redirect folders of all users to a file server. There are other GPOs to restrict usage of IE and Control Panel tools
(3) Recently we moved all users folders' to a new file server (presenving all security settings as it is), due to which the the GPO CO_REDIRECT_USERS_FOLDERS was deleted and a new GPO NEW_REDIRECT_USERS_FOLDERS was created with folder redirection configuration pointing to the file share located in the new file server (the server name and root of share name was changed)
(4) Now when an existing user logon to the DC from a client (Win2k prof), the modified NEW_REDIRECT_USERS_FOLDERS does not apply to loged in user, it still points to the old share name (pointing to the old file server). gpresult displays that the client is getting the "folder redirection settings" from the correct domain controller, but the GPO listed there is the non-existance deleted GPO CO_REDIRECT_USERS_FOLDERS. It is as if, the old GPO is cached, and the clients are getting their settings from the cached GPO
(5) This is happening mostly with existing users (from the same win2k prof client PC they used to access their old file server), newly created users seems to getting their settings correctly from the GPO NEW_REDIRECT_USERS_FOLDERS
(6) But some new users are not getting their folder redirection settings from GPO NEW_REDIRECT_USERS_FOLDERS, forcing them to use the local home directory
(7) Restarting the DC and clients PCs did not solved the problem

Thanks in advance
Alertey
Please use this email address to reply: (e-mail address removed)
The above email address is functional, created to check our spam filters.
 
I, too, have noticed the delay and have found a resolve. Strangely, m
resolution was merely a debugging tool that I later realized must forc
client synchronization.

I have AD running on a Win2003 server, while my clients are WinX
workstations. While logged in at the client as the particular use
(yes, I wish there was a better way), press the Windows-key and "R" t
open the Run Dialog, type "command" and press Enter. At the comman
prompt, type GPRESULT to view the RSOP (resultant set of policy) an
viola! You will see that the local policy has been update
appropriately.

While this has worked at multiple XP clients, I did notice that it di
NOT work as well for subsequent tries. In other words, once the loca
policy was indeed updated / synchronized, I then made a policy chang
for the particular user in AD, and then re-ran gpresult at the client
but the local policy retained the prior policies. I have mor
experimenting to do this week. I believe the client will eventuall
update on its own. As you will agree, the delay is frustrating and
security risk in my opinion.

Good luck and please do post your experience with this idea.

Paul

---------------------------
GPRESULT and other XP commands: http://tinyurl.com/25mrp

---------------------------
Other info from WinXP help:

Interactive logon - Require Domain Controller authentication to unlock

Registry:
Computer Configuration\Windows Settings\Security Settings\Loca
Policies\Security Options

Description:
Logon information must be provided to unlock a locked computer. Fo
domain accounts, this setting determines whether a domain controlle
must be contacted to unlock a computer. If this setting is disabled,
user can unlock the computer using cached credentials. If this settin
is enabled, a domain controller must authenticate the domain accoun
that is being used to unlock the computer.

Default: Disabled.

Important: This setting applies to Windows 2000 computers, but it i
not available through the Security Configuration Manager tools on thes
computers


-
FunkMasterWe
 
After running GPUPDATE and GPRESULT while logged in as the specifi
user, log off and then log back in. Now, check GPRESULT to see if th
local policy was updated.

Also try: GPUPDATE /FORCE
which will prompt you to reboot afterwards


-
FunkMasterWe
 
Follow-up: I had an opportunity to ask a Microsoft Product Exper
(face-to-face) and he stated the DC-to-client sync delay is 90 minute
... plus or minus 30 minutes depending on how busy the DC is


-
FunkMasterWe
 
The offset of 30 minutes only occurs at the first onset of the GPO
application. After that, there is a 90 minute interval. This is to allow for
an offset of all client computers refresh interval. IF they all stuck with
90 minutes to begin with, then every 90 minutes the poor DCs would be
pounded.

DCs don't play by this rule. They update every 5 minutes, with no offset.
 
Back
Top