• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    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:

    • Network applications

    • Network providers

    • Redirectors

    • Transports

    • Network adapter interfaces

    Figure 16.1. Network driver block diagram.

    graphics/16fig01.gif

    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.

    Network Applications

    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:

    • Wnet. 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.

    • Named pipes. 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.

    • Mailslots. 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. 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 Providers

    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:

    • Windows provider. For historical reasons, the Windows provider is called LanMan Workstation. The provider is part of Ntlanman.dll.

    • NetWare provider. 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.

    • Winsock provider. 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.

    NetBIOS Support

    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 interruptinterrupt 5C to be specificthat 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.

    Print Providers

    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
    Value:  ProviderOrder
    Data:   NWCWorkstation,LanManWorkstation
    

    For print providers, the Registry entries are as follows:

    Key:    HKLM | System | CurrentControlSet | Control | Print | Providers
    Value:  Order
    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

    1. Right-click My Network Places and select PROPERTIES from the flyout menu. The Network Connections window opens.

    2. 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.

      graphics/16fig02.gif

    3. Click Install. The Select Network Component Type window opens.

    4. 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.

    5. 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

    1. Right-click My Network Places and select PROPERTIES from the flyout menu. This opens the Network Connections window.

    2. From the menu, select ADVANCED | ADVANCED SETTINGS. The Advanced Settings window opens.

    3. Highlight the provider you want to reposition and click the up or down arrows to position it.

    4. Click OK to save the changes and close the window. There is no need to restart.

    Redirectors

    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."

    Registry Tip: Registry Keys for Redirectors

    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:

    • Administrative shares. 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."

    • IPC$. This share gives access to a symbolic link called Interprocess Connection (IPC). This share supports Remote Procedure Call (RPC) connections between Windows computers.

    • Sysvol. This share is seen on domain controllers. It gives access to the \Windows\Sysvol\Sysvol folder, which contains group policies and classic logon scripts.

    • Netlogon. 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.

    • Print$. 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.

    • FxsSrvCp$. 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.

    • RemInstall. 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
    

    Administrative Shares for CD-ROM Drives

    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.

      Previous Section Next Section