The Win2K DS Client
If you support Windows NT 4.0 or Windows 9x clients in a Windows 2000 domain, the Active Directory (AD) client is almost mandatory. The Directory Service (DS) extension installs the dsclient.exe service and provides the following functions for the client system:
- lets a legacy system log on to the closest Win2K domain controller (DC) instead of on to the PDC only
- lets a legacy system change passwords on the closest Win2K DC instead of on the PDC only
- supports NT LAN Manager (NTLM) version 2 authentication, which is more secure than older authentication protocols
- supports client access to Win2K Dfs shares
- lets the client display AD Windows Address Book (WAB) data
You can download the most recent version of the client software from the Microsoft Web site.
You can install the DS client on a Service Pack 6a (SP6a) system only. The installation procedure checks the version of the NT kernel (ntoskrnl.exe) and expects the current version to be SP6a. If you have installed the hotfix Q246467, the client install will fail because the hotfix sets the kernel version to SP6, Release Candidate 1.3 (RC 1.3). If you see the following error message, you must call Microsoft Support for a new version of kernel32.dll dated March 20, which contains the proper version numbers:
Setup cannot detect the Windows NT 4.0 with SP6a or higher operating system which is required to install the Directory Service Client. The installation will terminate.
Microsoft article Q293322 documents this DS client problem.
Win2K Security Policy Might Become Corrupted
Windows 2000 stores active security policy settings in one file in the Sysvol directory. Any policy change that occurs on the computer filters into the Group Policy file. Microsoft article Q290649 indicates that when a policy change results in multiple write operations to the file, those multiple write operations aren’t transaction-based. If any of the write operations doesn't succeed, an empty or corrupted Group Policy template might result. This potential problem exists on all Win2K SP1 systems. Microsoft Support has a code fix, a new version of scecli.dll with a release date of March 28.
Win2K Demands a Password Length Of 18,770 Characters
This entry is sheer entertainment—let me know if you’ve seen this problem on a Windows 2000 system. Apparently, when you log on to a Massachusetts Institute of Technology (MIT) Kerberos realm, press Ctrl+Alt+Delete, click Change Password, type your existing MIT password, and then type a new password that doesn’t pass the dictionary check in Kadmind, you might receive the following error message:
Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes.
Microsoft article Q276304 states that the number of required characters in this error message is 17,145 for the initial release version of Win2K and 18,770 on SP1 systems. Call Microsoft Support for a new release of msgina.dll, file date of March 8, to correct this problem.
Win2K DCs Reboot Every 15 Minutes
When the Knowledge Consistency Checker (KCC) creates enough Active Directory (AD) replication connection objects duplicates, a KCC stack overflow causes the Local Security Authority (LSA) service, lsass.exe, to halt and causes the DC to reboot. When this event occurs, you might receive the following error message:
The system process LSASS.EXE terminated unexpectedly with status code -1073741571. The system will now shut down and restart.
The reboot happens approximately every 15 minutes until either the KCC stops generating connection objects or you delete the duplicates that are causing the stack overflow on the DCs that are rebooting. Microsoft article Q284003 indicates that you can eliminate the endless reboot cycle by installing the new version of ntdskcc.dll released April 10. This problem is flagged as a Windows 2000 Service Pack 3 (SP3) fix, so it’s not likely to accompany SP2.
Safely Preserving an NT 4.0 Service Pack Uninstall Directory
Every time you install a service pack, the update utility asks whether you want to create an uninstall directory. If you want the option to remove a service pack, you must answer Yes to this question when you upgrade from a previous service pack. However, if—like me—you answer Yes to create the uninstall directory on subsequent reapplications of the same service pack, then, after you add a new device or service, the reinstall overwrites the uninstall directory with a copy of the currently installed service pack. Once this overwriting occurs, you can never revert to the previous service pack level.
Here's what happens: If you create the uninstall directory multiple times, the Control Panel Add/Remove Programs applet includes the option to uninstall the current service pack. When you select this option, the uninstallation appears to function correctly. However, the uninstall process is actually restoring files from the current service pack. When the system boots after the uninstall, the OS loader screen indicates that you’re still running the version you thought you uninstalled.
To preserve the option to revert to a previous service pack, never create an uninstall folder after the original service pack install. If a backup isn’t available and the system has overwritten the files in the uninstall folder, you can’t revert to a previous service pack. This behavior is the same on all SP3 and later NT systems, including NT Server 4.0, NT Workstation 4.0, NT Enterprise Edition, and NT 4.0, Terminal Server Edition (TSE). See Microsoft article Q248102 for more information.