NT 4.0 Post-SP6a Security Rollup Feedback
I heard from several readers who installed the Windows NT 4.0 post-Service Pack 6a (SP6a) security rollup. Here’s a quick summary of the feedback:
? Paul Fletcher from the Star Technology Group installed the rollup on an extranet server and reports that it broke the application that uses Active Directory Service Interfaces (ADSI) from Active Server Pages (ASP). After installing the hotfix, ADSI calls to obtain user objects failed, and a bizarre error message about a network path not found appeared. Removing the hotfix restored the ADSI functionality.
? Robin Penny from IT Support in London loaded the security rollup on an NT 4.0 Workstation machine. After rebooting, he received an error message saying that at least one driver failed to start. The driver in question was CMOSA, but Robin has been unable to identify where and how NT 4.0 uses the CMOSA driver. He says that being without the driver doesn't seem to have any adverse affects. Robin adds that he found one other person on the Internet who had experienced the same problem.
- Matt Bell installed the rollup on a Dell Latitude notebook. After rebooting, the video changed itself back to standard VGA and would present no other options. After removing the rollup, the video options returned. The solution was to update the notebook’s BIOS and then reapply the security rollup.
- Rich Lemley from the Journal Times in Wisconsin says that his IT group successfully deployed the security rollup without encountering any problems.
More About Installing Win2K SP2
A recent Knowledge Base posting indicates that an incorrect registry value causes the Windows 2000 Service Pack 2 (SP2) update.exe utility to generate an access violation, which prevents the SP2 installation from completing successfully. According to Microsoft article Q301556, the Update utility expects the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Currentversion\Setup\Drivercachepath to contain the default value entry %SystemRoot%\Driver Cache. If you change this key to another value before you install SP2, Update fails. To eliminate the problem, restore the registry key's default value.
SP2 Corrupts IE 5.5 On Multilanguage Win2K Systems
If you're building Windows 2000 Multilanguage systems, you’ll encounter problems with Internet Explorer (IE) 5.5. after you upgrade to Win2K Service Pack 2 (SP2). When you reboot and start IE from the Start menu, IE quits immediately and displays an error message, and the desktop closes and restarts. During the SP2 upgrade, Setup uses file versioning to determine whether it should replace a file by comparing the version of the file that's already installed with the service pack version of the file. The service pack installation downgrades certain system files that explorer.exe relies on for correct operation and that IE 5.5 had previously updated.
Microsoft article Q301416 documents several workarounds for this problem. You can set the language to English before you install the service pack or you can reinstall IE 5.5 after the service pack update finishes. If you’re updating many systems, neither of these workarounds is practical. To solve the problem permanently, install the new version of update.exe released on June 13. You need to call Microsoft Support to obtain this bug fix.
Mrxsmb Event Log Error Messages
My Windows 2000 event logs are heavily populated with messages from the Win2K component Mrxsmb. Apparently, the Win2K redirector has as many problems as the old Windows NT 4.0 redirector. Here’s just one example: When a client saves a new file in an offline folder, the client might see the error message
"An error occurred while reconnecting (drive letter) to \\computer name\\share nameMicrosoft Windows Network: The local device name is already in use. This connection has not been restored."
According to Microsoft article Q303339, Win2K correctly saves the file (i.e., the error message is erroneous, and you can safely ignore it). I’ve seen this exact error message repeatedly when attempting to map a network drive, so I suspect there are numerous conditions under which the redirector issues these messages. Microsoft released a new version of OS components Mrxsmb and Rdbss.sys on August 3 that (in theory) eliminate the problem.
Offline File Synchronization
This problem is a wee bit complicated. Assume that you set up client-side caching with a shared root drive (i.e., the system caches client files on a share at the root of a drive instead of in a lower directory). Then you disconnect the client from the network and change both the server and the workstation versions of synchronized files. When you reconnect the client to the network, Windows 2000 overwrites all changed files with the server version without first prompting you to select the version that you want to restore. Microsoft article Q292506 indicates that Win2K operates this way to prevent synchronization of hidden and system folders (e.g., Recycle Bin and System Volume Information) that are typically located on a drive root. You can avoid this problem by setting up client caching at a lower level on a hard disk. Alternatively, if you want to cache files at the root of a drive, you can ask Microsoft Support for the new version of cscui.dll released on May 8.
Intermittent Failures Browsing AD From a Multihomed System
I’ve encountered one aggravating Directory-browsing error in a Windows 2000 domain. I experience this problem on a Win2K Server machine (not a domain controller—DC) that has two network adapters—one connected to the LAN and one connected to the Internet. This server runs RRAS, Network Address Translation (NAT), and firewall software. I’ve added firewall rules for Lightweight Directory Access Protocol (LDAP), EPMAP, Microsoft Directory Service (DS), and all the other protocols that Win2K requires for communication. From this multihomed server, I can browse the entire network and see the standard shares on Win2K DCs and Windows NT 4.0 BDCs. When I attempt to browse the Directory, the process hangs, and I have to wait quite a while after pressing End Task in Task Manager to kill the lookup operation.
It’s natural to assume that the firewall is disabling access to the Directory. In fact, when I disable the firewall, I can browse the Directory. If I then enable the firewall, I can continue to browse the Directory for some time. In addition, if the firewall was preventing access to the Directory, other Win2K systems would experience the same problem. I can browse the Entire Network and the Directory from other Win2K systems on the network, so this problem appears local to the multihomed server.
The Knowledge Base has numerous articles about intermittent failures when browsing the Directory on multihomed systems, but most of the articles address this problem on Win2K DCs, not standalone servers. In my opinion, this problem is related to a system with multiple network adapters, regardless of the role the system plays. I’m still researching the multihome issues and I’ll pass on the results, hopefully with a solution, next week.
