none
Group Policy Preferences, roll back, and the Policies key

    Question

  • I have an odd case where someone set a Group Policy PREFERENCE to DELETE a registry value under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\... The registry value that it deleted wasn't originally applied by a policy, but was applied once by an application.

    The problem is now if if I remove this policy the registry value comes back. There are reasons behind this that aren't relevant, but I need to remove this policy and I WANT the registry to stay tattooed. Where are these values getting backed up to that after the policy is no longer applied the values are restore? I am 100% sure group policy is the one putting the value back and not an application. If there is a cache that stores this I could clear it before removing the policy, but I cannot find anything on this.

    Thursday, April 07, 2016 9:12 PM

Answers

  • > disable the policy, run GUPDATE on the computer, watch the values come back,
     
    If the value comes back during GPUpdate, it IS a different policy that
    is setting it. There's no cache during manual GPUPdate.
     

    Wanted to clarify one thing that I incorrectly stated. The GPP's are actually blanking out data in values (ex. "") for existing values. There are values names "1" - "10". There is a GPP set for each one that if data = something, then set value to "". When I disable the policy and do an gpupdate /Force all of the values are set back to what they were. I just traced it out and it is GP setting the values during a gpupdate. I am 100% sure there is no other GPO setting these values as that is impossible. These values originally came from an application local to the computer. I am wondering if it has something to do with GPP making changes directly to the Policies key. Still at a loss with this.

    I just did some more testing and found something very interesting. After blocking the policy for the computer and doing a gpupdate the values were restored. I then went looking around because the values HAVE to be stored somwhere on the computer. I looked at registry.pol under %WINDIR%\System32\GroupPolicy\Machine and the values were all saved in there! I reapplied the policy, the values blanked out, I renamed the registry.pol file, reapplied the policy, and values did not get restored this time.

    UPDATE: So what this looks like is the application that is making the original registry addition was doing it via local Group Policy hence the registry.pol file. That is why the values were coming back after the domain policy was blocked. Tricky situation.


    • Edited by MarkD7987 Thursday, April 14, 2016 6:28 PM
    • Marked as answer by MarkD7987 Friday, April 15, 2016 12:10 PM
    Thursday, April 14, 2016 5:53 PM

All replies

  • Hi,
    If I understand correctly, you scenario is that a GPP was configured to delete a registry key. You removed the GPP, then that registry key came back. Please help to confirm this.
    As far as I know, GP preference settings will tattoo, by default. In other words, when a Group Policy object (GPO) goes out of scope, the GP preference setting will be remain in the registry. In your case, that means after you remove that GPP, the value will not return unless you reconfigure another GPP to add that value back.
    According to your description, that value was restored only after the GPP is removed without re-adding it by another GPP. I suspect that something else created that registry key, such as another GPO or application. If that is the case, please use group policy result wizard to see if other group policy is configured to add that key. Also, I would suggest you use process monitor tool to check it. Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. You could download it from: https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx

    Regards,
    Wendy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 08, 2016 5:40 AM
    Moderator
  • As I said before it is NOT something else. You can literally disable the policy, run GUPDATE on the computer, watch the values come back, re-enable the policy, run the GPUPDATE, watch the values go away. No other policy is touching these values.
    Friday, April 08, 2016 12:07 PM
  • > disable the policy, run GUPDATE on the computer, watch the values come back,
     
    If the value comes back during GPUpdate, it IS a different policy that
    is setting it. There's no cache during manual GPUPdate.
     
    Friday, April 08, 2016 12:21 PM
  • > disable the policy, run GUPDATE on the computer, watch the values come back,
     
    If the value comes back during GPUpdate, it IS a different policy that
    is setting it. There's no cache during manual GPUPdate.
     
    Wanted to clarify one thing that I incorrectly stated. The GPP's are actually blanking out data in values (ex. "") for existing values. There are values names "1" - "10". There is a GPP set for each one that if data = something, then set value to "". When I disable the policy and do an gpupdate /Force all of the values are set back to what they were. I just traced it out and it is GP setting the values during a gpupdate. I am 100% sure there is no other GPO setting these values as that is impossible. These values originally came from an application local to the computer. I am wondering if it has something to do with GPP making changes directly to the Policies key. Still at a loss with this.
    Thursday, April 14, 2016 4:44 PM
  • > disable the policy, run GUPDATE on the computer, watch the values come back,
     
    If the value comes back during GPUpdate, it IS a different policy that
    is setting it. There's no cache during manual GPUPdate.
     

    Wanted to clarify one thing that I incorrectly stated. The GPP's are actually blanking out data in values (ex. "") for existing values. There are values names "1" - "10". There is a GPP set for each one that if data = something, then set value to "". When I disable the policy and do an gpupdate /Force all of the values are set back to what they were. I just traced it out and it is GP setting the values during a gpupdate. I am 100% sure there is no other GPO setting these values as that is impossible. These values originally came from an application local to the computer. I am wondering if it has something to do with GPP making changes directly to the Policies key. Still at a loss with this.

    I just did some more testing and found something very interesting. After blocking the policy for the computer and doing a gpupdate the values were restored. I then went looking around because the values HAVE to be stored somwhere on the computer. I looked at registry.pol under %WINDIR%\System32\GroupPolicy\Machine and the values were all saved in there! I reapplied the policy, the values blanked out, I renamed the registry.pol file, reapplied the policy, and values did not get restored this time.

    UPDATE: So what this looks like is the application that is making the original registry addition was doing it via local Group Policy hence the registry.pol file. That is why the values were coming back after the domain policy was blocked. Tricky situation.


    • Edited by MarkD7987 Thursday, April 14, 2016 6:28 PM
    • Marked as answer by MarkD7987 Friday, April 15, 2016 12:10 PM
    Thursday, April 14, 2016 5:53 PM
  • > stored somwhere on the computer. I looked at registry.pol under
    > %WINDIR%\System32\GroupPolicy\Machine and the values were all saved in
     
    Yes that's what I thought already after reading the previous post. This
    is the "local policy" which can be edited through "gpedit.msc" :-)
     
    Friday, April 15, 2016 11:39 AM
  • > stored somwhere on the computer. I looked at registry.pol under
    > %WINDIR%\System32\GroupPolicy\Machine and the values were all saved in
     
    Yes that's what I thought already after reading the previous post. This
    is the "local policy" which can be edited through "gpedit.msc" :-)
     
    Of course, but you don't see any of this when you launch gpedit.msc. Any way to actually see in the console?

    • Edited by MarkD7987 Friday, April 15, 2016 12:06 PM
    Friday, April 15, 2016 11:40 AM
  • > Of course, but you don't see any of this when you launch gpedit.msc.
     
    Yes - if you do not have the matching ADM templates on your computer,
    you will not see the values in registry.pol because gpedit.msc requires
    ADM templates to present a configuration dialog for each value.
     
    Friday, April 15, 2016 12:09 PM