Win2K Logon Problems in an NT 4.0 Domain
To ensure that your Windows 2000 systems can successfully log on to a Windows NT 4.0 domain, you must first perform several setup and configuration steps. Start by creating a computer account for each new Win2K system in NT 4.0’s Server Manager. You can create the accounts before installing Win2K or, if you have an administrator account, during setup. Next, configure Win2K systems with valid addresses for DNS and WINS servers; otherwise, Win2K systems won't be able to locate an NT 4.0 domain controller. If you install standalone Win2K servers in your NT 4.0 domain, be sure that each server has a valid DNS suffix (Setup doesn't automatically define this field when you install a standalone Win2K server). Finally, if your Win2K clients also log on to a Win2K domain, be sure that you check the box that lets Win2K change the DNS suffix when the domain name changes. To avoid continuous NT 4.0 DNS Event Log messages, disable Win2K’s dynamic DNS (DDNS) update option. Win2K enables this option during setup.

Your Win2K systems might have trouble logging on to an NT 4.0 domain if you unbind or remove Client for Microsoft Networks or if you run a third-party DNS server. As with an improper or incomplete\TCP/IP configuration, either or both of these problems can prevent a Win2K system from locating an NT 4.0 BDC. Symptoms of both these problems include the following:

  • Win2K might display the message, "The specified domain either does not exist or could not be contacted."
  • Pinging the domain controller by name fails, but pinging the domain controller by IP address succeeds.
  • If you issue the command net view \\<domain-controller-name>, you get your least favorite and most generic error message: "System error 53 has occurred. The network path was not found."

If by some remote chance you have Server Message Block (SMB) signing (also known as Common Internet File Sharing—CIFS—protocol) enabled on any of your NT 4.0 domain controllers, Win2K users might have trouble logging on. If a Win2K user enters an invalid password when SMB signing is turned on, Win2K responds with the error message "Network name is no longer available" instead of prompting for the correct password. One obvious workaround is to have your users enter the correct password the first time; you can also disable SMB signing on the NT 4.0 domain controllers. To resolve the problem, call Microsoft Support and ask for the new version of the NT 4.0 redirector.

Managing Win2K and NT 4.0 User Profiles
User profile management is a broad subject with a million possible complications, so don’t consider this discussion the final word on managing mixed clients. However, before you get started, you should know a few things about user profiles and system policies. First, NT 4.0 caches local profiles in the Profiles directory of the system root. If you upgrade an NT 4.0 system to Win2K, Win2K maintains this location. However, if you perform a clean Win2K installation, Win2K stores local user profiles under their respective usernames in the Documents and Settings folders on the boot drive.

Second, 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. Each time 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, Win2K adds a suffix that's either the domain name or the local computer name. If yet a third conflict arises, Win2K adds a numeric suffix that starts with .000 and increments by one, as in NT 4.0.

Keep this difference in mind when you decide you must delete a locally cached profile. When you delete a profile in NT 4.0, you delete only the registry settings that define the user’s computer and desktop environment. When you delete a local profile in Win2K and duplicates exist, make sure that you verify the user’s domain or you might inadvertently delete the wrong profile. And when you delete the local copy in Win2K, be aware that Win2K deletes the user’s entire directory under Documents and Settings, including all the files, folders, and desktop shortcuts stored with the profile.

You can change the location in which NT 4.0 stores the local copy of user profiles by editing the registry. 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 unattend.txt:

\[GuiUNattended\]ProfilesDir = z:\foldername

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

If the same user logs on to NT 4.0 and Win2K systems, each OS performs a profile update. As I discussed in an earlier column, NT 4.0 can update a roaming profile when the user has Change permission for his or her profile directory. However, the Win2K profile update for the same user will fail unless you give the user Full Control on the Profile directory.

File-Sharing Issues
The default permission on all my Win2K volumes is Everyone:Full Control, and, by default, each top-level directory on the drive inherits this permission from the volume. Win2K further sets the default permission for all file shares to Everyone:Full Control. To ensure a modicum of security, be sure that you set NTFS file permission appropriately for any directory you want to share, whether it hosts a user profile, an application, or data. When you create a file share, click Permission and enter the appropriate access controls to close this gaping security hole. The moral of this story is that you must check NTFS permissions for each directory and every file share that's accessible from the network.

A funny bug in NT 4.0 can prevent users from connecting to shared resources on a Win2K system. If your NT 4.0 account policy restricts logon hours and you enable the option to "forcibly disconnect users when logon hours expire," users who log on during valid hours can't access shared Win2K resources. Microsoft article Q263006 documents this behavior and describes a bug fix you can install to eliminate this hiccup.