This action might not be possible to undo. Are you sure you want to continue?
Dynamic Host Configuration Protocol (DHCP) in the Microsoft® Windows® Server 2003 family of operating systems enables centralized automatic management of IP addresses and other TCP/IP settings for network clients. You can reduce administrative overhead in your organization by designing and implementing a reliable and scalable DHCP solution.
In This Chapter
Overview of DHCP Deployment................................................................ .............70 Creating Your DHCP Server Design................................................................ ........72 Integrating DHCP with Other Services.......................................................... .........81 Defining Scopes........................................................................... .........................84 Implementing Your DHCP Solution...................................................................... ...95 Example DHCP Implementation.............................................. ............................102 Additional Resources.............................................................................. .............110
• For more information about Dynamic Host Configuration Protocol (DHCP), see the Networking Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit). For more information about integrating DHCP with Domain Name System (DNS), see “Deploying DNS” in this book. For more information about integrating DHCP with Windows Internet Name Service (WINS), see “Deploying WINS” in this book.
Overview of DHCP Deployment
Valid IP addresses and other network options must be configured for all computers and other devices on the network, such as printers, in a corporate network. Manually configuring this information is a time-consuming process that adds significant costs to an organization and is susceptible to user error. Windows Server 2003 Dynamic Host Configuration Protocol (DHCP) reduces the complexity and administrative overhead involved in managing network client IP addressing and configuration. DHCP allows you to assign IP addresses to network clients automatically and dynamically, as needed, and to automate, centralize, and simplify IP address and option configuration and distribution across your network. This protects against common configuration errors that occur when values are entered manually at each computer and helps to prevent address conflicts. By using DHCP options, you can configure DHCP servers to supply a full range of configuration values when assigning a DHCP lease, allowing you to configure a large number of computers at one time, and to change configuration as necessary. Different types of organizations can benefit from the automation and centralization that Windows Server 2003 DHCP provides, including: • • • Organizations in which administrators are responsible for configuring IP addresses and options for a large number of devices. Organizations that include a large population of mobile users or network configurations that frequently change. Organizations that already use versions of DHCP earlier than Microsoft® Windows® 2000, which can benefit from the added functionality of Windows Server 2003 DHCP by upgrading their DHCP deployment.
If you are deploying DHCP in a new Windows Server 2003 environment, begin your deployment process by creating a design for your DHCP servers. When you have completed all of the design steps for your DHCP infrastructure, you can implement your DHCP solution by configuring your DHCP servers. If you are upgrading your existing DHCP infrastructure to Windows Server 2003, begin by reviewing your current DHCP design and modifying it if required, and then migrate your existing DHCP databases.
DHCP Deployment Process
Deploying or upgrading DHCP in your organization involves several important planning, design, and implementation steps. Figure 2.1 shows the process for deploying DHCP. Figure 2.1 Deploying DHCP
Creating Your DHCP Server Design
It is important to create a DHCP server design that meets the needs of your organization in terms of functionality, availability, interoperability, and total cost of ownership (TCO). Figure 2.2 shows the process for creating a DHCP server design. Figure 2.2 Designing Your DHCP Server
Upgrading Your Existing DHCP Server Hardware
Determine whether your current hardware and software, including routers, switches, and other servers and clients, support Windows Server 2003 DHCP. Windows Server 2003 DHCP servers support Windows DHCP clients and third-party operating systems that use DHCP and comply with RFC 2131. For more information about the operating systems that support DHCP, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
If your current systems support Windows Server 2003, but are close to the end of their expected lifecycle, consider upgrading your hardware at the same time that you upgrade to Windows Server 2003. Upgrading DHCP servers running Microsoft® Windows NT® Server version 4.0 or earlier to Windows Server 2003 allows you take advantage of benefits related to the Active Directory® directory service, such as integrated secure dynamic updates of the DNS database. For information about hardware life expectancy, contact your hardware vendor or refer to any internal metrics that your organization might have developed. For information about hardware compatibility, see the Windows Catalog link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. For more information about performing a hardware inventory, see “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.
Determining DHCP Server Locations
To determine where to locate your DHCP servers, consider whether you are deploying a distributed, centralized, or combined DHCP infrastructure. For a distributed DHCP infrastructure, locate a DHCP server on each subnet. Because distributed infrastructures use a DHCP server on each subnet, they require a greater number of servers than centralized networks. For example, a network that includes 30 subnets and that is using a true distributed topology requires at least 30 DHCP servers, and possibly more to provide for redundancy. In a centralized DHCP infrastructure, DHCP servers are placed in a central location. A centralized DHCP topology requires the deployment of DHCP/bootstrap protocol (BOOTP) relay agents. Additional hardware resources are not generally required for DHCP relay agents; in most cases, the routers that are positioned between each subnet can assume this role, as defined in RFC 1542. If the routers cannot relay DHCP messages, configure a computer running Windows Server 2003 to act as a DHCP/BOOTP relay agent. For more information about configuring relay agents, see “Enabling DHCP Support for Multiple Subnets” later in this chapter. Combining both distributed and centralized DHCP infrastructures provides the maximum efficiency for your network. In a combined DHCP infrastructure, the locations for DHCP servers are based on the physical characteristics of the local area network (LAN) or wide area network (WAN) infrastructure, and not the logical groupings defined by the Active Directory logical structure. DHCP servers are not required for every subnet if the connecting routers support DHCP/BOOTP relay agents. You can administer Windows Server 2003 DHCP servers remotely from a computer running Windows Server 2003 and Microsoft Management Console (MMC) DHCP snap-in. You can also administer a DHCP server remotely at the command line by using Netsh commands for DHCP, or you can remotely administer a DHCP server from a computer running Microsoft® Windows® XP Professional that has the Windows Server 2003 Administration Tools Pack installed. You must have the correct level of security permissions in order to administer a DHCP server. For more information about using the Windows Server 2003 Administration Tools Pack, see “Windows Server 2003 Administration Tools Pack” in Help and Support Center for Window Server 2003.
Optimizing DHCP Server Performance
You can optimize the performance of DHCP servers in your organization by doing the following: • • Extending the duration of the IP address lease. Improving DHCP server hardware, specifically upgrading to a faster hard drive or adding random access memory (RAM).
Extending the IP Address Lease and Renewal Duration
The volume of traffic on your network can have a negative impact on DHCP performance. For example, a subnet that relies on a DHCP server at a remote location on the WAN might experience poor performance at start of day, when users turn on computers and a large load of requests might be sent over the network. DHCP traffic does not use significant network bandwidth during periods of normal usage; however, the following two phases of DHCP client configuration generate some network traffic load: • • IP address lease IP address renewal
When a DHCP client initializes TCP/IP or renews its address lease, it acquires an IP address from the DHCP server. This process results in an exchange between the DHCP client and the DHCP server, which typically consists of four packets, each containing a maximum of 4 kilobytes (KBs). For more information about the DHCP exchange, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit). You can reduce the amount of network traffic generated by DHCP IP address lease and IP address renewal by extending the lease duration. Before you extend the lease duration, you must take into consideration other factors in your network, such as ratio of clients to available IP addresses, or clients that frequently lease addresses on more than one subnet, such as laptops that move frequently. If you have a relatively stable network and many more available IP addresses than DHCP clients, increasing the lease duration reduces network traffic, because DHCP messages are sent less frequently. If, however, you have a limited number of IP addresses available to your DHCP clients, or a network that changes frequently, a longer lease duration might cause you to run out of IP addresses because IP addresses are not returned to the address pool and made available to other DHCP clients until the lease expires. For more information about extending the lease duration, see “Determining Lease Duration” later in this chapter.
Improving DHCP Server Hardware
You can optimize DHCP performance in your system by optimizing individual DHCP server performance. Windows Server 2003 includes performance monitoring tools that you can use to test and monitor your servers.
For more information about performance monitoring tools, see “Performance Monitoring Tools” in Help and Support Center for Windows Server 2003. The primary factors that impact DHCP server performance include: • • The speed of the server disk drives. The amount of RAM installed in the DHCP server computer.
The greatest volume of disk usage occurs when the service is started and when the database is backed up. When planning your DHCP server hardware specifications, evaluate the average time required for disk access and for disk read/write operations. If necessary, maximize DHCP server performance by increasing RAM and purchasing high-speed disk drives for the servers.
Enabling DHCP Support for Multiple Subnets
If you have multiple subnets in your network, and do not have a DHCP server on every subnet, determine whether your current routers relay DHCP/BOOTP messages. If your routers cannot be used for DHCP/BOOTP relay, set up a DHCP/BOOTP relay agent on at least one computer running Windows Server 2003 on each subnet. The DHCP/BOOTP relay agent relays DHCP and BOOTP message traffic between the DHCP-enabled clients on the local network and a remote DHCP server located on another physical network by using the IP address of the remote DHCP server. Figure 2.3 shows a simple, routed network in which the router acts as a DHCP relay agent. Figure 2.3 Subnets Configured to Use a DHCP Relay Agent
If your routers cannot be used for DHCP/BOOTP relay and you choose not to configure DHCP/BOOTP relay agents, you must configure your network so that a DHCP server has a network adapter on each subnet it serves. You can accomplish this by either placing a DHCP server on each subnet, or by multihoming DHCP servers. This distributed configuration does not provide fault tolerance. If a DHCP server becomes unavailable, DHCP clients on the subnet cannot receive IP addresses and options.
The DHCP Relay Agent service is available only on computers running Windows Server 2003, Microsoft® Windows® 2000, or Windows NT 4.0. To use the DHCP Relay Agent routing protocol, the Routing and Remote Access service must be installed and enabled.
For more information about installing and configuring DHCP relay agents, see “Configure the DHCP Relay Agent” in Help and Support Center for Windows Server 2003. For more information about the DHCP Relay Agent service, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit) or see Help and Support Center for Windows Server 2003.
Determining How Many DHCP Servers to Deploy
A single DHCP server can serve an almost unlimited number of clients. However, factors such as the size and layout of your network, the IP address class selected for use, and the volume of traffic on your network often make this impractical. You can deploy multiple DHCP servers to reduce the volume of DHCP-related traffic across your network and create faster response times for DHCP messages. Deploying multiple DHCP servers also creates fault tolerance on your network. If you choose to deploy more than one DHCP server, it is important to weigh the benefits of increased response times against the costs required for additional hardware. When deciding how many DHCP servers you need, consider: • • The location of DHCP-enabled clients on your network. The transmission speeds between the segments for which DHCP service is provided. If you have slower WAN or dial-up links, place a DHCP server on both sides of these links to improve DHCP response times for local clients. • The network traffic that DHCP produces, as well as your current network traffic. If your current volume of network traffic is high, consider deploying multiple DHCP servers to reduce the volume of DHCP requests traveling across the network. Make sure to account for periods when network traffic is heaviest, such as the beginning of the day, when many users turn on their computers at the same time. • Disk space requirements.
It is important to consider the database size when choosing your hardware. Each lease requires approximately 600 bytes per lease for the database, plus 1200 bytes for backup (600 bytes for the backup and 600 bytes for the temporary directory). In addition, the audit logs require approximately 500 bytes per lease transaction and are stored for seven days.
In general, allow at least 50-70 MB for the audit logs, however the number of lease transactions depends on the number of leases as well as the lease duration.
To figure out how much hard disk space is required, first multiply the number of leases by 600 bytes, then multiply the estimated number of lease transactions by 500 bytes, and add these two results. The sum is the minimum amount of disk space required by the DHCP server. For example, a DHCP server with 10,000 leases and lease duration of one week requires approximately 18 MB to store the leases and the backup (6 MB for the database, 6 MB for the backup, and 6 MB for the temporary database). The audit logs would require an absolute minimum of 10 MB: 5 MB (500 bytes x 10,000 leases) for startup, and 5 MB when the leases renew halfway through the week. If the number of leases increases or if lease time is shortened, this requirement will increase. A company might allocate 100 MB for audit logs to allow for flexibility in adding leases or reducing lease duration, as well as dealing with any peak-load events.
Optimizing DHCP Availability
A highly available solution must account for all possible points of failure, including server failures, WAN link interruptions, and router failures. You can increase the fault tolerance and availability of your design by using one or more of the following, depending on your needs and hardware cost considerations: • • • Split-scope configurations Clustered DHCP servers Using standby servers
Using Split-Scope Configurations
You can increase fault tolerance by splitting DHCP scopes between multiple DHCP servers. With a split-scope configuration, if one server becomes unavailable, the other server can take its place and continue to lease new IP addresses or renew existing clients. Splitting DHCP scopes also helps to balance server loads. When splitting the IP address pool of a scope between two servers, assign the same scope to both servers, and exclude opposite portions of the address range. You also need to make identical reservations at both DHCP servers, so that either server can assign the reserved IP address, ensuring that the intended device receives the address that is reserved for its use. Figure 2.4 shows a network that is using a split-scope configuration. Figure 2.4 Split-Scope Configuration
In Figure 2.4, DHCP Server 1 has 80 percent of the addresses in the scope and DHCP Server 2 has 20 percent of the addresses in the scope. Splitting a scope between servers in this way, which is commonly referred to as the “80/20 rule,” often relies on the proximity of the DHCP servers to the clients it serves. For example, when a DHCP client that is on the same subnet as DHCP Server 1 sends out a DHCP Discover packet, it takes longer for DHCP messages from clients to reach the DHCP Server 2 than DHCP Server 1, because DHCP Server 2 is on the other side of a router from the DHCP client. You can also configure a delay on the DHCP relay agent to ensure the local DHCP server has adequate time to respond. Because DHCP clients always accept the lease from the DHCP server that sends the first response, clients normally obtain leases from DHCP Server 1. If DHCP Server 1 goes offline for any reason, clients accept leases from DHCP Server 2.
Using Clustered DHCP Servers
Windows Server 2003 DHCP can use Windows Clustering, which allows two or more servers to be managed as a single system. You can increase DHCP (or multicast address dynamic client allocation protocol [MADCAP]) scalability, availability, and reliability by using the Cluster service to deploy a DHCP server cluster. By using clustering support for DHCP, you can implement a local method of DHCP server failover. In this way, you can achieve greater fault tolerance and minimize disruptions and work stoppages. Windows Clustering can automatically detect the failure of an application or server and restart the application on or transfer the server role to an alternate server. Users experience only a brief break in service. Windows Clustering creates a virtual DHCP server so that if one of the clustered nodes fails, the namespace and all of the services contained in that node are automatically transferred to a second node. No changes are visible to the client, which sees the same IP address for the clustered DHCP servers. Use Windows Clustering alone to create a fault-tolerant design that makes efficient use of available IP addresses. To further enhance DHCP fault tolerance and availability, combine DHCP server clustering with a remote failover configuration — such as a split-scope configuration across different segments of your network. Although combining server clustering with a split-scope configuration increases DHCP availability, you must consider whether the benefits to your organization outweigh the hardware costs involved. Figure 2.5 shows an example of clustered DHCP servers. DHCP Server 1 is the active DHCP server, and DHCP Server 2 is the backup DHCP server. Figure 2.5 Clustered DHCP Servers
Example: Using a Split-Scope Configuration in Combination with a DHCP Server Cluster to Enhance Availability and Fault Tolerance
A company has its main corporate office in North America, and two European offices in Milan and Seville. The North American DHCP server cluster includes two servers, which are configured as nodes of the server cluster. Twenty percent of the available IP leases for the Milan and Seville sites are configured on the North American server cluster. The remaining 80 percent of the available IP leases are configured on the local Milan and Seville DHCP servers. This configuration provides the following levels of fault tolerance for the European sites: 1. Under normal circumstances clients in Milan and Seville request IP lease assignments from the local DHCP server, which contains 80 percent of the available IP addresses for the subnet. 2. If either the Milan or Seville DHCP server is slow or unavailable, European DHCP clients use the North American DHCP server, which contains 20 percent of the available IP addresses for the Milan and Seville subnets. The relay agent between the European offices and the North American office is configured to delay the DHCP messages from the European offices, allowing the local (Milan or Seville) DHCP server enough time to respond. 3. Because the North American DHCP server is configured as a server cluster, if one node of the cluster becomes unavailable, Windows Clustering automatically brings the other node online.
Using Standby Servers
A standby server and its scopes are not activated for use under normal conditions, and are activated by the administrator only when needed, such as when a DHCP server fails or is taken offline for an extended period of time. Standby servers require manual administration to ensure failover transition, and therefore might not be as effective as other failover methods, such as split scopes and clustered servers. To use a standby configuration, configure an additional DHCP server to server as a backup if the primary server goes offline. You can either configure the standby server to be identical to your primary DHCP server or configure the standby server with unused scopes to temporarily replace the primary DHCP server.
If you are configuring the standby server with the identical scope to your primary DHCP server, you must implement server-side address conflict detection to prevent the assigning of duplicate addresses.
Because server-side conflict detection uses Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) messages to detect conflicts, Internet Connection Firewall (ICF) or other firewalls that are installed on clients on your network might interfere with conflict detection.
For more information about backing up your DHCP servers, see “Backing Up the DHCP Database” or “Netsh Commands for DHCP” in Help and Support Center for Windows Server 2003.
Integrating DHCP with Other Services
If you use DHCP servers for Microsoft network clients, you must use a name resolution service. Networks that support clients running Windows 2000, Microsoft® Windows® XP Professional, and Windows Server 2003 use the DNS service to support name resolution. Networks that support clients running versions of the operating system earlier than Windows 2000 must use a form of NetBIOS name resolution, such as WINS. Networks that support both types of clients must implement both WINS and DNS servers. Windows Server 2003 DHCP provides support for both DNS dynamic updates and secure DNS dynamic updates. DHCP and DNS work together to perform dynamic updates and work with Active Directory to perform secure DNS dynamic updates. DHCP also works with Active Directory to prevent unauthorized DHCP servers from running on the network. Figure 2.6 shows the process for integrating DHCP with other services.
Figure 2.6 Integrating DHCP with Other Services
Configuring Dynamic Update and Secure Dynamic Update
The Windows Server 2003 DHCP Server service can be configured to perform DNS dynamic updates and secure DNS dynamic updates for DHCP clients, which eliminates the need for administrators to update DNS records manually when a client’s IP address changes. Clients running Windows 2000, Windows XP, or Windows Server 2003 can also perform dynamic updates. Clients running versions of Windows earlier than Windows 2000 do not support DNS dynamic update. To enable the DHCP server to perform DNS dynamic updates on behalf of these clients, use the default client preference settings. Clients using WINS for name resolution cannot make an explicit request for DNS dynamic update protocol preference. For these clients, the DHCP service can be configured to update both the PTR and the A resource records. By itself, dynamic update is not secure; any client can modify DNS records. When secure dynamic update is configured, the authoritative name server accepts updates only from clients and servers that are authorized to make dynamic updates to the appropriate objects in Active Directory. Secure dynamic update is available only on Active Directory–integrated zones. To configure secure dynamic updates, you can use the Windows Server 2003 secure dynamic update feature.
Secure dynamic update protects zones and resource records from being modified by unauthorized users by enabling you to specify the users and groups that can modify zones and resource records. By default, Windows Server 2003, Windows XP Professional, and Windows 2000 clients attempt unsecured dynamic updates first. If that request fails, they attempt secure updates. When using multiple DHCP servers and secure dynamic updates, add each of the DHCP servers as members of the DnsUpdateProxy global security group so that any DHCP server can perform a secure dynamic update for any record. Otherwise, when a DHCP server performs a secure dynamic update for a record, that DHCP server is the only computer that can update the record.
To configure dynamic update for DHCP clients and servers
1. In the DHCP snap-in, select and right-click the DHCP server you want to configure, and then click Properties. 2. In the server name Properties dialog box, click the DNS tab. 3. On the DNS tab, select the Enable DNS dynamic updates according to the settings below check box. 4. On the DNS tab, select the dynamic update method you want: either always updating DNS A and PTR, or only updating the records when requested by the DHCP client. Use the DNS snap-in to enable secure dynamic update. For more information about dynamic update and secure dynamic update, see “Deploying DNS” in this book and in Help and Support Center for Windows Server 2003.
If DHCP will perform DNS dynamic updates, do not install it on a domain controller. Instead, install DHCP on a member server. When DHCP is installed on a domain controller and is configured to perform dynamic updates on behalf of clients in DNS zones that are configured to allow only secure dynamic update, specify a user account to update the DNS records. For more information about installing DHCP, see “Checklist: Installing a DHCP server” in Help and Support Center for Windows Server 2003.
Authorizing DHCP Servers in Active Directory
An unauthorized DHCP server on a network can cause a variety of problems, such as the leasing of incorrect IP addresses and options. To protect against this type of problem, when a Windows 2000 or Windows Server 2003 domain member DHCP server attempts to start on the network, it first queries Active Directory. The DHCP server compares its IP address and server name to the list of authorized DHCP servers. If either the server name or IP address is found on the list of authorized DHCP servers, the server is authorized as a DHCP server. If no match is found, the server is not authorized in Active Directory and does not respond to DHCP traffic. The process of authorizing DHCP servers is useful for only Windows 2000–based or Windows Server 2003–based DHCP servers. This process cannot be used for DHCP servers running Windows NT Server, or servers running non-Windows-based DHCP services. Only a member of the Enterprise Admins group can authorize or unauthorize a DHCP server in Active Directory.
You must be logged in as an enterprise administrator to authorize a DHCP server.
To authorize a DHCP server in Active Directory
1. In the DHCP snap-in, right-click DHCP. 2. Select Manage authorized servers. 3. In the Manage Authorized Servers dialog box, click Authorize. 4. In the Authorize DHCP Server dialog box, type the name or IP address of the DHCP server, and then click OK.
Detection of unauthorized DHCP servers requires the deployment of Active Directory and the DHCP service running on Windows 2000 or Windows Server 2003. Other DHCP servers do not attempt to determine whether they are authorized by Active Directory before offering IP address leases.
Before DHCP clients can use a DHCP server for dynamic TCP/IP configuration, you must define and activate scopes for your DHCP clients. A scope is the full, consecutive range of possible IP addresses for a subnet. The IP addresses in a scope define a single subnet on which DHCP services are offered. DHCP servers use scopes to manage network IP address distribution and the configuration of DHCP options.
Figure 2.7 shows the process for defining scopes. Figure 2.7 Defining Scopes
You must create a DHCP scope for each subnet in your network. Each subnet has a DHCP scope, with a single continuous range of IP addresses. Before you create scopes, you must install DHCP on your server. For more information about installing DHCP, see “Checklist: Installing a DHCP server” in Help and Support Center for Windows Server 2003. You can use the DHCP MMC snap-in to create a new scope on your DHCP server.
To create a DHCP scope
1. In the DHCP snap-in, select the name of the DHCP server. 2. Select Action, and then select New Scope. This opens the New Scope Wizard. Complete the New Scope Wizard by configuring the following properties: • • • • • • A scope name and description of the scope. A consecutive range of possible IP addresses. A unique subnet mask. For more information about defining subnet masks, see “Designing a TCP/IP Network” in this book. The IP addresses that are to be excluded from the scope. Lease duration values. Options.
For a worksheet to assist you in completing the New Scope Wizard, see the “Scope Data Collection Worksheet” (DNSDHC_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see the “Scope Data Collection Worksheet” on the Web at http://www.microsoft.com/reskit). After you create the scope, you can set reservations and configure any additional DHCP options. For information about setting reservations, see “Creating Reservations” later in this chapter. For information about configuring additional DHCP options, see “Configuring DHCP Options” later in this chapter.
Setting Exclusion Ranges
To prevent address conflicts, the scopes that you define must exclude the IP addresses of devices that you statically configure, such as DHCP servers. By setting exclusion ranges, an administrator can exclude IP address ranges within a scope so that those addresses are not offered to DHCP clients. When you create a new scope, immediately exclude addresses of the existing statically configured computers. Excluded IP addresses can be active on your network, but only when these addresses are manually configured or distributed as reserved IP addresses. For more information about reservations, see “Creating Reservations” later in this chapter.
You can set exclusion ranges in the Add Exclusions page of the New Scope Wizard. For more information about using the New Scope Wizard, see “Creating Scopes” earlier in this chapter.
To set an exclusion range after a scope is created
1. In the DHCP snap-in, expand the scope you want to configure. 2. Select and right-click Address Pool under the appropriate scope. 3. Select New Exclusion Range. 4. In the Add Exclusion dialog box, type the starting and ending IP addresses of the exclusion range, and then click Add.
Determining Lease Duration
When a scope is created, the default lease duration is set to eight days. However, because lease renewal is an ongoing process that can affect the performance of DHCP clients and your network, you can increase or decrease the lease duration to fit your specific needs. Determine what segments of your network have specific lease duration requirements, and decide how best to modify lease duration settings to improve DHCP performance on your network. You can set the lease duration in the Lease Duration page of the New Scope Wizard. For more information about using the New Scope Wizard, see “Creating Scopes” earlier in this chapter.
To set the lease duration after a scope is created
1. In the DHCP snap-in, select and right-click the scope you want to configure. 2. Select Properties. 3. In the Lease duration for DHCP clients box, adjust the lease time for the scope.
Increasing the Default Lease Duration
You can increase the lease duration in a scope to reduce network traffic. Increase the lease duration only if that segment of your network has a large number of IP addresses available and a configuration that rarely changes. Increasing lease duration reduces the rate at which IP addresses are reclaimed when changes occur. In a more stable environment, you can use a long lease, such as several months. This ensures both that addresses are ultimately recovered, and that DHCP-related network traffic is kept to a minimum.
Use caution when configuring unlimited lease durations. Even stable environments have a certain amount of client turnover. At a minimum, roving computers might be added and removed, desktop computers might be moved from one office to another, and network adapters might be replaced. If a client with an infinite lease is removed from the network, the DHCP server is not notified, and the IP address cannot be reused.
Reducing the Default Lease Duration
Reduce the lease duration for segments of your network that have any of the following: • • • A limited number of IP addresses available. Client configurations that change frequently. Clients that relocate often; for example, because they connect to conference rooms or wireless networks.
Although reducing the lease duration creates more DHCP-related network traffic, it increases the rate at which addresses are returned to the available address pool for reassignment. With an average volume of DHCP request traffic, Windows Server 2003 DHCP has a four-hour default grace period after which an expired lease can be reused. This means that an address is marked for deletion four hours after the lease expires, regardless of lease duration. When the volume of DHCP-related traffic is heavy and no leases are available to service lease requests, DHCP immediately instantiates a cleanup cycle, which reclaims any leases marked for deletion. By default, the cleanup cycle occurs every 60 minutes. You can adjust the duration of the default grace period after which an expired lease is marked for deletion by editing the following key in the registry:
Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.
Configuring DHCP Options
DHCP uses options to pass additional IP settings to DHCP clients on a network. Examples of DHCP options include: • • • The default gateway IP address The DNS server IP address The DNS domain name
You can configure DHCP options for specific values and enable them for assignment and distribution to DHCP clients based on server, scope, class, or reserved client levels. For example, you can enable the vendor class option Release on Shutdown for any laptops on your network to allow IP addresses assigned to mobile clients to be reincorporated into the address pool more quickly. You can configure options for an entire server, a scope, or for a single reserved client. The most specific options (reserved client) take precedence over the least specific options (server). Values configured manually on a client override any DHCP options of any type and of any level. Using the New Scope Wizard, you can configure some scope-level options, including router (default gateway), domain name, DNS servers, and WINS servers. You can also configure options at the server, scope, and reserved-client levels in the DHCP snap-in.
To configure server-level options
1. In the DHCP snap-in, expand the server for which you want to configure options. 2. Right-click Server Options, and then click Configure Options. 3. In the Server Options dialog box, select the options you want to configure. 4. In the Data Entry section of the Server Options dialog box, type the option parameters, and then click OK.
To configure scope-level options
1. In the DHCP snap-in, expand the scope for which you want to configure options. 2. Right-click Scope Options, and then click Configure Options. 3. In the Scope Options dialog box, select the options you want to configure. 4. In the Data Entry section of the Scope Options dialog box, type the option parameters, and then click OK.
To configure options for a reserved client
1. In the DHCP snap-in, expand the scope that holds the reservation for which you want to configure options, and then expand Reservations. 2. Right-click the reservation for which you want to configure options, and then click Configure Options. 3. In the Reservation Options dialog box, select the options you want to configure. 4. In the Data Entry section of the Reservation Options dialog box, type the option parameters, and then click OK. For more information about configuring reservations, see “Creating Reservations” later in this chapter.
Many option types are predefined in Windows Server 2003 DHCP. Other standard DHCP option types can be added as needed to support DHCP client software that recognizes or requires them. Windows Server 2003 DHCP supports all DHCP options, including those defined in RFC 2132, although most DHCP clients use or support only a small subset of the available option types. In general, use the following guidelines when configuring DHCP options for clients on your network: • • • Add or define new, custom option types only if you have new software or applications that require a nonstandard DHCP option. If your network is large, be conservative and selective when assigning global options. These options apply to all clients of a DHCP server, unless more specific options are specified. Use scope-level options for most options that clients are assigned. Setting options at the scope level allows you to take scope-related differences into account, such as different client needs or the use of a different DNS server from other scopes in the network. Use class-level options if you have a large network or diverse groups of clients that are able to support membership in option classes. Use reserved client options only for clients that have special requirements, for example, if your intranet has a DNS server that performs forwarding for resolving Internet DNS names not authoritatively managed on your network. In this case, you need to add the IP address of an external DNS server on your DNS server computer. You can configure your DNS server as a reserved client in DHCP and set this address as another reserved client option.
Configuring Option Classes
Windows Server 2003 DHCP includes vendor-defined and user-defined option classes. Use DHCP option classes to configure the parameters necessary for network clients to meet the special requirements of custom applications. Equipment from multiple vendors on a network can also use different option numbers for different functions. The option types used to support vendor-defined classes — the vendor class identifier and the vendorspecific option — are defined in the Internet DHCP options standard reference, RFC 2132. You can add and configure vendor-defined classes for submanaging DHCP options that are assigned to clients identified by vendor type. You can also add and configure user-defined classes for submanaging DHCP options that are assigned to clients identified by a common need for a similar DHCP option configuration. After you configure specific user-defined and vendor-defined options classes, you must configure scopes to assign the option classes to clients.
DHCP clients can use vendor-defined classes to identify the client’s vendor type and configuration to the DHCP server when obtaining a lease. For a client to identify its vendor class during the lease process, the client needs to include the vendor class ID option (option code 60) when it requests or selects a lease from a DHCP server. When vendor options are specified, the server performs the following additional steps to provide a lease to the client: 1. The server checks to see that the vendor class identified by the client request is a recognized class defined on the server. 2. If the vendor class is recognized, the server checks to see whether any additional DHCP options are configured for this class in the active scope. 3. If the vendor class is not recognized, the server ignores the vendor class identified in the client request, and returns options allocated to the default vendor class (includes all DHCP Standard Options). 4. If the scope contains options configured specifically for use with clients in this vendor-defined class, the server returns those options and uses the vendor-specific option type (option code 43) as part of its acknowledgment message. In most cases, the default vendor class — DHCP Standard Options — provides a default grouping for any Windows Server 2003 DHCP clients or other DHCP clients that do not specify a vendor class ID. In some cases, you might define additional vendor classes for other DHCP clients, such as printers or some types of UNIX clients. When you add other vendor classes for these purposes, be sure that the vendor class identifier that you use to configure the class at the server matches the identifier used by clients for your third-party vendor.
User-defined classes allow DHCP clients to specify what type of client they are, such as a remote access client or a desktop computer. For Windows Server 2003 clients, you can define specific user class identifiers to relate information about a client’s software configuration, its physical location in a building, or its user preferences. If user-defined option classes are not specified, default settings are assigned.
Configuring DHCP Option Parameters
When a DHCP server actively provides option parameters, clients receive and use the associated values in their local TCP/IP configurations for the period of leased configuration. By default, Microsoft-based DHCP clients can recognize and use two categories of option parameters: information options and protocol options.
Use the MMC DHCP snap-in to explicitly configure information options and any associated values provided to clients. These options are not required and can be assigned at your discretion. Use information options to assign values, such as DNS servers, WINS servers, and domain name.
Windows Server 2003 Protocol Options
You implicitly configure values for protocol options based on properties configured at either the applicable server or one of its scopes. These options are always included in DHCP client/server messages, as they are a required part of protocol design. For example, Lease Duration/Time is a protocol option. In most cases, the actual values included in these protocol options are provided to clients based on property settings for the applicable DHCP server. Depending on the needs of your clients, you can also use the DHCP snap-in to configure these options individually for defined scopes, identifying members of a specified user or vendor class, or for a single reserved client.
For clients that require a constant IP address, you can either manually configure a static IP address, or assign a reservation on the DHCP server. Reservations are permanent lease assignments that are used to ensure that a specified client on a subnet can always use the same IP address. You can use DHCP reservations for hosts that require a consistent IP address, but do not need to be statically configured. Reserved IP addresses differ from statically configured IP addresses in one significant manner: when network parameters are changed at the DHCP server, the device configured with a reserved IP address receives the new network parameters when the device requests renewal of its lease. To change network parameters on a device configured with a static IP address, the changes must be made manually to the device. Determine the clients for which you need to manually configure an IP address — such as DHCP server, DNS servers, WINS servers, routers, and domain controllers — and which clients can receive addresses from DHCP. Keep in mind that for clients for which you manually configure static IP addresses, you must insert all configuration parameters that the client requires in order to interact with the network. This includes IP addresses, DNS and WINS parameters, and default gateway information. Clients that have reserved IP addresses always have the same IP address, but still receive updated configuration information from the DHCP server. You might want to assign network printers and certain servers DHCP reservations to ensure that they always have the same IP address, but continue to receive updated configuration information from the DHCP server. For example, create reservations for servers that must always have the same IP address, such as: • • • • Windows Internet Name Service (WINS) and Domain Name System (DNS) servers Print servers that use TCP/IP print services Firewalls Routers
DHCP-enabled clients receive any available options, such as DNS server or router (default gateway), from the DHCP server when they renew their leases. If these devices are manually configured, an administrator must reconfigure each device individually when a change occurs.
To create a reservation
1. In the DHCP snap-in, expand the scope for which you want to create a reservation. 2. Select and right-click Reservations, and then click New Reservation. 3. In the New Reservation dialog box, enter the Reservation name, IP address, MAC address, and Description of the reservation. 4. Select the appropriate Supported types: DHCP only, BOOTP only, or Both. 5. Click Add.
A superscope is an administrative grouping of scopes that can support multiple logical IP subnets on the same physical subnet. Superscopes contain a list of member scopes that can be activated together. You cannot configure scope-level properties on superscopes; you must configure these on the member scopes. A superscope allows a DHCP server to provide leases from more than one scope to clients on a single physical network. You can use superscopes to resolve DHCP service issues for the following situations: • • • • • DHCP clients are located on a single physical network segment that includes multiple logical IP subnets. Multiple DHCP servers manage separate logical subnets on the same physical subnet. The available address pool for an active scope is nearly depleted and more computers must be added to the physical network segment. Clients are migrating to a new scope. You need to support DHCP clients on a network that has multiple logical subnets in one physical subnet on the other side of a BOOTP/DHCP relay agent.
Before you create a superscope, you must use the DHCP MMC snap-in to define at least one scope to be included in the superscope. Scopes added to a superscope are called member scopes. You can add additional member scopes either from the superscope menu, or from the individual scope menus.
To create a new superscope
1. In the DHCP snap-in, create at least one scope to be included in the superscope. For information about creating scopes, see “Creating Scopes” earlier in this chapter. 2. Select and right-click the DHCP server, and then select New Superscope. This opens the New Superscope Wizard.
3. On the Superscope Name page of the New Superscope Wizard, type a name for the superscope. 4. On the Select Scopes page of the New Superscope Wizard, in the Available Scopes list, select one or more scopes to include in the superscope.
To add scopes to an existing superscope
1. In the DHCP snap-in, select and right-click the superscope, and then select New Scope. This opens the New Scope Wizard. 2. Complete the New Scope Wizard. For information about creating scopes, see “Creating Scopes” earlier in this chapter. –or– 3. Create a new scope, right-click the new scope, and then select Add to Superscope. 4. In the Add Scope name to a Superscope dialog box, in the Available superscopes list, select the superscope.
Deleting the superscope does not delete the member scopes.
Configuring Multicast Scopes
Windows Server 2003 DHCP service offers MADCAP support in the form of multicast scopes. MADCAP supports dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks. Multicast scopes provide ranges of Class D IP addresses, which are reserved for multicast operation, by using directed transmission from one point to multiple points. With the exception of DHCP-assignable options, which multicast scopes do not support, you can configure a multicast scope in the same way that you configure a regular DHCP scope. Multicast IP addresses allow multiple clients to receive data that a server sends to a single IP address, enabling point-to-multipoint communication. This type of transmission is often used for streaming media transmissions, such as video conferencing.
In all TCP/IP networks, each computer requires a unique primary computer IP address from one of the standard address classes used for building the network (Class A, B, or C range). You must assign this required primary computer IP address before you can configure a computer to support and use secondary IP addresses such as multicast IP addresses.
Although the Windows Server 2003 DHCP service supports both DHCP and MADCAP, the services function independently; clients that do not obtain IP addresses from the DHCP service can still obtain MADCAP addresses from the DHCP service. DHCP scopes are used to allocate IP address ranges from Class A, B, or C addressing schemes, which enable unicast for point-to-point communication between networked computers. MADCAP scopes allocate Class D IP addresses to enable point-to-multipoint communication.
To configure a MADCAP scope
1. In the DHCP snap-in, select and right-click the DHCP server you want to configure. The New Multicast Scope Wizard appears. 2. In the New Multicast Scope Wizard, type a name and description for this multicast scope. 3. Set the multicast IP address range and Time to Live (TTL). 4. Add any exclusion ranges and the lease duration, then activate the multicast scope.
Clients that use MADCAP must be configured to use the MADCAP API. For more information about writing or programming applications that use the MADCAP API, see the MSDN Online link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Remove DHCP scopes when a subnet is no longer in use or when you need to renumber your network to use a different IP address range. Do not remove a scope while it has active leases. Before you remove a scope, deactivate the scope until all client leases expire or all lease renewal requests are denied. When you have confirmed that the scope no longer contains active leases, you can remove it by using the DHCP snap-in. For more information about deactivating scopes, see Deactivate a scope in Help and Support Center for Windows Server 2003.
Implementing Your DHCP Solution
After you have planned your DHCP solution and made the necessary configurations, you must implement your new or updated DHCP solution in your production environment. The DHCP implementation process involves the following steps: • • • Configuring your DHCP clients. Migrating existing DHCP servers, if necessary. Testing your DHCP solution.
Figure 2.8 shows the process for implementing your DHCP solution. Figure 2.8 Implementing Your DHCP Solution
Installing DHCP on Your Server
Install DHCP on your server either by using Manage Your Server or by adding DHCP from Add/Remove Windows Components. If you are migrating an existing DHCP server to a new Windows Server 2003–based server, install DHCP on the Windows Server 2003–based server before continuing with your migration. For more information about installing DHCP on your server, see “DHCP server role: Configuring a DHCP server,” “Installing a DHCP Server,” and “Checklist: Installing a DHCP server” in Help and Support Center for Windows Server 2003.
Migrating Existing DHCP Servers
If you already have a working DHCP infrastructure on your network, you can migrate your DHCP database and server configuration from your existing servers to new Windows Server 2003–based servers. Migrating can save you time because you do not need to reconfigure the scope, lease, and option information on the new server. Before migrating the database, create a backup of your working configuration, and test the migration procedures in a lab environment.
The following procedures migrate lease, scope, and option information, including reservations and exclusions. If you have changed any registry settings from their defaults on the existing server, you must manually make these changes on the new Windows Server 2003–based server for them to take effect.
The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or at http://www.microsoft.com/reskit.
Exporting DHCP Settings
When migrating from an existing DHCP server running Windows NT 4.0 or Windows 2000 Server, the first step is to export the current DHCP settings. Use the following procedure to export the DHCP database from an existing Windows NT 4.0–based server or a Windows 2000–based server.
To export the DHCP server settings from a Windows NT 4.0–based server or Windows 2000–based server
1. Run DHCPExim.exe. This opens the DhcpExim dialog box. To download and install DHCPExim.exe, see the Resource Kit Tools link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. 2. In the DhcpExim dialog box, select Export configuration of the local service to a file. 3. In the DHCPEXIM Export To File dialog box, enter a file name and location to save the file, and then click OK. The target location the file is shown in the DhcpExim Export dialog box. 4. In the DhcpExim Export dialog box, select all of the scopes on the list to migrate all settings on the server. Alternatively, you can only the specific scopes you want to export if you are not migrating the entire server. Select the Disable the selected scopes on local machine before export check box to disable the scopes on this server before exporting, and then click Export.
This step might take several minutes to complete, and there is no dialog box to indicate the progress of the export. You can view the process running on the Processes tab of the Windows Task Manager.
5. Click OK when a message appears that says “The operation was completed successfully.” 6. Copy the exported file to a location where you can access it from the new Windows Server 2003–based server.
Importing DHCP Settings
After exporting the DHCP settings and moving the exported file to a location where you can access it, you are ready to use the Netsh command-line tool to import the DHCP settings to the new DHCP server running Windows Server 2003. You might want to configure the new DHCP server to use the IP address that was formerly used on the old DHCP server. Before you do this, make sure to disconnect the old server from the network in order to avoid any IP address conflicts.
To import the DHCP server settings to Windows Server 2003–based DHCP server
1. Install DHCP on the Windows Server 2003–based server. DHCP must be installed before you can import the file. 2. At the command prompt, type:
netsh DHCP server import <path of export file> all
This imports the configurations of all scopes that you exported from the server running Windows NT 4.0 or Windows 2000. For more information about the Netsh command-line tool, see “Netsh” in Help and Support Center for Windows Server 2003.
Configuring DHCP Clients
When configuring your DHCP clients, it is important to consider the types of computers on each subnet of the network. For example, you might configure one subnet with a shorter lease duration for portable computer users. To configure a Windows client to obtain an IP address from the DHCP server, select Obtain an IP address automatically from the Internet Protocol (TCP/IP) Properties window. In addition to Windows-based clients, you can configure DHCP for UNIX, Linux, or Macintosh clients. Refer to the documentation for these operating systems to configure the clients for DHCP.
You can override DHCP information by configuring the individual client. Any information entered manually into a client’s TCP/IP configuration overrides dynamic settings.
Providing Support for Remote Access Clients
The remote access server can be configured to use DHCP to lease IP addresses in blocks of 10 from the DHCP server and store them in the registry. The remote access server leases additional addresses in blocks of 10 as needed. When passing the leases on to remote access clients, the remote access server discards the options configured for the scope. However, remote access clients receive WINS or DNS entries from the remote access server. This information is not taken from the DHCP options of the lease that the remote access client is using; it is taken directly from the settings of the remote access server. You can use a DHCP relay agent to provide DHCP scope options to remote access clients. In this situation, the remote access client continues to receive an IP address from the remote access server, but uses DHCPInform packets to obtain WINS addresses, DNS addresses, domain names, or other DHCP options.
DNS and WINS addresses obtained from DHCPInform packets override DNS and WINS addresses obtained from the remote access server.
For more information about using DHCP for remote access clients, see “Using Routing and Remote Access servers with DHCP” in Help and Support Center for Windows Server 2003 and article Q216805, “RAS Server Behavior When Configured to Use DHCP to Assign IP Addresses,” in the Microsoft Knowledge Base. For more information about configuring a DHCP relay agent to provide DHCP options to remote access clients, see article Q232703, “How to Use DHCP to Provide RAS Clients with DHCP Options,” in the Microsoft Knowledge Base. To find these articles, see the Microsoft Knowledge Base link on the Web Resources page at www.microsoft.com/windows/reskits/webresources.
Configuring Support for BOOTP Clients
Windows Server 2003 provides support for dynamic BOOTP, which allows you to provide BOOTP support without making a reservation for each BOOTP client. You can use DHCP to configure and support BOOTP clients. BOOTP clients can be configured to receive boot file information, or IP address information. You can also use DHCP to configure options for your BOOTP clients.
Configuring DHCP to Provide Boot File Information
To configure the DHCP service to provide boot file information to BOOTP clients, create BOOTP entries for each client-specific platform in the BOOTP table on the DHCP server. Information stored in the BOOTP table is returned to any BOOTP clients on the network that broadcast a BOOTP request message. If the BOOTP table includes at least one BOOTP entry, the DHCP service replies to BOOTP client requests. If no BOOTP entries are configured, the BOOTP client gets a lease, but no options or other information are passed to the BOOTP client. The reply message returned by the DHCP service indicates the name of a Trivial File Transfer Protocol (TFTP) server on the network and the location of the boot file. The client then contacts the TFTP server to retrieve the boot image file. BOOTP clients download the image file from a TFTP server. Because Windows Server 2003 does not provide a full TFTP file service, you might need to use a third-party TFTP server to support BOOTP clients that must start from an image file (usually diskless workstations).
Configuring DHCP to Provide IP Address Information
Windows Server 2003 allows you to designate a pool of addresses from which IP addresses for BOOTP clients are dynamically assigned, similar to the way that a scope is used for DHCP clients. After verifying that a specified lease time has elapsed and that the BOOTP client IP address is not still in use, the DHCP service can reclaim addresses used in the dynamic BOOTP address pool. To include BOOTP client support in your DHCP scope design, designate the DHCP scope as a BOOTP address pool or as both a DHCP and BOOTP address pool on the Advanced tab of the Scope Properties window in the DHCP snap-in. For more information about configuring a BOOTP address pool, see “Add Dynamic BOOTP Client Support to a Scope” in Help and Support Center for Windows Server 2003.
Configuring Options for BOOTP Clients
To retrieve all options, the client must specify option 55 (the Options Request List parameter) in the BOOTP request. Windows Server 2003 DHCP servers return as many options to BOOTP clients as can fit in a single datagram response. Because BOOTP only allocates 300 bytes for options, any options that exceed the 300 bytes are not sent. Therefore, when configuring options on a server that will service BOOTP clients, be aware of the size limitations for BOOTP response packets.
For more information about BOOTP options, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
DHCP options can apply to both DHCP and BOOTP clients. Therefore, you must configure your scopes to ensure that DHCP options are applied correctly.
Testing Your DHCP Solution
The ideal environment for validating a deployment plan is a test laboratory that is constructed to simulate your production environment. If you do not have a DHCP infrastructure in place, create a new DHCP infrastructure in the pilot lab. If you already have a DHCP infrastructure in place, recreate your existing infrastructure in the pilot lab and then test your migration and your updated solution. Use the following guidelines when testing your DHCP solution in the pilot lab: • Ensure that your test servers come from the same vendor and are configured in the same way as the servers that exist in your production environment. Represent all client computers that use DHCP in your organization in your pilot lab. Duplicate the network configuration of your organization in the pilot lab. If the network uses both Ethernet and Token Ring, you need to include both configurations in the test lab. If possible, set up a separate Windows Server 2003 domain for the lab so that you can monitor the performance of the domain controllers without interference from other network activity. If you are planning to deploy DHCP on a WAN, include routers in your lab design and use a link simulator to simulate network latency. Deploy a typical set of applications that run together in your production environment on the test server. This allows you to identify any interoperability issues that might arise when users run different applications simultaneously. Test your DHCP solution in burst traffic conditions. Make sure that all services on your servers continue to be available during burst traffic conditions, such as following a large-scale power outage, when many clients might restart simultaneously.
For more information about testing your design, see “Designing a Test Environment” in Planning, Testing, and Piloting Deployment Projects of this kit. Testing your DHCP solution in a pilot lab allows you to identify problems with your infrastructure, system configuration, or software. After you have tested your configuration thoroughly in a pilot lab, you can roll out your DHCP solution in your production environment.
Example DHCP Implementation
This DHCP example implementation depicts how a fictional company uses the Windows Server 2003–based DHCP servers to streamline and automate administration and assignment of IP addresses and other client configuration information. Though your network configuration might differ from this example, you can apply the basic concepts. The company has two offices, a main administrative office, and branch offices 25 miles away. The company employs 600 people, many of whom travel frequently between the two offices with portable computers. The main office is housed on two floors, with 75 desktop computer users per floor. Because many of these employees also have portable computers, conference rooms are configured with wireless networking. Wireless networking also provides ease of network connectivity to employees from the branch offices who are attending meetings at the main office.
Connectivity and Routing
A digital subscriber line (DSL) account at a rate of 1.1 megabits per second (Mbps) is established for each of the two company sites, providing a dedicated connection to the Internet through a DSL modem. Additional network adapters are installed on the server computers at both sites, one network adapter per subnet. The DSL-connected server in the main office has two additional network adapters, one for Subnet A and one for Subnet B. On Subnet A, network cable runs from the network adapter to a hub. On wireless Subnet B, media network cable runs from the network adapter to a hub, then to wireless access points stationed in conference rooms. The DSL-connected server computer in the branch office has four additional network adapters, one each for subnets C through F. On wireless subnet C, network cable runs from the network adapter to a hub, then to wireless access points stationed in conference rooms. On subnets D, E, and F, network cable runs from the network adapters to hubs that extend to each individual subnet. To provide secure, private, encrypted communication between the two sites over DSL, both DSL-connected servers are also configured as virtual private network (VPN) servers. To allow messages from both DHCP servers and DHCP clients to cross from site to site and between subnets at each site, the Routing and Remote Access service on the DSL-connected servers have the DHCP relay agent routing protocol installed and configured. For more information about connecting remote sites, see “Connecting Remote Sites” in this book.
Transmission Security Between Sites
Because the company wants the highest level of security available for the VPN connection that allows the two sites to communicate using their 1.1 Mbps DSL connections over the Internet, they install a Windows Server 2003 certification authority (CA) and establish a Layer Two Tunneling Protocol (L2TP) connection, relying on Internet Protocol security (IPSec) for encryption services. The combination of L2TP and IPSec is known as L2TP/IPSec. With certificate-based authentication and an L2TP/IPSec connection, the company is using the strongest form of authentication in Windows Server 2003. For more information about using a certification authority, see “Designing an Authentication Strategy” in the Designing and Deploying Directory and Security Services book of this kit. For more information about using IPSec, see “Deploying IPSec” in this book.
Active Directory Domain Structure
The company uses Active Directory to list IP addresses of DHCP servers authorized for operation on the network. If an unauthorized DHCP server running Windows 2000 or Windows Server 2003 is started on the network, it determines its authorization status from the directory service. If the server determines that it is not authorized, it stops functioning in the domain as a DHCP server, and cannot be used to provide IP address leases to clients. There are two sites to define in Active Directory, one at the main administrative site and one at the branch office site. Creating two sites optimizes the exchange of directory information and facilitates administration by centralizing resources such as configuration information.
Subnets and IP Addressing
Although the company employs approximately 600 people, most employees use both a desktop computer and a portable computer. Because the portable computers function primarily via wireless connections to the network, one subnet at each of the two company sites is configured as a wireless subnet. In all, there are six subnets on the company network, with 600 desktop clients and approximately 425 portable clients divided among the subnets as shown in Table 2.1. All subnets on the network are configured with the subnet mask 255.255.255.0. All six subnets are serviced by DHCP, with one DHCP server located at each site. The main office houses 150 employees dispersed over two floors of the building. All users also have portable computers that they frequently take to meetings in conference rooms. All of conference rooms are configured for wireless networking.
The company has divided the main office into two Class C subnets: • • Subnet A — Floors 1 and 2 Subnet B — Wireless subnet with wireless access points installed in conference rooms
The branch office houses 450 employees, dispersed throughout a three-story building. Over 200 users also have portable computers that they frequently take to meetings in conference rooms, all of which are configured for wireless networking. The company has divided the branch office into four Class C subnets: • • • • Subnet C — Wireless subnet for conference rooms Subnet D — Floor 3 Subnet E — Floor 2 Subnet F — Floor 1
Address Range 192.168.0.1/24 to 192.168.0.254/24 192.168.1.1/24 to 192.168.1.254/24 192.168.2.1/24 to 192.168.2.254/24 192.168.3.1/24 to 192.168.3.254/24 192.168.4.1/24 to 192.168.4.254/24 192.168.5.1/24 to 192.168.5.254/24 Approximate Number of Clients 150 Up to 225 Up to 225 150 150 150
Table 2.1 Address Range and Clients per Subnet
Subnet A B C D E F
Before creating and activating scopes on the DHCP server, the company plans IP address ranges, exclusion ranges, and reservations (where applicable) for each subnet. The company uses Class C IP address ranges on every subnet, as each Class C address range provides 254 IP addresses when the subnet mask is defined as 255.255.255.0. Because the client count per non-wireless subnet is 150 or fewer clients, 254 IP addresses per subnet allow the company to provide static address assignments for any servers that require them, and dynamic assignments to all clients on the network — with plenty of IP addresses remaining to provide for future network expansion. The wireless subnets are configured with a lease duration of 15 minutes. Because of the short lease time, 254 IP addresses per subnet is a sufficient amount for the wireless subnets, even though these subnets experience substantial traffic, with portable computers joining and leaving the subnet at high volume during a typical day. These short leases expire soon after the portable computer is disconnected from the network, and the IP address used by that computer becomes available for lease to other DHCP clients as they connect to the wireless subnet.
Some network devices need to use statically assigned IP addresses rather than addresses dynamically assigned through DHCP. For example, DHCP servers must have statically configured IP addresses. Also, some devices (such as legacy network printers) do not support DHCP. For the devices that need static IP assignments, the company creates an exclusion range from each IP address range. Creating one or more exclusion ranges prevents the DHCP server from assigning a client lease with any address in the exclusion range, thereby protecting it for use as a static IP address and preventing address conflicts between statically configured devices and dynamically configured devices. Although any addresses in the address range can be excluded, the company chooses to exclude the first 20 addresses from each address range for non-wireless subnets, and the first five IP addresses from each address range for wireless subnets. The company uses additional exclusion ranges to configure load balancing and fault tolerance using the 80/20 rule. For more information about DHCP scopes, see “Scope Configuration” later in this chapter.
After the address range and exclusion ranges are defined, the remaining addresses form the available address pool within the scope. These addresses are eligible for dynamic assignment by the server to DHCP clients on the network. Table 2.2 shows the address pool for each subnet prior to adding the exclusion ranges used to apply the 80/20 rule. Table 2.2 DHCP Address Pools per Subnet
Subnet A B (wireless) C (wireless) D E F Address Pool 192.168.0.21/24 to 192.168.0.254/24 192.168.1.6/24 to 192.168.1.254/24 192.168.2.6/24 to 192.168.2.254/24 192.168.3.21/24 to 192.168.3.254/24 192.168.4.21/24 to 192.168.4.254/24 192.168.5.21/24 to 192.168.5.254/24
For more information about DHCP scopes and the 80/20 rule, see “Scope Configuration” later in this chapter.
The company uses IP address reservations for file and print servers on their network. Reservations are used to create a permanent IP address lease assignment by the DHCP server. Reservations ensure that a specified hardware device on the subnet can always use the same IP address. When using the 80/20 rule and splitting a scope’s IP address pool between two servers for load balancing and fault tolerance, identical reservations must be made at both DHCP servers. When reservations are made at both servers, neither server assigns the reserved IP address to another client, assuring that the intended device receives the address reserved for its use. Table 2.3 shows two example address reservations. For more information about the 80/20 rule and for an example of how these reservations are created in specific scopes at each DHCP server, see “Scope Configuration” later in this chapter. Table 2.3 Example Address Reservations
Device Application server File server A D Subnet Reserved IP Address 192.168.0.21/24 192.168.3.68/24
Reservations can be created using any IP address in the scope’s address range, even if the IP address is also within an exclusion range. Because of this design, when the 80/20 rule is implemented and some addresses in the scope are excluded (80 percent at one server, 20 percent at the other), reservations still function properly.
The company uses DHCP relay agents to relay DHCP messages between subnets and sites. To support and use DHCP across multiple subnets, routers connecting each subnet should comply with DHCP/BOOTP relay agent capabilities described in RFC 1542. To cut the cost of expensive network hardware such as routers, the company uses the Windows Server 2003 Routing and Remote Access service including, DHCP relay agents, to forward DHCP/BOOTP messages between subnets. Because the VPN servers act as routers for network traffic, the DHCP relay agents are configured on the VPN servers. For more information about installing and configuring DHCP relay agents, see “Configure the DHCP Relay Agent” in Help and Support Center for Windows Server 2003.
Installing DHCP and Authorizing Servers in Active Directory
The company completes the following steps at both sites: 1. Configures the servers. 2. Installs the DHCP Server service. 3. Opens the DHCP snap-in from the MMC. 4. Authorizes the DHCP server in Active Directory. 5. Adds DHCP administrators to the DHCP Administrators group or the DHCP Users group, depending on their user rights. 6. Creates, configures, and activates one scope for each subnet. After creating scopes at the DHCP servers, the company defines a site in Active Directory for the branch office. Each of the six subnets is then associated with the appropriate site. When configuring your network, however, you can configure all sites in Active Directory before creating DHCP scopes.
By using the 80/20 split-scope configuration for fault tolerance and availability, scopes for all six subnets on the company network are defined on both DHCP servers. Exclusion ranges are used to allocate available addresses per scope, per server, as follows: • The main office DHCP server is configured with 80 percent of the IP addresses available for lease to clients in each scope serving subnets A and B and 20 percent of the IP addresses available for lease to clients located at the branch office (subnets C through F). The branch office DHCP server has 80 percent of all addresses in all scopes available for lease to clients in the branch office (subnets C through F) and 20 percent of all addresses in all scopes available for lease to clients located in the main office (subnets A and B).
Thus, if either server suffers a hard-disk failure or other failure, the alternate server is available to assign and renew leases on all subnets. To achieve the 80/20 rule, each Class C IP address range of 254 IP addresses available in each non-wireless scope is divided in the following manner: • • • 20 IP addresses for static assignments. 187 IP addresses, or 80 percent of the addresses for lease, in the address pool of the DHCP server at the same site. 47 IP addresses, or 20 percent of the addresses for lease, in the address pool of the DHCP server at the other site.
The wireless scopes are divided in the following manner: • • • 5 IP addresses for static assignments. 203 IP addresses, or 80 percent of the addresses for lease, in the address pool of the DHCP server at the same site. 51 IP addresses, or 20 percent of the addresses for lease, in the address pool of the DHCP server at the other site.
Table 2.4 shows the address pools and exclusion ranges configured on the main office DHCP server. Table 2.4 Scope Configurations on the DHCP Server at the Main Office
Scope Name A B (wireless) Address Range 192.168.0.1 to 192.168.0.254 192.168.1.1 to 192.168.1.254 192.168.2.1 to 192.168.2.254 192.168.3.1 to 192.168.3.254 192.168.4.1 to 192.168.4.254 192.168.5.1 to 192.168.5.254 Exclusion Ranges 192.168.0.1 to 192.168.0.20, 192.168.0.21 to 192.168.0.67 192.168.1.1 to 192.168.1.5, 192.168.1.204 to 192.168.1.254 192.168.2.1 to 192.168.2.203 Address Pool 192.168.0.68 to 192.168.0.254 192.168.1.6 to 192.168.1.203 192.168.2.204 to 192.168.2.254 192.168.3.21 to 192.168.3.67 192.168.4.21 to 192.168.4.67 192.168.5.21 to 192.168.5.67
D E F
192.168.3.1 to 192.168.3.20, 192.168.3.68 to 192.168.3.254 192.168.4.1 to 192.168.4.20, 192.168.4.68 to 192.168.4.254 192.168.5.1 to 192.168.5.20, 192.168.5.68 to 192.168.5.254
Table 2.5 shows the address pools and exclusion ranges configured on the branch office DHCP server. Table 2.5 Scope Configurations on the DHCP Server at the Branch Office
Scope Name A B (wireless) Address Range 192.168.0.1 to 192.168.0.254 192.168.1.1 to 192.168.1.254 Exclusion Ranges 192.168.0.1 to 192.168.0.20, 192.168.0.68 to 192.168.0.254 192.168.1.1 to 192.168.1.203 Address Pool 192.168.0.21 to 192.168.0.67 192.168.1.204 to 192.168.1.254
Table 2.5 Scope Configurations on the DHCP Server at the Branch Office (continued)
Scope Name C (wireless) Address Range 192.168.2.1 to 192.168.2.254 192.168.3.1 to 192.168.3.254 192.168.4.1 to 192.168.4.254 192.168.5.1 to 192.168.5.254 Exclusion Ranges 192.168.2.1 to 192.168.2.5, 192.168.2.204 to 192.168.2.254 192.168.3.1 to 192.168.3.20, 192.168.3.21 to 192.168.3.67 192.168.4.1 to 192.168.4.20, 192.168.4.21 to 192.168.4.67 192.168.5.1 to 192.168.5.20, 192.168.5.21 to 192.168.5.67 Address Pool 192.168.2.6 to 192.168.2.203 192.168.3.68 to 192.168.3.254 192.168.4.68 to 192.168.4.254 192.168.5.68 to 192.168.5.254
D E F
Subnet B in the main office and Subnet C in the branch office are both wireless subnets. Because wireless clients (portable computers and other portable devices) are connected to and disconnected from the network in large numbers and for short intervals throughout the average day, lease duration on these two subnets is set for 15 minutes. These short lease times help to ensure that the maximum number of IP addresses are available in the scope as clients connect to the network. Lease time for all other (nonwireless) subnets is eight days.
Each scope is configured with option 249, classless static routes. Using classless static routes, each DHCP client can be easily configured with the route to any destination on the network, and the subnet mask can be specified. Because each scope represents a physical subnet, the scope can be viewed as the start location for any message that is to be sent by a client to another subnet. The parameters used to configure option 249 are Destination, Mask, and Router. One or more static routes can be configured with option 249; the company provides all DHCP enabled clients on the network with routes to all other subnets using option 249. This option is not configured as a server option because it maps routes between subnets, so no one set of values for the required parameters of Destination, Mask, and Router is always correct. For example, subnets A and D each use a router (that is, a VPN server configured with the Routing and Remote Access service and DHCP Relay Agent service enabled) to communicate with each other. Of course, the routers they use are different, and the destination is different in each case.
The DHCP standard options shown in Table 2.6 are configured as server options at the main office DHCP server. Table 2.6 Example DHCP Options
Option Number 006 044 132 133 Description DNS servers WINS/NBNS servers Enable NBT hostname resolution Enable gethostbyname() WINS resolution Value 192.168.0.3, 192.168.3.3 192.168.0.4, 192.168.3.4 Byte: 0x1 (1=on) Byte: 0x1 (1=on)
Scopes on both DHCP servers are configured with the same reservations, lease durations, scope options, and server options.
These resources contain additional information and tools related to this chapter.
• The Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit) for more information about Dynamic Host Configuration Protocol (DHCP). “Dynamic Host Configuration Protocol” in the TCP/IP Core Networking Guide of the Microsoft® Windows® 2000 Server Resource Kit. “Deploying DNS” in this book. “Deploying IPSec” in this book. “Designing an Authentication Strategy” in the Designing and Deploying Directory and Security Services book of this kit for more information about using a certification authority. DHCP for Windows 2000, by Neall Alcott, 2001, Sebastopol, CA: O’Reilly & Associates. RFC 1542: Clarifications and Extensions for the Bootstrap Protocol. RFC 2131: Dynamic Host Configuration Protocol. RFC 2132: DHCP Options and BOOTP Vendor Extensions.
• • • • • • • •
• DHCPExim tool For more information about DHCPExim, see the Resource Kit Tools link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. • Netsh For more information about Netsh, in Help and Support Center for Windows Server 2003, click Tools, and then click Command-line reference A-Z.
Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox. • • • • • • • • “Checklist: Installing a DHCP server” in Help and Support Center for Windows Server 2003. “Checklist: Installing a DHCP Service resource” in Help and Support Center for Windows Server 2003. “Checklist: Installing a MADCAP server” in Help and Support Center for Windows Server 2003. “Cluster support for DHCP servers” in Help and Support Center for Windows Server 2003. “Configure the DHCP Relay Agent” in Help and Support Center for Windows Server 2003. “Netsh” and “Netsh commands for DHCP” in Help and Support Center for Windows Server 2003. “Add Dynamic BOOTP Client Support to a Scope” in Help and Support Center for Windows Server 2003. “Using Routing and Remote Access servers with DHCP” in Help and Support Center for Windows Server 2003.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.