Win2K and NT 4.0 Coexistence, Round 2

A heads up on the platform differences you must manage

A few months ago, I asked the question, "Can Win2K and NT 4.0 Coexist?" After testing a mixed Windows 2000 and Windows NT 4.0 environment, I shared my experiences and was pleasantly surprised at how the two technologies worked together. Perhaps you've been contemplating the move, but need a little advice. Let's take a look at some of the reasons for migrating, a few major platform differences, and some tips to help you make your move with confidence.

Why Migrate to Win2K?
If you’re thinking about migrating to Win2K, one of the first questions you'll probably ask yourself is "Why?" Three reasons might compel you to introduce Win2K into your network. The first, and most obvious, is to facilitate design and deployment of a distributed enterprise that crosses political, cultural, and language boundaries. Win2K's flexible and extensible Active Directory (AD) combined with sites, organizational units (OUs), and the ability to delegate control throughout the network eliminate most limitations inherent in NT 4.0's peer-to-peer model.

A second reason to move to Win2K is to increase network security. Win2K's security enhancements are ubiquitous, starting with AD’s sophisticated object security. Win2K gives administrators greater control over permitted activity through the use of Group Policy, extended security settings for files and directories, on-demand file encryption, IP Security (IPSec) for LAN and WAN connections, a native Certificate Authority (CA), and more.

The third reason is to eliminate Windows 9x from the network. The difference between Win2K Professional and legacy Win9x is stark, especially with respect to the feature set, reliability, and robustness. Win2K Pro delivers greatly improved installation and configuration procedures, the ability to create a new install that includes the most recent service pack (slipstream installation), and a wealth of native troubleshooting tools. As a matter of convenience, Win2K's GUI is also quite familiar to Windows users.

Migration Scenarios
After "Why?," the next obvious questions is "How?" You have three options for migrating to Win2K, as Figure 1 shows. You can build a Win2K-only domain that supports Win2K desktops and Win2K servers. When users in the new Win2K domain need to access resources in the legacy NT 4.0 domain, you can easily create trusts for cross-domain account authentication. This approach isolates the new technology from the old and has one big advantage—it eliminates the need to concurrently administer and manage platform differences in user profiles, system policies, and group policies. This approach also significantly reduces maintenance and special handling procedures.

Alternatively, you can build a Win2K hybrid domain that contains a mix of Win2K and NT 4.0 domain controllers (DCs), desktops, and servers. This migration path typically begins when you update an existing NT 4.0 PDC to a Win2K DC. To me, this option is the most risky and least desirable because you must perform the PDC-to-DC upgrade in place and risk the viability of your production environment in the process. A Win2K hybrid domain introduces several migration issues when you convert NT 4.0 accounts and groups to AD and change system policies to equivalent group policies. This approach also opens the door for mixed-platform DC synchronization and file replication problems (e.g., Win2K does not perform NT LAN Manager—NTLM—file replication). A Win2K hybrid requires that you manage the differences in how Win2K and NT 4.0 implement user profiles and identify features in Win2K Group Policy that do and do not apply to downlevel clients.

A final migration option is to build an NT 4.0 hybrid domain by adding Win2K desktops and Win2K standalone servers to your production network. This scenario lets you leverage improvements in the Win2K desktop and the much-improved Win2K standalone server feature set (e.g., RRAS, CA, and IPSec). Unlike the first two migration scenarios, an NT 4.0 hybrid domain does not disrupt your current infrastructure and requires little training. As a result, this method is an easy, low-risk option for incorporating new technology. As with the Win2K hybrid, an NT 4.0 hybrid requires that you concurrently manage platform differences in the desktop environment. You also need to identify the features in NT 4.0 system policy that do and do not function with Win2K systems.

