GPO Tattooing Myth: Administrative Templates, Not Configured and Live Policy

"The old GPO tattooed the registry." I wrote that diagnosis myself, on one enterprise laptop, and it was wrong. The value was not stranded. A different Group Policy Object (GPO), still applying, was writing it back at every refresh.

Tattooing is real, but it is narrower than most people think. Microsoft documents which kinds of Group Policy settings stay behind and which are removed. Administrative Template settings, the ones most of us mean when we say "the GPO", are in the second group. If one of them is still on a device, the first suspect is a GPO that still applies, not a dead one.

The problem: a value that "should have gone"

The project was moving Windows Hello for Business settings from Group Policy to Intune. The Intune profile set a minimum PIN length. One laptop accepted a shorter PIN than Intune asked for.

The registry explained why. A Group Policy copy of MinimumPINLength was on the device. For Windows Hello, Group Policy wins over Intune, so the Group Policy value was the one in force.

The team had already denied the Windows Hello GPO for this laptop. So the story wrote itself: the GPO was denied, its value was left behind, the registry was "tattooed". The obvious fix was to delete the value.

This is what the read looked like. The names and numbers are fictional, but the shape is the same as on the real device:

Illustrative. On the laptop I examined, the value sat in a PINComplexity subkey under HKLM\SOFTWARE\Policies\Microsoft\PassportForWork. The GPO names and PIN lengths here are invented.

Two facts broke the story. First, the denied GPO never set a PIN length at all. It carried the rest of the Hello settings, but not that one. Second, the value came from a general workstation GPO, here called "Contoso - Workstation Baseline". That GPO carried one Hello setting among many unrelated ones, and it was still applying at every refresh.

So the value was not stranded. It was live policy. Deleting it bought a short window at best, and any "after" evidence gathered in that window meant nothing.

Why it happens: what tattooing really is, and what it is not

Tattooing means a setting stays on a device after the thing that set it no longer applies. Whether that can happen depends on what kind of setting it is and where it is written. There are three kinds to tell apart.

1. Administrative Template settings: removed by design

Administrative Templates are the registry-based part of Group Policy. Microsoft's page on editing them says it directly: "Administrative Template policy settings are also known as registry-based policy settings."

Microsoft's Administrative Templates overview explains where these "true policies" live: "The registry information for true policies is located under \Software\Policies or under \Software\Microsoft\Windows\CurrentVersion\Policies in the HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE hives."

It then gives the removal behaviour. One of the stated advantages of those keys is: "When Group Policy changes, for any reason, these trees are cleaned, and the new policies are then rewritten." And the conclusion: "they will not cause persistent settings in the registry when the GPO that applies to them is no longer in effect."

The archived Group Policy team post says the same in plainer words. Policy settings will "not tattoo. In other words, when a Group Policy object (GPO) goes out of scope, the policy setting is removed allowing the original configuration value to be used."

Be clear about the age of these sources. The overview is a Windows Server 2003 page and the blog post is from 2008. Both are still published on Microsoft Learn. I did not find a newer Microsoft page that restates the removal rule in these words, and I found none that contradicts it.

2. Group Policy Preferences: they stay unless you say otherwise

Group Policy Preferences (GPP) are a separate set of client-side extensions. One of them, Group Policy Registry, can "Create, replace, or delete registry settings". It writes the key and value its author names in the item, and it is not one of the fixed template locations described above.

Microsoft's current Group Policy preferences page states the default: "By default, Group Policy Preferences don't remove settings when a Group Policy Object (GPO) no longer applies to a user or computer."

The opt-out is a check box on the item's Common tab. Selecting Remove this item when it is no longer applied changes the behaviour: "if the preference item falls out of scope, due to item-level targeting or GPO changes, the settings previously applied by that item are removed." Microsoft adds that the option "automatically sets the action to Replace".

3. Anything else that writes the registry

Scripts, installers and manual edits are not Group Policy at all. Group Policy does not clean up after them. The old Administrative Templates page calls settings stored outside the Policies trees preferences, and says they behave the way Windows NT 4.0 System Policies did: they remained "until the value was reversed, either by a counteracting policy or by editing the registry."

Put together:

The case in this post sits in the first row. The value was under HKLM\SOFTWARE\Policies, written by an Administrative Template setting. By Microsoft's own rules, if no applying GPO set it, it should have been cleaned. It was still there because a GPO still set it.

Enabled, Disabled and Not Configured

Every Administrative Template setting has three states. Microsoft's page on editing them defines each one by what it does to the registry:

For Minimum PIN length, Disabled and Not Configured give the user the same PIN rule. Microsoft's Windows Hello policy reference says: "If you disable or don't configure this policy setting, the PIN length must be greater than or equal to 6."

