Microsoft

SolutionBase: Caveats of using Group Policies with cloning and profile copying

See how one IT department ran into, and overcame, problems with their desktop cloning procedure after implementing Active Directory and Group Policies.

In my opinion, when Microsoft introduced Group Policies as part of Active Directory and Windows 2000, it was one of the best things to ever happen to network management. For administrators, Group Policies make life easier by controlling desktop settings, software installation, and many other important settings and tasks.

During my studies for my MCSE exams, I read numerous times that Group Policies do not "tattoo" or make permanent changes to the registry like the old System Policies did in Windows NT 4.0. However, a recent experience made me question that statement. I'd like to share an experience I had using Group Policies and the "Copy Profile" feature.

In two previous articles, I wrote about how to use Symantec's Ghost Corporate Edition and Microsoft's Sysprep tool to create images for rolling out new workstations. This is the process we currently use in our environment. Another procedure we use as part of this process is the Copy Profile function found under the User Profiles tab in the System Properties (Figure A). That procedure will be the focus of this article.

Figure A

Our process

After we've completed the "ghosting" process, the final step in preparing a PC for rollout is configuring the default user profile. The default user profile is the Windows 2000/XP profile that a user receives the first time he or she logs onto a machine. This default profile is the foundation on which the user's unique profile is built.

In the healthcare environment in which I work, it's common to have PCs that are shared by a large number of people in a given area. Nurses, doctors, and other support staff may all use the same PC throughout the course of a day. Each user, therefore, has a unique profile that defines that user's printers and network connections.

Prior to rollout, we log on to a PC and configure the printer and network settings as needed for the specific area where the PC will reside. Next we use the Copy Profile function to copy the configured profile to the default user profile. Every user that logs on subsequently receives the "cloned" profile with the proper setup.


Author's note

Yes, I am aware that there is commercial software available to perform profile management. Unfortunately, we don't always have the budget to buy all the tools we want, so we have to use what's available for free.


We've used this same cloning process for years (with Windows NT 4.0):

  1. Use ghost to clone the PC.
  2. Create a profile and copy it to default user.
  3. Deliver PC to end user or location.

We later added Sysprep to the process to aid in image management.

The problem

We made the move to Active Directory and started by adding a single Group Policy to lock down normal user desktops. We implemented many desktop and system restrictions to mimic the System Policies we had previously used under our Windows NT domain. We had originally created a dummy account that we used to create the default user profile. We used the Copy Profile feature to copy this profile to the default user profile.

We had just set up a new remote office, and we deployed several new PCs to the area by using our cloning method with Group Policies. Everything appeared fine—until the remote office required support. Our first call came in; we remotely connected via PCAnywhere, and when we logged on, we discovered that even the administrator account had a restricted desktop.

At first we thought it was just a fluke on one machine. Then we connected to other systems and subsequently found the same thing on each one. We began investigating and realized what these machines had in common was the fact that we had just activated a Group Policy prior to being cloned. The Group Policy was active when we copied the profile and now the changes were permanent, regardless of who logged on, or so it appeared.

To find out if the setting was permanent, or if somehow I was receiving the Group Policy, I ran gpresult.exe, the Group Policy command line tool, available in the Windows 2000 Resource Kit. This tool is used to troubleshoot Group Policy problems. Running this command presented a challenge in itself, since we had restricted the Run line and command prompt. We worked around this by creating a batch file to call the tool and redirecting the output to a file.

The output (Figure B) showed that no policy was being applied when I logged on. This made sense since my user account did not have a Group Policy assigned to it. Nevertheless, I still had a restricted desktop. So what was going on?

Figure B

Tattooing

One of the features originally touted with Group Policies is that they don't "tattoo" or make permanent changes to the Windows registry. That was an improvement because System Policies in Windows NT 4.0 make permanent changes that make it more difficult to remove a policy change once it is put in place.

In our experience with Group Policies, it appeared that the settings had been tattooed in the registry. After spending time searching for an answer, several other issues came up that required my attention. I realized that, in the time I spent looking for an answer, I could have reloaded the machines with a new image and moved forward with other tasks. Still, I felt it would be valuable to find out why this had happened. I decided to let someone else do the digging: I opened a case with Microsoft.

The Microsoft representative explained to me that the Group Policy settings are cached in case a user logs on to a machine and no domain controller is present, or the user logs on to the workstation while offline, as a mobile user with a laptop might do. The logic is, by caching the settings, the Group Policy will be applied even if the PC is offline. So the settings were not technically tattooed, but since they were cached in the user's profile, they were copied along with all the other settings when we made our copy of the "dummy" profile. This effectively made them a permanent part of any other user who inherited the cloned profile.

Repair job

To fix the machines, we had to replace the default user profile with one that had no Group Policy applied. We couldn't simply create a new profile and copy it over the existing default profile, because any new profile created would be based on the defective default user profile.

We had several other problems. In order to use the Copy Profile feature, you must have access to the tab under the properties of My Computer. Since our profiles were locked down, this was not an option. There was, however, one "clean" profile on the machine: the local administrator account. It is not affected by a domain Group Policy. This was the trick. We could log on with an unrestricted desktop and copy the profile to the default user profile. Then we deleted all the remaining user profiles, except the local admin account and the default user, and logged back on. The desktop was restored. Logging on with the dummy account yielded a restricted desktop as expected. All was well again in profile land.

Further explanation

Although our problem was fixed, I still wasn't satisfied with Microsoft's explanation. I understood the idea of caching the profile, but since I logged on, why wasn't the Group Policy cleared for me, since I didn't have a Group Policy applied to my user account? I did some more research on my own and discovered that Windows reapplies a Group Policy only if a change has been made to the policy. These policy settings are located in the Computer Configuration node, under Administrative Templates | System | Group Policy.

Each client-side extension has a policy setting for controlling the policy processing. By default, each Group Policy client-side extension updates its policy settings only when they have changed. The client-side extension is the .dll file that processes the Group Policy changes. This improves logon performance by not reapplying the Group Policy at each logon. This can be changed through the setting in the Group Policy console. In my case, I had no Group Policy applied to my account, so the cached setting was applied each time I logged on.

Summary

We learned a valuable lesson in how Group Policies work (and don't work) and found we needed to alter the cloning process that we had used for years. We created a new dummy account that is a member of an OU that has no policies applied to it. We use this account to do the "final prep" on a PC. So, if you decide to use the Copy Profile feature in Windows 2000/XP in conjunction with a cloning process, just be sure you use an account that has no Group Policies applied to it, or force the Group Policies to be applied with each logon.

Editor's Picks