Platform Differences
Regardless of which Win2K migration method you use, you need to master the differences between the two platforms. You need to plan for and manage platform differences in setup, configuration, user profiles, system policy, and methods for publishing and locating shared resources. Coexistence is a fundamental migration requirement—respondents from a Windows 2000 Magazine Win2K adoption survey indicated that when they migrate to the new OS, Win2K and NT 4.0 desktop systems will coexist for nearly 10 months, and Win2K and NT 4.0 servers will coexist for more than 7 months.

Before we jump into the technical details, let's look at a few caveats. To ensure a peaceful coexistence, you should be running NT 4.0 Service Pack 5 (SP5) at a minimum—SP6a with relevant hotfixes is much better. For Win2K, you should start with SP1 and the best of more than 75 bugfixes and hotfixes, some of which correct interoperability problems. Before you begin migrating, you need to understand that NT 4.0 does not do AD, Kerberos authentication, dynamic DNS (DDNS), or Network Time Protocol (NTP) time synchronization. On the Win2K side, you most likely need updated drivers for video and sound cards; plug-and-play (PnP) can occasionally be plug-and-pray; USB devices and drivers have random, sometimes frustrating, problems; and Internet Explorer (IE) still generates a multitude of access violations.

Win2K WINS, DNS, and DDNS. Assuming you're using NT 4.0 DNS, you must configure Win2K systems with valid addresses for DNS and WINS servers, including a DNS suffix (e.g., win2000mag.com). Otherwise, Win2K systems won't be able to locate an NT 4.0 DC. Likewise, if you don’t have a WINS server to register a Win2K system's name, Win2K computers won't appear in the browse list.

When you install standalone Win2K servers in an NT 4.0 domain, be sure that each system has a valid DNS suffix; otherwise, the system can't resolve names and, by extension, can't locate an NT 4.0 DC. Win2K setup doesn't automatically define the DNS suffix when you install a standalone Win2K server. If you plan to continue with NT 4.0 legacy DNS and WINS services, you need to know that Win2K Advanced Server (Win2K AS) setup installs local DNS and WINS services by default. If the standalone servers will interoperate with legacy systems, you might want to clear these options during the Win2K server’s installation.

During an NT 4.0-to-Win2K upgrade, a problem in the Adapters section of the setup.inf file might cause setup to overwrite static TCP/IP settings and change the system to a DHCP client. If, instead, you need to change a system from a DHCP client to a static TCP/IP address, complete the installation and change the address after the system is running. If you attempt to change from a dynamic address to a static address during setup, setup might hang. After the final reboot, check the final TCP/IP configuration to ensure that you have the static or dynamic client you expect.

All versions of Win2K enable DDNS registration by default, and NT 4.0 DNS servers don't support dynamic name registration. To avoid a steady stream of error messages from the NT 4.0 DNS server, you must disable DDNS registration by clearing the "Register this connection’s addresses in DNS" check box on the DNS tab of Advanced TCP/IP Settings for your network adapter, as Figure 2 shows. You can disable this function during Win2K setup or after the system is running and logged on to the network.

Changing a Win2K computer name. You can’t change the name of an NT 4.0 system during an upgrade to a Win2K DC. If you need to change the name, you must upgrade the NT 4.0 machine to a Win2K standalone server, change the name after setup finishes, and promote the system to a Win2K DC. If you install or upgrade a Win2K DC and need to change the system’s name, run the Win2K utility Dcpromo to demote the system, alter its name, and run Dcpromo again to change its role back to a DC.

You also can’t change the name of a Win2K server on which you install CA. If you issue certificates from a system running CA and later need to change the system’s name, you must export and import any certificates issued before you change the CA computer name. To avoid this monumental hassle and the risk of invalidating certificates, make sure the server’s name will remain valid long after you put the CA in place.

