• 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 WAN Device Support

    Outside the confines of PC networks, which run for the most part over a limited set of compatible Ethernet technologies, lies the wide world of WAN communications across the Public Switched Telephone Network, or PSTN. This is a world where flat satin cables lead to corroded punchdown blocks that connect to 30-year-old signal aggregators that tie to ATM interconnects that interface with multimillion-dollar switches that communicate over fiber optic networks designed and built by hundreds of different vendors and operated by thousands of corporate and government entities, all of whom never seem talk to each other over the very networks they control.

    Apparently the only person in the last 50 years who has not had any say at all in the structure of the public switched telephone network was my grandmother, and that's only because her complaints to AT&T always got lost in the only system that is even more complex than the PSTN: the public mail service.

    Figuring out how to patch PC data communications into the hodgepodge of the PSTN has absorbed the talents of some of the finest engineers and scientists this generation has produced. I try hard to recognize and respect the complexity of their task while I spend days and days trying to get a simple DSL connection into an apartment so that a travel-challenged client can work from home without hassling with a modem.

    From the point of view of connecting a Windows user in one location in the world to a server running Windows Server 2003 in another location in the same world, the available alternatives fall into these general categories:

    • Circuit-switched networks. Interfacing with these networks generally involves the familiar analog dial-up connections used by modems. You can also use switched digital connections via ISDN devices.

    • Packet-switched networks. Interfacing with these networks is done via X.25 PADs (Packet Assembler/Disassemblers) and Frame Relay Access Devices (FRADS) of one form or another. Connections across packet-switched networks either involve a Permanent Virtual Circuit (PVC) or the much less common Switched Virtual Circuit (SVC). Individual devices can make direct connection to each other via Point-to-Point Protocol (PPP) over Frame Relay.

    • Cell-switched networks. These networks primarily consist of Asynchronous Transfer Mode (ATM) devices. Although ATM typically makes up the backbone of a network, PCs can access each other directly over ATM using LANE (LAN Emulation) interfaces. Devices can make direct connection to each other over a cell-switched network via PPPoA (Point-to-Point over ATM).

    • Dedicated networks. This is a generic term for interfaces that have a full-time connection to the PSTN. Most organizations use full or fractional T-1 (DS-1) lines, although some use DS-3 and faster if their budget allows.

    • Broadband. This is a generic term for technologies that use high-bandwidth signaling to connect customer premise equipment to a special interface either at a PSTN central office or a digital network service center. Broadband includes a myriad of DSL flavors along with digital cable.

    WAN Support and NDIS

    The day-to-day business of running a communications server involves very little interaction with the devices that interface with the WAN. However, getting the server properly configured, or fixing it when it decides to take a small vacation, can involve a variety of challenges directly related to how the devices communicate with each other inside the Windows Executive. Figure 20.1 shows a diagram of the network drivers used to support WAN communications.

    Figure 20.1. WAN driver diagram.


    Windows supports WAN interfaces by making them appear to be standard network adapters. This permits the upper level protocols to go about their business without concern for the way data is getting shoveled around the network. Data link and media access control services that communicate to these devices are managed by the Network Device Interface Specification (NDIS) drivers.

    Because of their special nature, circuit-switched devices such as modems and ISDN terminal adapters are separately managed by Telephony API (TAPI) drivers that then interface with NDIS. The details of this connection do not normally help configuration and troubleshooting, but it is a good idea to remember that a particular modem might work fine when making serial connection that is handled solely by TAPI but fail miserably when called upon to do networking services.

    NDIS communicates with network adapters via miniport drivers. The generic miniport for WAN communications is the RAS Async Adapter driver, Asyncmac.sys. The INF file Netrasa.inf in \Windows\INF contains the setup information for this and other virtual WAN miniport drivers, such as the Layer 2 Tunneling Protocol (L2TP) interface, Point-to-Point Tunneling Protocol (PPTP) interface, and the direct parallel interface (PTI).

    NDIS works with the adapter minidriver to build a frame that conforms to the appropriate IEEE 802 specification for the interface. For example, an Ethernet frame conforms to IEEE 802.2, whereas a frame suitable for wireless Ethernet conforms to 802.11b. For WAN interfaces, NDIS uses an intermediate driver, Ndiswan.sys, to construct a communications frame that conforms to the requirements of the underlying PPP connection. The format for the framing is defined in RFC 1662, "PPP in HDLC-like Framing."

    Modem Registry Entries

    Modem configuration information is stored in the Registry under the Class ID (CLSID) for modems, 4D36E96D-E325-11CE-BFC1-08002BE10318. The configuration entries are kept in the following Registry entry:

    HKLM | System | CurrentControlSet | Control | Class | 

    Each modem is given a separate key that is a sequential number starting at 0000. Figure 20.2 shows the entries for a typical modem.

    Figure 20.2. Modem parameters stored under the Modem class in the Registry.


    These Registry entries come from INF scripts found in a hidden folder called \Windows\INF. If you encounter a modem setup problem that is resolved with a Registry change, make a corresponding change to the modem's INF file in the event that you install the same modem again.

    Point-to-Point Protocol (PPP)

    When it comes to data communications, a LAN is like the stock exchange. There's lots of shouting and signaling and tallying and somehow, in the end, transactions are completed. PC communications over a WAN are more deliberate and more focused. One box talks to another box over a link the two of them work step-by-step to create. The protocol used to create that communications link is called the Point-to-Point Protocol, or PPP.

    PPP has a lot of duties and it uses a suite of helper protocols to accomplish those duties. The protocols are defined in RFC 1661, "Point-to-Point Protocol." Here is a quick list of the stages involved in a PPP transaction followed by a description of the protocols used at each stage:

    • Link Establishment. During this stage, two physical devices must establish a data link connection that defines who they are, what size and type of frame to use, and what authentication protocol will follow.

    • Authentication. In this stage, the remote access server takes credentials supplied by the user who initiated the connection and uses them to validate the user's identity. This dial-in authentication is independent of any network authentication that might be required after the PPP connection is made.

    • Network Layer Establishment. After the user has been authenticated, the client interface is given an IP address and additional configuration settings, such as compression and encryption. It might also be required to hang up and wait for a callback to verify the actual source of the call.

    Link Establishment

    A PPP transaction begins with a negotiation performed using the Link Control Protocol, or LCP. This protocol is responsible for defining the data link parameters for the underlying network connection. These parameters include the following:

    • Maximum Received Reconstructed Unit (MRRU). This is the maximum frame size that will be transmitted over the connection. Messages larger than this frame size are dissected then reassembled. The MRRU is defined in RFC 1717, "PPP Multilink Protocol," and is set to 1614 bytes by default. (See the "PPPoE" section later in this chapter for additional constraints on the frame size.)

    • Asynchronous-Control-Character-Map (ACCM). The first 32 ASCII characters can act as control characters in an asynchronous serial connection. They are also potentially part of the data stream if that stream contains binary files. The ACCM option represents control characters as discrete bits in a 32-bit sequence. For example, Ctrl+L (^L) would be represented by bit 12. If the mask is set to all 0s, this indicates that no mapping is required.

    • Authentication Type. This option determines the authentication method that will be used in the next phase of the connection. The method depends on the configuration of the client and server. There are five options: EAP (0xC2-27), MS-CHAPv1 (0xC2-23-80), MS-CHAPv2 (0xC2-23-81), CHAP (0xC2-23-05), SPAP (0xC0-27), and PAP (0xC0-23).

    • Magic Number. A magic number is a random number that validates the packet source. If a host sees its own magic number in a packet, it knows there has been a loopback. It then discards the packet and re-establishes the link.

    • Protocol Field Compression. This option permits compression of the protocol field in the PPP frame. Both parties must agree to set this option before it can be used. The option is set ON by default.

    • Address and Control Field Compression. This option permits compression of the 1-byte Address field and the 1-byte control field in the PPP header. This option is set ON by default.


    PPP entities agree on an authentication method during the LCP phase of the connection. The selected method is implemented during this phase. This is the most complex part of the PPP transaction, and is detailed in the "PPP Authentication" section.

    Network Layer Establishment

    After the user has been authenticated, PPP gives the helm to the Network Control Protocol, or NCP. This protocol is responsible for establishing the network link over the top of the data link built by LCP.

    NCP employs several additional protocols. These include the following:

    • Callback control

    • Compression control

    • Encryption control

    • Transport control

    Callback Control Protocol (CBCP)

    This protocol determines the callback options, if any, that have been set for the user. In Windows Server 2003, the user's callback options are contained in one of two places. For standalone dial-up servers, the information is stored in the user's SAM account. For domains, the information is stored in the user's Active Directory object in the MSRADIUS-Callback-Number attribute. CBCP provides three options for setting callbacks:

    • No Callback. If this option is set, CBCP immediately returns control back to NCP.

    • Callback Set by Caller. If this option is set, CBCP tells the dial-in client that a callback is required and requests a callback number. The user enters a phone number then CBCP terminates the connection. The client waits for a callback from the server. The number entered by the user is recorded in the Event log. This option is commonly used to support overseas callers because an outbound call from the States is much cheaper than an inbound call from overseas.

    • Callback Preset To. If this option is set, CBCP tells the dial-up client that a preset callback number has been defined. The client acknowledges then terminates the call and waits for a callback from the server. The server dials the preset number, re-establishes the link, and turns control back to NCP. This option is used when you want to make absolutely certain that a particular user is making the connection.

    Compression Control Protocol (CCP)

    This protocol negotiates a data compression method. Windows uses a variation of CCP called Microsoft Point-to-Point Compression, or MPPC. It is documented in informational RFC 2118. MPPC can negotiate additional features with Windows clients while still supporting standard CCP for non-Windows clients. MPPC uses options set by the dial-up client and server to determine the compression setting.

    By default, Windows PPP uses software compression. Unfortunately, TAPI exposes a feature that enables hardware compression, as well. You should not use both simultaneously. This wastes cycles compressing frames that will just get compressed again by the modem. Software compression is usually faster, so if you want to disable hardware compression, the option is available at Control Panel | Phone and Modem | Modem Configuration Properties.

    With Windows 98 clients, always leave software compression enabled. The PPP connection transaction will fail if software compression is not selected.

    Encryption Control

    Standard PPP assumes that higher-level application protocols will encrypt the data stream if encryption is desired. Microsoft added encryption negotiation in the network establishment phase of PPP. The option is selected in Dial-Up Properties under the Security tab. Figure 20.3 shows an example from an XP client. Windows 9x uses a similar configuration window in Dial-Up Networking.

    Figure 20.3. Dial-Up Properties window, Security tab showing the Require Data Encryption option.


    When you select the encryption option, the client and server and encrypt the data stream using Microsoft Point-to-Point Encryption protocol, or MPPE, as documented in RFC 3078, "Microsoft Point-To-Point Encryption (MPPE) Protocol," and RFC 3079, "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)."

    MPPE uses RC4 streaming encryption with a 128-bit cipher key now that export controls on strong encryption have been relaxed. Bruce Schneier from Counterpane Systems (www.counterpane.com) points out that although a 128-bit key sounds secure, it is ultimately derived from the user's password, which is artificially limited to 14 characters and often contains far fewer, so the long key does not make MPPE significantly more resistant to attack than the older 56-bit key.

    PPP encryption only protects the data stream between the two end-point entities. If a client makes a PPP connection to an RRAS server then maps a drive to a server other than the RRAS server, the data stream will be unencrypted between the RRAS server and the destination server.

    If your data is secure enough to warrant encryption, you should consider implementing a VPN using L2TP and IPSec rather than using PPP encryption. See "Configuring Virtual Private Network Connections" for details.

    Control Protocols

    After compression and encryption protocols have been defined, NCP turns its attention to the control protocols that configure the interface to the networking protocols used by the system. Each network transport supported by Windows Server 2003 has a corresponding control protocol. They are as follows:

    • IPCP (Internet Protocol Control Protocol). This protocol is defined in RFC 1332, "The PPP Internet Protocol Control Protocol (IPCP)." IPCP sets parameters such as the client's IP address, primary and secondary DNS servers, primary and secondary WINS servers, and the option to use Van Jacobson compression for the IP header.

    • IPXCP (IPX Control Protocol). This protocol is used to control NetWare's Internetwork Packet Exchange (IPX) over a dial-in connection as defined in RFC 1552, "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)." IPXCP sets parameters such as the IPX Network Number, the IPX Node Number, the IPX Compression Protocol, the IPX Routing Protocol, and the IPX Router Name.

    • NBFCP (NetBIOS Frame Control Protocol). This protocol is defined in RFC 2097, "The PPP NetBIOS Frames Control Protocol (NBFCP)." NBFCP sets parameters such as NetBIOS Name Projection that lists the names of the servers to add to the NetBIOS Name table at the client and Peer Information that declares whether the client is an end-point or a gateway. There is also an IEEE MAC Address Required option to specify whether transmitted frames include MAC addresses to facilitate communication on the other side of a gateway and a Multicast Filtering option to control NetBIOS broadcasts through the gateway. At the conclusion of the IPCP negotiation phase, PPP is finished and the link is established. NDIS takes over and begins sending data to the interface.


    PPP is not limited to connections between circuit-switched interfaces such as modems and ISDN terminal adapters. Windows can use PPP to establish a direct data link connection between two entities over a number of underlying WAN protocols.

    One increasingly common example of this ability is the use of PPP to authenticate and connect a DSL user to a DSL provider network over an existing full-time broadband connection. This link uses a variation of PPP called PPP over Ethernet, or PPPoE, documented in RFC 2516, "A Method for Transmitting PPP Over Ethernet (PPPoE)."

    Purportedly, the reason for using PPPoE lies with security. In early DSL implementations, each DSL interface was assigned a fixed IP address and was "always on" the network. A server or workstation with a DSL interface could route users onto the Internet using NAT, or the user could get an inexpensive hardware gateway to do the same thing. DSL providers saw this as a security vulnerability because users could do mischief from the anonymity of a NAT connection.

    The real purpose for PPPoE, though, lies with revenue generation rather than security. A single DSL line can handle dozens of users, and the customer gets those connections for the cost of a single Digital Subscriber Line (DSL) interface. This is common practice over dedicated connections like a T-1, but the revenue model for T-1 networking is much different than for DSL, which is far less expensive.

    The industry wrangled over this for a while and came up with PPPoE as way to manage user accounts individually over the same DSL interface. Each PPPoE request is separately authenticated and separately logged and billed. Servers running Windows Server 2003 and XP desktops have PPPoE support built in, so there is no need to install separate authentication software.

    One important limitation imposed by PPPoE is a reduction of the maximum frame size that can be transmitted by clients through a server that has a PPPoE-enabled connection. A standard Ethernet frame has a useful payload of 1500 bytes (octets). This is termed the Maximum Transmission Unit, or MTU. The PPPoE header takes 6 octets with an additional 2 octets for the PPP protocol ID. This leaves an MTU of 1492.

    When a TCP/IP client negotiates a connection to a server, the two entities negotiate an MTU. This is ordinarily 1500 octets. If the client sits behind a server with a PPPoE connection, the PPPoE server will drop the frame and return an Internet Control Management Protocol (ICMP) message to the server telling it that the MTU is 1492. If the web server has been configured to refuse ICMP, and many are, the web page will not load completely.

    A handy diagnostic technique to check for this situation is to ping the web server from the client with the Цl switch to specify a payload size and the Цf switch to prevent fragmentation. The syntax would be as follows:

    ping Цf Цl 1492 <internet_host>

    If you get an error saying Packet needs to be fragmented but DF set, you'll know that you've exceeded the MTU of the web server or one of the intervening routers.

    You can avoid these sorts of problems by reducing the MTU at clients that sit behind a server that uses a PPPoE device. You can do this for each client or you can make the change at one client then export the change using Regedit into to a file that can be applied to the remaining clients in a logon script. Here are the changes:

    Key:    HKLM | System | CurrentControlSet | Services | Ndiswan | Parameters | Protocols | 0
    Values: ProtocolType
    Data: 0x0800 (REG_DWORD)
    Values:  PPPProtocolType
    Data: 0x0021 (REG_DWORD)
    Values:  ProtocolMTU
    Data: <MTU size> (REG_DWORD)
      Previous Section Next Section