MCSE Training Kit (Exam 70-222): Migrating from Microsoft® Windows NT® 4.0 to Microsoft Windows® 2000

Author Microsoft Corporation Pages 576 Disk 1 Companion CD(s); 2 Evaluation CD(s) Level Int/Adv Published 01/31/2001 ISBN 9780735612396 ISBN-10 0-7356-1239-0 Price(USD) $59.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Related Series Related Books About the Author Support: Book & CD Rate this book

Chapter 7: Transitioning an Upgrade to Native Mode

• About This Chapter
• Before You Begin
• Lesson 1: User Profiles in an Upgrade
• Effect of an Upgrade on Profiles
• Practice: Testing User Profiles
• Lesson Summary
• Lesson 2: Windows NT and Windows 2000 Policies
• Windows NT Policies
• Windows 2000 Group Policy Objects
• Practice: Working with Group Policies
• Lesson Summary
• Lesson 3: Policy Transition and Migration Phases
• Policies in Mixed Environments
• Tattooing of Windows NT System Policies
• Policy Scenarios
• Organizational Units
• Practice: Investigating Ntconfig.pol and Group Policy Objects
• Lesson Summary
• Lesson 4: Finalizing the Upgrade
• Server Upgrades
• Pre-Upgrade Procedures
• Practice: Upgrading a Backup Domain Controller
• Lesson Summary
• Lesson 5: Moving to Native Mode
• Practice: Converting a Mixed-Mode Domain to Native Mode
• Review

About This Chapter

This chapter takes you through transitional issues you might encounter when upgrading your Microsoft Windows NT domains to Microsoft Windows 2000 and the scenarios that require consideration depending on how you plan your upgrade. It also takes you through the final stages of upgrading your Windows NT domain by upgrading the MIGKIT2 BDC and switching the Windows 2000 network to native mode.

Before You Begin

To complete this chapter you must have

• Read and performed the practices in Chapter 6, "Performing an Upgrade."
• PC1 running Windows 2000 as migkit.microsoft.com, and PC2 running MIGKIT2, the Windows NT BDC.

Lesson 1: User Profiles in an Upgrade

User profiles provide a way of allowing Windows NT users to have the same desktop settings and configuration regardless of which Windows NT workstation they log on to. The profile is supplied to the user's workstation during logon. In this lesson, you'll examine how the upgrade affects the Windows NT user profiles.

After this lesson, you will be able to

• Understand how profiles are updated when a Windows NT server is upgraded to Windows 2000 and any type of mixed Windows NT and Windows 2000 systems are involved.

Estimated lesson time: 20 minutes

Effect of an Upgrade on Profiles

The location of the profile is a property of the user name. If it is a roaming profile, it is stored in a shared folder. When the user logs on, the profile is uploaded to the workstation being used for logon. At logoff, it is then copied back to the shared folder unless it's a mandatory profile, in which case, nothing else occurs.

When a system is upgraded to Windows 2000, all user properties are retained, including the user profile information. Therefore, the behavior of user profiles for both downlevel and Windows 2000 clients will remain the same. Users shouldn't notice any difference in the way their profiles perform.

Potential Profile Problems

The caveat to the previous scenario is that profiles will work perfectly as long as your users don't switch between logging on to Windows 2000 clients and Windows NT clients. If your users need to use both versions of workstations, you might find inconsistencies. For example, if the Windows NT workstation client has bitmaps being used for the desktop that the Windows 2000 client doesn't have, the bitmaps won't be available when the user logs on to the Windows 2000 workstation client. This type of problem existed with Windows NT networks as well, but it's likely to be exacerbated now when working with Windows 2000 clients as the Windows 2000 Professional clients are more likely to contain different files from the Windows NT workstation clients.

Another complication occurs when Windows NT system policies are in use. If a user is subject to a Windows NT system policy that updates his or her roaming profile in any way, such as changing a bitmap, these settings will be cached with the profile and then uploaded when the user logs off. As you'll see in the next lesson, Windows 2000 saves its policy settings in a different location. This, in turn, causes the size of the user's profile to increase because of the number of extra (duplicated) registry settings.

