An IEAK Compatibility Problem; An MSCS 1.0 Bug Fix

Windows 2000 High-Encryption Compatibility Problem
Microsoft announced an Internet Explorer Administration Kit (IEAK) high-encryption compatibility problem that can adversely affect Windows 2000 (Win2K) systems. IEAK lets you create custom Internet Explorer (IE) 5.0 installations. To include 128-bit encryption in the browser, you must include the Win2K custom 128-bit encryption component ie5dom.exe. However, ie5dom.exe’s instructions incorrectly indicate that you should use the command-line switch /n:v to disable version checking with ie5dom.exe. According to Microsoft Support Online article Q255669, if you use the /n:v switch, your IE 5.0 build might include non-compatible versions of high-encryption modules rsaenh.dll or schannel.dll.

If you have a high-encryption system with this problem, you’ll see the message, "System cannot log you on because domain Computer_name is not available" after you reboot and attempt a normal or safe-mode logon (Computer_name is the name of the system you are logging on to). To avoid the problem, use IEAK to create a separate IE 5.0 build that includes encpack.exe for Win2K (encpack.exe updates rsaenh.dll only).

Microsoft Support Online article Q244671 documents a complex procedure you can follow to recover a system with cryptographic file problems. The article points out that because rsaenh.dll installs only with the high-encryption service pack, the system doesn’t check or replace the file when you repair system files; you must check and replace rsaenh.dll using Recovery Console if the file is missing or corrupt, or if it’s an incorrect version.

Microsoft Cluster Server 1.0 Bug Fix
Microsoft has a bug fix for Microsoft Cluster Server (MSCS) 1.0 that corrects three cluster problems: a shutdown problem, a cluster restart problem, and a disk-access problem.

You must call Microsoft Support to get the bug fix, a MSCS file called clustdisk.sys dated January 18, 2000. The file isn’t available for public download.

Service Packs Don’t Update International License Server Files
If you apply an NT 4.0 service pack (SP1 through SP6a) to an international version of NT, the service packs won’t update four license server files: liccpa.cpl, llsrpc.dll, llssrv.exe, and ntlsapi.dll. You can spot the outdated files because they have 1996 dates. Update.exe, the utility that installs service packs, doesn’t recognize these four files and therefore doesn’t install updates, even though the service pack distribution includes current versions of the files. To work around the problem, expand the service pack (e.g., type sp6i386.exe /x at the command line) and manually copy the four files to the %systemroot%system32 directory. See Microsoft Support Online article Q257274 for more information.

RasDial API Memory Leak
According to Microsoft Support Online article Q257647, when the system calls the RasDial API in a tight loop with an invalid entry, a memory leak occurs that you can view with Performance Monitor. The problem applies specifically to SP6a systems. Call Microsoft Support for a new version of rasapi32.dll that eliminates the memory leak.

RAS "Client Access Denied" Troubleshooting
Here’s an interesting tip that might help you troubleshoot RAS client authentication, particularly when your users log on with Secure ID or SmartCard technology. Before SP6, RAS ignored the domain field if it was empty or contained one or more spaces. SP6 tightens client authentication by passing the contents of the logon dialog box’s Domain field when the field isn’t empty, even if the field contains only spaces. When you use Secure ID to authenticate users, you typically don’t require a domain name. However, if the Domain field contains a blank, its contents pass to RAS for authentication, and although the user has the correct Secure ID, the authentication attempt might fail. The next time you’re using Secure ID or SmartCard technology and you get a call from a RAS user who can’t authenticate, ask the user to delete the blanks in the Domain field and try again. Microsoft Support Online article Q256509 describes the problem and includes three PPP log records that can help you diagnose it.

Norton AntiVirus Update Crashes System
The February 14 Norton virus update might crash your system and display a Stop Code of 0x1e after the installation completes. Microsoft Support Online article Q255928 (http://support.microsoft.com/support/kb/articles/Q255/9/28.asp) indicates that navex15.sys is the problem file. Symantec recommends that you work around the system crash by either reverting to the previous update or installing the March update.