But the PIN rule is not the only thing that matters during a migration. What matters is whether Group Policy is still configuring the setting. Microsoft's Windows Hello configuration page says: "If you mix GPO and CSP policy settings, the conflicting CSP settings aren't applied until the group policy settings are cleared." Disabled is still a configured state, so it is not cleared. Not Configured is the state that leaves the registry alone.

Why the GPO's name misled everyone

A GPO's name is a label someone typed. It says nothing reliable about what the GPO contains. In this project, everybody looked at the GPO called "Windows Hello" because that was where Hello settings were expected. The one setting that mattered was in a baseline GPO nobody associated with Hello.

The lesson: look for the setting, not the policy. Search every GPO's settings for the value you see on the device. The companion post Find which GPO sets a registry value walks through that search.

How to verify: live policy or leftover?

Every check here only reads. Don't delete anything yet: the value on the device is your evidence.

Check 1: where is the value?

The registry path tells you which row of the table you are in. For Windows Hello, Microsoft documents two different parents, and they look confusingly alike:

• Under SOFTWARE\Policies: an Administrative Template wrote it. Microsoft says this tree is cleaned when Group Policy changes. A value that survives is most likely live.
• Outside the Policies trees: a Preferences item, a script or an installer could have written it. Real tattooing is possible here.
• Under SOFTWARE\Microsoft\Policies\PassportForWork: this is the CSP path. It is not Group Policy at all.

Check 2: which GPOs applied at the last refresh?

The Group Policy operational log records policy processing. Microsoft's troubleshooting guidance says: "Events in this log include the list of applied GPOs and a list of denied GPOs that includes the reasons for the denials." The log name is Microsoft-Windows-GroupPolicy/Operational.

This reads the newest events from that log:

Good looks like this: the GPO you denied is in the denied list, or in neither list, and you can name another GPO in the applied list that carries the setting. Bad looks like this: you cannot name any applied GPO that sets the value. Then a Preferences item, a script or a local policy is the next suspect. The companion post Find which GPO sets a registry value shows how to read the applied and filtered lists in detail.

Check 3: compare two times

This is the check that settles it. Every registry key has a last write time. Microsoft's RegQueryInfoKey documentation says it records "the last time that the key or any of its value entries is modified." Note that the time belongs to the key, not to one value.

Compare that time with the time of the last Group Policy refresh:

Illustrative times. On the laptop I examined, the key's last write time landed a few seconds after the refresh on two separate refreshes. The companion post has the read-only steps that produce both numbers.

What good and bad look like:

• Write time a few seconds after a refresh, more than once: live policy. Find the GPO that carries the setting.
• Write time weeks old, matching no refresh: a leftover is now plausible. Look for a Preferences item or a script.
• Write time after a refresh only once: not enough. Wait for another refresh and check again.

Check 4: don't trust an empty History folder

Where do Administrative Template settings actually live? In the GPO itself. Microsoft's overview says that the Registry.pol file "contains registry settings that are specific to the HKEY_LOCAL_MACHINE key. It is stored in the GPT\Machine folder." On SYSVOL, each GPO has its own folder, which Microsoft's troubleshooting guide writes as \\<dcName>\SYSVOL\<domain>\Policies\<guid> when it locates the GPO's gpt.ini. Read the GPO's own settings, or its settings report, not the local cache.

The fix: Not Configured, in the GPO that still applies

The device doesn't need repairing. The GPO needs one setting changed.

Why deleting the value is temporary

Group Policy runs again on its own. Microsoft's Policy CSP reference for Set Group Policy refresh interval for computers says: "By default, computer Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes." It adds that "Group Policy for the computer is always updated when the system starts." The [MS-GPOD] protocol notes give the same default: "every 90 minutes, plus, by default, a random offset between 0 and 30 minutes."

Not every refresh rewrites every registry value. The Configure registry policy processing setting says that "Many policy implementations specify that they're updated only when changed," and offers an option that "updates and reapplies the policies even if the policies haven't changed." So the value comes back at whichever comes first:

• A forced refresh. Microsoft's gpupdate reference says /force "Reapplies all policy settings." Many people run it straight after deleting a value, to "test". That rewrites the value at once.
• Any change to the GPO. When Group Policy changes, Microsoft says the Policies trees are cleaned and rewritten. An edit to that GPO, even to a different setting, brings the value back at the next refresh.
• Every background refresh, if registry processing is set to reapply unchanged policy. Then the 90-minute cycle rewrites it.

Why not deny or unlink the GPO?

Denying or unlinking does remove Administrative Template values, by Microsoft's own rules. The problem is everything else in the GPO:

1. It removes every other setting too. A baseline GPO carries many unrelated settings. In this project it held many settings that had nothing to do with Hello and had to keep applying. Denying it to remove one Hello value would have removed all of them.
2. It can create real tattoos. If that GPO also has Preferences items with default options, Microsoft says they "don't remove settings when a Group Policy Object (GPO) no longer applies". Those values stay behind.
3. It is a blunt tool for a precise job. You want one setting gone. Not Configured removes exactly that one and leaves the GPO working.

The steps

1. Find the GPO that actually carries the setting. Search the settings of every GPO, not their names. See Find which GPO sets a registry value.
2. Make sure the replacement is already in place. For this setting, the Intune side is the PassportForWork CSP node ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/MinimumPINLength. Configure it in Intune first, so devices never fall back to the default when the GPO value goes. The move itself is covered in Move Windows Hello policy from Group Policy to Intune.
3. Edit the live GPO. In Group Policy Management, edit "Contoso - Workstation Baseline" and go to Computer Configuration › Administrative Templates › System › PIN Complexity › Minimum PIN length. Set it to Not Configured. Not Disabled.
4. Leave the GPO linked and applying. Don't touch its security filtering. Its other settings still matter.
5. Let it arrive. Because the GPO changed, the next refresh processes it. On a test device, gpupdate /force shows the result sooner.
6. Don't deploy the delete script. If anyone wrote a remediation to delete the value, retire it. Group Policy now removes the value itself, on every device in scope.

This is the setting in the editor. It is a simulated view, but the path and setting name are the ones in Microsoft's Windows Hello policy reference:

If Intune already sets the value the business wants, users see no change in the PIN rules when the GPO value goes. The only difference is which source is in charge.

Proof it worked: the value goes, the GPO stays

Run the same reads again after the change has reached the device. The block below shows what to expect. It is illustrative.

Check four things, in this order:

1. The value is gone from SOFTWARE\Policies\Microsoft\PassportForWork. If it is still there, the change has not arrived, or a second GPO also sets it. Check the time comparison again.
2. The GPO is still in the applied list. This proves the value went because the setting is Not Configured, not because the GPO stopped applying. That is the difference between a clean retirement and an accidental one.
3. The timing matches the refresh that removed the value. If the PINComplexity key still exists, its last write time should sit close to that refresh. If the key has gone completely, that is fine too: there was nothing left in it.
4. The Intune value is now the one in force. With the Group Policy setting cleared, Microsoft's rule that "conflicting CSP settings aren't applied until the group policy settings are cleared" no longer blocks Intune.

Don't rely on a behaviour test alone. If both sources happen to hold the same value, a PIN test proves nothing either way. The registry is the evidence: which path holds the value, and when its key was last written.

References

• Administrative templates overview for GPMC - Microsoft Learn (archived). True policies under the Policies keys, the "cleaned and rewritten" behaviour, and where Registry.pol is stored in the GPO.
• GP Policy vs. Preference vs. GP preferences - Microsoft Learn (archived Group Policy team blog). Policy settings "not tattoo", preferences "tattoo".
• Group Policy preferences in Windows - Microsoft Learn. Preferences are not removed by default, and the Remove this item when it is no longer applied option.
• Remove this item if it is no longer applied option - Microsoft Learn. The local database for that option and its location in the Group Policy History folder.
• Edit Administrative Template Policy settings - Microsoft Learn (archived). The Not Configured, Enabled and Disabled states.
• Policy CSP - ADMX_GroupPolicy - Microsoft Learn. The 90-minute refresh with a 0 to 30 minute offset, and registry policy processing.
• [MS-GPOD]: Product Behavior - Microsoft Learn. The default periodic refresh timer.
• gpupdate - Microsoft Learn. /force reapplies all policy settings.
• Applying Group Policy troubleshooting guidance - Microsoft Learn. The operational log lists applied and denied GPOs, and the SYSVOL path of a GPO.
• Configure Windows Hello for Business - Microsoft Learn. Policy precedence, conflicting CSP settings, MDMWinsOverGP, and the Group Policy and CSP registry paths.
• Windows Hello for Business policy settings - Microsoft Learn. Minimum PIN length: CSP path, Group Policy path and default behaviour.
• RegQueryInfoKeyW function - Microsoft Learn. A key's last write time.
• Get-WinEvent - Microsoft Learn. -LogName and -MaxEvents.
• Get-ItemProperty - Microsoft Learn. Reading registry values with -Path.

Related reading on EndpointWeekly

• Find which GPO sets a registry value - read the applied and filtered GPO lists, and compare refresh time with key write time.
• Move Windows Hello policy from Group Policy to Intune - the migration this case came from.
• Windows Hello for Business PIN complexity - every PIN setting, with its CSP and GPO.
• Moving off Group Policy - plan a GPO to Intune move with Group Policy analytics.

The case in this post comes from one enterprise laptop during a Group Policy to Intune migration. All names, values and times shown are illustrative. Microsoft facts were checked against the pages above on 31 October 2026.