Practice: Testing User Profiles

Answers

When working with a mixture of Windows NT and Windows 2000 clients, these types of anomalies will occur frequently. However, if you're upgrading only the Windows NT servers, your Windows NT client profiles will be unaffected. The best solution for this is to store all profile components such as bitmaps on a network share or to upgrade the Windows NT workstations as soon as possible. See Appendix B on Windows 2000 Workstation deployment for further details.

Lesson Summary

In this lesson, you learned that the profile settings for a user are retained after upgrading a Windows NT domain controller; however, if a mixed environment of Windows NT and Windows 2000 clients are used, users who log on to both platforms might encounter inconsistencies with their profiles.

Lesson 2: Windows NT and Windows 2000 Policies

This lesson recaps the mechanics of the Windows NT system policies and Windows 2000 group policies. You also examine what happens in a mixed upgraded environment consisting of Windows 2000 and Windows NT servers and workstations.

After this lesson, you will be able to

• Explain how Windows NT and Windows 2000 system policy mechanisms differ.
• Understand the problems associated with policies in a mixed environment.

Estimated lesson time: 25 minutes

Windows NT Policies

Windows NT policies allow administrators to tailor the environment of their users by using a program called the System Policy Editor. It is used to define the policies applied to users when they log on. For example, you can hide Network Neighborhood from the users as a policy. By default, these settings are held in the Netlogon shared folder on each server in a Windows NT network in a file called Ntconfig.pol. As shown in Figure 7.1, this file can contain settings for the user (for example, Benjy), the group (for example, finance), and the computer (for example, migkit1) that the user is logging on at.

Figure 7.1 System Policy Editor containing user, group, and computer settings

Windows 2000 Group Policy Objects

Windows 2000 has a powerful and flexible policy scheme known as group policy objects (GPOs). These look similar to the Windows NT system policies. They can be applied to the site, domain, and OU, and multiple GPOs might apply at different levels when a user logs on. Policies are applied in the following order:

1. Ntconfig.pol. This file is used by Windows NT to implement policies. It is stored on the Netlogon share on each domain controller. In a pure Windows 2000 environment, Ntconfig.pol will cause a number of problems, as you'll see shortly. It should be migrated to a group policy object as soon as possible and applied at the appropriate level.
2. Local Computer. These policies are set on the local computer.
3. Site. These policies are set for the site. They tend to address the needs of the WAN links, such as network bandwidth settings.
4. Domain. These policies are set for the domain. They tend to be security-related, such as a policy that requires all users to have a password length of seven or more characters.
5. Organizational Unit. These policies are set for the OU containing the account. These policies are more concerned about the users and the computers in their environment. For example, these policies might determine which options are available to users on the Start menu, or whether users in an OU can see the My Computer icon on their desktops.

Barring the existence of the Ntconfig.pol file, the policy flow for Windows 2000 clients is often referred to as the LSDOU mode (Local+Site+Domain+OU). If an NTconfig.pol file exists and a Windows 2000 client has been enabled to use the Windows NT policy file, then the policy flow would be L4SDOU (where 4=NT4 policy file). By default, Windows 2000 clients are not enabled to use Ntconfig.pol files located on Windows 2000 domain controllers.

GPO Basics

The policies can interact in many different ways. By default, policies are aggregated unless there's a conflict. When a conflict occurs, the last policy to be applied will override the settings inherited from a GPO applied to a parent or grandparent container object. This behavior can be changed by using Block Inheritance and No Override settings. Block Inheritance prevents parent container settings from being passed to the current level. No Override prevents Block Inheritance settings from being applied and enforces the inherited policy setting even if a lower GPO is in conflict. An example of when to use the No Override setting is when you need to enforce a security setting or a policy that requires efficient use of the WAN.

Remember the following points concerning GPOs:

• GPOs are assigned to containers.
• Avoid large numbers of GPOs at a container. As a rough guide more than eight GPOs at an OU is a clear indication something is wrong and the design should be revised.
• GPO computer settings are installed at reboot for the machine.
• GPO User settings are installed at logon for the user.
• The user has to log on to remove a GPO.
• GPOs are applied in full at first reboot and logon. Subsequent settings are only applied if the GPO changes.

