(Fixed) GPO Not Propagating to Servers After Change

[Jason S. Global Moderator]

We've recently transitioned our instance of WSUS from Server1 to Server2. The transition went just fine. Part of the transition is to update the associated GPO that tells the servers in the domain which WSUS server to use.

 

We actually have (4) GPOs that do this, broken out by type of server (DC, DB, Web, etc). After making the change to the GPOs, it seems that the change is not propagating to the servers in the domain.

 

So far we've tried a manual "gpupdate /force", idle time to let the servers sync, and reboots. None of these are working.

 

On one server we did a "/force" then an immediate reboot, and that still didnt work. I can verify this by looking in the registry or running a config report in GP Manager.

 

I've explored permissions issues as well. According to MS, a GPO only needs the default Authenticated Users group. I've also verified that the "apply group policy" permission is set.

 

As a further permissions test, i added Domain Admins to one of the GPOs and tried a /force. This still didnt work.

 

Nothing is working. The GPO will not propagate.

 

fwiw, this is a Windows Server 2008 R2 environment with a single Windows 2012 WSUS server.

 

Any suggestions?

 

(edit) forgot to mention that we even removed the GPO from the OU and reapplied it. Didnt work either!

[TPreston]

Are you getting computer /user policy updated successfully ?

If so do gprusult  /h c:\blah\x.htm and check the policy there.

[Jason S. Global Moderator]

Are you getting computer /user policy updated successfully ?

If so do gprusult  /h c:\blah\x.htm and check the policy there.

Yes. The gpupdate /force works just fine.

 

I've done the gpresult output too. That just shows the same thing - that the policy hasnt changed/updated.

[Praetor]

Are you getting computer /user policy updated successfully ?

If so do gprusult  /h c:\blah\x.htm and check the policy there.

 

Or rsop.msc, it will open a mmc with all the policies applied. The best way to determine if the policy is being applied at all is the check the gpresult to see if the policy is being applied at all and to which group (computer or user) is being applied to.

 

Also do a simple thing: create a OU inside of the OU where those servers reside and block all the GPOs, so only those WSUS GPOs are being applied to and move a server into it, to see if it can receive the policy. You can also troubleshoot if it's a problem with those policies by creating a new policy that configures the Windows Update and apply that GPO into one of your servers (or into that new OU), to see if the servers can recieve the policy. Last, you can see the Delegation Tab on those GPO to see if there is a group, member or computer objects being denied to recieve the GPO.

 

edit: last but not least: one trick i usually do is to delete the cached policies when trying new ones:

 

DEL /S /F /Q "%ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History\*.*"

many times i thought that some policy was being applied but it wasn't because the previous one was cached.

[Jason S. Global Moderator]

 

 

Or rsop.msc, it will open a mmc with all the policies applied. The best way to determine if the policy is being applied at all is the check the gpresult to see if the policy is being applied at all and to which group (computer or user) is being applied to.

 

Also do a simple thing: create a OU inside of the OU where those servers reside and block all the GPOs, so only those WSUS GPOs are being applied to and move a server into it, to see if it can receive the policy. You can also troubleshoot if it's a problem with those policies by creating a new policy that configures the Windows Update and apply that GPO into one of your servers (or into that new OU), to see if the servers can recieve the policy. Last, you can see the Delegation Tab on those GPO to see if there is a group, member or computer objects being denied to recieve the GPO.

 

edit: last but not least: one trick i usually do is to delete the cached policies when trying new ones:

 

DEL /S /F /Q "%ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History\*.*"

many times i thought that some policy was being applied but it wasn't because the previous one was cached.

 

I'm not sure i can find that Group Policy location... i get to 'Microsoft' and dont see anything relating to 'Group Policy'

[Praetor]

I'm not sure i can find that Group Policy location... i get to 'Microsoft' and dont see anything relating to 'Group Policy'

 

from a Server 2012 R2. It's there.

[Jason S. Global Moderator]

from a Server 2012 R2. It's there.

hmm. perhaps it's different in 2012 and 2008 R2

 

update: i can confirm that there is no "C:\ProgramData\Windows\Group Policy" anywhere. I've looked on a 2008 server, 2008 R2 and 2012. I cannot seem to find the location of the cached GPOs on servers...

 

Also, we're currently trying the suggestion of the embedded OU right now. i'll report back.

[sc302 Veteran]

It is in the registry.  Also where does your gpo sit that you are trying to apply?  Where do your servers sit in relation to that gpo.  Policies get trickled down, if the servers are not in a OU that is under the OU that the gpo is in, the gpo will never apply.  You can't reverse apply a gpo or make it jump OUs, it doesn't work that way.  The gpo would have to either be applied at the domain level, or directly at the Domain Controllers OU level.  If it is anywhere else it will not apply.

[Jason S. Global Moderator]

It is in the registry.  Also where does your gpo sit that you are trying to apply?  Where do your servers sit in relation to that gpo.  Policies get trickled down, if the servers are not in a OU that is under the OU that the gpo is in, the gpo will never apply.  You can't reverse apply a gpo or make it jump OUs, it doesn't work that way.  The gpo would have to either be applied at the domain level, or directly at the Domain Controllers OU level.  If it is anywhere else it will not apply.

i can assure you that the GPOs and OUs are in the correct hierarchy. Remember that these domain servers already had the GPO(s) applied. All we did was change the WSUS GPO to point to the new WSUS server - 1 seemingly simple change that isnt be propagated.

 

So, as another test per Praetor's recommendation, we embedded another OU with a single test server, blocked all GPOs except the WSUS one. We did a 'gpupdate /force' as well as a reboot. The result - the server still shows the WSUS GPO applied with the original WSUS and not the new one!

[Praetor]

