Multiple UNC Provider: NT's Traffic Cop

Alter MUP's behavior or NT's configuration to avoid network access delays

Jane and Joe are eager to get working, so they log on to their Windows NT workstations. Jane decides to work on a file stored on a NetWare server, and Joe decides to print a document on a nearby NetWare printer. To Jane's and Joe's dismay, their systems freeze as they try to access those NetWare resources. After about 30 seconds, the systems grant them access and seem to run flawlessly. Then, 15 minutes later, the same delay occurs again.

If you have a mixed network with systems running the NT Client for Microsoft Networks and Novell's intraNetWare Client for Windows NT, this scenario might sound all too familiar. If you analyze your network's traffic, the analysis will likely reveal that communication difficulties between the client and server are not causing these delays. Instead, you will probably find that the delays are originating in the client system, which seems to pause for several seconds before initiating communication with the NetWare server. Because the delays occur only when users access NetWare resources, you might attribute the problem to a bug in the intraNetWare Client software. But this software is not the culprit. If you remove the NT Client for Microsoft Networks (and any other installed clients) from the system and leave only the intraNetWare Client for Windows NT installed, the delays will disappear, which means that the delays are resulting from having multiple network clients installed on the system.

So what can you do to eliminate these delays? You first need to understand how the Multiple Uniform Naming Convention Provider (MUP), NT's traffic cop, works. You then need to alter MUP's behavior or change NT's configuration.

How MUP Works
When you're working on an application in a mixed NT-NetWare network, you can open files on local drives, on NT network shares, or on NetWare server volumes. Redirectors and MUP (mup.sys) make that process possible.

Both the NT Client for Microsoft Networks and the intraNetWare Client for Windows NT include a module called a redirector. (Other clients that you install on an NT network will also have a redirector.) As the name implies, the redirector redirects a resource request from the NT workstation to the device on the network that can provide that resource.

For example, suppose you select a file from a directory on another system. NT notates that file in Uniform Naming Convention (UNC) format and passes the notation to a redirector. The redirector then transmits the UNC resource request (i.e., the file request) over the network to the system that hosts that file.

For this process to work, NT must tell the difference between UNC names that refer to NT network shares and UNC names that refer to NetWare volumes. (For more information about the differences, see the sidebar, "UNC Identifies Network Resources.") Differentiating between NT and NetWare UNC names is MUP's responsibility. MUP determines which client the system must use to access the requested UNC name and hands off the request to that client's redirector. All applications that use UNC names for their I/O requests require MUP's services. (NT's Multi-Protocol Routing­MPR­handles requests from applications that use Win32 network API calls.)

After MUP receives a UNC request from NT's I/O Manager, MUP determines which of the installed redirectors provides access to the requested resource. MUP uses a five-step trial-and-error process to make this determination:

This process has several problems that can cause network access delays. First, MUP's attempt to send the UNC request to DFS wastes valuable seconds if the network doesn't use DFS. Second, MUP sends the request to each redirector sequentially (not simultaneously), so MUP wastes time awaiting the response from one redirector before querying another. Finally, MUP wastes time waiting for the responses from all redirectors. Even if the first redirector that MUP queried will receive the request, MUP waits for responses before selecting the request recipient.

Waiting for the responses from all the redirectors is the primary source of access delays. For example, suppose the UNC request identifies a NetWare resource. MUP will always query the NT Client redirector, even if MUP queries the intraNetWare Client redirector first. MUP therefore sends the request to the NT Client redirector and waits for it to fail.

Unfortunately, the NT Client redirector diligently tries to locate the share that the UNC name specifies. It uses all the NetBIOS name resolution mechanisms at its disposal. If your NT Client system uses Windows Internet Naming Service (WINS), the NT Client redirector sequentially queries the primary and secondary WINS servers, which takes about 4 seconds. When WINS fails to resolve the UNC name (which identifies a NetWare server, not a NetBIOS name), the NT Client system resorts to broadcasting NetBIOS name query request messages. This attempt to resolve the UNC name also fails, so the system retransmits the broadcast message four times, with each message taking as long as 4 seconds to time out. Depending on your NT Client system's configuration, other name resolution procedures might add more time to the delay, bringing the total to as many as 30 seconds. (For more information about NT's name resolution processes, see Mark Minasi, "Advanced WINS Features" and "WINS Proxy Agents," September and October 1997.)

