Windows XP SP1 SMB Hotfix Update
Last week, I described two patches you can apply to Windows XP Service Pack 1 (SP1) and Windows 2000 systems to eliminate XP errors when you access files hosted on a Server Message Block (SMB)-enabled Win2K server. Readers in the United States, France, Sweden, Australia, and Slovenia wrote to tell me that the XP security hotfix MS02-070 (see Microsoft Security Bulletin MS02-070—Flaw in SMB Signing Could Enable Group Policy to be Modified) won't install on XP SP1 systems. Each reader encountered the same Setup error message during the installation: "The Service Pack version of the system installed is newer than the update you are applying to it. You can only install this update on a computer with no service packs installed."
After some time-consuming research, I've concluded that the security hotfix is faulty and the documentation in the Microsoft article "Flaw in SMB Signing May Permit Group Policy to Be Modified" is incorrect. Here are the facts I uncovered:
- Microsoft first released XP SP1 on October 2, 2002, and updated the service pack on October 25, 2002.
- In the XP gold release, srv.sys is version 5.1.2600.0; the XP hotfix I downloaded contains srv.sys version 5.1.2600.105 with a file release date of October 31.
- Microsoft released security hotfix MS02-070 on December 11, 2002. The documentation states that the hotfix contains the file srv.sys with a release date of October 31, 2002. Because the file release date of October 31 postdates both SP1 releases, it's unlikely that the hotfix version of srv.sys file is included in SP1.
The security hotfix probably contains either an out-of-date version number or a bad catalog entry. Either of these problems will prevent setup from installing the hotfix. At some point, Microsoft will likely release the hotfix that corrects the SMB negotiation problem, closes the group policy vulnerability, and eliminates the file access errors; I'm just not sure when this event will occur. The XP hotfix disappeared today, so I suspect Microsoft is working on the problem.
Win2K SP3 and SP2 Terminal Services Bug Fix
In spite of the fact that Win2K SP3 introduces a much-improved Win2K Server Terminal Services client-licensing model and corrects numerous problems with Terminal Services clients, the userinit.exe module in SP3 and SP2 systems might fail when a user logs on as a Terminal Services client. Microsoft offers no explanation for why this failure occurs and doesn't provide either an error message or an estimate of how often this component fails. If you experience this problem on your terminal servers, call Microsoft Product Support Services (PSS) and ask for the fix that corrects this problem. The patch updates two Terminal Services modules, printui.dll and wlnotify.dll, and both files have a release date of November 1, 2002. The Microsoft article "Userinit.exe May Stop Working in Windows 2000" documents this problem.
Win2K SP3 Msgina Startup Error
When Win2K boots, the startup process activates services in a specific order. When one service requires the features in another service, the second service is said to be dependent on the first service. If the first service isn't yet fully initialized and running, the dependent service can't start. In Win2K SP3, Microsoft introduced a new service dependency in the Microsoft Graphical Identification and Authentication (GINA) DLL, Msgina.dll. Msgina activates when a user logs on. The Winlogon component presents the logon screen and calls msgina.dll to accept and authenticate the user's credentials. Msgina now depends on the multiple provider router, mpr.dll, and can't start until after the mpr code is operational. A timing problem specific to Win2K SP3 can prevent the mpr code from starting before a user logon.
When this timing problem occurs, you'll see an error message when you attempt to log on to an SP3 system. In this case, an SP3 system might fail with the error message "User Interface Failure: The Logon User Interface DLL msgina.dll failed to load. Contact your system administrator to replace the DLL, or restore the original DLL." PSS has a fix for this problem that corrects the service startup sequence, a new version of msgina.dll with a file release date of October 15, 2002. The Microsoft article "Msgina.dll Does Not Load in Windows 2000 Service Pack 3" documents this problem.
Unusual Win2K SP3 SMB Error
Here's an SMB protocol problem that can produce the error message "The network BIOS command limit has been reached" on Win2K SP3 systems that manage multiple concurrent requests from the same Win2K client. The maximum number of outstanding requests between a client and a server is determined when the client/server session is negotiated. Two registry values, MaxCmds and MaxMpxCt, set limits on the number of concurrent connections between the two systems. On the client, MaxCmds defines the maximum number of network control blocks, and thus the maximum number of concurrent connections the client can manage. On the server, MaxMpxCt controls the maximum number of outstanding requests to one client.
By default, both values are set to 50, which means a server should be able to handle 50 concurrent requests from the same client without a problem. However, if you have tweaked these values to improve network performance, a server managing 50 or more concurrent requests will produce the network BIOS error when either of these entries is lower than 50. See the Microsoft article "Error Message: The Network BIOS Command Limit Has Been Reached" for instructions about how to locate and modify the registry values that control concurrent SMB connections.
