Lesson 1: Overview of Post-Migration Tasks | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

Once the migration has been completed, several issues with the migrated systems will need to be addressed. This lesson identifies these issues, assesses their impact, and describes techniques for dealing with them.

After this lesson, you will be able to

Understand the post-migration tasks that are required and how they can be incorporated into the migration plan.
Perform post-migration tasks.

Estimated lesson time: 30 minutes

Installing Support Tools

Many of the tools described for use in the post-upgrade process are those in the Support and Tools folders on the Microsoft Windows 2000 Server and Advanced Server CD-ROMs; more tools are included with the Microsoft Windows 2000 Server Resource Kit. Prior to a migration and in a post-migration scenario, you should investigate which tools might come in handy. As a guide, have a look at the post-migration problems in your test facility and then create a post-migration plan based on your testing, together with which tool could help correct the problem. Invariably, you'll encounter some unexpected challenges. A good overview of the post-migration utilities will be useful to help resolve any problems you might have.

Examining Event Logs

Once the migration has completed, each of the event logs on the servers should be checked to ensure that all the services have started correctly and the hardware is working properly. The security log can also be used to determine the success or failure of the migration of objects.

Backing Up the Migrated Environment

Once your migrated environment has been established, it should be backed up. If it's lost for any reason, the migration will have to be performed again, and the initial starting points for remigration might no longer exist apart from a backup, which could also take a while to restore.

If the migration contains a number of milestones, the environment should be backed up at each stage so that less rollback is necessary.

During upgrade or installation of a system, the hard disk will become fragmented. To optimize the performance of the hard disks in your systems, they should be defragmented soon after the upgrade.

Redefining Security (DACLs and Rights)

When a security principal is cloned or copied, it is given a new security identifier (SID) in the destination environment. All objects and resources to which the account had access will retain the old SID. However, when viewing security properties, the owner of the object might be displayed as Unknown User and unresolved SID values might be displayed in DACLs.

The user will retain access because the old SID value is present in his or her SIDhistory property, but managing resources will be difficult because administrators won't be able to determine who owns the resources and which permissions are set on them. Once the migration is complete, you must eventually replace the references to old SIDs with permissions for the migrated accounts so that migrated users can retain access. The new permissions can be added before the old SIDs are removed.

IMPORTANT
Don't remove the source accounts and trust relationships in the Microsoft Windows NT source domain until all permissions for the new SIDs have been established and tested and the old SID values have been removed.

The ADMT Security Translation Wizard

The Active Directory Migration Tool contains the Security Translation wizard. Figure 10.1 shows the Security Translation Options page of the Security Translation wizard.

click to view at full size.

Figure 10.1 ADMT Security Translation Options page

The settings have the following meaning:

Replace. DACL entries containing the SID values of the source account on resources in the source domain are replaced with access control entries (ACEs) containing the SID values of migrated accounts in the destination domain (also known as re-ACLing). The implication here is that the original accounts in the source domain will no longer be able to access the resource and that the SIDhistory property is no longer required. The Replace option is useful when migrating from Windows NT 3.51 because the Windows NT 3.51 access token can't support SIDhistory. If you're performing an intra-forest migration (a move operation), the source account no longer exists; therefore, Replace is the only option available.
Add. DACLs containing the SID values of the migrated accounts are added to the DACLs on the source objects. If the Add option is selected in an inter-forest restructure, where the destination accounts have been produced by copying the source, both the source and destination accounts will have access to the source objects.
Remove. DACLs containing SID values of accounts in the source domain are removed from the objects. The Remove option can be used at the completion of an inter-forest restructure to remove DACLs that apply to accounts in the source domain.

The Security Translation wizard dispatches an agent to a server in the source domain to scan the volumes on the system and updates the directory entries on the files.

The SIDWalker Tools

The SIDWalker tools can also be used to migrate the DACL entries on resources. As you saw in Chapter 9, "Restructure Tools," SIDWalker consists of the Showaccs and Sidwalk command-line tools. They can help you determine which users have access to particular resources, map accounts onto SID values (via Showaccs), and convert the SID values on DACLs (via Sidwalk).

The Security Migration Editor (an MMC snap-in) can also be used to view and edit the mapping files. SIDWalker is fully described in the Microsoft Windows 2000 Support Tools help.

