Lesson 7: Profiles in a Restructure | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

A restructure, like an upgrade, affects the source domain's profiles and policies. In this lesson, you'll learn what to expect and how to handle potential problems with user profiles.

After this lesson, you will be able to

Understand why the restructure affects user profiles.
Handle issues that arise with profiles during the restructure.

Estimated lesson time: 15 minutes

Chapter 7, "Transitioning an Upgrade to Native Mode," investigated potential problems with policies during an upgrade. A restructure will also suffer from these instabilities, and you need a strategy to address these concerns. When you restructure either by a move or a clone, you might find additional problems related to profiles.

Moving Profiles

When you move a user from one domain to another, the user is given a new SID value that will become his or her new primary SID. There is an option to include the user's previous SID value by adding it to the SIDhistory list. When the user logs on to a system using his or her migrated account, Windows 2000 uses its primary SID to locate the profile in the registry. The profile won't be found because the primary SID has changed. Even though the original SID exists in the SIDhistory attribute, it's no longer listed as the SID that owns the profile from a registry perspective.

Therefore, a user logging on to a workstation after being moved to another domain will lose access to his or her logon profiles because the user no longer has the appropriate primary SID. In this situation, you can make a profile available to a user in two ways, as described in the following two sections.

Sharing Profiles

You can re-ACL the profile to make it available to the original and the migrated accounts, which means the profile can be accessed and used by both. This method will save disk space on systems and has this potential benefit: updates to the profile from one account are reflected on the other. However, unless you have a mandatory profile, problems can arise from having two different operating systems accessing that profile. Changes made to the profile when logged on via Windows 2000 or Windows NT might not be reflected when logging on from the other platform. The settings are further complicated when group policies are in use on the Windows 2000 account and system policies are in use on Windows NT. As discussed in Chapter 7, Lessons 1 and 2, unpredictable behavior can occur, such as the following: the system policies can update the profile by changing the desktop colors and bitmaps, which might not be available on the other platform.

Copying Profiles

The second way to maintain access to user profiles after migrating the users is to copy the profile at the time of migration so that a duplicate is held in the registry under the new primary SID. The problem of interaction occurring between accounts is then removed because separate profiles are used for each. However, updates to one profile won't be reflected in the other, and, if a system has a large number of profiles, duplicating them will consume considerable additional disk storage.

NOTE
The Active Directory Migration Tool will copy user profiles as part of a migration. Use of ADMT is described in Chapter 9.

Profiles in Windows 2000

In an entirely native Windows 2000 environment, moving users isn't a problem because the GUID can be used to locate user profiles. Every object in Active Directory has a GUID that never changes over the lifetime of the object. During logon to a Windows 2000 client, if the profile isn't found, the system will use the GUID of the user object to find the previous SID value, which is then used to locate the profile.

Profiles and Migration

If the user profile is used by third-party applications to store configuration information, and if any of this information is specific to a user's primary SID, the application will fail when the user is migrated into the new domain, regardless of whether the profile is moved or copied. It will fail because the primary user SID will have changed. In addition, some applications might store references to specific servers or shared resources in a domain. When the user is moved, these must be retained or the application won't be able to find them. If the connections to the resources rely on trust relationships, these trust relationships will need to be recreated in the destination domain or they might potentially fail.

Lesson Summary

In this lesson, you learned that while SIDhistory allows migrated users to retain access to resources in the source domain, the change of the primary SID for a user might mean that the profile for the user, which is stored in the registry under the primary SID, won't be found. To circumvent this problem, user profiles must be shared or copied. You also learned that sharing a profile between Windows NT and Windows 2000 accounts can cause inconsistent profile behavior, and that the alternative of copying profiles will require extra disk space and the subsequent changes in one profile won't be updated in the other.