NT 4.0 Server System Policy Registry Tatooing

Registry tatooing refers to the old style workstation policies that Windows NT4 Server used. You also see these on a network if you are connecting to a Samba server, because it uses the old System Policy model. Policy changes in this system are permanently applied to the Registry as values that are never undone unless you explicitly remove them or change them to a different value. On a client, you edit these policies using the System Policy Editor and then the Config.pol file gets downloaded to the client at logon and is applied to the registry as keys and values.

Windows 2000/2003 Group Policy works in a different and much better way. The policy settings that are applied from GPOs do not make permanent changes to the registry. If you remove a setting from the policy, it will automatically revert to the default value for that setting. This makes policy operation more efficient since you don't need to set a value for every policy. It also ensures that default values that are defined in the GPOs will work when they say they will.

Tatooing is the effect of the old style policies onto a workstation running Windows 2000 or later. The System Policy model was used by older desktop versions of Windows, including all Win9x systems (95, 98, ME) and Windows NT4 Workstation. However it can also be applied to Windows 2000/XP workstations when the PDC is Windows NT4 or Samba (may vary with version of the latter). The GPO model that we have today was introduced on Windows 2000 Server and Windows 2000 Professional. There are two parts to it, the server component and the desktop client component, and you have to have both of them to use it. Hence, an older desktop OS connecting to a Windows 2000 or later server still uses the old System Policy model, and a modern desktop OS (Windows 2000 or later) connecting to an older server (NT4/Samba) still uses System Policy.

We came originally from a Samba server to Windows 2003 domain controllers, and we saw these effects on our XP workstations. One of the first ones that I remember was connected with the policy setting that reads "Connect home drive to the root of the share". When you set up a user account you specify a home drive letter and path. This policy setting overrides the path so that only the share is used and the drive letter connects to the root of that share. The default for this setting is to be disabled, but we found that we had to specifically disable it because, I presume, the default had been overridden by tatooing.

Another possible example I have just noticed is remote shutdown. We reinstalled a pile of machines, and they all started to give "Access denied" errors when we tried to run a script on the server to shut them down remotely. There must have been a setting tatooed into the registry that allowed the remote shutdown to occur with the right user permissions (the script is running as the domain administrator). There are a few options I have to try to see which is the best way of resolving this.

Imaging Vista part 2A

The next PC to try imaging was an old Compaq Pentium III/800. I had previously installed Vista on it and had bumped up the memory to 512MB and the HDD to 40GB. This PC is one I kept around for just this sort of testing. The biggest issue is its lack of USB ports especially as one was needed for the mouse and the HDD at startup needed both its plugs connected for power. I decided to do without the mouse and boot WinPE from a CD. Getting the image reload going is no problem off the external HDD. The main delay in this case is due to this old computer having only USB1.1 and therefore transferring data off the external HDD slower. About 90 minutes being the estimated load time in this case. Actually it took about 60 minutes, and it worked just the same as the other PCs.

Imaging Vista part 2

Getting this started turned out somewhat difficult due to the way the PC recognises USB boot devices. I had both a USB key and a USB external HDD plugged into the master PC for the imaging. The key drive is used to boot Windows PE and the HDD is used to store the image. The problem seemed to be, at first, in getting the key drive recognised - the first one had some sort of corruption or other problem making it unrecognisable for booting. Trying another one, the problem seems to be that with the USB HDD connected as well, it tries to boot that, fails and doesn't get any further like trying other USB devices or other devices.

I'm not really sure what the problem was, but after a lot of work I got it booting PE off the USB key, and then plugged in the HDD partway through boot. I still don't know if WinPE supports hotswapping and automatic detection of USB devices. However it evidently does include the drivers for most of them as both devices were able to be accessed in the command prompt.

The first step of making my image is to Sysprep the master PC (step 3 of the guide). This is easier on Vista because Sysprep is now included in a subdirectory of \Windows\System32. Once this was done, I proceeded to the imaging (step 4). Note that you can use alternative forms of boot media; the Windows PE help included with the WAIK describes how to do this. Now run ImageX with the appropriate switches. I tried two images: one on the external HDD and one to a second partition of the internal HDD. The first took about 30 minutes to create a 5.5 GB file; the second about 20 minutes. The original files on the HDD are 13 GB so this is slightly better than a 2:1 compression ratio.

When the original PC was restarted, there was a period of disk activity for about 10 minutes and then the PC restarted and came up with various screens asking for information - as is usual when starting a Sysprepped image. The PC then started normally. I went to Step 5 of my instructions to apply the image to the other machine, after first following the steps to partition and format the HDD. This PC had Linux installed, but there were no problems in removing the partition information and Grub, and applying the image from the external HDD. On rebooting the PC followed the same process as the master.

The issues which I want to fix for future deployments are

1. Drivers not installed (even though the master had them). In this case the display adapter was the only device not installed, even though originally I had to provide Vista with network and sound drivers as well. Vista provides a Package Manager to inject drivers to an image
2. No automatic domain join. Riprep knows how to do this automatically if the answer file specifies it. Sysprep on XP if an answer file is not provided still knows that the PC was previously joined to one and asks the user if they want to join a domain and carries that out.
3. Product key not asked for. Sysprep does do this on XP. At this stage I would still have to reenter the product key and then activate this PC.

Most of the questions/issues can be addressed using the tools which Microsoft provides. The Package Manager for driver injection, the System Image Manager for creating the answer file, and some technique that I haven't yet discovered to put the answer file into this image. At this time we want to automate the whole process even more.

The next trial step is to apply my existing image to another completely different PC. This is an old Pentium III with just enough memory and HDD, the first real challenge being whether it will even boot WinPE or be able to read the USB HDD. WDS also looks more promising, but there is still a lot of work to get it there, and the server's disk is filling up with all the different RIS and Ghost images.