Reverting GPO tattooed settings without having the original values

  • Last Post 26 April 2017
dtobias posted this 20 April 2017

I know this is going to be messy any way I look at it but would appreciate any thoughts on developing a plan behind this.   A prior administrator was tasked with preventing Google Chrome from self-updating past a certain version because of a specific line-of-business application our organization uses. Rather than using any of the Google Chrome GPO admin templates to control the updating, he built a GPO that was more or less used to change certain settings directly in the Registry when it comes to the Google Updater as well as disabling several Scheduled Tasks also surrounding Google Updater. There’s about 10 different things going on in the GPO all in an attempt to blocking Google Updater from running. Looking at the GPO and it appears that the option for “Remove this item when it is no longer applied” was kept as No.   Fast forward to this week. We no longer use the LOB application in question so I was looking to remove this GPO and simply allow Chrome to update to its latest version. I removed the link for the GPO but when I tried to manually update Chrome on a single system, it tells me still that “Updating has been disabled by an administrator”. My initial assumption is that the settings from the GPO are still tattooed against the system even though it’s no longer linked. My biggest obstacle is I don’t know what any of the original values were so attempting to recreate them will be problematic.   I can develop and deploy Chrome packages that I can push to our users but since Chrome isn’t our main browser and is more of a secondary option for our users; I was hoping to just allow it to self-update silently.   As stated….I know any way I dice this, I’m in for some work but any thoughts or opinions would definitely be welcomed!   Thank you ~Dave

CONFIDENTIALITY NOTICE: This communication and its attachments may contain non-public, confidential, or legally privileged information including HIPAA-protected PHI. The interception, use or disclosure of such information is prohibited. If you are not the intended recipient, or have received this information in error, please notify the sender immediately by reply email and delete all copies of this message and attachments without reading, saving, or further distributing them.

Order By: Standard | Newest | Votes
darren posted this 26 April 2017



Yes, in many cases that utility will do the job. Interestingly, however, I designed it to look in the “GP archive file” for the settings to remove, just as the GP engine would.

The effect of this is that any settings delivered to those 4 keys below, that didn’t use Admin Templates policy to get delivered, would not get removed by my utility. This utility is most useful in the scenario where you have a machine that’s been removed

from a domain, that continues to have Admin Template settings “stuck” in the registry.


It also reminds me that this utility is old

😊. I need to update it!





SamErde posted this 26 April 2017

Darren, would your Clean Registry Policy tool not be able to take care of this?


darren posted this 21 April 2017

If you still have the GPO that was using GP Preferences to set these options, then you should be able to identify where the settings are set within GP Editor. My guess is that the issue is within one of 4 registry keys that are typically

used by applications to enforce policy:







The challenge of setting these outside of Administrative Templates is that they don’t benefit from the tattooing removal mechanism when the GPO is unlinked—so that’s probably why you’re seeing what you are. Frankly, one way to handle this

is to delete the keys and values under these 4 keys above. What this will do is essentially remove all tattooed registry settings. Then when you do a

gpupdate /force these keys will be re-populated from the legitimate, remaining, linked GPOs, but your Chrome settings should get removed (assuming that GPO is now unlinked).






gduke posted this 20 April 2017



As others have said, it would be useful to be able to compare a system that has the Google update settings applied against another system.


This article suggests there’s a single value you can set to prevent (or enable) the Google autoupdate service: has some more complete information:


If you can figure out which registry settings are causing the problem, I would suggest using Group Policy Preferences to delete (or change) those settings.




Configuring a Registry Item (


Group Policy Preferences Overview (


Group Policy Preferences Frequently Asked Questions (FAQ) (


I hope that helps.




Geoffrey Duke

802.656.1172 |

Sr Systems Administrator |

Enterprise Technology Services |

University of Vermont







PARRIS posted this 20 April 2017

Were the settings in the GPO delivered via an ADM or GPP?


If it was an ADM then the ADM template may still be on the server that the GPO was created from.

The GPO can then be unset – I always used to put the old and new values in my template.




Mark Parris


Cloud | Identity | Security


MVP Enterprise Mobility | MCM Directory Services

Mobile: +44 7801 690596

E-mail: mark@xxxxxxxxxxxxxxxx


Twitter | Blog | LinkedIn | Skype |



SmitaCarneiro posted this 20 April 2017

If you have access to a snapshotting tool like Prism Pack, setup a clean machine and then take a snapshot of applying the GPO . That should help you detect the registry keys that were changed. Be very careful

though, as tools pick up much more than you think they will.


Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

Ross Enterprise Center

3495 Kent Avenue, Suite 100

West Lafayette, IN 47906



kennedyjim posted this 20 April 2017

Regedit delete the offending entries and reinstall Chrome, using the enterprise version.  Might be able to just push the enterprise msi and it will overwrite the old entries…worth a try.


Test the heck out of it but it feels like it would work.