Restoring Applications Overwritten by the Upgrade

The Windows 2000 upgrade will replace applications on the systems with versions from the Windows 2000 distribution CD-ROM. These might be older than the ones previously in use; for example, if you were using Internet Explorer 5.5, it will be replaced with Internet Explorer 5.0 after the upgrade to Windows 2000. Applications that have been overwritten such as Internet Explorer 5.5 will need to be reinstalled.

Removing the SIDhistory Attributes

The SIDhistory attribute makes it possible for migrated accounts to access resources in the source environment. Migrated users and groups have this attribute to record the old SID values from their original domains for use in authenticating resources there. When the resources have been migrated into the new environment and the users and groups in this environment have been assigned their own permissions on them, the SIDhistory attributes don't need to persist and you can remove them.

Deleting SIDhistory entries isn't just a matter of good housekeeping—you should remove them as soon as possible because of their effect on the size of access tokens. All the SIDhistory attribute values accumulated by a user and the groups he or she is a member of are copied onto the access token at logon. If a migrated user is a member of many groups that have SIDhistory properties, this will greatly increase the size of the access token.

IMPORTANT
An access token is able to hold up to 1,023 SID values. If it grows beyond this size, the user will be unable to log on or access resources.

To clean up SIDhistory, the attribute must be deleted from the user and group entries in Active Directory directory services. Once you've fully completed the migration, you can use the Active Directory Service Interface (ADSI) MMC snap-in to search for the SIDhistory attribute from security principals and ADSI scripts to perform a search-and-delete operation.

CAUTION
If the SIDhistory values are removed prematurely, the security principals that rely on them will no longer be able to access the resources.

Practice: Using ADSI Edit to Find SIDhistory Entries

In this practice, you'll use the ADSI Edit snap-in tool to locate migrated objects in the trainkit.microsoft.com domain that have the SIDhistory attribute set. There should be some user objects on this system that you migrated in the practices in Chapters 8 and 9 as part of the restructure migration.

Log on to TRAINKIT1 (PC1) as Administrator with the password secret.
Select Run from the Start menu and open the Microsoft Management Console (MMC) by typing mmc in the Open box.
Select Add/Remove Snap-In from the Console menu (or press Ctrl+M), and then click the Add button.
From the list of snap-ins that appears, select ADSI Edit and click the Add button followed by the Close button.
Click the OK button to close the Add/Remove Snap-In dialog box.
You have now installed the ADSI Edit tool, and it should appear in the Console Root window. Now the ADSI Edit tool needs to be connected to the trainkit.microsoft.com domain.
Right-click ADSI Edit in the left pane of the window and select Connect To from the shortcut menu that appears.
The Connection dialog box opens. By default, this connects you to the current domain.
Click OK to make the connection.
There should now be an entry named Domain NC beneath the ADSI node in the left pane of the Console Root window, as shown in Figure 10.2.

Figure 10.2 Connecting ADSI to TRAINKIT1
Right-click the Domain NC node and from the shortcut menu, point to New, and then select Query.
You are now going to build a query to search for all the SIDhistory attributes.
Type SIDhistory Locator in the Name field of the New Query dialog box.
Click Browse, select Trainkit, and then click OK.
Click in the Query String box and type the following query:
```
 (&(objectCategory=user)(SIDhistory=*)) 
```
In the Query Scope section, select Subtree Search.
Your query should appear as shown in Figure 10.3.

Figure 10.3 Query to locate SIDhistory attributes
Click OK.
Select Domain NC in the left pane and your query will be visible in the right pane of the console.
Double-click the query.
You should see results that match the criteria. If you performed the inter-forest migration in Chapter 9, the users Mig1 and Mig2x should appear in the list.
Right-click the Mig1 user name and select Properties from the shortcut menu.
In the Mig1 Properties dialog box, select SIDhistory from the Select A Property To View list.
The SIDhistory value should appear as shown in Figure 10.4.

Figure 10.4 SIDhistory attribute for user Mig1

