On Microsoft Windows NT Workstation/Server version 4.0, a delay may be seen during an initial connection attempt to a network resource from a system with multiple redirectors installed. Such as a 20-30 Second Pause during printing for the first time and after not printing for 15 minutes.

Several customers have recently reported performance issues when running the intraNetWare Client for Windows NT. The majority of these issues are caused by the way a Microsoft driver named MUP.SYS functions. Microsoft has an updated MUP.SYS that is available to customers, but customers currently have to contact Microsoft to get the updated driver. Customers experiencing performance issues should call Microsoft and reference Q171386. With this reference, Microsoft will instruct customers where to download the updated MUP.SYS driver.

Microsoft has chosen not to release this patch into "hotfix" form at this time. A "hotfix" patch is a patch that is available on the web but is not officially supported by Microsoft. They are planning on including the updated MUP.SYS in the next NT Service Pack (Service Pack 4). Microsoft will be persuaded to release the patch into "hotfix" form, where customers will be able to download it from the web without having to contact Microsoft, if a significant number of customers call them. If you have any customers that are experiencing performance issues with the intraNetWare Client for Windows NT this update will most likely resolve their problem.

When a non-WNET API initial UNC connection attempt is made to a network resource from a system with multiple redirectors, The Windows NT system sends the request to the MUP to identify which redirector should handle the request.

The MUP first establishes whether DFS (Distributed File System) is in use and passes the request to DFS. The MUP then checks it's internal cache to see whether the connection had been made previously. (Entries in the MUP cache are held for 15 minutes) The MUP then sends the request to each redirector that handles each request synchronously and attempts to identify a resource on the network that matches the request. Once all redirectors return, the MUP chooses (based on response and priority) which redirector the application will use.

The delays come from two locations. First, the attempt to access the resource via DFS, secondly, the MUP must wait and accept all responses from all redirectors before completing the request. So if a resource is readily available and accessible over one redirector, the request must still be made over the other installed redirectors before the request completes.

Depending on the number of redirectors, protocols, and timer configurations for connectivity, these delays can exceed 13 seconds per initial connection.

The NetWare Redirector will be used as an example.

The following illustrates an initial UNC connection attempt:
------------------------------------------------------------

Application makes UNC request
           |
           |
DFS is checked and request is processed if enabled.
           |
           |
MUP then checks MUP cache for recent connection.
           |
           |
MUP then makes query to first Redirector (NetWare) ---> First redirector returns (The return is immediate as NetWare uses only IPX and the calls are fast)
           |
           |
MUP sends request to second Redirector (Microsoft) ---> Second redirector returns (The delay for the Microsoft Redirector depends on the protocols installed. With TCP\IP delays exists as the resource name is queried via WINS, Broadcasts, LMHOSTS, DNS, etc. The default delay for an H-Node client is 13 seconds.) (A priority is assigned to each redirector queried so if both redirectors return successfully, the priority is used to designate which redirector takes the request.)
           |
           |
The handle to the resource is returned to the application based on the MUPs decision.

If the applications request was made for a NetWare resource, the application would have to wait for the Microsoft Redirector to timeout before returning the handle to the resource.

Priority for the redirectors can be configured in Control Panel\Network\Services\Network Access Order.

A modification to the MUP has been made such that if the redirector with the highest priority is attempted first with a successful response, those redirectors with lower priorities are then bypassed, and the connection is made via the redirector with the highest priority.

Enabling this capability requires an updated MUP.SYS, and a modification to the registry entry DisableDFS.

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

The Windows NT registry entry for DisableDFS is located in

HKEY_LOCAL_MACHINE\SYSTEM
  \CurrentControlSet
   \Services
     \Mup

DisableDFS REG_DWORD

Range: 0 or 1
Default: 0 (Enabled)
 Set this value to 1

In summary, the slow performance issues that is addressed with the updated MUP from Microsoft is seen when a workstation has both the Novell intraNetWare Client for Windows NT and the Microsoft Client Services for Microsoft Networks loaded. One way a customer could test to verify that the performance issue they are seeing is in fact this MUP issue would be to remove all client services except for the Novell intraNetWare Client for Windows NT and see if the performance issue goes away. If the performance issue does in fact disappear, customers should call Microsoft and reference Q171386.

Search: slow performance issues issue