MUP.SYS Causing slow performance for NWClient
(Last modified: 27Dec2002)
This document (10026063) is provided subject to the disclaimer at the end of this document.
fact
Novell Client 4.8 for Windows NT/2000
symptom
MUP.SYS Causing slow performance for NWClient
Slow performance, Hangs, timeouts
fix
This document only applies to workstations running Microsoft Windows NT and the Novell Client for Windows NT. It does NOT apply to workstations running Microsoft Windows 3.x, 95, or 98.
NT NETWORK ARCHITECTURE OVERVIEW:
NT allows applications to retrieve and store information on hard drives using a "File System". Common examples of the different File Systems for NT are FAT, NTFS, and CDFS. If the file system is remote (as opposed to local), then the OS will use a "Provider" as the interface between the files/directories and the OS. For network File Systems, the File System support is implemented as part of the Network Provider (NWFS in the case of the Novell Client for Windows NT). They are responsible for interacting with core OS components such as the MUP.SYS (Multiple UNC Provider) as well as knowing how to retrieve/store information on their remote File Systems.
The Operating System stores all file locations as UNC (Universal Naming Convention) paths. When an application makes a request for a UNC location, the OS must determine what Network Provider the file system location belongs to. The first 2 entries in the UNC path are the Server and Share\Volume where file location exists. The OS stores a Network Provider Order and a Print Provider Order that is used when searching for a new \\Server \[Share/Volume] location. When a \\Server\[Share/Volume] request is issued, the MUP will sequentially pass the request to each of the Network Providers in the Network Provider Order . The network provider is responsible to either indicate that the resource is locatable through them or that it is not locatable by them. If it is not locatable by this network provider, the MUP will pass the request to the next provider in the list. The MUP will not pass the request to the next Network Provider until it has heard from the previous Network provider.
All \\Server\[Share/Volume] pairs that the MUP locates will be stored in a MUP cache for 15 minutes, so once a drive mapping or other operation is complete, the MUP will not need to relearn the network provider for this location unless all file connections to this \\Server\[Share/Volume] are lost for 15 minutes.
The Network Provider order can be accessed under Control Panel/Network/Services/Network Access Order. This document focuses on the Network Provider Order, but the same issue also exists with the Print Provider Order and this order can be changed in the same location as the Network Provider Order. The corresponding registry keys for the NT Network Provider Order and Print Provider Order are:
Key:
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\NetworkProvider\Order
Value:
ProviderOrder : REG_SZ : "NetWareWorkstation,LanmanWorkstation"
Key:
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Print\Providers\
Value:
Order: REG_MULTI_SZ : "Novell Distributed Print Services | NetWare Print Services | LanMan Print Services"
The following additional explanation comes from TID 2928430:
"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."
DOCUMENTED MUP.SYS PROBLEM:
There is a problem with the MUP.SYS that shipped with NT 4.0, NTSP1, NTSP2, and NTSP3. It would read the registry key for both the Network or Print Provider Order, but would not return a handle back to the application until it heard from all Network Providers in the list. This means that the Microsoft Network Provider would have to time out and pass back a failed to find message to the MUP.SYS every time an attempt was made to locate a NetWare resource. The Microsoft Network Provider will take between 3 to 13 seconds for each of these attempts (depending if WINS, DNS, and NetBIOS are configured). Whereas the Novell Network Provider will typically only take 1 to 3 seconds for an attempt to locate a Non-NetWare resource. Also many of the attempts to locate a Microsoft Network resource are WNET API calls made with the provider specified (an example of this would be all Microsoft Network authentication attempts). In these cases, the MUP is bypassed altogether as the request is handed directly to the Network Provider, so the request would never be handed to the Novell Network Provider even if the Novell Network Provider is configured as the Primary Network Provider (first in the list).
The following additional explanation comes from TID 2928430:
"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."
EXAMPLES OF WHAT THE PROBLEMATIC MUP.SYS CAN CAUSE:
The most common symptom of the MUP.SYS problem is slow logins/authentication to a NetWare server (can be 10-30 minutes instead of 1-3 minutes).
Normally the MUP.SYS problem will only extend the login by 1-2 minutes. However, when the Microsoft Network Provider is able to resolve the NetWare Server name using NetBIOS, WINS, or DNS, the time to login will increase by 10-30 minutes (depending on how many NetWare UNC Paths are being resolved). The most common reasons why the Microsoft Network Provider is able to resolve a Server name that is a NetWare server are:
1. An NT Network device has the same name as a NetWare Server or an NDS Tree.
2. The NetWare Servers are registered in DNS by their Server Name and have the same DNS Domain name as the NT Workstation/Server (i.e. The NetWare File Server NDS1 is registered as NDS1.Company.Com and the NT Workstation is registered as NTWS.Company.Com. The Microsoft Network Provider running on NTWS will consider the Server name NDS1 as a valid Microsoft Network Resource if they try to resolve using DNS).
If the Microsoft Network Provider can resolve the Server name in the UNC (i.e. found a DNS entry for the NetWare server), then it will then try to authenticate to it as a Microsoft Network resource using RPC. The request will eventually fail by timing out, but then the Microsoft Network Provider will back off and try again repeatedly before sending a "failure to locate" back to the MUP.SYS. This will cause a significantly longer login time than if it simply fails to locate a Microsoft Network resource using DNS, WINS, or NetBIOS with the Server name from the UNC.
The MUP.SYS problem will occur whenever a \\Server\[Share/Volume] UNC pair are passed to the MUP.SYS and it does not exist in the MUP Cache. Other frequent times this occurs include launching an application, issuing a manual map command from the generic Explorer Map utility, and using any application that initiates a connection to a new UNC.
SOLUTION
Microsoft has released a fixed MUP.SYS that resolves this problem by properly reading the registry keys for the Network and Print Provider Orders. The following is a list of MUP.SYS file information for versions that are know to CAUSE the problem:
Date Size Time Notes
08/09/1996 67,280 bytes 01:30:00 AM Initial MUP.SYS that shipped with NT 4.0
04/30/1997 67,568 bytes 10:00:00 PM From NTSP3
The following is a list of MUP.SYS file information for versions that are known to FIX the problem:
Date Size Time Notes
08/04/1997 67,632 bytes 02:41:14 PM From a Hotfix given out by MS regarding Q171386
10/15/1998 67,696 bytes 12:04:00 PM From NTSP4.
document
| Document Title: | MUP.SYS Causing slow performance for NWClient |
| Document ID: | 10026063 |
| Solution ID: | 1.0.53558236.2523943 |
| Creation Date: | 02Feb2000 |
| Modified Date: | 27Dec2002 |
| Novell Product Class: | NetWare Novell eDirectory |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.