NOTE
The SIDhistory values can be selected but cannot be deleted from this dialog box. Although you can select the values, click Remove, and then click Apply, you'll receive a message that the attribute is owned by the SAM database. To remove the SIDhistory value, you can either use scripting with ADSI, use the ADMT tool, or use a third-party utility.
Click OK and then close the MMC. When asked whether you want to save the MMC settings as a tool, click No.

Using Scripts to Manage SIDhistory

When deleting the values contained in the SIDhistory attribute of a user, you're more likely to use a script to avoid the time-intensive task of locating and deleting every SIDhistory attribute on every system. ADSI is built on the Component Object Model (COM), which allows such programs to be driven by diverse scripting languages and programs. Windows 2000 is supplied with version 2.5 of ADSI. For more details on scripting Active Directory, go to http://www.microsoft.com/ADSI.

Setting and Managing Quotas

Windows 2000 NTFS (NTFS version 5) supports the assignment of disk quotas to users. A given user can be allocated a particular amount of space on a disk volume, and Windows 2000 will prevent further disk space from being used if the limit value is reached. The system will also log events once a user exceeds a lower warning quota value.

Quotas are enabled on a per-volume basis. You can set quotas for all the users of a volume, and you can also create quota entries that can be assigned to one or more users. You can also set quota entries for users accessing shared folders. These quotas will limit the amount of data that the specified user can store in the shared folder. It isn't possible for a quota entry to be assigned to a group of users, nor can a user be assigned to more than one quota entry. Enabling quota management for a volume can reduce its responsiveness slightly.

To set quotas on an NTFS version 5 volume, open My Computer, right-click the volume, and select Properties. If the selected volume is a Windows 2000 NTFS 5 volume, a Quota tab will be available, as displayed in Figure 10.5. As this figure shows, users who don't have individual quota entries are able to store up to 50 MB of files on this volume; a warning event will be logged when they exceed 48 MB.

Figure 10.5 Disk quota settings for a Windows 2000 NTFS volume

Enabling a quota on one volume doesn't affect the amount of space that users have available on other volumes.

CAUTION
Be careful not to allocate more space in quotas than is actually available on a given drive; for example, Windows 2000 won't stop you from allocating 1,000 users 50 MB of storage each (50 GB of storage) on a 20-GB drive. Your objective is to ensure that the drive will never be completely filled and also that each user is guaranteed his or her quota of storage space.

Quotas and Profiles

If the disk volume holding a user's profile has quotas enabled, storage of the profile information will fail if a user exceeds his or her quota during logoff. The user will be unable to log on again because of the quota violation. Even when the user has been granted extra space, he or she might still be unable to log on because the profile is now incomplete. To repair the profile, the administrator will have to take ownership of the user's profile directory and delete it to force the creation of a new one when the user next logs on.

To avoid this administrative headache, user profiles shouldn't be stored on a volume that has quotas enabled. Other alternatives would be to either make the profile mandatory so that the user can't grow the profile in any way or to use a system policy that restricts the size of user profiles, and thereby prevent users from storing large files in their profiles. However, even with these methods, you're advised not to store profiles on a volume managed by quotas.

Installing the Distributed File System

The Distributed file system (Dfs) allows you to create a single directory tree containing multiple file servers and network shares for an organization. A single folder called the root node contains link nodes that point to shared folders. The user connects to the root node and from there can navigate to the shares that appear as folders inside the root. Dfs can be made fault tolerant if the share is published to Active Directory and a number of shares on other servers are assigned to the Dfs share.

As a post-migration task, you might want to use Dfs to make it easier for users to find resources. Dfs is configured using the Distributed File System administrative tool, as shown in Figure 10.6. The figure shows that the user's share has been converted to a Dfs root and now contains three other shares. These shares appear to the users as folders within the root share, although they might physically be located on separate volumes and even separate servers.

click to view at full size.

Figure 10.6 Distributed File System administrative tool

Lesson Summary

In this lesson, you learned that a number of tasks must be performed after a migration has been completed. The support tools should be installed. The event logs must be checked and the new environment must be backed up. Any unwanted SID values must be removed from DACLs in the resource domain, and the SIDhistory attributes should be removed from accounts and groups. File system quotas can be installed and Dfs can be used to simplify users' access to shared resources. You also learned how to use the ADSI Edit snap-in to search for SIDhistory values on users.