• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1778
  • Last Modified:

Servers using old GPO

I am having a problem where I am pulling policy results for a user accounts on different servers and getting mixed results on what gpo's are being read.

My setup is 3 domain controllers and 6 Remote Desktop servers all running windows 2k8 R2 with a 2k8 R2 Active Directory domain. The 6 TS servers are in a RD farm config. When I ran the gpresult for the same username against all 6 servers, I got half of them reading and applying the newest versions of the GPOs while the other half are using older versions and not seeing the newly created GPOs. The half that read the old GPOs are also showing GPOs that have been unlinked.

The only thing that I've found different between the servers is which DNS server they are pulling from, which I thought was the main issue, but I am not sure anymore after I did some testing to prove that.

Here's what I've done so far.

1.) Ran GPOTool - Everything came back OK
2.) Ran Repadmin /showrepl - No problems, all servers replicating to each other
3.) Cleared the GPO cache (programdata/microsoft/group policy/history/*.*)on one of the servers that is having a problem and then ran a gpupdate /force - did not fix.
4.) Rebooted other two domain controllers and left one up, then ran gpupdate /force on all 6 servers to refresh from the same Domain Controller ans still had different rsop on half of them.
5.) confirmed that loopback is off on all servers
6.) DNS servers on the single NIC are set to two of the Domain Controllers
7.) Windows firewall is off on each server and the Domain Controllers
8.) The operational log for Group Policy doesn't show any errors when I do a gpupdate /force.
9.)The only errors I get in GP event log is on boot "Group Policy dependency (Network Location Awareness) did not start. As a result, network related features of Group Policy such as bandwidth estimation and response to network changes will not work." followed by "Group policy bandwidth estimation failed. Group policy processing will continue. Assuming fast link." When I checked the service, it is running though. I'm getting this error on machines both good and bad servers.
10.) Made sure that the local profiles are all gone. We are using Roaming profiles, so the RD's are using TEMP folders (which of course I'm making sure are gone before testing)

Any idea's on what might be causing something like this to happen? It feels like a cache issue, but I don't know where any other cache could be hidden or what else is going on.

This has been going on since I installed everything, so it's never worked properly.
  • 2
1 Solution
If you run a gpresult /r on the server not getting the new policy what does it output?

Does it actually see the new gpo but is denied\not applied?
musickmannData AnalystAuthor Commented:
I ran it locally and the GPO's show up under the applied section. I have been running gpresults from one of the domain controllers this whole time. I didn't expect it to be any different if I ran it locally vs remotely on a DC. Just asking, but do you know if this is expected behavior from the servers because they are in a Farm?
I would strongly recommend using the Group Policy Results Wizard from Group Policy Management console as you can specify the workstation\server name from this and check for results remotely.

Not sure why you are getting inconsistencies doing the gpresult remotely (assuming you are using RDP) it could be a cache issue for that rdp session, are you logging in as administrator to run the gpresult?

Another thing to check is on the server via session open command prompt and type in SET if the logonserver the same when running via RDP and locally?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now