Win2K Logon Problems
To ensure that a Win2K system can successfully log on to an NT 4.0 domain, you must use NT 4.0’s Server Manager to create a computer account for each new Win2K system. You can create the computer account before you install Win2K or during setup, if you have administrative privileges. Win2K needs the Client for Microsoft Networks component (which it installs by default) to locate an NT 4.0 DC. Client for Microsoft Networks provides Win2K with NetBIOS name resolution, and NetBIOS is the only way a Win2K system can locate legacy shared resources. If Win2K clients will also log on to a Win2K domain and the Win2K domain has a different DNS address, be sure that you select the check box that lets Win2K change the DNS suffix when the domain name changes. You can access this check box by selecting Properties on the Network Identification tab and clicking More.

Certain NT 4.0 logon restrictions can prevent users from accessing shared Win2K resources. For example, imagine that you have a legacy NT 4.0 network and an NT 4.0 PDC, and your users access shared resources on Win2K servers. In the NT 4.0 domain, you restrict logon hours for user accounts and enable the option "Forcibly disconnect remote users from server when logon hours expire." However, when you set these features, nonadministrative users who log on to NT 4.0 systems during valid logon hours can't access shared resources on the Win2K systems. To correct this problem, you need to obtain a new version of srv.sys from Microsoft Support.

Win2K Stealth Logons
When you attempt to log on to a Win2K or NT 4.0 domain from a Win2K system and the system can't locate a DC, Win2K silently logs you on to the local computer using cached credentials. This cached logon can also occur with a RAS or RRAS dialup or VPN connection. When you log on to the local system, you are not a member of the domain and, by definition, you can’t access login scripts, system policies, roaming profiles, or your home directory, which results in an unexpected user environment and no network access.

To make matters worse, Win2K does not inform you that it logged you on with cached credentials. After a cached logon, if you log off and look at the logon screen, you’ll see the expected domain name instead of the local system name. The only way to determine the type of logon that Win2K performs is to examine the environment variable LOGONSERVER. To display this variable, go to the command prompt and type

echo %logonserver% 

If LOGONSERVER is set to the name of your computer, you logged on with cached credentials; if LOGONSERVER is set to the name of a DC, you logged on to the domain.

Although you can’t change this behavior, you can instruct Win2K to display a message whenever it logs on a user with cached credentials. To display this message, you must make two registry modifications on each system where a warning is required—one edit for the local system configuration and another for each user for whom you want to display the "logged on with cached credentials" message.

Launch a registry editor and go to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon. From the Winlogon key, add the entry ReportControllerMissing of type REG_SZ and set it to TRUE (make sure that the string TRUE is uppercase). To make the per-user modification, go to HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogon and add the entry ReportDC of type REG_DWORD and set it to 1. Notice that you enter a string value for the first Winlogon entry and a numeric value for the user-specific Winlogon control.

Win2K Time Synchronization
Shortly after you install a Win2K system in an NT 4.0 domain, you’ll notice that Win2K posts repeated warnings with a source of W32Time and Event ID 64 in the System event log. You'll also see a message that says, "Because of repeated network problems, the time service has not been able to find a domain controller to synchronize with for a long time." Every Win2K system looks to a Win2K DC to accurately define the time. When no time server is available or the time source is not reachable, you’ll see this message.

You can use several methods to provide a time service for Win2K in an NT 4.0 domain. You can configure an NTP-enabled router to set the time from an external source and direct all Win2K systems to query the router for the time. You can also install your own NTP-based local network time server (see below for how to install an NT 4.0 NTP time server). If you have no other option, you can configure each Win2K system to independently synchronize time with an external time source. Once you have an official non-Win2K time source, you need to enter the following Win2K console commands to instruct the OS systems to query the designated NTP time source:

net time /setsntp:  | 

to define the NTP time source,

net time /querysntp

to display the NTP time source, and

w32tm /s

to synchronize the time after you define the time source. For additional information on the Win2K time service, see Zubair Ahmad's "Windows Time Synchronization Service."