hmm. perhaps it's different in 2012 and 2008 R2

 

update: i can confirm that there is no "C:\ProgramData\Windows\Group Policy" anywhere. I've looked on a 2008 server, 2008 R2 and 2012. I cannot seem to find the location of the cached GPOs on servers...

 

Also, we're currently trying the suggestion of the embedded OU right now. i'll report back.

 

Eh, it's hidden. I just checked on a Server 2008, Server 2008 R2 and the above Server 2012 R2, it's in there.

[sc302 Veteran]

OK then, did you change or did you add?  if you added, what has the higher order?  check rsop.msc to see which policy is being applied to the windows update area.  There has to be another policy overriding that policy then.

[Jason S. Global Moderator]

sc302 - in our test we only allowed the WSUS GPO to be applied. We did not allow any others. After the reboot i did another 'gpresult', and it shows the GPO was successfully applied. If I check the WSUS server registry key it still shows the old one, not the new one, even though the GPO has been changed.

[sc302 Veteran]

I understand what you are saying.  I don't care what gpresult says, what does rsop.msc say?  something isn't lining up.  rsop.msc will show you exactly what policy is changing that particular area.

[sc302 Veteran]

Also to default the policies in the system, regedit and delete the following keys (back them up prior to deletion)

 

HKLM\Software\Policies\Microsoft

HKCU\Software\Policies\Microsoft

HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

[Jason S. Global Moderator]

just to clarify before i do these, you mean on the Test Server right? obviously not on the domain controller..

[Praetor]

just to clarify before i do these, you mean on the Test Server right? obviously not on the domain controller..

 

yes. if you unsure you can deploy a test computer for this? so if something gets borked you don't screw your test server :)

[sc302 Veteran]

yes, do that with the test server...however what does running rsop.msc show, what is making that policy change?  If it is the old policy, you may want to consider removing that policy and applying a new one, if you double click on the policy in rsop.msc it will display what rules take precedence over other rules as well.  While 1 policy may be applied, another policy may take precedence.  You said you have denied all other policies except one, how exactly did you deny all other policies, did you go into every policy on your network and made an explicit rule to deny that server from accepting those policies?  Not exactly a good test if you ask me.

 

I would be more than happy to take a peak if you allow me.

[Jason S. Global Moderator]

let me get back to you guys. i have our other admin messing w/ this test server so things are getting mixed up.

[sc302 Veteran]

how did you guys make out?

[Jason S. Global Moderator]

So our other admin has made some headway into figuring out why things arent propagating.

 

This info is all new to me, so i'll try to piece it together the best i can.

 

If you login to any server and go to the following directory "\\<domain>\SYSVOL\<domain>\Policies", you'll see a list of GPOs on the currently active domain controller. Right click in that folder, choose Properties, then the DFS tab. It'll show you which domain controller is Active.

 

We found that, if you made another DC active in this tab and refresh the folder, the Policies are not the same. This led us to find out that there's a replication issue between our 3 DCs. Essentially, if a domain server was pointing to the Active DC, it would get the correct GPOs. If a domain server was pointing to a Passive DC, it wouldnt. These servers were simply relying on an old, cached set of policies.

 

This led us down the rabbit hole a bit further. We found out that the File Replication Service (FRS) is not functioning properly. It's been messed up for over a year now w/o anyone knowing. So this is where we are currently. I know nothing about these errors, so we're investigating how to fix this service.

 

Here's a screenshot:

 

[sc302 Veteran]

look at your dfs replication, directory service, and dns server for any failures there as well.

 

https://social.technet.microsoft.com/Forums/en-US/d88385dd-ba83-43d4-8bc7-85e15aa1ae58/event-id-13568

http://www.eventid.net/display-eventid-13568-source-NtFrs-eventno-1743-phase-1.htm

 

There could be a larger issue, but that is something to go on first.

[Jason S. Global Moderator]

look at your dfs replication, directory service, and dns server for any failures there as well.

yeah there's a mess of errors in those as well.

 

i'll look into the links you provided. Thanks.

[sc302 Veteran]

could be a dns configuration issue, could be a site/services configuration issue, or is could be that journal issue.  hard to say what it is without seeing the setup.  It will have to be looked at from the basic config on up, from each AD server.

[sc302 Veteran]

Probably would be faster if I looked at it or you made a call to ms

[Jason S. Global Moderator]

Relaying more information from our other Admin. He performed what is called a "non-authoritative SYSVOL Restore" today. This seemingly cleared up the issue. Here's an excerpt from the document that was used:

 

"When you are working in Active Directory environment you may fall into this problem, especially in case where you have many Domain Controllers. Sometimes you may figure out that one or more Domain Controllers are out of date with SYSVOL replication.

 

Each Domain Controller has its own folder where GPOs and scripts are saved. This folder is located under %WINDIR%\SYSVOL\domain (by default, if you changed that location during DC promotion, you need to refer to your own location).

 

There are 2 folders:

• Policies where Group Policies are saved (%WINDIR%\SYSVOL\domain\Policies)
• Scripts where logon scripts or other files are saved (%WINDIR%\SYSVOL\domain\Scripts shared as NETLOGON)

If a DC does not replicate SYSVOL you can see that some Group Policies (GPOs) or scripts are not available on DC(s) in SYSVOL\domain folder on particular DC. Another symptom may be that all GPOs are in place but they are not updated.

 

When you notice one of these behaviors, you would need to do non-authoritative SYSVOL restore which re-deploys SYSVOL data from working Domain Controller (holding PDC Emulator operations master role)."

 

This guide mentioned setting the "Burflags" in the registry from '0' to 'd6' and restarting FRS. Ive certainly never heard of this before. Anyway, it seemed to do the trick. We'll monitor for the next day or two and see what happens.