SideBar    UNC Identifies Network Resources

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_MACHINE\SYSTEM\CurrentControlSet\Services\Mup\DisableDFS 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:

  • Broadcast node (b-node), which instructs the NT Client system to use only broadcast messages for name resolution
  • Point-to-point (p-node), which instructs the NT Client system to use only WINS queries for name resolution
  • Mixed node (m-node), which instructs the NT Client system to first use broadcasts and then WINS queries if the broadcasts fail
  • Hybrid node (h-node), which instructs the NT Client system to first use WINS queries and then broadcasts if the WINS queries fail

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_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\NodeType 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:

\Registry\Machine\System\CurrentControlSet\Services\NetBT\Parameters 
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.

End of Article

Prev. page     1 [2]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Congratulations on an excellent magazine. It’s on my must-read list, and I recommend it to all aspiring Windows NT engineers. Craig Zacker’s “Multiple UNC Provider: NT’s Traffic Cop” (May) was very informative but too late for me. I went through the ordeal last year. My client had the extremely slow NetWare browsing symptom the article mentioned, and incredibly slow logon times. Approximately 1000 users had to wait 3 minutes to 4 minutes to log on. Last year, obtaining the updated mup.sys file from Microsoft was like pulling teeth. I had to talk with a technical director before the company emailed me the new file. Because my client couldn’t afford to have 1000 users losing productivity, I created a temporary solution: an lmhosts file with mock IP addresses for the NetWare servers that all the PCs had to preload into memory (look at the LMHosts.sam file to see how to do that). This setup made the Microsoft redirector respond right away to Multiple Uniform Naming Convention Provider (MUP). The solution wasn’t clean, but it got all the users up and running. After I received the updated mup.sys file, I removed the lmhosts file and everything worked great. I used the Cognet (http://www.cognet.com) software distribution application, and the changes were easy and completely automated.<br> --Nick Krishnani

Nick Krishnani

Excellent!!!

Anonymous User

Article Rating 5 out of 5

 
 

ADS BY GOOGLE