tech article - Windows 2003 GPO's and "tatooing"

Way back in the old days, Windows policy management was done with "poledit", it would "tatoo" the registry; I remember teaching that a lockdown policy for the regular users was a type of "poison", and you had to be very careful to create the perfect "antidote" to the "poison" you were creating; it was an un-lockdownpolicy, reversing everything the lockdown policy did, and applied to the administrator. Without it, deleting the policy wouldn't help, you would never get back in to the controls, and the solution was re-install.

Two of the CNS engineers this week remembered their Windows 2000 & 2003 MSCE training, and insisted that the "tatooing" of the registry ended in the NT4 / Windows 95 days. Two other engineers, embedded in troubleshooting hours still in the puzzle stage, insisted that it must be happening, right here in the year 2009.

A request had called for a change to a large business' Active Directory Group Policy for the Citrix Servers. Most of our Citrix implementations are powerfully locked down with a combination of Group Policy and Script Logic's "Desktop Authority" login scripts. An Active X control running on the SQL server had failed to load on the Citrix server's published desktop, when the users tried to print from a SQL reporting services web page. The Microsoft tech article told us we could load the dll's into the Citrix server manually, and declare the reporting server as a "trusted site", allow Active X from trusted sites, and we'd be all set. The change was made right away, and the test users - copies of typical user accounts, both admin and non-admin - started getting the print dialog box, as exepcted.

But when the customer opened the gates to let in the masses, for published application and desktop testing, there were several calling in to our help desk, disappointed with the error that they had seen all too many times before, telling them they would be unable to print, because the ActiveX control had failed to load.
Resultant Set of Policy said we were applying the same GPO's to the users who had it working, and the users who had the error. So of course we looked at the user accounts: what was special about them, why wasn't the GPO applying?

This is when a couple of engineers in the group suggested the concept of "tatooing" the registry, and two other engineers repeated their training, saying it couldn't happen.
Turns out everybody was right.

The users who had the issue all had roaming profiles. Not all users had roaming profiles, and those who didn't, did not have the issue. We tried renaming the profile to .OLD and having the user log in again. That worked every time.

So the GPO's did not tatoo the REGISTRY, in the sense that they did with Windows NT 4/95, but it apparently did tatoo the PROFILES. So either way, it's something else we all need to be aware of.