Solving XP SP1 Network File Errors

In response to last week’s article about the ever-morphing redirector components, reader Phil Rupp wrote to tell me that Windows XP Service Pack 1 (SP1) clients on his network experience consistent problems accessing files stored on a Windows 2000 server. He wonders whether the two redirector components might be the problem. Rupp first noticed the problem after upgrading XP systems to SP1. After the upgrade, XP clients encountered a variety of error messages when trying to access remote files. Messages include slow performance messages, notification that files are corrupt or already open by another user, or messages that state the file is no longer available. Rupp noted that clients encounter these errors in a variety of applications, but only when accessing files hosted on a Win2K system.

According to Microsoft, the connectivity problems aren't related to multiple versions of the redirector code but do involve the Server Message Block (SMB) protocol. The Microsoft article "'File or Network Path No Longer Exists' or 'No Network Provider Accepted the Given Network Path' Error Message When You Copy or Open Files in Windows XP SP1 at http://support.microsoft.com/default.aspx?scid=kb;en-us;q329170 states that the client errors are the result of a bug in how the Win2K system hosting the shared resource processes signed SMB packets from an XP SP1 client. The protocol bug produces many error messages in a variety of circumstances. Clients might also experience delays accessing a remote file, and in some cases, hang and need to be restarted.

So how widespread is the problem? SMB signing is active by default on Win2K domain controllers (DCs). If you don’t replace or modify the Default Domain Controllers Group Policy Object (GPO), all Win2K DCs have SMB signing enabled. The protocol bug causes XP SP1 clients to encounter errors accessing any file hosted on a DC, including logon scripts, GPOs, and files accessible from a network share. You can enable SMB signing on generic Win2K servers with either a GPO or a registry edit. If you enable this feature on servers, clients experience the same connectivity problems when they attempt to connect to shared resources on such servers.

Here are some of the symptoms XP SP1 clients exhibit when SMB signing is causing problems:

To correct this problem, call Microsoft Product Support Services (PSS), quote reference article Q329170, and ask for the fix that addresses the problem. The patch corrects SMB processing errors in eight OS components, including localspl.dll, printui.dll, spoolss.dll, spuninst.exe, srv.sys, srvsvc.dll, winspool.drv, and wlnotify.dll. The files have a release date of October 10. You must install this patch on all WinK servers that host remote shares for XP SP1 clients.

To temporarily work around the problem, you can disable SMB signing on servers that host resources for XP SP1 clients. To do so, you need to modify the Default Domain Controllers policy, a built-in policy that applies to all DCs. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. Right-click the Domain Controllers organizational unit (OU), and click Properties. Click the Group Policies tab, select the Default Domain Controllers Policy, then click Edit. Expand the keys and navigate to Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options. Here, you will find four of Win2K’s SMB signing options, including

A default DC installation enables the last option, "Digitally sign server communication (when possible)." You turn off SMB signing on a DC by disabling this feature. If the last option isn't enabled, check the settings for the other three options and disable every enabled SMB option. At this point, you can wait 5 minutes for the automatic Group Policy refresh cycle, or you can manually refresh the policy on each DC with the command secedit/refreshpolicy machine_policy/enforce. The Microsoft article "Network File Errors Occur After You Install Windows XP SP1" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q331519 documents this workaround.