Assigning a Group Policy Object

Figure 7.2 shows the group policies for migkit.microsoft.com. The property information for a GPO is accessed from the Active Directory Users And Computers administrative tool. The GPOs Migkit Domain Controllers Policy and Migkit Domain Security Policy have been applied to the domain.

Figure 7.2 Assigning a group policy object to a domain

This assignment mechanism is similar for sites and OUs, in that their properties also have an entry for Group Policy assignment. Settings in Default Domain Controllers Policy and Default Domain Policy might conflict. In this case, the ordering of the policy objects in the list is used to determine precedence. The higher objects have the highest precedence, so in Figure 7.2, the settings for Default Domain Controllers Policy will override those for Default Domain Policy.

To assign a group policy object

1. From a Windows 2000 domain controller, open Active Directory Users And Computers from the Administrative Tools menu.
2. Right-click a container object and select Properties.
3. From the container's Properties dialog box, click the Group Policy tab.
4. Click New to add a GPO or select an assigned GPO, as shown in Figure 7.2, and click the Edit button.

   Now you'll see a dialog box similar to the one shown in Figure 7.3.

During the Active Directory design phase, the settings to be enforced and actions to be performed by each of the GPOs will be planned. During the restructure, you'll need to create the objects and assign them according to your design. The properties of a GPO are edited using the Group Policy snap-in of the MMC.

Figure 7.3 Editing a GPO

Figure 7.3 shows a Default Domain Controllers GPO being edited. Note the wide range of options shown in Figure 7.3 that can be configured for this object. It's also possible to configure logon and logoff batch files and to control the installation of software for a particular user.

Practice: Working with Group Policies

Lesson Summary

In this lesson, you learned how the Windows NT system policies, based around the Ntconfig.pol file, have been replaced in Windows 2000 by a more powerful regime based on group policy objects that are applied at multiple levels in an organization.

Lesson 3: Policy Transition and Migration Phases

In this lesson, you will examine the effect of Windows NT and Windows 2000 policies in a mixed migrated environment.

After this lesson, you will be able to

• Understand how policy mechanisms behave during the upgrade.
• Explain how system policies are used in conjunction with OUs.

Estimated lesson time: 40 minutes

Policies in Mixed Environments

In their own environments, both Windows NT and Windows 2000 policies offer tremendous benefits in locking down (preventing users from changing) and maintaining a user's environment. However, in a migration environment, you might experience inconsistencies and your users or your help desk will need to know how to handle them.

Tattooing of Windows NT System Policies

One aspect of Windows NT system policies is that no "Undo" feature exists. Once a policy has been applied, it's difficult to reverse the effects without prior knowledge of every workstation whose registry settings were affected by the policy change. Because Windows NT registry changes made by policies are permanent, it is known as tattooing.

Windows 2000 Registry Areas for Policies

Windows 2000 policies can be removed from Windows 2000 client systems simply by removing the relevant GPOs from the containers. Their policy settings are saved in two new special areas of the registry that don't exist in Windows NT.

Computer settings are maintained in these two registry keys:

• HKey_Local_Machine\Software\Policies
• HKey_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Policies

User settings are maintained in these two registry keys:

• Hkey_Current_User\Software\Policies
• Hkey_Current_User\Software\Microsoft\Windows\CurrentVersion\Policies

Because Windows NT uses tattooing, if a Windows 2000 client is validated by a Windows NT server, the policies in the Ntconfig.pol file are also tattooed on the Windows 2000 client. Windows 2000 can replicate this behavior by changing the following setting found in the domain GPO policy.

Object: Domain GPO Policy

Location: Computer Configuration/Administrative Templates/System/Group
Policy

Valuename: Disable System Policy

Value: 1 (default) or 0 (to enable Windows NT, Ntconfig.pol-like system
policies for Windows 2000 client systems)