Therefore, although MUP already possesses the information it needs to pass the UNC request to the NetWare redirector, MUP remains idle, waiting for a response from the NT Client redirector. The delays occur only when users access NetWare resources, because the NT Client redirector usually locates NT resources quickly with the first WINS query or broadcast message. Thus, time isn't lost requerying WINS or retransmitting broadcast messages.

After MUP sends the request to the NetWare redirector, MUP stores the resource's location in MUP's cache, where MUP can quickly access the information to satisfy repeated requests for the same UNC name. However, every 15 minutes, MUP purges its cache. The entire process then must begin again, which explains the periodic delays.

Alter MUP's Behavior
The best way to prevent NetWare access delays is to alter MUP's behavior. Microsoft has a revised version of the mup.sys file (with the same name) that replaces the module that ships with Windows NT 4.0. In the revised version, MUP doesn't require a response from all redirectors before it selects the appropriate client for a UNC request. After MUP receives a positive response to a UNC request from the client with the highest priority, MUP passes the request to that client without querying the other redirectors. Thus, if you select NetWare in the Network Access Order setting, the NetBIOS name resolution processes will not delay access to NetWare resources.

Unfortunately, Microsoft has not released the revised mup.sys file as a hotfix, but Microsoft will include this file in Service Pack 4 (SP4), which might be available by the time you read this article. Until then, you can call Microsoft's technical support to obtain the file. Reference document Q171386 when you request the file. On request, Microsoft will refund the charge for the technical support incident if you state that MUP was causing access delays in your network.

Change the NT Client System's Configuration
If you don't want to replace the mup.sys file but you want to reduce network access delays, you can make two configuration changes to the NT Client system. First, you can disable the DFS query if your network doesn't use DFS. Disabling DFS will eliminate the delay that MUP's DFS check causes.

To disable DFS, you can add (or modify) the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMupDisableDFS Registry entry. Then set the REG_DWORD value to 0. If you later want to implement DFS on your network, change the value to 1 to enable DFS.

Another way you can reduce the network access delays is to change your NT Client system's node type. The node type of a TCP/IP-based NT network system specifies the mechanisms that the NT Client uses to resolve NetBIOS names. NT has four types of nodes:

Because the NT Client redirector's name resolution process will fail when the UNC name refers to a NetWare resource, you want to make that process as brief as possible, without sacrificing the NT Client's functionality. If your network relies on WINS servers for name resolution, NT automatically configures your NT Client as an h-node. However, in a proper WINS installation, the NT Client rarely uses the broadcast fallback mechanism. Therefore, you can reconfigure your NT Client as a p-node. Because p-nodes don't use broadcast transmissions, you eliminate the cause of MUP's longest delay.

To change your client's node type, you can use Dynamic Host Configuration Protocol (DHCP) to modify the TCP/IP client configuration parameters. Both NT Server and intraNetWare include DHCP servers that can configure a client as a p-node. DHCP is especially useful if you have more than one client system to modify, because it automates the reconfiguration process. When you use a DHCP server to configure the node type, the server automatically creates a DHCPNodeType key in the Registry with the appropriate value, as specified by the DHCP administrator.

If your NT system does not use DHCP, you can change your NT Client's node type by creating the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetBTParametersNodeType Registry entry. The REG_DWORD values for the NodeType key are 1 for b-node, 2 for p-node, 4 for m-node, and 8 for h-node, so you need to set the value to 2. The NodeType key performs the same function as the DHCPNodeType key. When the NodeType key and DHCPNodeType key are present, the value for NodeType key takes precedence over the value for the DHCPNodeType key. Thus, you can override the DHCP node type setting by manually adding the NodeType key to a client system.

You can use the regini.exe utility in the Microsoft Windows NT Server Resource Kit to automate the NodeType key Registry modification. This command-line utility uses a script file to perform Registry changes. For the NodeType key modification, you need to create an ASCII text file called pnode.ini that contains two lines:

RegistryMachineSystemCurrentControlSetServicesNetBTParameters NodeType = REG_DWORD 0x00000002

You must place the pnode.ini and regini.exe files in a shared network directory. Then you can use a batch file or logon script to execute the following command from that directory at each workstation you want to modify:

regini pnode.ini

The next time you restart the system, the NT Client will operate as a p-node. You can verify the client's node type by executing this command:

ipconfig /all

As you must with all Registry modifications, back up your system before making any changes, and be careful to avoid typographical errors.

Take Action
If you have a mixed network, don't let the MUP traffic cop bring your network traffic to a screeching halt. You can alter the traffic cop's behavior by installing the revised mup.sys file, or you can change your NT Client's DFS and node type configurations. Either course of action will help network traffic flow smoothly.