none
Old GPO settings being assigned

    Question

  • Hi all,

    We changed a GPO three weeks ago and these changes seem to have been replicated across the four DCs ok. The new GPO settings are correct on all present machines in our environment. Our problem is when we build new machines via SCCM. Some of the machines pick up the old GPO settings even though when i run 'gpresult /r' it tells me it has synced to the correct DC recently and is picking up all the linked GPOs but RSOP shows that it is picking up the old settings on that one GPO which changed three weeks back.

    If  I run a gpupdate /sync it seems to resolve the error but I would like to know where and why the machine would first be getting the old settings and how I can stop having to run a gpupdate /sync every time I build a new machine?

    Thanks

    Thursday, July 09, 2015 6:26 AM

Answers

  • Hi Andrew,

    You mentioned DC ip as 172.30.40.33. However, your DNS IPs' are  172.30.40.25 , 172.30.40.26 & 172.20.0.21. Are these nearest DCs' ? Can you run the command "nltest /sc_query:domain name" and see if it gives any error?

    On domain controllers, can you check if there is any error event logs in DFSR or FRS? Do you see any error event log in client machines related to group policy?

    -Umesh.S.K

    Thursday, August 06, 2015 7:09 AM

All replies

  • Our problem is when we build new machines via SCCM....

    If you are using OSD to deploy your custom captured image WIMfile, did you capture a machine which had been domain-joined?
    If so, that capture might have included the POL file from the domain GP..

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, July 09, 2015 9:27 AM
  • That was before my time but from what I've been told the GPO settings we are talking about (Bitlocker) were not in use back when the image was captured so that might not be relevant - not sure how I would investigate that just to be 100% though?
    Friday, July 10, 2015 3:46 AM
  • That was before my time but from what I've been told the GPO settings we are talking about (Bitlocker) were not in use back when the image was captured so that might not be relevant - not sure how I would investigate that just to be 100% though?

    checkout c:\Windows\System32\GroupPolicy\Machine

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, July 10, 2015 8:20 AM
  • Thanks Don.

    I've opened that file and there's nothing that refers to Bitlocker GPO settings in there, just Antimalware, BITS, WindowsUpdate and Terminal Services settings.

    *Opened the .pol file with the registry.pol viewer tool from https://sdmsoftware.com/freeware-thanks/

    *The Machine folder is hidden

    Thursday, July 16, 2015 3:29 AM
  • Hmm.

    If gpupdate /sync causes the problem to resolve, that suggests to me that a foreground refresh is never occurring (until you set that flag via /sync)

    So, what's the GP processing history/log look like on the machine?

    When you issue gpupdate /sync, do you accept either of the resulting restart/logoff offers right then?

    Have you simply tried a reboot without setting the /sync flag ?

    If foreground processing isn't happening at regular unforced machine startup, look to why that might be. Is it Slow Link kicking in?


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, July 16, 2015 9:03 AM
  • In Eventvwr > Microsoft > Windows > GroupPolicy > Opertational logs

     - I can't see any errors that stand out but then i haven't looked at this log before. Is there anything particular I should be looking for?

    Yes, I accept to reboot after the gpupdate /sync and the computer reboots within a minute. Just a standard restart without this doesn't work but even if it did there shouldn't be anywhere left for it to get those settings from in the first place.

    Slow link - Do you mean slow link detection (am in the main office)? Or the GPOs linked to that OU being slow to process?

    Thanks for your help Don.

    Friday, July 17, 2015 3:05 AM
  • In Eventvwr > Microsoft > Windows > GroupPolicy > Opertational logs

     - I can't see any errors that stand out but then i haven't looked at this log before. Is there anything particular I should be looking for?

    Yes, I accept to reboot after the gpupdate /sync and the computer reboots within a minute. Just a standard restart without this doesn't work but even if it did there shouldn't be anywhere left for it to get those settings from in the first place.

    Slow link - Do you mean slow link detection (am in the main office)? Or the GPOs linked to that OU being slow to process?

    Slow Link, yes, I meant Slow Link Detection. It doesn't matter where you are or necessarily the actual speed of your network - SLD is about if you are using or configuring that feature, if you have networking change or new subnets being implemented. SLD, if triggering, will be reflected in the gpresult.

    You mentioned > Operational Logs>, this suggests you are using at least WinVista - what OS are you using?
    Depending upon the OS you are using, you may need to enable deeper logging, but first, check the log entries (even in Application and System Logs), and compare the events in the time period when new/broken, against the time period when not-new/fixed. e.g. pre-gpupdate /sync, and, post-gpupdate /sync. Because you have performed a restart as part of gpupdate /sync, you can use that reboot event in the logs as a marker between pre and post.

    You can also compare the events logged between a known-good machine and a known-bad machine, to get an idea of what "normal" or known-good looks like, for comparison.

    With event logs, in general, there are many events which are "normal noise" even if the event is classed as "error" or "warning", sometimes that's acceptable/normal (eg if the computer is not able to contact a domain controller because it's unplugged from the network, GP events will be logged reflecting that. so if you know it's unplugged, then it's expected that GP won't be applied.

    Similarly, some events are logged by components as "WARNING - everything is ok", or, "INFORMATIONAL - something is horribly wrong". My point is that you can't always skip over the severity/class of events until you've familiarized yourself with what "normal" looks like in your own environment.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, July 17, 2015 8:36 AM
  • We have using Windows 7 SP1 with the latest updates

    Thanks Don - I'll take more of a look through the event logs.

    Monday, July 20, 2015 5:50 AM
  • I've had this happen on another laptop and running gpupdate /force or gpupdate /sync didn't work. I was having a look at the logs for a couple of hours and then just did a normal restart and once it booted back up again the new GPO settings were being applied! So it seems it will get the new settings, just after a few hours. No idea why this takes so long and also this doesn't explain how it is getting the old settings and from where

    I do have a NETLOGON Error in the System log but this comes up before and after it received the correct GPO settings so shouldn't be an issue:

     - This computer was not able to set up a secure session with a domain controller in domain. There are currently no logon servers available to service the logon request

    I've since had the issue on another machine and a gpupdate /sync and gpupdate /force hasn't worked.

    When I run RSOP I do get the message:

     - Unable to generate RSoP Data. In logging mode, likely causes are group policy has never successfully processed for the computer or user. RSoP logging was never enabled, or data is corrupt. In planning mode, verify that the selected Domain Controller supports RSoP

    It also doesn't get the new ADM templates and so has some settings under 'Extra Registry Settings'

    In gpresult /r it has:

     - Group Policy slow link threshold: 500kbps

    But GroupPolicy logs show that a fast link was detected


    Wednesday, July 22, 2015 5:57 AM
  • Hi, does anyone have any further suggestions?
    Tuesday, July 28, 2015 7:41 AM
  • Hi Andrew,

    This computer was not able to set up a secure session with a domain controller in domain. There are currently no logon servers available to service the logon request

    Do you see this event in client machine or DC? It appears that either server performance is bad or there must be DNS resolution issue. Can I know the IP of your DC and client DNS IP? Also, can you check your DC performance?

    -Umesh.S.K

    Tuesday, July 28, 2015 8:57 AM
  • Hi Andrew,

    Any update on the issue?

    -Umesh.S.K

    Wednesday, August 05, 2015 11:11 AM
  • It also doesn't get the new ADM templates and so has some settings under 'Extra Registry Settings'

    If you aren't using a Central Store, and the settings are defined in an ADMX, this is expected.
    If using a CS, this shouldn't be happening.
    (if it's an ADM, then the ADM is auto-copied into the GPO GUID folder on sysvol, which is why it's called "sysvol bloat" ;)

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, August 05, 2015 11:46 AM
  • Hi Umesh S K,

    We are getting that message on the client computer.

    Here are the IPs:

    Client: 172.21.204.144

    DC: 172.30.40.33

    DNS1: 172.30.40.25

    DNS2: 172.30.40.26

    DNS3: 172.20.0.21

    Can ping all by name and IP.

    Thursday, August 06, 2015 2:42 AM
  • Hi Andrew,

    You mentioned DC ip as 172.30.40.33. However, your DNS IPs' are  172.30.40.25 , 172.30.40.26 & 172.20.0.21. Are these nearest DCs' ? Can you run the command "nltest /sc_query:domain name" and see if it gives any error?

    On domain controllers, can you check if there is any error event logs in DFSR or FRS? Do you see any error event log in client machines related to group policy?

    -Umesh.S.K

    Thursday, August 06, 2015 7:09 AM
  • Hi Andrew,

    Any update on the issue?

    -Umesh.S.K

    Monday, August 10, 2015 5:36 PM
  • Hi Umesh, thanks again.

    The nltest came back with completed successfully.

    I think we might be ok now. A consultant came in and reported that the GPOs were not synchronising, DFS replication issues. I believe there were different versions on one DC to the others and the DFS had to be rebuilt. I'm trying to find out a bit more information on exactly what the did to fix this and they i want to go through it myself. Basically research about all the troubleshooting steps you take in general for GPO issues. The DFSR/FRS logs are the first point, after that I'm not sure.

    Thursday, August 13, 2015 9:26 AM