If you have any Ntconfig.pol style files then these will be applied to Windows 2000 systems also and can make troubleshooting very difficult, so use the setting sparingly.

Benefits of Tattooing

Tattooing is an excellent feature when you want to make certain registry settings permanent. For example, you might want a logon banner to appear even when a user is validated by his or her local machine instead of just the domain. Another positive effect of tattooing is when you want to ensure consistency between Windows NT and Windows 2000 client systems. However, tattooing is disadvantageous when you need to undo settings or change settings regularly.

Policy Scenarios

How policies from Windows NT will migrate to Windows 2000 must be considered when planning the migration because you might not want to have tattooing on the registries of Windows 2000 clients by Windows NT policies. Consider the following five scenarios.

Authentication of Clients by Upgraded Windows 2000 Domain Controller

As shown in Figure 7.5, when a Windows NT client is authenticated by an upgraded Windows 2000 domain controller, it isn't affected by any GPOs. Instead, the settings in any migrated Ntconfig.pol files held on the upgraded Windows 2000 domain controller are applied.

Ntconfig.pol and, indeed, all the aforementioned logon scripts and any other resident files are copied from the %Systemroot%\System32\Repl\Import\Scripts folder into the new Netlogon folder, which is now the %Systemroot%\Sysvol\ %Userdnsdomain%\Scripts folder (assuming you've accepted the default values for the system volume). In contrast, a Windows 2000 client will receive its settings from any GPOs set for the user and computer objects in the Active Directory of the Windows 2000 domain controller.

Figure 7.5 Policy processing for Windows NT and Windows 2000 clients when the user names are held on a Windows 2000 domain

Authentication of Clients by Existing Windows NT Domain Controllers

As shown in Figure 7.6, Windows NT clients and Windows 2000 clients that log on to Windows NT domain controllers will receive their settings from the Ntconfig.pol file on the Windows NT domain controller. If an upgraded Windows 2000 controller is in the domain, the Windows 2000 client will try to be authenticated by the Windows 2000 controller and hence, get its user and computer settings from the GPO mechanism instead of from the Ntconfig.pol file.

Figure 7.6 Policy processing for Windows NT and 2000 clients when the user names are held on a Windows NT domain controller

However, if for any reason the Windows 2000 client can't be authenticated by a Windows 2000 domain controller, and it was authenticated by a Windows NT domain controller, the Ntconfig.pol file settings will be permanently tattooed into the Windows 2000 client's registry. In other words, the setting from the Ntconfig.pol file will remain in the Windows 2000 registry even if a GPO is assigned that changes the effective setting. Once the GPO is removed, the setting from the Ntconfig.pol file will return because it is held in a different registry key.

Authentication via a Trusted Windows 2000 Domain from a Windows NT Resource Domain

Figure 7.7 shows a new scenario in which a Windows NT accounts domain has been upgraded to Windows 2000. The resource domain is still a Windows NT domain with a one-way trust to the upgraded domain.

Figure 7.7 Policy processing for Windows NT and Windows 2000 clients when user accounts are held on a trusted Windows 2000 domain

If a user logs on via a Windows NT workstation in the Windows NT resource domain, the resource domain will pass through the authentication to the Windows 2000 domain holding all the user accounts. The workstation will use both the user and computer settings in the Ntconfig.pol file held on the Windows 2000 domain controller. However, if a user logs on via a Windows 2000 workstation in the Windows NT resource domain, the Windows 2000 workstation will use any GPOs set for the user from the trusted Windows 2000 domain and combine those with the computer policy settings from the Ntconfig.pol file held on the Windows NT resource domain controller (if one exists).

Windows NT Client Authentication when User Accounts Are in Different Domains

Figure 7.8 shows two users split across the domains. If User1 and User2 log on via the same Windows NT workstation, the workstation will have computer settings from the Ntconfig.pol file in the resource domain and settings from the Ntconfig.pol file on the accounts domain. Any policies that contain conflicts will be overwritten by whichever user's Ntconfig.pol is being used at the time of logon.

Figure 7.8 Policy processing for Windows NT clients using accounts held in both a Windows NT domain and a trusted Windows 2000 accounts domain

Windows 2000 Client Authentication when User Accounts Are in Different Domains

Figure 7.9 is the same scenario as Figure 7.8 except that now the access is from Windows 2000 clients. This scenario is discussed in Lesson 3, "Migration Environments," of Chapter 1. It is relatively stable compared to the previously discussed scenarios and is an advantage when considering upgrading the Windows NT workstations to Windows 2000 prior to any upgrade of domain controllers.

Computer policies are received from the Ntconfig.pol file in the Windows NT domain. User registry settings are received from the GPOs if the user is authenticated by the Windows 2000 domain or from the Ntconfig.pol file if the Windows NT domain validates the user.

Figure 7.9 Policy processing for Windows 2000 clients when user accounts are held in both a Windows NT domain and a trusted Windows 2000 accounts domain

Validation via a Trusted Windows NT Domain from a Windows 2000 Resource Domain

Figure 7.10 shows a final scenario. This scenario could represent a complete trust relationship or might be part of a multiple master domain situation in which one of the accounts domains has already been upgraded to Windows 2000. In this case, User1 is held on the Windows NT accounts domain that is awaiting upgrade.

Figure 7.10 Policy processing for Windows 2000 clients using a trusted Windows NT accounts domain

As you can see from Figure 7.10, User1 receives the user settings from the Ntconfig.pol file held on the Windows NT accounts domain (where User1's account resides), but the computer settings come from any GPOs set on the computer object in the Windows 2000 domain controller. User2's situation is simpler: because this user account is held on the Windows 2000 domain controller, all policies for the user and computer are determined by GPOs on the Windows 2000 domain controller.

Policy Pandemonium

As you've seen, how the policies are assigned depends on where the user is authenticated, and with roaming users, this can vary from one session to the next. The scenarios become even more complicated when you consider that these examples have used pure Windows NT and Windows 2000 domains. Consider the problems if each of the domains shown contain both Windows NT and Windows 2000 domain controllers. Policy processing issues must be addressed in the migration planning process.

Organizational Units

After an upgrade, all the users and security groups in the source domain are placed in the Users container object in the new Active Directory. You can create OUs in the upgraded domain to

• Apply group policy objects to replace those previously supplied by Ntconfig.pol.
• Allow control to be delegated within the upgraded domain.

Windows 2000 OUs are managed by the Active Directory Users And Computers administrative tool. In the next practice, you'll create an OU and apply a GPO to it.

Practice: Investigating Ntconfig.pol and Group Policy Objects

In this practice, you'll create Windows NT system policy settings and Windows 2000 GPOs and verify that they work. Both MIGKIT1 and MIGKIT2 will be involved in this practice. You'll then see the effect of running the Windows NT Ntconfig.pol and Windows 2000 operating system policies in a mixed environment.

To create an Ntconfig.pol policy file on MIGKIT2

1. Log on to MIGKIT2 as Administrator using the password secret.
2. From the Start menu, click Programs, Administrative Tools, and System Policy Editor.
3. Select New Policy from the File menu of the System Policy Editor.
4. Select Add Group from the Edit menu.
5. From the Add Group dialog box, click Browse and then select the Finance group.
6. Click the Add button to add the name and then click OK to close the Add Group dialog box.
7. Double-click the new Finance group to open its Properties dialog box.
8. On the Policies tab, expand Shell and Restrictions, and then place a check mark next to Remove Run Command From Start Menu.
9. Now expand the Control Panel policy until you reach Restrict Display. Place a check mark next to Restrict Display.

   Options for the Restrict Display setting will appear in the bottom half of the dialog box.

10. Place a check mark next to Hide Background Tab.

    Your screen should look like that shown in Figure 7.11.

    

    Figure 7.11 Finance group policy settings

11. Click OK to close the Finance Properties dialog box.
12. Select Save from the File menu and save the policies as Ntconfig.pol in the path C:\Winnt\System32\Repl\Import\Scripts\Ntconfig.pol.

    The user Migkitfin1 is a member of the migkit Finance group, so this policy should apply to Migkitfin1.

13. Log off MIGKIT2 as Administrator and then log on again as Migkitfin1 using a password of secret2.
14. Verify that the policy has taken effect by clicking the Start button to see that the Run command has disappeared.
15. Right-click the desktop and select Properties to verify that the Background tab has also been removed.
16. Log off MIGKIT2.

To create a group policy object on MIGKIT1

1. Log on to MIGKIT1 as Administrator with the password secret.
2. From the Start menu, select Programs and Administrative Tools, and then open Active Directory Users And Computers.
3. Right-click the migkit.microsoft.com item at the root of the tree and select New from the shortcut menu that appears.
4. Click Organizational Unit.
5. Give the OU the name Finance and click OK.

   You will now create a group policy object and assign it to the Finance OU.

6. Right-click the Finance OU and select Properties from the shortcut menu.
7. Select the Group Policy tab in the Finance Properties dialog box.
8. Click the New button to create a new group policy object.
9. Right-click the new object, if necessary, and change its name to Financeprops.
10. Click the Edit button to open the Group Policy window.
11. In the left pane, expand Computer Configuration, Administrative Templates, and System.
12. In the right pane, double-click Run These Programs At User Logon.
13. When the Properties dialog box opens, select the Enabled option.
14. To add a program, click the Show button.
15. When the Show Contents dialog box appears, click the Add button and type write.exe.
16. Click OK in the three dialog boxes, close the Group Policy window, and then click Close in the Finance Properties dialog box.
17. In the Active Directory Users And Computers window, move MIGKIT1 from the Domain Controllers OU to the Finance OU by expanding the Domain Controllers OU and right-clicking MIGKIT1.

    ---

    NOTE
    If Migkit1 doesn't appear in the Domain Controllers OU, look for it instead in the Computers OU.

    ---

18. Select Move from the shortcut menu, select Finance in the Move dialog box, and then click OK.
19. Confirm that MIGKIT1 is now listed in the Finance OU.
20. In the same way, move Migkitfin2 from the Users container into the Finance OU.
21. Now log on to MIGKIT2 with the user name Migkitfin2 and a password of secret2.
22. Now log off MIGKIT2.
23. Restart MIGKIT1 and log on with the user name Migkitfin2 and a password of secret2.
24. Try to use the Run command on the Start menu. What happens? Try to access the Background tab in the Display Properties dialog box. What happens? Why?
    
    
    

Answers

Further Research

Prior to completing your upgrade analysis of policies and profiles, you might want to make your own investigations. If you have the time, experiment. To help you learn, create a table of users and workstation types and then do some or all of the following:

• Create a few more users (Migkitfin3, Migkitfin4, and so on) and place them in the Finance OU. Create some user settings in the GPO for Finance. Experiment with having the Ntconfig.pol file in the Netlogon folder on MIGKIT2 and see the different effects of logging on at the MIGKIT1 and MIGKIT2 systems.
• When you create your policies, use obvious settings like colors and bitmaps. When using bitmaps, create ones that make changes in settings obvious, such as writing the bitmaps with the words "Bitmap for Migkitfin4 user on MIGKIT domain." Use the logon banners and run commands for computer policies in Windows 2000 and Windows NT. In the logon banners, include statements such as "MIGKIT logon in GPO," and so forth.
• If you have extra PCs to experiment with, install a resource domain with Windows NT and Windows 2000 clients and try some of the combinations shown in the diagrams in this lesson.

Lesson Summary

In this lesson, you learned about the differences between the Ntconfig.pol configuration file and GPOs. You saw that the Windows NT policy file causes tattooing on the Windows NT and Windows 2000 clients if they are validated by a Windows NT domain controller. Authentication by a Windows NT controller can occur if the system is in a Windows NT resource domain with a trust relationship to a Windows 2000 domain that holds the user accounts or if no Windows 2000 domain controllers are available at logon in a mixed-mode environment. If the Windows NT BDC authenticates the logon, the system policies based on Ntconfig.pol are applied. This can lead to problems for users who might see different environments, depending on which system authenticates their logons.