An Example: Installing and Configuring a DHCP Server on Windows 2000/2003Installing a DHCP server on Windows 2000 or Windows 2003 Servers is just as simple as most application installs . However, you'll need to have some information ready before you begin the installation. You will need to know the range of addresses that the server will administer and lease to clients . If you have any servers on the network that need static addresses, you'll need to know those if they fall within the scope of the DHCP managed addresses. For example, DNS and WINS servers must have static IP addresses, and most DHCP servers do also. In a large network, you also should consider using multiple DHCP servers and enabling routers so that they can forward DHCP packets. Installing the DHCP Server Service on Windows 2000 or Server 2003In this section you will learn about installing DHCP on both Windows 2000 and Windows Server 2003 server platforms. To install the server, follow these steps:
You won't have to restart the computer to begin configuring the DHCP server.
Before the server can begin managing IP addresses on the network, you will have to authorize the server in the Active Directory and then configure a scope of addresses that the server can administer. Authorizing the ServerThe DHCP manager snap-in for the Microsoft Management Console utility is used to manage the DHCP service on the Windows server. For Windows 2000 click Start, Programs, Administrative Tools, DHCP. For Windows 2003 click Start, Administrative Tools, DHCP. The MMC utility pops up with the DHCP Management snap-in ready for you to use, as shown in Figure 29.2. Figure 29.2. The MMC DHCP snap-in is used to manage the DHCP service on the Windows 2000 Server.
On the left side of the management console is a tree structure that can be used to manage one or more DHCP servers from a central location. Click on the server that falls under DHCP and you'll see the Server Options folder for this particular DHCP server. After you click on the server, you'll notice that the icon to the left of the server name will change and a red arrow (pointing downward) will appear on top of the icon. This is a reminder that this server has not yet been authorized in the Active Directory. Windows 2000/2003 DHCP servers perform a process called rogue server detection . When a Windows 2000/2003 server boots and the DHCP service is started, it sends out a DHCPINFORM packet. Other DHCP servers, if any are configured on the network, reply with the DHCPACK message. Next, the service checks to see whether it is registered in the Active Directory. If it is not, it will not begin answering client requests . Figure 29.3 shows an example of the event log entry that the server makes when this occurs. Figure 29.3. The DHCP server will log an error in the system event log file if it is not authorized to run on your network.
The DHCP server undergoes this rogue server detection process once each hour . Thus, each DHCP server can keep track of other authorized DHCP servers on the network. Authorizing a server is simple:
Use the Refresh option from the Action menu to determine when the process has finished. The red arrow is replaced with a green arrow pointing upward. Using the MMC Action MenuTo configure a server, click once to highlight it, and then click the Action menu. The Action menu allows you to perform the following tasks if you select a particular DHCP server object:
When you first install the service, the first thing you need to do is create a scope of IP addresses that the DHCP server can use to allocate leases to its clients. After that, other options in the Action menu can be used to further configure the server. Creating an Address ScopeAfter you have authorized a server on the network, you can create a scope of addresses that the DHCP server can administer to clients. From the MMC utility, click once on the server you want to administer, and then select New Scope from the Action menu. The New Scope Wizard pops up. Alternatively, you can right-click the server and select New Scope. Click Next to dismiss the introductory dialog box and continue creating an address scope. The wizard then prompts you through the following steps:
If you did not choose to activate the scope, you can do so later by right-clicking on the scope and selecting Activate. Alternatively, click once on the scope and select Activate from the Action menu. In Figure 29.12 you can see the DHCP MMC snap-in after a scope has been created and activated. Figure 29.12. The new scope shows up in the right pane of the DHCP MMC snap-in utility.
The Status field in this display tells you whether the scope is active, and the Description field can be useful when you create multiple scopes and need a reminder of their use. After the scope has been activated, clients that boot on the network and that have been configured to use a DHCP server can now receive configuration information from this DHCP server. If you expand the scope by clicking on the plus sign in the left pane, you can see that there are four other objects that can be managed. Figure 29.13 shows the new scope with the Address Pool object selected. Figure 29.13. You can manage addresses, leases, reservations , and options offered by the scope using the DHCP MMC snap-in.
You can click on any of the other objects to see information. For example, if you want to see what options are enabled in this scope, click Scope Options. The option number (from the RFCs), name, and values for the options are displayed. In the case of this initial setup using the wizard, you would see options for the default router (gateway), DNS server, and domain name. If you entered an address for a WINS server, that option would also be displayed. Reserving a Client AddressYou can choose to exclude certain addresses from a scope that you know are configured manually, such as routers. However, you might want to use the Reservation method to reserve an address for a DHCP client that might need to keep the same IP address, but obtain other information from the DHCP server at times. A DNS server is a good example of a server that should have a reserved address. To reserve an address within a scope, expand the scope in the MMC console and open up the Reservation dialog box either by highlighting the Reservation object and selecting New Reservation from the Action menu, or by right-clicking the Reservations object and making the same selection. In Figure 29.14, you can see the simple dialog box used to create a reservation. Figure 29.14. You can identify specific computers that will have a reserved IP address on the DHCP server.
As discussed later in this chapter, assigning options to a reserved IP address gives the administrator the best method for fine-tuning what options the client will end up being offered by the DHCP server. Options associated with a reservation override all other options defined for the server, the scope, or any option class to which the computer might belong. Configuring the DHCP Server and Scope OptionsEarlier in this chapter, many options that can be used for BOOTP and DHCP clients were discussed. The Windows 2000/2003 DHCP service enables you to configure which options will be offered to clients of the service. To configure the options, expand the MMC tree of DHCP servers to locate the server you want to manage. Click that server to get to the Options Folder for that server. After you have highlighted the Options Folder, click the Action menu.
From the Action menu, select Configure Options. In Figure 29.15, you can see the default dialog box used for configuring options. Note that this dialog box has a General and an Advanced tab. Figure 29.16 shows the Advanced tab. Figure 29.15. You can configure the options that the server can present to clients using this dialog box.
Figure 29.16. The Advanced tab enables you to more precisely control the options that are offered to clients.
Because the server enables you to specify options for several levels, it is important to understand the precedence used to decide which options apply to a client. Options can be set for the following, and in this order:
Similarly, you can configure options for a scope if you did not do so during the initial creation of the scope. You also can use these same steps to change or add options to the scope. To change the options for a scope, expand the scope and select the Scope Options folder. Option ClassesIn Figure 29.15, the list of Available Options is the list of options that are defined for the current DHCP server, and they are mostly the same options you'll find in RFC 2132. Note that although the server can offer all these options, not all Microsoft clients can use this entire set of options, which is why the wizard prompted you for only a few options when it allowed you to select options for the newly created scope. The Advanced tab shown previously in Figure 29.17 enables you to look at the different classes of objects. You'll see a vendor class and a user class . Vendor classes are groupings of options that are useful for a particular vendor's client, such as Microsoft 98 or Windows NT clients. User classes are for grouping options that a particular class of users has in common; for example, BOOTP clients or Remote Access users. Figure 29.17. Select the scopes to include in the superscope .
If you define options for the server, the scopes you create will inherit them. A good place to start is to define the basic subset of options that all clients will need, if you have such a list, and configure these options for the server. Next, you can expand the particular scope and select the Scope Options folder to add or remove options that apply to a particular scope. SuperscopesIn the earlier example, only one scope of addresses was created on the DHCP server. The server is capable of handling additional address scopes, however, to provide for other clients that might be physically accessible to the DHCP server but use a different logical subnet address. To create a superscope, you first must create the scopes to be included in it. Use the same procedures as before to create the new scope, specifying its address range, options, and so on. Next, select New Superscope from the Action menu. A wizard pops up and again prompts you through the process:
Providing Support for BOOTP ClientsThe Windows 2000/2003 DHCP servers provide support for BOOTP clients. The Default BOOTP user class of options is used to configure the information that is supplied to these clients. Although standard BOOTP servers require that the server be configured in advance with a table of client hardware addresses and corresponding IP addresses, Windows 2000/Server 2003 DHCP servers instead select the next available address to give to a BOOTP client. This matches the method the DHCP server uses when granting IP address leases to its DHCP clients. Enabling the DHCP Relay AgentRFC 1542, "Clarifications and Extensions for the Bootstrap Protocol," defined support for a BOOTP relay agent. That agent now is supported by almost every router. The relay agent function enables you to support clients on different subnets, using a single BOOTP or DHCP server. DHCP requests are forwarded by the router to the DHCP server, and the server's responses are returned to the client. Because BOOTP and DHCP use almost the same frame format and the same UDP ports, you'll also find that most BOOTP relay agents will perform this duty for DHCP clients. However, on a small network, you might not have a router. Instead, you might be using the Routing and Remote Access services available in Windows 2000/2003 Servers. In that case, you'll need to add the DHCP Relay Agent protocol. Follow these steps to enable the DHCP Relay Agent:
When the relay agent receives a DHCP or BOOTP broadcast message on one of its network interfaces, which it can recognize because the packet is addressed to port 67, it will forward the message to a DHCP server. You can see an example of this in Figure 29.21. The DHCP server resides on Subnet 1, along with other servers. This subnet is connected to Subnet 2 using a routeror possibly a Windows 2000 server running the DHCP Relay Agent service. Figure 29.21. The DHCP Relay Agent can support clients on another subnet.
When Workstation A on Subnet 2 boots, it broadcasts a DHCPDISCOVER message using UDP. When the router sees this broadcast, it looks at the Gateway Address field (discussed earlier in this chapter, and not to be confused with a default gateway on a TCP/IP LAN). If the value for this field is all zeros (0.0.0.0), the relay agent service on the router will place its own address in this field. This enables the DHCP server to reply directly to the router when it replies to the DHCP or BOOTP request. The DHCP server looks at the Gateway Address field. It then consults its list of scopes to determine an appropriate address based on the value of the Gateway Address field and sends a DHCPOFFER packet back to the router, which then broadcasts the packet on Subnet 2. Remember that a broadcast is necessary in this case because at this time Workstation A knows its hardware address but doesn't yet have an IP address. If the client decides to accept the address offer, it sends a DHCPREQUEST message to the server, and the server responds with a DHCPACK acknowledgment granting the workstation the lease. What Is a DHCP Cluster?If you are using Windows 2000 Advanced Server or Windows Server 2003 Enterprise or Datacenter servers, you can use the clustering feature for DHCP. This allows two separate DHCP servers to be administered as a single DHCP server. Windows 2000/2003 clustering supports a failover mode in which a service running on one computer can be monitored . If the node that is supplying a DHCP service supported by the clustering software fails, another node that runs the same service can be activated to take over for the failed node. By clustering DHCP services between two nodes, you will make the network less prone to downtime due to problems with your DHCP server. The alternative to clustering is to use two separate DHCP servers, each responsible for a portion of the address scope. This allows all your clients to get an address from one or the other server. Because leases usually are measured in days or weeks on a stable network, the loss of a single DHCP server for a few hours or a day or so might not cause you any problems unless someone decides to reboot every PC on the network. A secondary server, configured with a smaller portion of the address space, can continue to handle DHCP traffic while the main server is repaired. In a larger network, however, where computers are frequently moved, a more stable DHCP service can be provided by hosting the DHCP service on a cluster. Keep the following points in mind when using a Windows cluster for the DHCP service:
In addition, keep in mind that the cluster itself must have a unique IP address, which can't be delegated to it by a DHCP server. Additionally, you'll need to create a domain security group and make both servers members. To this group, assign Full Control permissions for the DNS zone object in the Active Directory where DHCP A and PTR records are stored for the servers' clients. Using Windows clusters is the subject of many books. Before you decide to use a cluster on your network, I would recommend that you become intimately familiar with Windows clusters. There are many aspects of clustering (such as the utilities used to start/stop and otherwise manage the cluster) that you need to learn before you try to set DHCP and the clustering software. Considerations for Using DHCP in Large or Routed EnvironmentsIn a large network you need to provide for redundancy for DHCP servers. Because a larger network typically is connected using routes to join a diverse set of network segments, you will need to enable BOOTP and DHCP forwarding on any routers in the network. Each DHCP server will need to be carefully planned, and the address scopes, reservations, and exclusions will need to be carefully thought through in advance. You don't want, for example, a DHCP server to allocate an address to a client when that address should have been reserved and already is in use by another server! This is exactly the kind of thing automatic dispensing of IP addresses is supposed to solve. Of course, when you're planning the placement of DHCP servers in a large, routed environment, it's easiest to place a single DHCP server on each subnet. In many cases, though, this is not practical. And with the forwarding capabilities it is not necessarily needed. Also, don't yield to the temptation of placing all your DHCP servers on the same subnet, allowing them to receive forwarded replies from other network segments. If the single subnet becomes unavailable, all your DHCP servers become unavailable. This applies to any major server. Don't place all your eggs in one basket , so to speak. How DHCP Interacts with Microsoft's Dynamic Domain Name Service (DNS)Microsoft's version of DNS supports dynamic updates, as specified in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)." Windows 2000 clients can send dynamic updates after having received configuration information from a DHCP server. When a DHCP lease expires , the client will send an update to deregister the addressing information. To register with DNS, the client first contacts a name server. If the name server is just a local server and is not authoritative for the zone, it will return the address of the authoritative server to the client. The client then will contact the primary authoritative server to send it the updated addressing information. If it's successful, a reply is sent back to the client. The DHCP server also can be used to send dynamic updates to DNS. This is useful for preWindows 2000 clients that do not understand the dynamic update process. This also can be negotiated between the DHCP server and a Windows 2000 client during the initial DHCP process. This is done using a special FQDN (fully qualified domain name) DHCPREQUEST packet (using Option number 81). This packet has three possible flags that can be set:
For more information about A and PTR records that are used in the DNS database, see Chapter 30. These flags are not all that controls the process of which computer performs which updates. Instead, both the client and the server can be configured to perform (or not perform) this function. Configuring Dynamic Updates on the DHCP ServerOn the server side, you can specify in the properties page for the server how it will respond to dynamic update requests, and whether it will perform dynamic updates for clients that do not support this function (that is, preWindows 2000 clients). To configure the service for this functionality, follow these steps:
Configuring Dynamic Updates on the ClientYou also can control how the client handles the dynamic DNS update function if you are using Windows 2000 clients. Remember from the preceding section that the server can override a client's request if the appropriate selection is made on the scope's DNS properties page. Windows 2000 clients and servers, as well as Windows XP and Windows Server 2003, are already configured, by default, to send the FQDN packet with the Flags field set to zero. This means the client wants to update the A resource record and wants the server to update the PTR record. You can change this behavior by doing the following:
Reservations and ExclusionsSome computers or other networked devices, such as routers or printers, might need to keep the same IP address all the time. For example, Microsoft very strongly suggests you be sure that your DHCP server has a static, unchanging address. There are two ways you can be sure a particular computer or device keeps the same static address. The first method is to manually configure the client using the client's software. For example, when you configure a Microsoft Windows 2000 Professional client or a Windows XP client, you can specify a static IP address (along with other network information) using the TCP/IP properties page for the client. If you use the first method, you'll need to exclude the address you use from the address pool that you assign to a scope. If you forget this step and the address does fall within the range of a scope, eventually it will be issued to a client, causing a duplicate address error on the LAN. A reservation is similar to an exclusion but is used for computers or devices that do support DHCP but still require a constant, static address. You can enter a reservation for an address that falls within the address pool for a scope. The reservation is linked to the computer or device's hardware address so that when it boots and begins the process of obtaining configuration information via DHCP, it will always receive the same address. Exclusions are created when you create the address pool, as explained earlier in this chapter. To create a reservation, carry out these steps:
Note in this example the reservation was made for a router. Other types of devices for which you might want to reserve addresses (or exclude if the computers are statically configured) are important servers that are mapped to specific addresses in your DNS system. Also, if you have non-Windows clients, such as Linux or Unix desktops or servers, you might want to reserve an address for them if they cannot use DHCP. What Is APIPA?If a client is configured to use DHCP, what happens if no DHCP server is available on the network? In that case, Microsoft Windows 2000 clients can use Automatic Private IP Addressing (APIPA). This is not a solution for a large network. It is for use on small LANs, such as a home office with 25 or fewer network nodes. Simply configure each client computer to use DHCP in the properties page for TCP/IP, and reboot. When the client computer realizes that no DHCP server is on the network (because it's not receiving any replies from its broadcasts), it will timeout and begin to use APIPA. The scheme in which addresses are allocated is not that complicated. The network of addresses reserved for use by APIPA is 169.254.0.1 to 169.254.255.254, with a subnet mask of 255.255.0.0. When the client does not receive an answer from any DHCP server after a short time, it will select an address randomly from this network. It then will test to see whether this address is already in use.
Note that a Microsoft client that is using APIPA will periodically check the network (about every five minutes) to see whether a DHCP server has become available. If one does come online, the client will perform as any other DHCP client and obtain configuration information from the DHCP server it discovers. Because clients randomly choose IP addresses, it is always quite possible that one computer will choose an address already in use. To solve this problem, each computer first chooses an address and then broadcasts a packet containing that IP address and waits to see whether another computer replies that the address is already in use. This is referred to as gratuitous ARP. When this occurs, a client will attempt to select an IP address up to 10 times before ending the process. Troubleshooting Microsoft DHCPTroubleshooting DHCP can be a complicated process. Perhaps you've forgotten to authorize the server on the network or activate a scope. Clients might be unable to locate the server. In any case, there are several things you can do to troubleshoot DHCP problems. With the client, start by using the ipconfig /all command at the command prompt to view IP configuration data. If the client shows either no address or an address of 0.0.0.0, a problem exists between the client and the server. It might be a network card, a misconfigured router, or another network component. Use the standard TCP/IP tools (that is, ping or tracert) from another client on the same subnet to the DHCP server to see whether connectivity exists. If you can't reach the DHCP server from that client, try the same tests from other clients on other subnets to help localize where in the network the problem lies. Two other useful tools for troubleshooting are the Windows 2000 Event Logs and the DHCP server's own audit log file. Earlier in this chapter you saw an example of an event log entry. In the next section you'll learn how to enable the DHCP server's own logging capabilities. Managing LoggingBesides the records that the DHCP server records in the event log, you also can enable logging by the server to its own log file. For troubleshooting purposes, both the event log and the server's own log file can be very useful. To manage the server's log file, follow these steps:
When you enable audit logging, a new log file is created at midnight each day. Header information is written to the file and significant events are logged. The format for the filename used for log files is DhcpSrvLog. day of week . For example, a log file created on Monday morning would be named DhcpSrvLog.Mon . Because the day of the week is used as the file extension for the log file, it should be obvious that in a week you'll have to overwrite an existing file. Indeed, this is what happens, unless the file has been modified within the past 24 hours. If this happens, logging will be suspended until the file is removed or renamed . The log file is a simple ASCII text file using comma-delimited fields. Each event is recorded as a single line in the file, using the fields ID, Date, Time, Description, IP Address, Host Name, MAC Address which are as described here:
The standard event IDs are as listed here:
As you can see, a significant amount of information is stored in the log files. Start your troubleshooting efforts here if you are experiencing problems with the server itself or with multiple clients. You can follow the trail of events leading up to the current problem. Again, if you are having problems with a single client, examine the event log file on the client to look for any indication that the client was unable to locate or interact with the DHCP server. |