Functional Description of Windows Resource Sharing
Figure 16.1 shows the general arrangement of network drivers in Windows Server 2003. The network stack consists of the following major elements:
Figure 16.1. Network driver block diagram.
The applications at the top of the stack are not "applications" in the sense of spreadsheet or word processing programs. They are applications that make active network calls of one form or another. An email client application, for example, has a POP3 or an IMAP4 module that issues Winsock network calls to send and receive messages.
The network services that interact with network applications have two components:
A provider that runs in the user memory space. The provider exposes network services to network applications. Network providers come in the form of Dynamic Link Libraries (DLLs) that are loaded and managed by the Service Control Manager, Services.exe.
A redirector that runs in kernel space. This is a file system driver designed to communicate with a peer network service on another computer. The term redirector is a holdover from the early days of PC networking when network drivers intercepted DOS function calls and "redirected" them to the network interface. Network redirectors come in the form of SYS drivers running under the I/O Manager in the Windows Executive.
Providers and redirectors are paired together. For example, the LanMan Workstation provider is paired with the Mrxsmb.sys redirector driver.
Redirectors communicate with transport drivers via the Transport Driver Interface, or TDI. The TDI layer acts like a United Nations translator. The redirectors don't need to know details about the transports and vice versa. They simply talk through the TDI to each other.
Just as the file system drivers do not communicate directly with the transport drivers, the transport drivers do not communicate directly with the network adapter drivers. Instead, they communicate via the Network Driver Interface Specification (NDIS) driver, Ndis.sys. The NDIS driver and its helpers present a networking face to the transport drivers and a hardware communications face to the network adapter.
The hardware face communicates with the adapter via an NDIS MAC driver supplied by the vendor. MAC stands for Media Access Control. NDIS also provides interfaces for asynchronous communications over modems and ISDN lines via the Telephony API, or TAPI.
Let's take a brief look at each of the components of the Windows network stack to see how they interface with each other. This information is useful when resolving problems that involve system integration, failures in network communication, or performance enhancements. For instance, if you have multiple network providers, you can improve performance by placing them in the correct binding order in the stack.
Most Windows-based network applications use one of four API libraries to access network services. The function calls for these network services are contained in the network provider DLLs, discussed in the next section:
Most network applications use the Wnet API within Win32 to communicate between servers and clients. For example, the WnetAddConnection function call connects a network client to a share point on a server.
A pipe is an Interprocess Connection (IPC) method where two or more applications share the same memory and communicate with each other by manipulating the contents of that memory. A named pipe is a special form of pipe that contrasts with an anonymous pipe that has no name. Named pipes are commonly used by client/server applications such as database applications.
A mailslot is also an IPC, but one that is unidirectional rather than connection-oriented like named pipes. Windows applications generally use mailslots when sending broadcasts or unicasts. For example, NetBIOS-over-TCP/IP name registration uses mailslots.
Winsock stands for Windows Sockets. A socket is a form of IPC first introduced in Berkeley Software Distribution (BSD) UNIX. A socket consists of an IP address, a port number, and a flag indicating whether the socket represents a datagram or a communications stream.
(A fifth networking method, NetBIOS, is still supported even though NetBIOS applications are becoming very rare. See the sidebar, "NetBIOS Support.")
Network applications require an interface that can convert their network API calls into commands that can be understood by the network file systems in the Windows Executive. That is the role of a network provider.
Windows Server 2003 includes several network providers in the shrink wrap. It's instructive to know their names and the source libraries because you will see this information in Event log entries when something goes wrong. Take note of these providers:
For historical reasons, the Windows provider is called LanMan Workstation. The provider is part of Ntlanman.dll.
The NetWare provider is called NWCWorkstation. The provider code is contained in Nwwks.dll.
Remote Desktop provider.
This provider gives multiuser access to the server via the Remote Desktop Protocol (RDP). The provider code is contained in Rdpnp.dll. Citrix Metaframe loads an Integrated Computing Architecture (ICA) provider to support multiuser access from Citrix clients.
Web Client provider.
This is a new provider in Windows XP and Windows Server 2003. It is paired with the WebDAV redirector to give live file access (not just Puts and Gets) over HTTP. The provider code is contained in Davclnt.dll.
Windows provides both 16-bit (Winsock.dll) and 32-bit (Wsock32.dll) libraries that act as interfaces to the main 32-bit Winsock library, Ws_32.dll. This library supports both Winsock 1.1 and Winsock 2.0 applications.
There is a lot of misinformation about NetBIOS floating around the world of Windows network administration. For instance, many administrators believe (or have been told) that Windows networking is NetBIOS-based. This is not the case now and has not been the case for at least a decade.
NetBIOS is a set of functions built into the hardware of a PC. A NetBIOS application works by building a data structure called a Network Control Block (NCB) in memory then issuing a BIOS-based interrupt—interrupt 5C to be specific—that essentially turns the contents of the NCB over to a network driver for delivery to the controller on the NIC.
In Windows, applications are not permitted to talk directly to the hardware. If you run an old NetBIOS application, the 5C interrupt is intercepted by the operating system and turned over to the NetBIOS Emulator, a part of TDI.
The NetBIOS Emulator converts the NetBIOS function calls into TDI calls that can be carried by any of the three native transport protocols.
For more details about NetBIOS, see www.mcgrew.net/Training/NPS/nps-netbios.htm.
The Windows server has a small user-mode service, LanMan Server, that acts something like a provider. Its job is to create shares, communicate management information to the server file system running in kernel space, and support the legacy Browser service by registering the server with the browser database. LanMan Server has no separate DLL.
The Named Pipe and Mailslot network file system drivers do not require separate providers. Win32 handles these API calls and establishes connection to the proper network file system.
Theoretically, an application could be coded to communicate directly to the TDI, or even directly to the transport drivers themselves. These are rare birds because coding them requires intimate knowledge of the core networking APIs, something that is very difficult to come by outside of Redmond.
Most third-party NOS vendors implement Windows clients in the form of network providers. Examples include Novell's NetWare Core Protocol (NCP) provider, Transarc's Andrew File System (AFS) provider, and Sun's Network File System (NFS) provider.
Figure 16.1 does not show the print providers, but they would occupy the same location as the file system providers. Print providers are network applications, similar to but much more limited than full-fledged file system providers, that know how to communicate to printer services running on a remote machine. Windows Server 2003 comes with a variety of print providers. The major ones are as follows:
LanMan print provider.
This supports print requests coming from Windows clients.
Internet print provider.
This supports HTTP-based print requests from Windows or non-Windows clients.
NetWare print provider.
This supports printing to NetWare print servers. A different provider, installed with Services for NetWare (SFN), enables a Windows server to accept print jobs directed at it from NetWare clients.
Macintosh print provider.
This supports printing to Macintosh hosts via AppleTalk.
There is no network print provider for UNIX. This service is part of the Line Printer Daemon (LPD), Lpdsvc, which is loaded as part of Print Services for Unix, an optional component in Windows Server 2003.
Multiple Provider Router
Each provider that supports the Wnet API is linked to the Multiple Provider Router, or MPR. This simplifies programming because MPR gives a consistent to network applications.
When presented with a function call to pass a message to a particular server, MPR must choose the correct network provider. It does this by polling the providers to determine which one speaks the proper command language to talk to the target server. It polls based on the network provider order stored in these Registry entries:
Key: HKLM | System | CurrentControlSet | Control | NetworkProvider | Order
For print providers, the Registry entries are as follows:
Key: HKLM | System | CurrentControlSet | Control | Print | Providers
Data: NetWare or Compatible Network, LanMan Print Services, Internet Print Provider
If you have both a NetWare and Microsoft client loaded, you should always put the NetWare client at the top of the provider order. This is true even if the majority of your servers run Windows. The NetWare provider takes very little time to report back a failed connection. Microsoft providers, on the other hand, take their own sweet time thanks to all the browsing and name resolution that goes on in the background.
Multiple UNC Provider (MUP)
In addition to specific network client providers that interface directly with MPR, Windows Server 2003 has a general-purpose kernel-mode interface for applications that do not make network function calls but still need access to network resources. This access requires specifying the name and resource in Universal Naming Convention (UNC) format, so the general-purpose provider is called the Multiple UNC Provider, or MUP.
Here's how MUP works. If you use Notepad to open a file and you enter the path \\srv2\data\textfile.txt, Win32 recognizes this as a network path and passes the string to MUP, which parses the string to find the name of the server and the name of the shared folder then polls the network file system drivers, similar to the way MPR polled the providers, to find a driver that can contact the specified server.
Before polling the file system drivers, MUP checks the Distributed File System (Dfs) interface. If Dfs returns a positive response, it indicates that the UNC path is in a Dfs volume. At that point, MUP tests the link to the share at the host server. If the link is valid, MUP associates the UNC with the server that hosts the share. If there is no Dfs entry for the UNC, or MUP gets no response from the host server, it continues polling.
When MUP establishes an association between a UNC path and a network provider, it caches that association for subsequent transactions to the same server. For instance, if MUP determines that resource \\bigred\folder_name is a folder on a NetWare server, it will use the NetWare provider whenever the user connects to server BIGRED.
If a particular UNC path gets no traffic for 15 minutes, MUP removes it from the cache. The next connection request for that UNC causes MUP to poll again. Keep this behavior in mind when troubleshooting intermittent connection delays.
Installing Network Providers
The SMB provider, also called the Microsoft Client, is installed by default and cannot be removed. You can install additional providers using the Network Connections window. The following procedure uses the Microsoft Client Services for Netware as an example. Other providers can be obtained from third-party vendors.
Procedure 16.1 Installing Additional Network Clients
Right-click My Network Places and select PROPERTIES from the flyout menu. The Network Connections window opens.
Right-click the Local Area Connection icon and select PROPERTIES from the flyout menu. The Local Area Connection Properties window opens (see Figure 16.2). If you have more than one network adapter, it doesn't matter which one you choose. The client will be installed and linked to all network interfaces.
Figure 16.2. Local Area Connection Properties window.
The Select Network Component Type window opens.
Highlight Client and click Add.
The Select Network Client window opens. The default list has only Client Services for NetWare. If you need to install any other client, click Have Disk and point the system at the location of the drivers.
Highlight the provider and click Add. The system copies the files from the CD and returns to the Local Area Connection Properties window. Additional windows may open to set operating parameters.
Verify that the client is functioning properly by restarting and making connection with a server that is running the target protocol. In the case of the NetWare client, this involves authenticating either in Novell Directory Services (NDS) or a bindery-based NetWare server.
Changing the Network Provider Order
Both the Multi-Protocol Router (MPR) and the Multiple UNC Provider (MUP) poll the installed providers and network file systems looking for the correct one to use for a particular server. If a client has multiple network providers, you can improve initial connection performance by sorting the provider polling order so that the provider that is quickest to time out is listed first. This is generally the NetWare provider. Different networks respond differently, though, so you may need to fuss around with the sort order. Change the provider order as shown in Procedure 16.2.
Procedure 16.2 Changing the Network Provider Order
Right-click My Network Places and select PROPERTIES from the flyout menu. This opens the Network Connections window.
From the menu, select ADVANCED | ADVANCED SETTINGS. The Advanced Settings window opens.
Highlight the provider you want to reposition and click the up or down arrows to position it.
Click OK to save the changes and close the window. There is no need to restart.
The network client providers and MUP only provide an interface to the network. The real work is done by the network file system drivers, a.k.a. the redirectors. Redirectors are distinguished by the command language used to communicate to a server:
Windows Redirector (Mrxsmb.sys).
This driver communicates with Windows servers using the Server Message Block (SMB) command protocol.
NetWare Redirector (Nwrdr.sys).
This driver communicates with NetWare servers using NetWare Core Protocol (NCP).
RDP Redirector (Rdpdr.sys).
This driver communicates with Windows terminal servers using Remote Desktop Protocol (RDP).
WebDAV Redirector (Mrxdav.sys).
This driver communicates with WebDAV servers (Windows and others) using the WebDAV protocol.
The NetWare Redirector provided by Microsoft is NDS aware but does not support advanced NDS features such as Zero Effort Networking (ZENWorks) and NetWare Application Launcher (NAL).
In addition to accepting function calls from the Wnet client providers, the redirectors also handle network requests from other file system drivers. For example, both the Named Pipe File System (NPFS) and the Mailslot File System (MSFS) use the Mrxsmb redirector.
Server File Systems
The Server service also takes the form of a file system driver, Srv.sys. Like the Mrxsmb redirector, Srv.sys lives in kernel space as part of the I/O Manager. It is paired with LanMan Server service in user space. Client applications cannot make function calls directly to LanMan Server, so there is no need for it to link to MPR. Srv.sys depends on the Mrxsmb redirector to communicate with other servers.
Default Share Points
An SMB server exposes network resources in the form of share points. A share point can be a folder or a printer. A shared folder is often just called a share, as in "I need to create a share for that."
Parameters associated with the file system drivers and providers are located in the Registry under HKLM | SYSTEM | CurrentControlSet | Services. The file system keys have the same name as the drivers.
For example, the HKLM | SYSTEM | CurrentControlSet | Services | Mrxsmb key contains parameters and settings for the Windows file system redirector.
All Windows servers have default share points used to support network services and for administrative access. Some of these default shares have names that end with a dollar sign ($) to hide them from browsing interfaces such as My Network Places. These hidden shares are commonly called dollar sign shares or administrative shares, which are described as follows:
These shares provide access to the root of each drive on the server and to the system root folder, which is \Windows for Windows Server 2003. The permissions are set by the system to only permit access to members of the local Administrators group. The Domain Admins global group is nested in the Administrators group, giving domain administrators privileges to use the admin shares. See the sidebar, "Administrative Shares for CD-ROM Drives."
This share gives access to a symbolic link called Interprocess Connection (IPC). This share supports Remote Procedure Call (RPC) connections between Windows computers.
This share is seen on domain controllers. It gives access to the \Windows\Sysvol\Sysvol folder, which contains group policies and classic logon scripts.
This share gives access to the \Windows\Sysvol\Sysvol\Scripts folder. All domain member Windows clients (including Win3.11 and Win9x/ME) look for a Netlogon share on the domain controller where they authenticate. The share contains classic system policies and downlevel logon scripts.
This share gives access to the \Windows\System32\Spool\Drivers folder. This folder contains the drivers for each printer loaded on the server. Clients who connect to a shared printer download the drivers from this share. This includes downlevel clients such as NT4 and Win9x/ME, if the drivers for those clients have been installed.
This share is put in place when the Fax service is installed. It gives access to the folder holding the shared fax cover pages. By default, this folder is \Documents and Settings\All Users\Application Data\Microsoft\Windows NT\MSFax\Common Coverpages.
This share is put in place when Remote Installation Service (RIS) is installed on a server. It gives PXE (Preboot Execution Environment) clients access to installation files.
You can get a quick list of the share points on a server by opening a command prompt and typing net share. Here is an example listing. This server is running Visual Studio, so the web root folder has been shared to permit collaborative work behind a firewall:
Share name Resource Remark
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
C$ C:\ Default share
IPC$ Remote IPC
X$ X:\ Default share
ADMIN$ C:\WINDOWS Remote Admin
wwwroot$ c:\inetpub\wwwroot Used for file share access to web
By default, Windows Server 2003, XP, and Windows 2000 do not create administrative shares for CD-ROM, CD-R/RW, DVD-ROM, and DVD-RAM drives. If you change the drive letter for one of these devices, at that point the system will create an administrative share for the new drive letter.