Multiple Redirector Support

Applications can examine or access resources on remote systems in two ways. One way is by using the UNC standard with Windows functions to directly address a remote resource; a second way is by using the Windows Networking (WNet) API to enumerate computers and resources that those computers export for sharing. Both these approaches use the capabilities of a redirector to find their way to the network. (CIFS is described in Chapter 12.) As we stated earlier, to access CIFS servers from a client, Microsoft supplies a CIFS redirector, which has a kernel-mode component called the redirector FSD and a user-mode component called the Workstation service. Microsoft also makes available a redirector that can access resources shared by Novell NetWare servers, and third parties can add their own redirectors to Windows. In this section, we'll examine the software that decides which redirector to invoke when remote I/O requests are issued. Here are the responsible components:

• Multiple provider router (MPR) is a DLL (\Windows\System32\Mpr.dll) that determines which network to access when an application uses the Windows WNet API for browsing remote file systems.

• Multiple UNC Provider (MUP) is a driver (\Windows\System32\Drivers\Mup.sys) that determines which network to access when an application uses the Windows I/O API to open remote files.

Multiple Provider Router

The Windows WNet functions allow applications (including the Windows Explorer My Network Places) to connect to network resources, such as file servers and printers, and to browse the contents of any type of remote file system. Because the WNet API can be called to work across different networks using different transport protocols, software must be present to send the request correctly over the network and to understand the results that the remote server returns. Figure 13-13 shows the redirector software responsible for these tasks.

Figure 13-13. MPR components

A provider is software that establishes Windows as a client of a remote network server. Some of the operations a WNet provider performs include making and breaking network connections, printing remotely, and transferring data. The built-in WNet provider includes a DLL, the Workstation service, and the redirector. Other network vendors need to supply only a DLL and a redirector.

When an application calls a WNet routine, the call passes directly to the MPR DLL. MPR takes the call and determines which WNet provider recognizes the resource being accessed. Each provider DLL beneath MPR supplies a set of standard functions collectively called the provider interface. This interface allows MPR to determine which network the application is trying to access and to direct the request to the appropriate WNet provider software. The Workstation service's provider is \Windows\System32\Ntlanman.dll, as directed by the ProviderPath value under the HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\ NetworkProvider registry key.

When called by the WNetAddConnection API function to connect to a remote network resource, MPR checks the HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder\ ProviderOrder registry value to determine which network providers are loaded. It polls them one at a time in the order in which they're listed in the registry until a redirector recognizes the resource or until all available providers have been polled. You can change the ProviderOrder by using the Advanced Settings dialog box, shown in Figure 13-14. (Only one provider is installed on the system from which the screen shot was taken.) If you have Windows 2000 or a Start menu configured in its Classic setting, this dialog box is accessible from the Advanced menu of the Network Connections folder. You can access the Network Connections folder by right-clicking the My Network Places icon on the desktop and selecting Properties from the pop-up menu or by selecting it from the Settings option from the Start menu. Another way to access the dialog box is to open Network Connections in the Control Panel, click the connection you want to view, and then click Advanced Settings on the Advanced menu.

Figure 13-14. The provider order editor

The WNetAddConnection function can also assign a drive letter or device name to a remote resource. When called to do so, WNetAddConnection routes the call to the appropriate network provider. The provider, in turn, creates a symbolic-link object in the object manager namespace that maps the drive letter being defined to the redirector (that is, the remote FSD) for that network.

Figure 13-15 shows the \?? directory on a Windows 2000 system (see Chapter 3 for information on the \?? directory), where you can see several driver letters representing connections to remote file shares. The figure shows that the redirector creates a device object named \Device\LanmanRedirector and that the additional text included in the symbolic link's value indicates to the redirector which remote resource the drive letter corresponds to. When a user opens X:\Book\Chap13.doc, the redirector is passed the unparsed portion of the path that resolves through the symbolic link, which is ";X:0\dual\e\Book\Chap13.doc". The redirector notes that the resource being accessed is located on the E share of server dual.

Figure 13-15. Resolving a network resource name

Like the built-in redirector, other redirectors create a device object in the object manager namespace when they are loaded into the system and initialized. Then, when the WNet or other API calls the object manager to open a resource on a different network, the object manager uses the device object as a jumping-off point into the remote file system. It calls an I/O manager parse method associated with the device object to locate the redirector FSD that can handle the request. (See Chapter 12 for more information on file system drivers.)

Multiple UNC Provider

The Multiple UNC Provider (MUP) is a networking component similar to MPR. It fields I/O requests destined for a file or a device that has a UNC name (names beginning with the characters \\, indicating that the resource exists on the network). MUP takes such requests and, like MPR, determines which local redirector recognizes the remote resource. Unlike MPR, MUP is a device driver (loaded at system boot time) that issues I/O requests to lower-layer drivers, in this case to redirectors, as shown in Figure 13-16. Mup.sys also contains the Distributed File System (DFS is described later in this chapter) client implementation. The DFS client is enabled by default and can be disabled by setting the HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\Mup\DisableDfs DWORD registry value to 1.

Figure 13-16. Multiple UNC Provider (MUP)

When MUP loads during the boot it creates a device object named \Device\Mup. When a network redirector, like CIFS, loads the redirector it creates a named device object (for example \Device\LanmanRedirector) and registers itself with MUP as an UNC provider by calling the function FsRtlRegisterUncProvider. If the redirector is the first one to register and MUP's DFS client support is disabled then FsRtlRegisterUncProvider creates a symbolic link name \??\UNC that points to the redirector's device object; otherwise MUP sets up the symbolic link name \Global??\UNC (\??\UNC on Windows 2000) to point to its own device object, \Device\MUP.

The MUP driver is activated when an application first attempts to open a remote file or device by specifying a UNC name (instead of a redirected drive letter, as described earlier). When the Windows client-side DLL Kernel32.dll (which is the DLL that exports file-I/O-related APIs) receives a file I/O request with UNC paths, the subsystem appends the UNC path to the string \Global??\UNC and then calls the NtCreateFile system service to open the file.

If there is one registered network provider \Global??\UNC resolves to the device object representing the driver and that driver handles the request. If there are multiple registered providers \Global??\UNC resolves to \Device\MUP and MUP must determine which provider should process the request.

When the MUP driver receives an I/O request and the DFS client is enabled MUP first determines if the path references a DFS path (DFS paths are also UNC formatted) and, if so, processes the I/O request itself. If the DFS client is disabled or the path is not a DFS path then MUP uses the HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder registry value to determine priority order of the network providers that registered with it using FsRtlRegisterUncProvider. It polls them one at a time in the order in which they're listed in the value until one of them indicates that it recognizes the path or until all available providers have been polled. MUP ignores those redirectors that are listed in the registry key but not registered. When a redirector recognizes a path the redirector indicates how much of the path is unique to it. For example, if the path is \\WIN2K3SERVER\PUBLIC\Windowsinternals\Chap13.doc, the redirector might recognize it and claim the prefix \\WIN2K3SERVER\PUBLIC as its own. The MUP driver caches this information and thereafter sends requests beginning with that prefix directly to the redirector, skipping the polling operation. The MUP driver's cache has a timeout feature, so after a period, a prefix's association with a particular redirector expires.