Resetting the Win2K time service. When you are ready to move a Win2K system from NT 4.0 to a Win2K domain, the Win2K system will not synchronize with a Win2K DC until you reset the time service to its default mode of operation. The W32Time service stores its operating parameters in the registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters, as Figure 3 shows. (For detailed documentation on all the W32Time service registry entries, see Microsoft article "Registry Entries for the W32Time Service.") When you manually define an NTP time source, the time service adds the entry Ntpserver of type REG_SZ with a value of either or , depending on whether you define the time source by name or by address. The time service modifies a second entry, Type, of type REG_SZ and a value of NTP.

To reset Win2K to its default mode, you must delete the Ntpserver entry, change the Type entry to nt5DS, and resynchronize the time service in the Win2K domain to verify that you made the registry edits correctly. You can adjust the interval at which the time service tries to synchronize by adding an entry called Period of type REG_DWORD and using one of the values that Microsoft documents in article Q223184. You can set the interval to once every 2 days, once every 3 days, once a week, or once every 45 minutes until three good synchronizations occur and then either once or three times per day afterwards. You can also set the interval to synchronize a fixed number of times per each 24-hour period.

Installing an NT 4.0 NTP time server. You can make one of your NT 4.0 systems function as an NTP time server by installing the Windows NT 4.0 Server Resource Kit utility w32time.exe. Then, you can easily configure the Win2K systems to check with the NT 4.0 NTP time server. If you go this route, be sure you download the updated copy of w32time.exe from Microsoft's FTP site because the copy in the published Resource Kit does not include the extensions W32Time needs to function as an NTP time server.

To properly configure the NT 4.0 W32Time service, you need to modify the w32time.ini file. Open the .ini file in a text editor and set LocalNTP=yes. Stop the NT 4.0 time service, instruct it to read the .ini file, and start it again with the following commands:

net stop w32time w32time –updatenet start w32time

Win2K NetBIOS and File Sharing
NT 4.0 publishes and locates shared resources by each share’s NetBIOS name. Because one of Microsoft's goals in developing Win2K was to eliminate the dependency on the company's proprietary protocol, Win2K uses Server Message Block (SMB) to publish and connect with shared resources. In a pure Win2K domain, you can disable NetBIOS and suffer no adverse consequences. In fact, if you disable NetBIOS, you reduce network traffic by eliminating NetBIOS name registration and name resolution packets.

However, when a Win2K system needs access to legacy shares or when legacy systems such as NT 4.0 and Win9x need access to Win2K shares, you must install and bind NetBIOS to the LAN network adapter. You should not experience NetBIOS-related problems unless you override the default Win2K settings—Win2K installs the Client for Microsoft Networks component by default, as Figure 4 shows, and binds it to all network adapters. However, if you have a multihomed Win2K system with an Internet connection, you should unbind the Client for Microsoft Networks and File and Print Sharing to disable broadcast of NetBIOS names on the WAN link.

Finally, let me add a few words on Win2K volume and share security. Like NT 4.0, Win2K volume and newly defined share access defaults to Everyone: Full Control. To ensure a base level of security, you should eliminate this wide-open access on volumes and shares by adding appropriate access controls.

Managing Mixed-Platform User Profiles
Did you know that when you perform a fresh install of Win2K, the OS caches local profiles under their respective usernames in the Documents and Settings folder? Probably. But I bet you didn’t know that when you upgrade an NT 4.0 system to Win2K, the OS maintains the existing NT 4.0 profile directory in the system root. As a result, you can end up with two different locations for cached profiles, depending on whether you upgrade NT 4.0 to Win2K or install a fresh copy of Win2K.

You can change the default location for Win2K cached user profiles during installation if you use unattended setup mode. When you install Win2K with the command

winnt /unattend

or

winnt32.exe /unattend

setup expects to find Win2K configuration information in the file unattend.txt. To redirect Documents and Settings, you must add the following section to the unattend.txt file:

[GuiUNattended]ProfilesDir = z:foldername

