Secure Channel Stealth Connection
If you have Windows 2000 systems that log on to a Windows NT 4.0 domain, you must pay attention to this cached-credential problem. The first time you add a Win2K system to an NT 4.0 domain, the system creates a secure channel with the NT 4.0 PDC. A secure channel is a password-protected connection between the Netlogon components on each system. After the systems establish the secure channel, Win2K caches the secure channel credentials, which include the PDC's name, on the local system. However, because Win2K never updates the cached secure channel credentials, the next time you boot the Win2K system, it uses the cached credentials to establish a secure channel with the NT 4.0 PDC.
Although Microsoft article Q272348 doesn't explore potential consequences of this caching behavior, I believe it can cause myriad problems, especially if you subsequently promote and demote NT 4.0 DCs. The article offers a rather untenable workaround. If you stop the Netlogon service on the NT 4.0 PDC before you boot a Win2K system, Win2K can't communicate with the PDC. Win2K must then locate a BDC and create a new secure channel, instead of using the cached credentials. If you run an NT 4.0 hybrid domain with Win2K systems, be proactive and apply the fix as soon as possible: Ask Microsoft Support for the new version of Win2K's Netlogon.dll, which the company released August 25.
Lsass Access Violation
A bug in the Win2K Lsass code might cause an access violation when you implement security packages. Although the explanation of the bug is obtuse, to say the least, Microsoft article Q264600 (http://support.microsoft.com/support/kb/articles/Q262/5/39.asp) indicates that you can work around the Lsass Dr. Watson failure by adding a registry key that lets you audit base system objects. If the AuditBaseObjects key is not present, create it. If the audit key already exists, set its value to 1.
To permanently solve the problem, ask Microsoft Support for the bug fix—a new version of Secur32.dll that the company released June 8.
Lsass Memory Leak
I described the Lsass Memory Leak problem months ago, but because we're on the subject of Lsass, mentioning it again seems appropriate. Microsoft article Q262539 (http://support.microsoft.com/support/kb/articles/Q262/5/39.asp) indicates that the Lsass Samsrv.cll component leaks private memory bytes when it enumerates groups (e.g., Administrators or Operators) that contain a large but unspecified number of members. To eliminate the memory leak, ask Microsoft Support for the bug fix that updates Samsrv.dll and Ntdsa.dll. The files have a release date of May 10 and April 17, respectively.
Local Backups That Take Forever
If you run Ntbackup locally to back up a system to an IDE-based tape drive, the process might take much longer than you expect. If the system has both a CD-ROM and an IDE tape backup unit such as a Travan on the same channel, Ntbackup slows significantly because the CD-ROM Autorun feature gets in the way. Microsoft article Q263480 indicates that when these two devices share an IDE channel, the CD-ROM driver checks the CD-ROM drive once per minute to see whether the media has changed. This once-per-minute polling can turn a 5-minute backup job into a several-hour task. If you instruct Ntbackup to verify the backup, the Autorun feature prevents the verification phase from completing successfully. To eliminate this conflict on the shared IDE channel, you can either disable the CD-ROM Autorun feature (easy) or move one of the devices to another IDE channel (harder).
To enable or disable the Autorun feature, you need to edit the registry. Find the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CDRom. Set the Autorun value to zero to disable the feature (a value of 1 enables the feature) and reboot. Microsoft article Q155217 indicates that two Explorer registry entries (one for the current user and one for the Default User) also affect the Autorun feature. The article states that the correct value for NODriveTypeAutoRun is 0x00000095, but the article doesn't explain what this value is for or how Win2K uses these additional Autorun settings.
NoDriveTypeAutoRun = 0x00000095
NoDriveTypeAutoRun = 0x00000095
QoS CPU Loop
When you connect to a Quality of Service (QoS) socket, Win2K might go into a tight CPU loop for an extended time. Microsoft article Q263207 indicates that a race condition in Rsvpsp.dll causes the 100 percent CPU utilization. If you're developing or deploying a QoS application, call Microsoft Support for a new version of Rsvpsp.dll, which the company released July 31.
Unlike Windows NT 4.0, Windows 2000's License Manager doesn't reveal that a Win2K Server or Advanced Server system is running a Not For Resale (NFR) copy of the OS. When you add more Win2K licenses using License Manager to increase the number of permissible connections, the operation completes successfully, but the server doesn't recognize the additional licenses and lets only 10 client computers connect concurrently. Microsoft article Q263657 explains that because the NFR copy hard-codes the 10-connection limit, License Manager is unaware of the restriction. Furthermore, you've no way to determine whether an installed version of Win2K Server is the NFR version or the full retail version, except for the "connection-limit-exceeded" messages in the Event log. The only solution is to install the Win2K retail version.