Lesson 3: Policy Transition and Migration Phases | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

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.

click to view at full size.

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

TIP
You can find out the %Systemroot% and %Userdnsdomain% folders by typing set at a command prompt.

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.

click to view at full size.

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.

click to view at full size.

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.

click to view at full size.

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.

click to view at full size.

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.

click to view at full size.

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

Log on to MIGKIT2 as Administrator using the password secret.
From the Start menu, click Programs, Administrative Tools, and System Policy Editor.
Select New Policy from the File menu of the System Policy Editor.
Select Add Group from the Edit menu.
From the Add Group dialog box, click Browse and then select the Finance group.
Click the Add button to add the name and then click OK to close the Add Group dialog box.
Double-click the new Finance group to open its Properties dialog box.
On the Policies tab, expand Shell and Restrictions, and then place a check mark next to Remove Run Command From Start Menu.
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.
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
Click OK to close the Finance Properties dialog box.
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.
Log off MIGKIT2 as Administrator and then log on again as Migkitfin1 using a password of secret2.
Verify that the policy has taken effect by clicking the Start button to see that the Run command has disappeared.
Right-click the desktop and select Properties to verify that the Background tab has also been removed.
Log off MIGKIT2.

To create a group policy object on MIGKIT1

Log on to MIGKIT1 as Administrator with the password secret.
From the Start menu, select Programs and Administrative Tools, and then open Active Directory Users And Computers.
Right-click the migkit.microsoft.com item at the root of the tree and select New from the shortcut menu that appears.
Click Organizational Unit.
Give the OU the name Finance and click OK.
You will now create a group policy object and assign it to the Finance OU.
Right-click the Finance OU and select Properties from the shortcut menu.
Select the Group Policy tab in the Finance Properties dialog box.
Click the New button to create a new group policy object.
Right-click the new object, if necessary, and change its name to Financeprops.
Click the Edit button to open the Group Policy window.
In the left pane, expand Computer Configuration, Administrative Templates, and System.
In the right pane, double-click Run These Programs At User Logon.
When the Properties dialog box opens, select the Enabled option.
To add a program, click the Show button.
When the Show Contents dialog box appears, click the Add button and type write.exe.
Click OK in the three dialog boxes, close the Group Policy window, and then click Close in the Finance Properties dialog box.
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.
Select Move from the shortcut menu, select Finance in the Move dialog box, and then click OK.
Confirm that MIGKIT1 is now listed in the Finance OU.
In the same way, move Migkitfin2 from the Users container into the Finance OU.
Now log on to MIGKIT2 with the user name Migkitfin2 and a password of secret2.
Now log off MIGKIT2.
Restart MIGKIT1 and log on with the user name Migkitfin2 and a password of secret2.
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.