More Win2K-NT 4.0 Coexistence; New Win2K Bug Fixes

Password Problem Follow-up. Last week, I wrote about a problem I experienced when changing an expired password on a Win2K workstation that was a member of an NT 4.0 domain. Thanks to the readers who responded, we now have a solution. To ensure that Win2K users can successfully change expired passwords for NT 4.0 accounts, you must disable the "User must logon to change password" option (User Manager displays this check box when you select the Account option on the Policies menu). Disabling this feature affects all accounts in the domain, so I’m not very comfortable with this solution's security implications. However, I tested the solution, and it works as advertised.

Running NT 4.0’s User and Server Manager on Win2K. Last week, I discussed creating a shortcut to User Manager on my Win2K Advanced Server machine so that I could manage the NT 4.0 domain account database without walking downstairs. In response, one reader pointed out that the Windows 2000 Server Resource Kit contains several utilities you can use to manage NT 4.0 systems from a Win2K desktop. After installing the resource kit, you’ll find a plethora of tools in the Network Management Tools folder. Although most of the tools run only from the command line and have unusually cryptic and poorly documented argument lists, the Win2K versions of User Manager for Domains and Server Manager have the same GUI that NT 4.0's native applets employ. I tried both utilities and was pleasantly surprised by how well they work.

If you prefer to add or modify Win2K or NT 4.0 user accounts from the command line, check out the Console User Manager utility (cusrmgr.exe). And while we’re on the subject of user accounts, you might want to try the user status utility usrstat.exe, which displays the full name and last logon time for each user in a domain. If you maintain a large NT 4.0 account database, you should pipe this utility's output to a file.

Win2K-NT 4.0 Time Synchronization. One reader wrote to say that he tried to set up an NT 4.0 time server that his Win2K systems could use for synchronization, but he discovered that the timesrv.exe utility from the original Windows NT 4.0 Server Resource Kit doesn't support the Network Time Protocol (NTP) that Win2K systems need. After some exploration, I discovered that Microsoft has released updates for w32time and timesrv, the tools you need to successfully set up an NT 4.0 system that operates as an official time server. However, the updates are hidden in a most unlikely spot: a folder called Y2kfix at Microsoft’s FTP site. You can download the tools and documentation from ftp.microsoft.com/reskit/y2kfix/x86. Microsoft article Q258059 contains all the information you need to create an NT 4.0 NTP server.

Roaming Profile Update Fix. Microsoft article Q265357 indicates that when you implement a roaming user profile and enable the "Delete roaming profile cache" policy, a bug in Win2K prevents the system from updating the profile. The article is vague about the symptoms this problem displays, but it indicates that you can call Microsoft Support for the bug fix, a new version of rsabase.dll released July 11.

FAT32-to-NTFS Conversion Fix. Here’s the scenario: You install Win2K on a 20GB or larger IDE hard disk and select FAT32 for the initial drive format. When you attempt to convert the drive to NTFS, the conversion fails with the message, "Conversion failed, not enough disk space on drive"—even though the drive has as much as 18GB of free space. Microsoft article Q271644 indicates that Win2K doesn't calculate the Logical Block Addressing (LBA) correctly for certain large IDE drives. Call Microsoft Support for the bug fix, which updates four files: atapi.sys, intelide.sys, pciide.sys, and pciidex.sys.

DCPromo Fix. If you run dcpromo.exe and it fails, check the Dcpromo log file for the error message, "The replication system encountered an internal error." According to Microsoft article Q267887, dcpromo.exe replication fails and generates an internal error when it attempts to replicate a tombstone with a phantom parent. The replication process tries to read the globally unique ID (GUID) of the parent tombstone to send to the destination, but fails when it finds that the parent is a phantom rather than a live object or a tombstone. The bug fix, which you can only get directly from Microsoft Support, updates two files, ntdsa.dll and samsrv.dll. The files have a release dates of July 21 and July 19, respectively.