Microsoft article "Cannot Move or Rename the Documents and Settings Folder" documents two additional procedures that you can follow to move an individual profile or relocate the top-level Documents and Settings directory.

Duplicate profiles. NT 4.0 and Win2K manage duplicate profiles differently. NT 4.0 adds a numeric suffix, starting with .000, to the first duplicate local profile. When another user logs on with a username that already has a profile, NT 4.0 increments the numeric suffix by one. When a duplicate user logs on to Win2K, the OS appends a suffix that matches the computer name if the conflicting user logs on to the local system or a suffix that matches the domain name if the user logs on to the domain. If a third conflict arises, Win2K adds a numeric suffix that behaves just like NT 4.0 and the suffix starts with .000 and increments by one. Figure 5 shows how Win2K caches local profiles when you log on with the same username to the local workstation and to different domains. Keep this difference in mind when you need to delete a local copy of a Win2K user’s profile—make sure that you verify the user’s domain or you might inadvertently delete the wrong one.

Updating profiles. When you set up a user in Win2K or NT 4.0, you typically define a file share that points to the user’s roaming profile directory. If you run a mix of Win2K and NT 4.0 systems, you can store the profile directories on either a Win2K or NT 4.0 system. Be aware that one very important difference exists in the security that each platform requires to perform a successful profile update. When Win2K updates a user profile, the user needs Full Control permission on the profile share, and when NT 4.0 updates a user profile, the user only needs Change permission on the profile share.

If you don't extend the security on the profile share to give the user account Full Control, NT 4.0 will successfully update the profile. However, if the same individual logs on to a Win2K workstation and then logs off, the Win2K profile update will fail with the error message "Windows cannot update your roaming profile. Contact your network administrator. DETAIL - Access is denied." If you store profiles on a Win2K system, give the user’s account the NTFS file permissions List Folder Contents, Read, and Write on the profile directory.

Deleting profiles. Another important difference in how the two platforms manage profiles has to do with deleting profiles. When you delete a local profile in NT 4.0, you delete only the registry settings that define the user’s computer and desktop environment. When you delete the local user profile copy in Win2K, you delete the user’s entire directory under Documents and Settings, including all files, folders, and desktop shortcuts stored with the profile. If you don't redirect saved files to another folder, you can inadvertently delete user documents and data files when you delete the local profile.

System Policy and Group Policy
The party line on Win2K Group Policy and NT 4.0 system policy, which can include computer and user policies, is as follows: Win2K and NT 4.0 apply policy from the domain in which the respective account exists. In the simplest case, when the computer and user accounts are in an NT 4.0 domain, clients running either platform apply computer and user settings from the NT 4.0 system policy file, ntconfig.pol. When computer and user accounts are in a Win2K domain, Win2K applies the equivalent Group Policy settings for the computer and the user. When a computer account is in an NT 4.0 domain and the user account is in a Win2K domain, the client receives computer policy settings from ntconfig.pol and applicable user settings from Win2K’s Group Policy. In the reverse situation, when the computer account is in a Win2K domain and the user account is in an NT 4.0 domain, the computer settings come from Win2K's Group Policy and the user settings come from NT 4.0's system policy.

Have you ever defined a system policy, logged on to a system where the policy should apply, and discover the policy did not download? Apparently, some OEMs ship Win2K and NT 4.0 systems with a registry setting that disables the application of system policy. In such cases, registry entry UpdateMode in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlUpdate registry key is set to 0. If you set UpdateMode to 1 (Automatic mode), the system searches for a system policy file named ntconfig.pol in the authenticating server’s Netlogon share. If you set UpdateMode to 2 (Manual mode), the system searches for the system policy file in the location defined by the accompanying registry entry, NetworkPath.

