locked
Old Group Policy settings remain on machines RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a handful of machines that retain old group policy data, specifically incorrect information for the Windows Update settings.  In particular, these machines point to an old intranet WSUS address.  All policies have been updated to reflect the new server address but these machines have not accepted the updated information.  I have scoured all GPO's to make sure there is nothing that still points to the old address and there is not.  I have removed and created new GPO's to get a fresh start, but no luck.

    The machines are desktops and laptops running XP Pro SP3 and all servers are 2008 R2 SP1.

      So far I have tried the following to no avail:
    -gpupdate /force...no change
    -updating the GP info manually on the machine, but it reverts to the old info.
    -deleting the reg keys for the info and running gpupdate /force - but it returns the old info
    -remove PC from domain and re-join...no change
    -I have been through all of the Windows Update troubleshooting information and everything tests fine (can reach the server, can download the wuident.cab file, have done all the client self update troubleshooting and resets...all to no avail
    -I have run gpresult and all the data is correct, the right GPO's are applying
    -I have checked to make sure both User and Computer Configurations are set to apply
    -there are no GP restrictions in place, nothing is configured to keep the policy from applying
    -I have modified other group policy settings to make sure the GPO's are applying and discovered that only part of the Computer Configuration is applied...specifically anything within Windows Settings is applied, however I can't find any settings from within Administrative Templates that are being applied.

     

    What has worked, but only temporarily, is the following:

    - Delete HKLM\Software\Microsoft\Windows\CurrentVersion\GroupPolicy

    -ipconfig /flushdns

    -arp -d *

    -reboot and the correct settings will apply consistently in all cases.

     

    The problem is that after a while the old settings reappear.

    I have checked the event view on these machines looking for SceCli errors, but all of them report that the policy is applying successfully.

    gpedit.msc reports that the local policy is empty, so I don't think the problem lies there, however I plan to test this more thoroughly by disabling all GPO's from applying to a specific machine and then checking the local policy again.

     

    I have not been able to find any permanent solution so far and welcome any help I can get.


    Thanks!

    Tuesday, October 11, 2011 5:56 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Steve-

    It is possible that the DDP is corrupt, though I'm not sure what kind of corruption would result in old settings being continuously read by your Win7 clients (and not XP). Server 2008 and above has a tool called DCGPOFix that is designed to reset the settings within the DDP and Default DC Policy GPOs. You can run it against one or both of the GPOs so that could be an option. Also, the issue you're seeing with foreground GP processing not running on Win7 is curious. Have you had a look at this setting:

    Computer Configuration\Policies\Administrative Templates\System\Group Policy\Startup Policy Processing Wait Time.

    You might try bumping up that value from the default to cure this issue.

    In the meantime, another option is to crack open the registry.pol file that is stored in SYSVOL for your DDP and see if it is harboring settings that shouldn't be there. I have a GUI tool that lets you view the contents of this file here:

    http://www.gpoguy.com/FreeTools/FreeToolsLibrary/tabid/67/agentType/View/PropertyID/87/Default.aspx

    Let me know if you find those WU settings within that file. We may be able to avoid nuking the whole DDP.


    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    • Marked as answer by Steve Martens Tuesday, November 8, 2011 6:07 PM
    Monday, November 7, 2011 5:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Steve-

    "Rats" on reading the registry.pol file with my tool! That could indicate a bug in my app or it could be a problem with the registry.pol file. If you have the Server 2003 Resource Kit installed anywhere, MS has a command-line equivalent of my tool called regview.exe. Try using that on your registry.pol file and see if it has any better luck. If not, then the file may indeed be corrupt. If you don't have a lot of Admin Template settings in that GPO, you might be able to just blow away that file and start over without running DCGPOFix. 

     

    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    • Marked as answer by Steve Martens Tuesday, November 8, 2011 6:07 PM
    Monday, November 7, 2011 6:56 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Might want to look at this thread that talked about similar issues and let us know if you have additional questions:

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/75ab1158-e460-4aa5-8658-402836e6096a

    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    Tuesday, October 11, 2011 6:00 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks Darren, that was helpful.  I do not have results across all machines yet, but I'm making progress now.

    Tuesday, October 11, 2011 10:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I've been through the steps recommended in the link supplies.  This works temporarily only.  Within 24 hours the affected machines have reverted to the old info.  I am in need of further help.
    Thursday, October 13, 2011 9:08 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    I would like to confirm that have you delete all the old Group Policy registry keys using GPP?

    If after delete manually, it works, we suggest you use GPP to delete them. After that the registry keys won't come back.

    Best Regards,

    Yan Li

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, October 17, 2011 4:54 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yes, the old ones have been deleted.
    Monday, October 17, 2011 8:16 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Steve-

    I presume the WSUS settings you're trying to deliver are under Computer Configuration, rather than user configuration, correct? Assuming that is correct--have you run GP Results from within GPMC against one of these machines to just double-check that the bad settings aren't coming from some lingering GPO?

    If all that fails to produce results, try this: assuming these are per-computer settings, on one of these machines, open up the folder %allusersprofile% and look for a hidden system file called "ntuser.pol" (make sure you find the .pol file and not the .dat). If you find that file, rename or delete it, and the do a gpupdate /force and see if that helps.

    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    • Marked as answer by Yan Li_ Thursday, October 20, 2011 1:09 AM
    • Unmarked as answer by Steve Martens Thursday, October 20, 2011 1:13 AM
    Monday, October 17, 2011 9:01 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks Darren, I'll give that a try tomorrow and post an update following that.

     

    Steve

    Thursday, October 20, 2011 1:14 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Darren,

    The settings are applied from Computer Configuration, correct.  

     

    I have run GP Results against a few of the machines, with some odd results.  The Default Domain Policy is applied successfully according to the results.  The AU settings in the results show the old info on affected machines (the new info displays correctly on functioning machines, as one would expect)  although the Default Domain Policy is correctly configured with the new settings and seems to be successfully applying to all machines, yet with different results on some.  I think this is the source of my confusion....where are these settings coming from when all GPO's are correctly configured?

    Some machines show the Local Group Policy is being applied and on some it is denied.  However, it is applied to both machines with and without the WSUS problem and in all cases the Default Domain Policy is the winning policy.

     

    I could not find 'ntuser.pol'

     

    Steve

    Thursday, October 20, 2011 5:08 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Additional information, I have discovered that in some cases the following works:

     

    regsvr32 /u wuaueng.dll

    del c:\windows\softwaredistribution

    del c:\windows\windowsupdate.log

    regsvr32 wuaueng.dll

    net start wuauserv

    wuauclt.exe /resetauthorization /detectnow

     

    For some machines this corrects the wrong settings right away, for some of them the correct info shows up after a few reboots or in some cases just after 15 minutes or so.

    Saturday, October 22, 2011 1:28 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This looks like GP is unable to enforce the settings to the local machine OR the old WSUS path is stored and called by one of the auto update related file.

    But GP should always take precedence but in your case local files are doing the trick. for me it looks like a local currupted file problem rather than a GP problem.

    I think GP setting for WSUS lies under Comuter configuration - Amin templates which is just registry changes,

    Check for the specific registry key to see gp has done the proper changes (You should have new WSUS path under HKLM),  this will tell u that GP has processed succesfully.

    But the Automatic update related files which pulls the WSUS details from the registry hive is not picking up the settings properly, that is why it worked when you delete the windows update directory.  

    I think this is what happening. I'll try and find more when Iam back to office on monday.

    Goodluck friend.

    AR

    Best Regards, AR
    Saturday, October 22, 2011 9:44 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Correct, GP settings are in Computer Config - Admin Templates.  The registry entries on the problem machines do in fact show the wrong info despite the logs indicating that GP is applying successfully.  gpupdate does not correct the issue, reports that it is applying correctly, and seems to function for other settings, just not these ones.
    Saturday, October 22, 2011 7:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Its called Tattoing, see the below link.

    http://www.gpoguy.com/FAQs/Whitepapers/tabid/63/articleType/ArticleView/articleId/5/Understanding-Policy-Tattooing.aspx

    You can disable that settings or you have remove manually or you can use GPP for deleting those keys.

    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
    Sunday, October 23, 2011 8:40 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks Biswajit, but according to Darren's article (great article, which I've read before) the settings I'm having problems with are applied to part of the registry where tattooing does not happen.  See the following quote from the article.

     

    " Microsoft has allocated 4 registry keys--2 under HKEY_LOCAL_MACHINE and 2 under HKEY_CURRENT_USER which are considered "no-tattooing zones". Any registry values placed under one of these 4 keys will be removed when the policy no longer applies.  These 4 keys are:

    HKEY_LOCAL_MACHINE\Software\Policies

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies

    HKEY_CURRENT_USER\Software\Policies

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies"

     

    Unless I'm mistaken, the WindowsUpdate settings fall within the four keys designated as no-tattooing zones.  Correct me if I'm wrong here, or if I'm missing something.


    Monday, October 24, 2011 2:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    No you're correct Steve--those WSUS settings are all within the Policies keys. The fact that those settings are staying stuck (say that 4 times fast :-)) is a bit odd. I take it you did not find an ntuser.pol file anywhere on one of these systems? Another option--can you check the permissions on the policies key under which the old WSUS settings appear to see if they are different from any other policies key permissions? (it's a long shot but worth a try). It's interesting that you say that essentially re-initializing/re--registering the WSUS client works in some cases--is there any consistency to when it works vs. when it doesn't? Like particular OS version or something else?

    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    Monday, October 24, 2011 6:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Indeed Darren, I did not find an ntuser.pol file on any of the systems yet.  I'll take a look at the permissions tomorrow.  Where re-initializing/re-registering the WSUS client has been successful, the OS's have been XP SP3.  When I attempt to do this on a Windows 7 OS, I get an error msg "The module 'wuaueng.dll' was loaded but the call to DllUnregisterServer failed with error code 0x80070005"  I havn't looked into this yet either.  Other than that, I have not been able to identify any other consistent factors.  That said, if this process continues to work on all my XP machines, I may have found a solution.

     

    Steve

    Tuesday, October 25, 2011 2:31 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Darren, here's the update on the permissions.

     

    Good and bad PC's have the same permissions for :

     

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

    HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

     

    HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy

    HKLM\Software\Microsoft\Windows\CurrentVersion\Policies

     

     

    Functional PC's have the following added permissions:

    HKCU\Software\Policies\Microsoft - the user RESTRICTED has read access

    HKLM\Software\Policies\Microsoft - the user CREATOR OWNER has Special Permissions granting Full Control, USERS and POWER USERS both have Read access

     

    The only one that seems sigificant is the CREATOR OWNER with Full Control of HKLM\Software\Policies\Microsoft.  In all cases, the Local Adminstrators and the SYSTEM have Full Control

    Tuesday, October 25, 2011 5:55 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    OK. Those perms all look ok. The error you're getting on Win7 is an access denied error because you have to run the commands as elevated (i.e. administrator) due to UAC. Try that and see if it works on Win7--if it works, then I suppose that at least a functional fix--though doesn't explain the policy settings getting stuck (at least in my mind).


    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    Tuesday, October 25, 2011 8:05 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The elevated cmd prompt still didn't work.  What's more interesting, the problem is returning to machines I had corrected using the above process.  I have learned one more thing that is very interesting.

     

    The Group Policy Infrastructure fails during a reboot, preventing the other GP components from processing.  This does not happen after I have logged in, then run gpupdate /force.  In this scenario, all components process.

     

    I have returned all WindowsUpdate settings in my GPO to 'not configured'.  At one point the settings disappeared from my registry but they returned after a short while.  I have no idea how or where they came from.

    Tuesday, October 25, 2011 9:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Well, I thought it was a DNS issue for a while.  But it's not.  Is there any possibility that my Default Domain Policy could be corrupt somehow?  I have configured a separate GPO just to apply WindowsUpdate settings to client machines, the same settings are Not Configured in the Default Domain Policy, however, from a client machine, gpresult indicates that the Default Domain Policy is configuring WindowsUpdate settings with incorrect information.  This information is not present in the policy.  If you look at the gpresults for the same client from the server, it does not show this information.  It seems like the server has the correct information and the client is reading information from somewhere else or is retaining old settings somehow.

    Several months back, we transitioned from SBS2003 to WS2008 R2.  The process was not smooth and there was a lot a cleanup to be done afterwards.  Is there any chance this could have affected my policies?

    Sunday, October 30, 2011 3:51 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    For those who might still be reading this...I have learned only a few additional things.

    My Windows 7 clients are not contacting a DC at startup, but everything works fine after they establish a connection.  Background group policy processing is happening.

     

    My Windows CP clients will pick up the correct GP settings after 'ipconfig /flushdns' and 'arp -d *', followed by resetting windows update and clearing the relevant registry settings, then reboot.  This works every time for my XP machines.

     

    That said, the wrong settings will come back, so I do believe I have a corrupt Default Domain Policy.  Any advice?

    Monday, November 7, 2011 4:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Steve-

    It is possible that the DDP is corrupt, though I'm not sure what kind of corruption would result in old settings being continuously read by your Win7 clients (and not XP). Server 2008 and above has a tool called DCGPOFix that is designed to reset the settings within the DDP and Default DC Policy GPOs. You can run it against one or both of the GPOs so that could be an option. Also, the issue you're seeing with foreground GP processing not running on Win7 is curious. Have you had a look at this setting:

    Computer Configuration\Policies\Administrative Templates\System\Group Policy\Startup Policy Processing Wait Time.

    You might try bumping up that value from the default to cure this issue.

    In the meantime, another option is to crack open the registry.pol file that is stored in SYSVOL for your DDP and see if it is harboring settings that shouldn't be there. I have a GUI tool that lets you view the contents of this file here:

    http://www.gpoguy.com/FreeTools/FreeToolsLibrary/tabid/67/agentType/View/PropertyID/87/Default.aspx

    Let me know if you find those WU settings within that file. We may be able to avoid nuking the whole DDP.


    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    • Marked as answer by Steve Martens Tuesday, November 8, 2011 6:07 PM
    Monday, November 7, 2011 5:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Darren,

     

    I've been trying to avoid DCGPOFix so far, however I recognize it may be necessary soon.

     

    Thanks for the advice on Startup Policy Processing Wait Time, I've bumped the value up for now, we'll see what happens.

    UPDATE: No Group Policy errors after startup now.  Thanks!

     

    I am having a problem viewing the registry.pol file for the computer config of the DDP...when I submit the path, I receive the error: "The output char bugger is too small to contain the decoded characters, encoding 'Unicode (UTF-8)' fallback 'System.Text.DecoderReplacementFallback'. Parameter name: chars."

     

    Steve

     

     

     

     


    Monday, November 7, 2011 5:50 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Steve-

    "Rats" on reading the registry.pol file with my tool! That could indicate a bug in my app or it could be a problem with the registry.pol file. If you have the Server 2003 Resource Kit installed anywhere, MS has a command-line equivalent of my tool called regview.exe. Try using that on your registry.pol file and see if it has any better luck. If not, then the file may indeed be corrupt. If you don't have a lot of Admin Template settings in that GPO, you might be able to just blow away that file and start over without running DCGPOFix. 

     

    Darren

    Darren Mar-Elia MS-MVP, Group Policy
    www.gpoguy.com
    www.sdmsoftware.com - "The Group Policy Experts"
    • Marked as answer by Steve Martens Tuesday, November 8, 2011 6:07 PM
    Monday, November 7, 2011 6:56 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Darren

     

    Regview did work to view the file, however the contents were too much for the window and I could not read everything.  I tried DCGPOFix /target:domain and that ran successfully.  However, when I returned to the GPMC and attempted to access the DDP, I received an error indicating the file could not be found.  The settings indicated nothing had been configured and the edit window failed to display any contents.  So restored the DDP from my backup and all is as it was now.  Any idea how I can make this work as expected?  

     

    UPDATE: A second attempt worked without any problems.  Odd.  I'll be working on comparing the newly reset DDP with my old DDP and creating new GPO's for any settings I had changed.

     

    Thanks,

     

    Steve


    Monday, November 7, 2011 7:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    DCGPOFix did fix up my DDP and DDCP.  I'm guessing the problem was caused in the ugly transition from SBS2003 to WS2008R2.  Rebuilding them has cleaned them up and so far I'm seeing positive results.  Workstations are picking up the correct policy settings.  I'm going to give it a few days to see all the results and watch for any problems, but so far this is the best progress I've seen yet.
    Tuesday, November 8, 2011 6:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I had exactly the same error on some of our machines. Therefore I also tried to fix DDP and DDCP but that didn't resolve the issue in my case.

    So I checked which logon server the machines with the error are using. It turned out that this machines all log on to our old Win 2003 domain controller. It turned out that on this domain controller the changes of the WSUS policy wasn't replicated. By the way, any newer changes were replicated.

    So I forced reinitialization of the File Replication Service replica sets using this article: http://support.microsoft.com/kb/290762/en-us. I started on the wrong server, therefore the old policy was activated on all DCs, so be careful when using this procedure. Anyway, it was not a problem to change the WSUS server setting in GPO again. This change was replicated to all DCs with no problem.

    After that the settings was deployed to all machines correctly.

    Just wanted to share this experience ....

    Saturday, July 6, 2013 9:47 AM