System policy that doesn’t migrate. For security reasons, administrators often create an NT 4.0 system policy that prevents the computer from displaying the last logged on username. You can disable the last logged on username in Win2K as well, but because the two OSs store this setting in different registry locations, Win2K does not inherit this setting from NT 4.0 system policy. To disable the display of the last logged on user in Win2K, you must manually modify the registry on each system. As Figure 6 shows, Win2K stores this logon setting in the registry path HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciessystem. The registry entry is DontDisplayLastUserName of type REG_DWORD. When you set the entry to 0, Win2K displays the last username, and when you set the entry to 1, Win2K suppresses the username.

This setting also disappears when you upgrade an NT 4.0 system to Win2K. You can reactivate the feature using the registry edit above or by modifying the local system’s policy. Start the Microsoft Management Console (MMC) and add the Group Policy snap-in. The MMC changes the Group Policy snap-in to the Local Computer Policy snap-in when you load it on a workstation or server that's not a DC. Go to the Security Options key (Windows Settings, Local Policies) and scroll down the right pane until you find "do not display last username in logon screen." Right-click this entry, and check the Enable box. Reboot the system to activate the change.

Win2K Group Policy and environment debugging. You can debug user environment problems in NT 4.0 if you install the debug version (checked build) of userenv.dll, but it’s very inconvenient because you have to reconfigure, shutdown, and reboot to activate the debugging features in the checked build of the .dll. It’s difficult to debug layer upon layer of adjustments made with computer policy, user policy, and logon scripts, but a good technique does exist for debugging Win2K environment problems.

Win2K has environment debugging built-in and all you need to do is add a key and a couple of value entries. This feature is quite helpful when you consider the task of troubleshooting local or domain Group Policy problems with computers or users, remote booting, application management, IPSec policy, and more.

Open a registry editor, go to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT CurrentVersion, and add a new key called Diagnostics (this key is not present by default). When prompted, leave the class key empty. You can add four different entries to the Diagnostics key. One entry instructs Win2K to log all user environment activity, one instructs Win2K to log only Group Policy events, one instructs Win2K to log remote boot activity, and the last option instructs Win2K to log only application management-related events.

If you want to log every user environment and policy setting you implement in Win2K when a user logs on, add the entry RunDiagnosticLoggingGlobal of type REG_DWORD and a value of 1

to the Diagnostic key. Figure 7 shows the registry entry you need to enable for debugging all events. To enable logging of Group Policy events, add the entry RunDiagnosticLoggingGroupPolicy of type REG_DWORD and a value of 1. To enable logging of remote boot activity, add the entry RunDiagnosticLoggingIntelliMirror of type REG_DWORD and a value of 1, and to log application management events, add the entry RunDiagnosticLoggingAppDeploy of type REG_DWORD with a value of 1.

Log off and back on and read through the copious records in the Application event log for indications of what is going wrong where. Remember to delete the Diagnostics key when you finish troubleshooting so the Application log doesn’t fill up with debug messages.

Summary
Now that you know some of the differences you’ll encounter when you manage a network of mixed Win2K and NT 4.0 systems, you can begin to plan for them. The solutions you devise will depend on the migration scenario you select. You know you must provide a time synchronization source for Win2K, and you can select from at least three solutions. You know that user profiles are cached in a different location on each platform. If you go the NT 4.0 hybrid route, you probably want to maintain Win2K user profiles in the system root for consistency. If you go the Win2K hybrid route, you might want to relocate NT 4.0 user profiles to the Documents and Settings directory. You might also elect to keep your domains platform-specific to eliminate some of the concurrent management issues.

You understand the difference between legacy and Win2K file sharing, and you know that you need NetBIOS on Win2K systems to publish and locate legacy resources. You know that Win2K and NT 4.0 apply system policies and group policies based on the domain where the computer and user accounts reside, and you know that NT 4.0's Don’t Display Last Username setting does not migrate to Win2K. Finally, you are prepared to debug layers of Win2K environment controls with a registry edit or two. Good luck, and may the force be with you—the force, in this case, is knowledge.