DHCP

Dynamic Host Configuration Protocol (DHCP) is a TCP/IP standard designed to reduce the complexity of administering address configurations by using a server computer to centrally manage IP addresses and other related configuration details used on your network. Windows 2000 Server provides the DHCP service, which enables the server computer to perform as a DHCP server and configure DHCP-enabled client computers on your network as described in the current DHCP draft standard, RFC 2131.

  • Before you begin using a DHCP server with this computer, see the Checklist: Installing a DHCP server.
  • To find features that have been moved in Windows 2000 Server, see New ways to do familiar tasks.
  • For tips about using DHCP, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklist: Installing a DHCP server

Step | Reference
Review DHCP concepts such as scopes, leases, and options.

Important

  • If you are operating in a domain environment under an earlier version of Windows NT Server, it is recommended that you first upgrade your domain controllers to Windows 2000 Server before installing DHCP on your network.
 DHCP terminology
Determine the IP address range or ranges for which DHCP will be needed to provide configuration service on your network. | Configuring scopes
Manually configure TCP/IP properties for the DHCP server computer. | To configure TCP/IP for static addressing
Install the DHCP server. | To install a DHCP server
Open the DHCP console. | To open the DHCP console
Authorize the DHCP server in Active Directory. | To authorize a DHCP server in Active Directory
If the DHCP server is multihomed, disable service bindings for any connection not to be used to listen and provide service to clients. | To selectively set DHCP server bindings for network connections; Multihomed DHCP servers
Set DNS dynamic update policy for the DHCP server. | To enable DNS dynamic updates for clients
If you are using multiple scopes, configure any default option types for the server that should be inherited by all additional scopes. | To assign a server-based option
Create a new scope and assign commonly used options, such as WINS and DNS servers. | To create a new scope; Configuring scopes; Commonly used options
Configure additional scope option types, if needed. | To assign a scope-based option; Assigning options
Add reservations for clients that require a reserved IP address assigned by DHCP, if needed. | To add a client reservation
Exclude additional IP address ranges that should not be leased for this scope, if needed. | To exclude an address from a scope
Activate the scope. | To activate a scope
Configure and assign option classes, if needed. | Using option classes
Define additional option types, if needed. | To define a new option; Assigning options
Adjust the length of lease durations, if needed. | To change or view scope properties; Managing leases
If you need to implement support for more than one logical network for each physical network, create and use superscopes as necessary to support your DHCP network configuration. | To create a superscope; Using superscopes
For routed networks, determine if you need to implement relay agents or update routers, and if so, review possible relay agent configurations and related design issues. | DHCP/BOOTP relay agents
Create multicast scopes, if needed. | To create a multicast scope; Using multicast scopes
Configure the BOOTP table if you want to support BOOTP clients on your network. | Supporting BOOTP clients; To add an entry to the BOOTP table; To view the BOOTP table
Verify DHCP service to clients, if needed. | To verify, release, or renew a client address lease
For Windows 2000 clients, disable automatic address configuration, if necessary. | To disable automatic address configuration
Use System Monitor to track DHCP server performance. | Monitoring server performance; Using Performance
If desired, add DHCP administrators or users to specially created local groups available for limiting access to the DHCP server. | New features
Troubleshoot and resolve common DHCP-related problems. | Troubleshooting
Review DHCP server audit log files to help troubleshoot a problem. | Analyzing server log files


Checklist: Installing a MADCAP server

Step | Reference
Review Multicast Address Dynamic Client Allocation Protocol (MADCAP) concepts such as IP multicasting and multicast address allocation. | Multicast address allocation; Understanding multicasting
Determine the multicast IP address range or ranges for use in your MADCAP server configuration. The ranges you select depend on whether you need to use administrative local scooping or global scooping practices to provide multicast address allocation service on your network. | Determining the ranges to use for multicast scopes
Manually configure TCP/IP properties for the DHCP (MADCAP) server computer. | To configure TCP/IP for static addressing
To install a MADCAP server, install the DHCP Server service.

Important

  • The DHCP Server service can be used to deploy MADCAP servers independently of how DHCP servers are used on your network. For example, to install Windows 2000 DHCP for MADCAP service only:
    1. Create multicast scopes.
    2. Do not create other scopes or superscopes.

    Only where other scopes or superscopes are configured, does the server computer also function as a DHCP server.

 To install a DHCP server
Open the DHCP console. | To open the DHCP console
Authorize the DHCP (MADCAP) server in Active Directory. | To authorize a DHCP server in Active Directory
(optional) If the DHCP (MADCAP) server is multihomed, you can disable service bindings for any connection not to be used to listen and provide service to DHCP (MADCAP) clients. | To selectively set DHCP server bindings for network connections; Multihomed DHCP servers
Create a multicast scope. | To create a muticast scope
If necessary, you can additionally manage multicast IP address allocation by creating and removing scopes, or by modifying multicast scope properties, such as scope TTL and lifetime settings as needed. | Manage multicast scopes
(optional) For additional fault tolerance, you can implement DHCP clustering support using a server cluster.

Note

  • DHCP clustering servers are implemented using the Clustering service, which is only provided with Windows 2000 Advanced Server.
 Cluster support for DHCP servers


New ways to do familiar tasks

The following table lists common tasks for managing DHCP servers using the DHCP console and shows where you can perform these tasks in Windows 2000 Server. For current DHCP console users, the table also shows where these tasks are performed in Windows NT Server 4.0.

If you want to | In Windows NT 4.0 use | In Windows 2000 use
Install a DHCP server on this computer | Network in Control Panel | Add/Remove Programs For more information, see To install a DHCP server.
Start the DHCP console | Click Start, point to Administrative Tools, then click DHCP Manager. | The DHCP console. For more information, see To open the DHCP console.
Authorize a DHCP server in Active Directory prior to use. | Not available in Windows NT Server 4.0. | Log on first as a user who is a member of the Enterprise Administrators group for the enterprise where you need to authorize the server. For more information, see To authorize a DHCP server in Active Directory.
Start or stop a DHCP server | Services in Control Panel | The DHCP console. For more information, see To start or stop a DHCP server.
Add a server to the DHCP console to manage. | Server menu in DHCP Manager. | The DHCP console. For more information, see To connect to a DHCP server.
Add and configure a scope for a DHCP server. | Create option on Scope menu in DHCP Manager. | The DHCP console. For more information, see To create a new scope.


Best practices

  • Use the 80/20 design rule for balancing scope distribution of addresses where multiple DHCP servers are deployed to service the same scope.

    Using more than one DHCP server on the same subnet provides increased fault tolerance for servicing DHCP clients located on it. With two DHCP servers, if one server is unavailable, the other server can take its place and continue to lease new addresses or renew existing clients.

    A common practice when balancing a single network and scope range of addresses between two DHCP servers is to have 80 percent of the addresses distributed by one DHCP server and the remaining 20 percent provided by a second. For more information and an example of this concept, see Configuring scopes.

  • Use superscopes for multiple DHCP servers on each subnet in a LAN environment.

    When started, each DHCP client broadcasts a DHCP discover message (DHCPDISCOVER) to its local subnet to attempt to find a DHCP server. Because DHCP clients use broadcasts during their initial startup, you cannot predict which server will respond to a client's DHCP discover request if more than one DHCP server is active on the same subnet.

    For example, if two DHCP servers service the same subnet and its clients, clients can be leased at either server. Actual leases distributed to clients can depend on which server responds first to any given client. Later, the server first selected by the client to obtain its lease might be unavailable when the client attempts to renew.

    If renewal fails, the client then delays trying to renew its lease until it enters the rebinding state. In this state, the client broadcasts to the subnet to locate a valid IP configuration and continue without interruption on the network. At this point, a different DHCP server might respond to the client request. If this occurs, the responding server might send a DHCP negative acknowledgement message (DHCPNAK) in reply. This can occur even if the original server that first leased the client is available on the network.

    To avoid these problems when using more than one DHCP server on the same subnet, use a new superscope configured similarly at all servers. The superscope should include all valid scopes for the subnet as member scopes. For configuring member scopes at each server, addresses must only be made available at one of the DHCP servers used on the subnet. For all other servers in the subnet, use exclusion ranges for the same scope ranges of addresses when configuring the corresponding scopes.

    For more information, see Using superscopes.

  • Deactivate scopes only when removing a scope permanently from service.

    Once you activate a scope, it should not be deactivated until you are ready to retire the scope and its included range of addresses from use on your network.

    Once a scope is deactivated, the DHCP server no longer accepts those scope addresses as valid addresses. This is only useful when the intention is to permanently retire a scope from use. Otherwise, deactivating a scope causes undesired DHCP negative acknowledgement messages (DHCPNAKs) to be sent to clients.

    If the intent is only to affect temporary deactivation of scope addresses, editing or modifying exclusion ranges in an active scope achieves the intended result without undesired results.

    For more information, see Manage scopes.

  • Use server-side conflict detection on DHCP servers only when it is needed.

    Conflict detection can be used by either DHCP servers or clients to determine whether an IP address is already in use on the network before leasing or using the address.

    For DHCP clients running Windows 2000 and earlier versions, client computers that obtain an IP address use a gratuitous ARP request to perform client-based conflict detection before completing configuration and use of a server offered IP address. If the DHCP client detects a conflict, it will send a DHCP decline message (DHCPDECLINE) to the server.

    If your network includes legacy DHCP clients, you can use server-side conflict detection provided by the DHCP Server service under specific circumstances. For example, this feature might be useful during disaster recovery when scopes are deleted and recreated. For more information, see Troubleshooting.

    By default, the DHCP service does not perform any conflict detection. To enable conflict detection, increase the number of ping attempts that the DHCP service performs for each address before leasing that address to a client. Note that for each additional conflict detection attempt that the DHCP service performs, additional seconds are added to the time needed to negotiate leases for DHCP clients.

    Typically, if DHCP server-side conflict detection is used, you should set the number of conflict detection attempts made by the server to use one or two pings at most. This provides the intended benefits of this feature without decreasing DHCP server performance.

    For more information, see To enable address conflict detection.

  • Reservations should be created on all DHCP servers that can potentially service the reserved client.

    You can use a client reservation to assure that a DHCP client computer always receives lease of the same IP address at its startup. If you have more than one DHCP server reachable by a reserved client, add the reservation at each of your other DHCP servers.

    This allows the other DHCP servers to honor the client IP address reservation made for the reserved client. Although the client reservation is only acted upon by the DHCP server where the reserved address is part of the available address pool, you can create the same reservation on other DHCP servers that exclude this address.

    For more information, see To add a client reservation.

  • For server performance, note that DHCP is disk-intensive and purchase hardware with optimal disk performance characteristics.

    DHCP causes frequent and intensive activity on server hard disks. To provide the best performance, consider RAID solutions when purchasing hardware for your server computer that improves disk access time.

    When evaluating performance of your DHCP servers, you should evaluate DHCP as part of making a full performance evaluation of the entire server. By monitoring system hardware performance in the most demanding areas of utilization (CPU, memory, disk input/output), you obtain the best assessment of when a DHCP server is overloaded or in need of an upgrade.

    Note that for Windows 2000 Server, the DHCP service includes several new System Monitor counters that can be used to monitor service. For more information, see Monitoring server performance.

  • Keep audit logging enabled for use in troubleshooting.

    By default, the DHCP service enables audit logging of service-related events. With Windows 2000 Server, audit logging provides for a long-term service monitoring tool that makes limited and safe use of server disk resources. For more information, see Audit logging.

    For more information on interpreting server audit log files, see Analyzing server log files.

  • Reduce lease times for DHCP clients that use Routing and Remote Access service for remote access.

    If Routing and Remote Access service is used on your network to support dial-up clients, you can adjust the lease time on scopes that service these clients to less than the default of three days. For Windows 2000, one recommended way to support remote access clients in your scopes is to add and configure the built-in Microsoft vendor class provided for identifying them. For more information, see Supporting Routing and Remote Access clients.

  • Increase the duration of scope leases for large, stable, fixed networks if available address space is plentiful.

    For small networks (for example, one physical LAN not using routers), the default lease duration of three days is a typical period. For larger routed networks, consider increasing the length of scope leases to a longer period of time, such as 7-21 days. This can reduce DHCP-related network broadcast traffic, particularly if client computers generally remain in fixed locations and scope addresses are plentiful (at least 20 percent or more of the addresses are still available).

  • Integrate DHCP with other services, such as WINS and DNS.

    WINS and DNS can both be used for registering dynamic name-to-address mappings on your network. To provide name resolution services, you must plan for interoperability of DHCP with these services. Most network administrators implementing DHCP also plan a strategy for implementing DNS and WINS servers.

  • For routed networks, either use relay agents or set appropriate timers to prevent undesired forwarding and relay of BOOTP and DHCP message traffic.

    If you have multiple physical networks connected through routers, the routers must be capable of relaying BOOTP and DHCP traffic. If you do not have such routers, you can set up the DHCP Relay Agent component on at least one computer running Windows 2000 server (or Windows NT Server) in each routed subnet. The relay agent relays DHCP and BOOTP message traffic between the DHCP-enabled clients on a local physical network and a remote DHCP server located on another physical network.

    When using relay agents, be sure to set the initial time delay in seconds that relay agents wait before relaying messages on to remote servers. For more information on DHCP relay agents, see DHCP/BOOTP relay agents.

  • Use the appropriate number of DHCP servers for the number of DHCP-enabled clients on your network.

    In a small LAN (for example, one physical subnet not using routers), a single DHCP server can serve all DHCP-enabled clients. For routed networks, the number of servers needed increases, depending on several factors, including the number of DHCP-enabled clients, the transmission speed between network segments, the speed of network links, whether DHCP service is used throughout your enterprise network or only on selected physical networks, and the IP address class of the network. For more information on determining how many DHCP servers to set up, see Planning DHCP networks.

  • For dynamic updates performed by the DHCP service, use the default client preference settings.

    For Windows 2000 Server, the DHCP service performs dynamic updates for DHCP clients based on how clients request them to be done. This setting provides the best use of the DHCP service to perform dynamic updates on behalf of its clients as follows:

    • Client computers running Windows 2000 explicitly request that the DHCP server only update pointer (PTR) resource records used in DNS for the reverse lookup and resolution of the client's IP address to its name. These clients update their address (A) resource records for themselves.
    • Clients running earlier Windows versions cannot make an explicit request for DNS dynamic update protocol preference. For these clients, the DHCP service updates both the PTR and the A resource records for the client.
  • Follow the recommended process for moving a DHCP server database from old server computer hardware to new hardware.

    Moving a DHCP server database can be problematic. To manage moving the server database more easily, choose and follow a process tried and used by Microsoft Product Support Services such as the following:

    • For restoring server data at the same server computer, see Restoring server data.
    • For moving DHCP server data to another server computer, such as in the case of hardware failure or disaster recovery, see Moving a DHCP database to another server.
  • Before you install a DHCP server, identify the following:
    1. The hardware and storage requirements for the DHCP server.

      For more information, see Planning DHCP networks.

    2. Which computers you can immediately configure as DHCP clients for dynamic TCP/IP configuration and which computers you should manually configure with static TCP/IP configuration parameters, including static IP addresses.

      For more information, see Checklist: Installing and configuring TCP/IP.

    3. The DHCP option types and their values to be predefined for DHCP clients.

      For more information, see Assigning options.


How to...

  • Install and administer servers
  • Manage server access
  • Monitor and configure servers
  • Manage scopes
  • Manage superscopes
  • Manage multicast scopes
  • Manage options and classes
  • Manage clients and leases
  • Manage reservations and reserved clients
  • Manage BOOTP and remote access clients
  • Use DHCP command-line tools


Install and administer servers

  • Install a DHCP server
  • Open the DHCP console
  • Connect to a DHCP server
  • Disconnect from a DHCP server
  • Start or stop a DHCP server
  • Reconcile the DHCP database
  • Manually compact or repair the DHCP database
  • Remove or uninstall DHCP


Install a DHCP server

To install a DHCP server

  1. Open Windows Components wizard.
  2. Under Components, scroll to and click Networking Services.
  3. Click Details.
  4. Under Subcomponents of Networking Services, click Dynamic Host Configuration Protocol (DHCP), and then click OK.
  5. If prompted, type the full path to the Windows 2000 distribution files and click Continue.

    Required files are copied to your hard disk. Server software can be used after restarting the system.

Notes

  • To open the Windows Component wizard, from the desktop, click Start, point to Settings, and click Control Panel.

    When Control Panel opens, double-click Add/Remove Programs and then click Add/Remove Windows Components.

  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.
  • It is strongly recommended that you manually configure the computer to use a static IP address.

Related Topics


Open the DHCP console

To open the DHCP console

  • Open DHCP.

Notes

  • The DHCP console is an administrative tool for managing DHCP servers. For more information, see Related Topics.

Related Topics


Connect to a DHCP server

To connect to a DHCP server

  1. Open DHCP.
  2. In the console tree, click DHCP.
  3. On the Action menu, click Add Server.
  4. Select either this server or another authorized DHCP server to which to connect.

    For more information on specific items in this dialog box, click What's This? and then click the item.

Notes

  • If you are operating DHCP in an Active Directory environment and are connecting to a server for the first time, you need to first authorize the new DHCP server in the directory service. For more information, see Related Topics.
  • If DHCP is installed and running on this computer, you do not need to make a manual connection using the wizard. In most cases, the local DHCP server automatically appears in the list of servers when the DHCP console starts, and you connect to the server by clicking it in the console tree.
  • Only users belonging to the DHCP Users, DHCP Administrators, or Administrators groups can connect to a DHCP server. Only users in the DHCP Administrators or Administrators groups can modify the DHCP server configuration.

Related Topics


Disconnect from a DHCP server

To disconnect from a DHCP server

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Delete.
  4. When prompted to confirm removing the server, click Yes.

Note

Related Topics


Start or stop a DHCP server

To start or stop a DHCP server

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, point to All Tasks and then click one of the following:
    • To start the service, click Start.
    • To stop the service, click Stop.
    • To interrupt the service, click Pause.
    • To stop and then automatically restart the service, click Restart.

Notes

  • After you pause or stop the server, the Resume option appears and can be clicked to immediately resume service.
  • You can also perform most of these tasks at a command prompt by using the following commands:
    • net start dhcpserver
    • net stop dhcpserver
    • net pause dhcpserver
    • net continue dhcpserver

Related Topics


Reconcile the DHCP database

To reconcile the DHCP database

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Reconcile All Scopes.
  4. In the Reconcile Database dialog box, click Verify.

    Inconsistencies found are reported in the status window.

  5. If the database is found to be consistent, click OK.

    If the database is not consistent, select the displayed addresses that need to be reconciled, and click Reconcile to repair inconsistencies.

Notes

  • For more information, see Related Topics.

Related Topics


Manually compact or repair the DHCP database

To manually compact or repair the DHCP database

  1. At a DHCP server computer, open a command prompt.
  2. Use the Jetpack.exe command-line utility to perform offline compaction.

    The correct syntax for Jetpack.exe is:

    jetpack database_name temporary_database_name

    These are example commands to compact the DHCP database:

       cd %systemroot%\system32\dhcp
   net stop dhcpserver
   jetpack dhcp.mdb tmp.mdb
   net start dhcpserver

Notes

  • In the examples above, Tmp.mdb is a temporary database that is used by Jetpack.exe. Dhcp.mdb is the DHCP database file. Jetpack.exe compacts the DHCP database by doing the following:
    1. Copying database information to a temporary database file called Tmp.mdb.
    2. Deleting the original DHCP database file, Dhcp.mdb.
    3. Renaming the temporary database file to the original file name.
  • Windows 2000 Server includes the Jetpack.exe utility so that it can be used to compact the DHCP and other Jet databases (such as WINS) when those databases are offline.

    It is recommended that you use Jetpack.exe to compact a Jet database periodically whenever the database grows beyond 30 megabytes or more in size. For Windows 2000 Server, the DHCP Server service performs dynamic Jet compaction of the DHCP database while the server is online. This reduces the need to use Jetpack.exe for offline compaction. Therefore, this procedure is most useful for DHCP and WINS servers running under earlier versions of Windows NT Server.

  • For more information, see Related Topics.

Related Topics


Remove or uninstall DHCP

To remove or uninstall DHCP

  1. If necessary, stop the DHCP server on this computer.

    For more information, see Related Topics.

  2. Open Add/Remove Programs.
  3. Click Add/Remove Windows Components.
  4. In Components, select Networking Services from the list of components, and then click Details.
  5. In Subcomponents of Networking Services, scroll to Dynamic Host Configuration Protocol (DHCP) and clear the check box.

Notes

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click the appropriate icon.
  • When you remove DHCP, all DHCP files are deleted from the server except program files that are in use. When the system is restarted, these files are removed as well.
  • If you do not stop the DHCP Server service in step 1, this procedure only deletes the DHCP server registry entries.
  • Certain Windows components require configuration before thay can be used. If you installed one or more of these components, but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components wizard, click Components.

Related Topics


Manage server access

  • Authorize a DHCP server in Active Directory
  • Delegate ability to authorize DHCP servers to a non-enterprise administrator
  • Selectively set DHCP server bindings for network connections
  • Add a user or group as a DHCP user at a member server
  • Add a user or group as a DHCP user at a domain controller
  • Add a user or group as a DHCP administrator at a member server
  • Add a user or group as a DHCP administrator at a domain controller


Authorize a DHCP server in Active Directory

To authorize a DHCP server in Active Directory

  1. Open DHCP.
  2. In the console tree, click DHCP.
  3. On the Action menu, click Manage authorized servers.

    The Manage Authorized Servers dialog box appears.

  4. Click Authorize.
  5. When prompted, type the name or IP address of the DHCP server to be authorized, and then click OK.

Notes

  • For a DHCP server to be authorized in an Active Directory domain environment, you must first be logged on as a member of the Enterprise Administrators group for the enterprise where the server is being added.
  • This procedure is usually only needed if you are running a DHCP server on a member server. In most cases, if you are installing a DHCP server on a computer also running as a domain controller, the server is automatically authorized the first time you add the server to the DHCP console.

Related Topics


Delegate ability to authorize DHCP servers to a non-enterprise administrator

To delegate ability to authorize DHCP servers to a non-enterprise administrator

  1. Open Active Directory Sites and Services while logged on as an enterprise administrator.

    For more information, see Notes.

  2. On the View menu, click Show Services Node.
  3. In the console tree, click NetServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • NetServices
  4. On the Action menu, click Delegate Control.

    The Delegation of Control wizard appears.

  5. Click Next, then for Users and Groups, click Add.
  6. In Select Users, Computers, or Groups locate and select the user or group account you want to permit access to the NetServices object for authorizing DHCP servers.

    For example, you might select the DHCP Administrators group for a specific domain, such as the EXAMPLE domain.

  7. Click Add and then click OK.
  8. For Tasks to Delegate, select Create a custom task to delegate and then click Next.
  9. For Delegate control of, select This folder, existing objects in this folder, and creation of new objects in this folder and then click Next.
  10. For Permissions, click Full Control and then click Next.

    This enables access control rights to the user or group account specifically delegated in this procedure for it to add, modify, or delete new objects of DHCP class type in the NetServices folder.

Notes

  • To be logged on as an enterprise administrator, you must logon using a member account in the Enterprise Administrators group. By default, this can typically be done by logging on as local Administrator at the first domain controller created in your enterprise.
  • For more information on setting permissions, see Related Topics.

Related Topics


Selectively set DHCP server bindings for network connections

To selectively set DHCP server bindings for network connections

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. Click Bindings.
  6. In the Bindings dialog box, for the list of Connections and server bindings, select or clear check boxes for any statically configured network connections that should be enabled or disabled for use at the applicable DHCP server.
  7. Click Apply.

Notes

  • If a network connection has more than one IP address configured, only the first configured IP address is used or affected by the DHCP server bindings. Any additional configured IP addresses are not used or configurable for bindings and are never used to service clients.
  • The DHCP Server service never binds to any wide area network (WAN) or DHCP-enabled network connections on a server computer. For this reason, these connections do not appear in the Bindings dialog box.

Related Topics


Add a user or group as a DHCP user at a member server

To add a user or group as a DHCP user at a member server

  1. Open Computer Management if the DHCP server is installed as a domain member server (or a stand-alone workgroup server).
  2. In the console tree, click Local Users and Groups.

    Where?

    • Computer Management (Local)
    • System Tools
    • Local Users and Groups
  3. In the details pane, click DHCP Users.
  4. On the Action menu, click Properties.
  5. Click the Members tab, and then click Add.
  6. Click Look in to display a list of domains from which users and computers can be added to the group, and then click the domain containing the users and computers you want to add.
  7. Click the users and computers to be added, and then click Add.

Notes

  • The DHCP Users group provides a way to grant read-only console access to the DHCP server. Other users or groups added as members of this group are granted the right to view, but not modify, data for the applicable server in the DHCP console.

Related Topics


Add a user or group as a DHCP user at a domain controller

To add a user or group as a DHCP user at a domain controller

  1. Open Active Directory Users and Computers if the DHCP server is installed at a domain controller.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • Applicable domain
    • Users
  3. In the details pane, click DHCP Users.
  4. On the Action menu, click Properties.
  5. Click the Members tab, and then click Add.
  6. Click Look in to display a list of domains from which users and computers can be added to the group, and then click the domain containing the users and computers you want to add.
  7. Click the users and computers to be added, and then click Add.

Notes

  • The DHCP Users group provides a way to grant read-only console access to the DHCP server. Other users or groups added as members of this group are granted the right to view, but not modify, data for the applicable server in the DHCP console.
  • To add users and computers to a group, you can also select the users and computers to be added, click the Add selected objects button on the toolbar, and then click the group to which they will be added.

Related Topics


Add a user or group as a DHCP administrator at a member server

To add a user or group as a DHCP administrator at a member server

  1. Open Computer Management if the DHCP server is installed as a domain member server (or a stand-alone workgroup server).
  2. In the console tree, click Local Users and Groups.

    Where?

    • Computer Management (Local)
    • System Tools
    • Local Users and Groups
  3. In the details pane, click DHCP Administrators.
  4. On the Action menu, click Properties.
  5. Click the Members tab, and then click Add.
  6. Click Look in to display a list of domains from which users and computers can be added to the group, and then click the domain containing the users and computers you want to add.
  7. Click the users and computers to be added, and then click Add.

Notes

  • The DHCP Administrators group provides a way to grant limited administrative access to the DHCP server only, while not providing full access to the server computer. Other users or groups added as members of this group are granted the right to fully administer the applicable server in the DHCP console, but are not able to perform other administrative actions on the server computer.
  • To add users and computers to a group, you can also select the users and computers to be added, click the Add selected objects button on the toolbar, and then click the group to which they will be added.

Related Topics


Add a user or group as a DHCP administrator at a domain controller

To add a user or group as a DHCP administrator at a domain controller

  1. Open Active Directory Users and Computers if the DHCP server is installed at a domain controller.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • Applicable domain
    • Users
  3. In the details pane, click DHCP Administrators.
  4. On the Action menu, click Properties.
  5. Click the Members tab, and then click Add.
  6. Click Look in to display a list of domains from which users and computers can be added to the group, and then click the domain containing the users and computers you want to add.
  7. Click the users and computers to be added, and then click Add.

Notes

  • The DHCP Administrators group provides a way to grant limited administrative access to the DHCP server only, while not providing full access to the server computer. Other users or groups added as members of this group are granted the right to fully administer the applicable server in the DHCP console, but are not able to perform other administrative actions on the server computer.
  • To add users and computers to a group, you can also select the users and computers to be added, click the Add selected objects button on the toolbar, and then click the group to which they will be added.

Related Topics


Monitor and configure servers

  • Enable server statistics to automatically refresh
  • Enable DHCP server logging
  • Enable address conflict detection
  • Enable DNS dynamic updates for clients
  • Manually refresh server statistics
  • View DHCP server statistics
  • View DHCP server properties


Enable server statistics to automatically refresh

To enable server statistics to automatically refresh

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Properties.
  4. On the General tab, for Automatically update statistics every, specify the number of hours and minutes to use as a refresh interval, and then click OK.

Note

Related Topics


Enable DHCP server logging

To enable DHCP server logging

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Properties.
  4. On the General tab, select Enable DHCP audit logging, and then click OK.

Note

Related Topics


Enable address conflict detection

To enable address conflict detection

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. For Conflict detection attempts, type a number greater than 0 (zero), and then click OK.

    The number you type determines how many times the DHCP server tests an IP address before leasing it to a client.

Notes

  • When conflict detection attempts are set, the DHCP server uses the Packet Internet Groper (ping) process to test available scope IP addresses before including these addresses in DHCP lease offers to clients.
  • A successful ping means the IP address is in use on the network. Therefore, the DHCP server does not offer to lease the address to a client. If the ping request fails and times out, the IP address is not in use on the network. In this case, the DHCP server offers to lease the address to a client.
  • Each additional conflict detection attempt delays the DHCP server response by a second while waiting for the ping request to time out. This increases the load on the server. A value of no greater than two (2) for ping attempts is recommended.

Related Topics


Enable DNS dynamic updates for clients

To enable DNS dynamic updates for clients

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Properties.
  4. Click the DNS tab.
  5. Select the Automatically update DHCP client information in DNS check box.
  6. If needed, modify other DNS update settings.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Notes

  • For more information, see Related Topics.

Related Topics


Manually refresh server statistics

To manually refresh server statistics

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Display Statistics.
  4. In the Server Statistics dialog box, click Refresh.

Note

Related Topics


View DHCP server statistics

To view DHCP server statistics

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Display Statistics.

Note

Related Topics


View DHCP server properties

To view DHCP server properties

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click Properties.
  4. View or modify server properties as needed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Note

Related Topics


Manage scopes

  • Create a new scope
  • Remove a scope
  • Exclude an address from a scope
  • Activate a scope
  • Deactivate a scope
  • Change or view scope properties
  • Reconcile a scope


Create a new scope

To create a new scope

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • applicable DHCP server
  3. On the Action menu, click New Scope.
  4. Follow the instructions in the New Scope wizard.

Notes

  • Before you create the scope, determine starting and ending IP addresses to be used within it.
  • Depending on the starting and ending IP addresses for your scope, the DHCP console suggests a default subnet mask useful for most networks. If you know a different subnet mask is required for your network, you can modify the value as needed.
  • When you finish creating a new scope, you might need to complete additional tasks, such as activating the scope for use or assigning scope options.

Related Topics


Remove a scope

To remove a scope

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • applicable DHCP server
    • applicable superscope (if used)
    • applicable scope
  3. On the Action menu, click Delete.
  4. When prompted, click Yes to delete the scope.

Important

  • Before removing a scope, be sure to have deactivated the scope long enough to migrate clients to a different scope. To migrate clients, either wait for 50% of the configured scope lease time to elapse or manually renew clients in another active scope. Once all clients have been moved or forced to seek leases in another scope, you can safely remove the inactive scope.

Note

Related Topics


Exclude an address from a scope

To exclude an address from a scope

  1. Open DHCP.
  2. In the console tree, click Address Pool.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Address Pool
  3. On the Action menu, click New Exclusion Range.
  4. In the Add Exclusion dialog box, type the Start IP address that you want to exclude from this scope.

    To exclude a range of more than one IP address, type an End IP address.

  5. Click Add.

Notes

  • Addresses that are excluded from the scope are not offered by the DHCP server to clients obtaining leases from this scope.
  • You cannot exclude a range of addresses that includes an active lease. You must first delete the active lease and then retry the exclusion.

Related Topics


Activate a scope

To activate a scope

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
  3. On the Action menu, click Activate.

Notes

  • Activating a scope is needed only for new scopes to start lease distribution. You must activate a scope to make it available for DHCP clients.
  • Do not activate a scope until you specify the options you want.
  • The Action menu command changes to Deactivate when the selected scope is currently activated. Do not deactivate a scope unless you are retiring it permanently from use on your network.

Related Topics


Deactivate a scope

To deactivate a scope

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
  3. On the Action menu, click Deactivate.

Important

  • Do not use Deactivate to pause a scope. Instead, adjust the available scope address range by setting exclusions for scope addresses.
  • The Action menu command name changes to Activate when the selected scope is currently deactivated.
  • Because deactivation begins recall of scope addresses, it is recommended that you avoid reactivating scopes. Typically, this command is used when you want to retire a scope and remove it from the server.

Note

Related Topics


Change or view scope properties

To change or view scope properties

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
  3. On the Action menu, click Properties.
  4. View or modify scope properties as needed.

    To view a description of a dialog box item, right-click the item, and then click What's This?

Notes

  • The subnet identifiers and address pool (defined by the Start and End IP addresses used to create the scope) make up the basic properties of a scope. You can only change some properties of an existing scope, such as the exclusion ranges, client reservations, configured scope option type values, or the time set for leasing scope addresses to clients.
  • You cannot exclude a range of addresses that includes an active lease. You must first delete the active lease, and then retry the exclusion.
  • You can extend the address range of the scope, but you cannot reduce it. However, you can at any time selectively exclude any unwanted addresses from the full scope range of addresses.

Related Topics


Reconcile a scope

To reconcile a scope

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
  3. On the Action menu, click Reconcile.
  4. In the Reconcile dialog box, click Verify.

    Inconsistencies found are reported in the status window.

  5. If the scope is found to be consistent, click OK.

    If the scope is not consistent, select the displayed addresses that need to be reconciled, and click Reconcile to repair inconsistencies.

Notes

  • For more information, see Related Topics.

Related Topics


Manage superscopes

  • Create a superscope
  • Remove a superscope
  • Add a scope to a superscope
  • Activate a superscope
  • Deactivate a superscope


Create a superscope

To create a superscope

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, click New Superscope.

    This menu option only appears if at least one scope, that is not currently part of a superscope, has been created at the server.

  4. Follow the instructions in the New Superscope wizard.

Notes

  • A superscope can have scopes added to it, either during or after its creation.
  • Scopes that are contained within superscopes are sometimes called child scopes or member scopes.

Related Topics


Remove a superscope

To remove a superscope

  1. Open DHCP.
  2. In the console tree, click the applicable superscope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope
  3. On the Action menu, click Delete.
  4. When prompted, click Yes to delete the superscope.

Notes

  • Removing a superscope does not remove any of the scopes included in it.

Related Topics


Add a scope to a superscope

To add a scope to a superscope

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable scope
  3. On the Action menu, click Add To Superscope.
  4. In the Available superscopes list, click the superscope to which you want to add this scope.

Notes

  • In order to complete this procedure, at least one superscope must already exist at the applicable DHCP server.

Related Topics


Activate a superscope

To activate a superscope

  1. Open DHCP.
  2. In the console tree, locate the applicable superscope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope
  3. On the Action menu, click Activate.

Notes

  • Activating a superscope is needed only for new superscopes. When you activate a superscope, it activates all of its member scopes on your network. You must activate a superscope to make IP addresses for all of its member scopes available for use by DHCP clients.
  • Do not activate a superscope until you specify the options you want for each of its member scopes.
  • The Action menu command changes to Deactivate when the selected scope is currently activated. Do not deactivate a superscope unless you intend to permanently retire all of its member scopes from use on your network.

Related Topics


Deactivate a superscope

To deactivate a superscope

  1. Open DHCP.
  2. In the console tree, click the applicable superscope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope
  3. On the Action menu, click Deactivate.

Important

  • Do not use Deactivate to pause a superscope. Instead, you can adjust the superscope membership by adding or removing from the list of member scopes.
  • Because deactivation begins recall of member scope addresses, use this command only when you intend to retire all member scopes and remove the superscope from the server.
  • The Action menu command name changes to Activate when the selected superscope is currently deactivated. Avoid reactivating a superscope once you deactivate it.

Note

Related Topics


Manage multicast scopes

  • Create a multicast scope
  • Remove a multicast scope
  • Set the multicast scope Time-To-Live (TTL) value
  • Specify a finite lifetime for a multicast scope


Create a multicast scope

To create a multicast scope

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, click New Multicast Scope.
  4. Follow the instructions in the New Multicast Scope wizard.

Note

Related Topics


Remove a multicast scope

To remove a multicast scope

  1. Open DHCP.
  2. In the console tree, click the applicable multicast scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable multicast scope
  3. On the Action menu, click Delete.
  4. When prompted, click Yes to remove the multicast scope.

Notes

  • Removing a multicast scope does not necessarily stop the use of multicast groups associated with scope addresses on your network.
  • If computers on your network are configured by means other than DHCP to use these same addresses, the multicast group might still be used even after this procedure is complete.

Related Topics


Set the multicast scope Time-To-Live (TTL) value

To set the multicast scope Time-To-Live (TTL) value

  1. Open DHCP.
  2. In the console tree, click the applicable multicast scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable multicast scope
  3. On the Action menu, click Properties.
  4. In Time to live, specify a new value.

Notes

  • The multicast Time-To-Live (TTL) value specifies the number of routers (hops) that multicast traffic is permitted to pass through before expiring on the network. For each router (hop), the original specified TTL is decremented by one (1). When its TTL reaches a value of zero (0), each multicast datagram expires and is no longer forwarded through the network to other subnets.

Related Topics


Specify a finite lifetime for a multicast scope

To specify a finite lifetime for a multicast scope

  1. Open DHCP.
  2. In the console tree, click the applicable multicast scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable multicast scope
  3. On the Action menu, click Properties.
  4. Click the Lifetime tab.
  5. For Multicast scope lifetime, click Multicast scope expires on.
  6. Using the controls, specify a date and time when the multicast scope is to be expired and removed from the applicable DHCP server.

Notes

  • By default, multicast scopes do not expire. When created, they exist until they are manually removed. This procedure, however, can be used to provide a means of having the DHCP server automatically remove the multicast scope at an appointed future date and time.

Related Topics


Manage options and classes

  • Assign a server-based option
  • Assign a scope-based option
  • Assign an advanced (class-based) option
  • Create a new user or vendor class
  • Define a new option
  • Modify an option
  • Remove an option


Assign a server-based option

To assign a server-based option

  1. Open DHCP.
  2. In the console tree, click Server Options.

    Where?

    • DHCP
    • Applicable DHCP server
    • Server Options
  3. On the Action menu, click Configure Options.
  4. In list of Available Options, select the check box for the first option you want to configure.
  5. Under Data entry, type the information required for this option.
  6. Repeat the two previous steps for any other server options you want to specify, and then click OK.
  7. In addition, you can click the Advanced tab and specify additional server options to be applied only for members of select user or vendor classes.

    Options assigned at this level are only provided to clients identified as members of the classes specified at this tab.

Notes

  • Server options are inherited as default values for all scopes created at the applicable DHCP server. Option values you configure here are overridden by any scope-based or client-based values assigned for the same options.

Related Topics


Assign a scope-based option

To assign a scope-based option

  1. Open DHCP.
  2. In the console tree, click Scope Options.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Scope Options
  3. On the Action menu, click Configure Options.
  4. In list of Available Options, select the check box for the first option you want to configure.
  5. Under Data entry, type the information required for this option.
  6. Repeat the two previous steps for any other server options you want to specify, and then click OK.
  7. In addition, you can click the Advanced tab and specify additional scope options to be applied only for members of select user or vendor classes.

    Options assigned at this level are only provided to clients identified as members of the classes specified at this tab.

Notes

  • Scope options are inherited as default values for all clients of the applicable scope. Option values you configure here are overridden by any reserved client-based values assigned for the same options.

Related Topics


Assign an advanced (class-based) option

To assign an advanced (class-based) option

  1. Open DHCP.
  2. In the console tree, choose one:
    • Click Server Options, if you want to assign advanced options for use by all new scopes at the DHCP server.

      Where?

      • DHCP
      • Applicable DHCP server
      • Server Options
    • Click Scope Options, if you want to assign advanced options for use by a specific scope at the DHCP server.

      Where?

      • DHCP
      • Applicable DHCP server
      • Applicable superscope (if used)
      • Applicable scope
      • Scope Options
  3. Right-click the folder, and click Configure Options.
  4. Click the Advanced tab.
  5. Select from the following:
    • For Vendor class, scroll to select the defined vendor class at the DHCP server (or use the default, DHCP Standard Options) for assigning options for the server or scope.
    • For User class, scroll to select the defined user class at the DHCP server (or use the default, Default User Class) for assigning options for the server or scope.
  6. In the list of Available Options, select the check box for the first option you want to configure.
  7. Under Data entry, type the information required for this option.
  8. Repeat the two previous steps for any other options you want to specify, and then click OK.

Notes

  • If a class-based option is assigned, it only applies to DHCP clients that are identified as members of the specified user or vendor class.

Related Topics


Create a new user or vendor class

To create a new user or vendor class

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, choose one of the following:
    • To create a new user class, click Define User Classes.
    • To create a new vendor class, click Define Vendor Classes.
  4. Click Add.
  5. In New Class, type the required information.

    To view a description of a dialog box item, right-click the item, and then click What's This?.

Notes

  • In the DHCP User Classes and DHCP Vendor Classes dialogs, you can also click either Edit or Remove to modify or delete option classes.
  • In the New Class dialog box, for ID, set the same binary or ASCII string that matches the DHCP class ID string which is either implemented or set at member clients.
  • For Windows 2000 DHCP client computers, the ipconfig /setclassid command can be used to set the specified DHCP class ID string. For more information, see Related Topics.

Related Topics


Define a new option

To define a new option

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, click Set Predefined Options.
  4. In Predefined Options and Values, click Add.
  5. In Option Type, type the required information to define the new option, and then click OK.

    To view a description of a dialog box item, right-click the item, and then click What's This?.

Notes

  • By default, standard DHCP options and BOOTP extensions as described in RFC 2132 are predefined for use at Windows 2000 DHCP servers. For more information, see Related Topics.

Related Topics


Modify an option

To modify an option

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, click Set Predefined Options.
  4. In Predefined Options and Values, select the following:
    • For Option class, select the class where the option to be modified is used.
    • For Option name, scroll to select the option you want to modify.
  5. Click Edit.
  6. Modify the Name and Description fields for the option as needed.

Notes

  • For options already defined, only the Name and Description fields can be modified using this procedure. To change other fields (such as Data type, Code, or the applicable class where the option is used), the existing option must be removed and a new option defined.
  • By default, standard DHCP options and BOOTP extensions as described in RFC 2132 are predefined for use at Windows 2000 DHCP servers. For more information, see Related Topics.

Related Topics


Remove an option

To remove an option

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, click Set Predefined Options.
  4. In Predefined Options and Values, select the following:
    • For Option class, select the class where the option to be removed is used.
    • For Option name, scroll to select the user-defined option you want to remove.
  5. Click Delete.

Notes

  • By default, standard DHCP options and BOOTP extensions as described in RFC 2132 are predefined at Windows 2000 DHCP servers for use and cannot be removed using this procedure. For more information, see Related Topics.

Related Topics


Manage clients and leases

  • View client lease information
  • Delete a client lease
  • View, release, or renew a client address lease
  • Set DHCP class ID information at a client computer
  • Show DHCP class ID information at a client computer


View client lease information

To view client lease information

  1. Open DHCP.
  2. In the console tree, click Address Leases.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Address Leases
  3. In the details pane, locate the client lease for which you want to view information.

Notes

  • For most clients displayed in the DHCP console, you cannot edit the displayed lease information. Only reserved scope clients permit some of this information to be edited.

Related Topics


Delete a client lease

To delete a client lease

  1. Open DHCP.
  2. In the console tree, click Address Leases.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Address Leases
  3. In the details pane, click the IP address of the client you want to delete.
  4. On the Action menu, click Delete.
  5. Make a reservation with the IP address, or exclude it from the range.
  6. Force the client with the existing lease to give it up. At the command prompt on the client computer, type ipconfig /release.
  7. If needed, give the client a new IP address. At the command prompt on the client computer, type ipconfig /renew.

Notes

  • If you want, you can cancel leases for all clients in the scope. To cancel all current leases, select all of the clients in Address Leases, right-click, and then click Delete.
  • Deleting a client lease does not prevent the server from offering that IP address again in a future client lease. It also does not prevent the client from requesting the address again, unless steps 5 to 7 are followed.
  • For Windows 95 and Windows 98 clients, you can use Winipcfg.exe to release or renew a computer address lease.

Related Topics


Verify, release, or renew a client address lease

To verify, release, or renew a client address lease

  1. At a DHCP-enabled client computer running Windows, open a command prompt.
  2. Use the Ipconfig command-line utility to verify, release, or renew the lease of the client with a DHCP server, as follows:
    • To verify a DHCP client lease, type ipconfig to view lease-status information.

      Or, type ipconfig /all.

    • To release a DHCP client lease, type ipconfig /release.
    • To renew a DHCP client lease, type ipconfig /renew.

Notes

  • The Ipconfig utility is also supported for use in Windows NT. For Windows 95 and Windows 98 clients, use Winipcfg, the Windows IP configuration program, to perform these same tasks.
  • To run Winipcfg on supporting clients, type winipcfg at either an MS-DOS command prompt or in the Run command window (click Start, and then click Run). When using Winipcfg to release or renew leases, click Release or Renew to perform these respective tasks.

Related Topics


Set DHCP class ID information at a client computer

To set DHCP class ID information at a client computer

  1. At a DHCP-enabled client computer running Windows 2000, open a command prompt.
  2. Use the Ipconfig command-line utility to set the DHCP class ID the client uses when obtaining its lease from the DHCP server.

    You can type the ipconfig /setclassid command as demonstrated in the following example command, which sets an ASCII string ("MyNewClassId") as the DHCP class ID string for the local area network connection in use at the client computer:

    C:\>ipconfig /setclassid "Local Area Connection" MyNewClassId

Windows 2000 IP Configuration

        DHCP ClassId successfully modified for adapter"Local Area Connection"

Notes

  • For a DHCP options class to be in effect between the DHCP server and its clients, both must be configured with a matching DHCP class ID string that identifies the client as a member of a specific user or vendor options class when it obtains its address lease from the server.
  • For more information, see Related Topics.

Related Topics


Show DHCP class ID information at a client computer

To show DHCP class ID information at a client computer

  1. At a DHCP-enabled client computer running Windows 2000, open a command prompt.
  2. Use the Ipconfig command-line utility to show the DHCP class ID that the client uses when obtaining its lease from the DHCP server.

    You can type the ipconfig /showclassid command as demonstrated in the following example command. This example shows an ASCII string ("MyNewClassId") that is currently set as the DHCP class ID for the local area network connection at the client computer:

    C:\>ipconfig /showclassid "Local Area Connection"

Windows 2000 IP Configuration

DHCP Class ID for Adapter "Local Area Connection":
        DHCP ClassID Name . . . . . . . . : Default BOOTP Class
        DHCP ClassID Description  . . . . : User class for BOOTP clients
        DHCP ClassID Name . . . . . . . . : Default Remote Access Class
        DHCP ClassID Description  . . . . : User class for remote access clients

        Host Name . . . . . . . . . . . . : HOSTA
        Primary DNS Suffix  . . . . . . . : example.microsoft.com
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Combo PCMCIA EthernetCard
        Physical Address. . . . . . . . . : 00-00-00-00-7C-DC
        DHCP Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 10.0.0.51
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 10.0.0.1
        DHCP Class ID . . . . . . . . . . : MyNewClassId
        DNS servers . . . . . . . . . . . : 10.0.0.3
        Primary WINS server . . . . . . . : 10.0.0.5

Notes

  • For a DHCP options class to be in effect between the DHCP server and its clients, both must be configured with a matching DHCP class ID string that identifies the client as a member of a specific user or vendor options class when it obtains its address lease from the server.
  • For more information, see Related Topics.

Related Topics


Manage reservations and reserved clients

  • Add a client reservation
  • Change information for a reserved client
  • Assign an option to a reserved client
  • Configure advanced (class-based) options for a reserved client
  • Change the reserved IP address for a client


Add a client reservation

To add a client reservation

  1. Open DHCP.
  2. In the console tree, click Reservations.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Reservations
  3. On the Action menu, click New Reservation.
  4. In New Reservation, type the information required to complete the client reservation.

    To view a description of a dialog box item, right-click the item, and then click What's This?.

  5. To add the client reservation to the scope, click Add.
  6. Repeat the two previous steps for any other client reservations you want to add, and then click Close.

Notes

  • When adding a reservation, the DHCP server checks for the address you enter in the database to make sure it is not currently in use by another client.
  • Reservations are applied on the basis of the DHCP client Media Access Control (MAC) address for the applicable network connection.

    To locate this address, at the client computer, type ipconfig /all at a command prompt and view the Physical Address for the connection. Alternately, you can right-click the connection in the Network and Dial-up Connections folder and select Properties to view this information.

Related Topics


Change information for a reserved client

To change information for a reserved client

  1. Open DHCP.
  2. In the console tree, click Reservations.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Reservations
  3. In the details pane, click the reserved client for which you want to change information.

    Note any information currently used for the reservation that you want to preserve.

  4. On the Action menu, click Delete.
  5. Add a new reservation, merging any of the reserved client information you want to keep or modify as needed.

    For more information, see Related Topics.

Notes

  • Reservations, once made, cannot be modified. To change information for an existing client reservation, you must delete and recreate it.

Related Topics


Assign an option to a reserved client

To assign an option to a reserved client

  1. Open DHCP.
  2. In the console tree, click Reservations.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Reservations
  3. In the details pane, click the reserved client for which you want to assign options.
  4. On the Action menu, click Configure Options.
  5. In the list of Available Options, select the check box for the first option you want to configure.
  6. Under Data entry, type the information required for this option.
  7. Repeat the two previous steps for any other reserved client options you want to specify, and then click OK.

Notes

  • Reserved client options configured here override option values assigned at either the server or scope levels of configuration.

Related Topics


Configure advanced (class-based) options for a reserved client

To configure advanced (class-based) options for a reserved client

  1. Open DHCP.
  2. In the console tree, click Reservations.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Reservations
  3. In the details pane, click the reserved client for which you want to assign options.
  4. On the Action menu, click Configure Options.
  5. Click the Advanced tab.
  6. Select from the following:
    • For Vendor class, scroll to select the defined vendor class at the DHCP server (or use the default, DHCP Standard Options) for assigning options to the reserved client.
    • For User class, scroll to select the defined user class at the DHCP server (or use the default, Default User Class) for assigning options to the reserved client.
  7. In the list of Available Options, select the check box for the first option you want to configure.
  8. Under Data entry, type the information required for this option.
  9. Repeat the two previous steps for any other options you want to specify, and then click OK.

Notes

  • If a class-based option is assigned, it only applies if the reserved client is identified as a member of the specified user or vendor classes.

Related Topics


Change the reserved IP address for a client

To change the reserved IP address for a client

  1. Open DHCP.
  2. In the console tree, click Reservations.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
    • Reservations
  3. In the details pane, select the reserved client for which you want to change the IP address.
  4. To delete the current reservation, on the Action menu, click Delete.
  5. Add a new reservation in DHCP that uses the new IP address for the client.

    For more information, see Related Topics.

Notes

  • The IP address in an existing client reservation cannot be modified directly. To achieve similar results, the existing reservation must be deleted and a new reservation added.

Related Topics


Manage BOOTP and remote access clients

  • View the BOOTP table
  • Add an entry to the BOOTP table
  • Add dynamic BOOTP client support to a scope
  • Change the lease time for remote access clients


View the BOOTP table

To view the BOOTP table

  1. Open DHCP.
  2. In the console tree, click the applicable DHCP server.

    Where?

    • DHCP
    • Applicable DHCP server
  3. On the Action menu, click Properties.
  4. Verify that the Show the BOOTP table folder check box is selected.

    If the check box is cleared, select it and then click OK.

  5. In the console tree, click BOOTP Table.

    Where?

    • DHCP
    • Applicable DHCP server
    • BOOTP Table

    BOOTP entries, if any have been added to the BOOTP table, appear in the details pane.

Notes

  • By default, the BOOTP table is empty. For more information, see Related Topics.

Related Topics


Add an entry to the BOOTP table

To add an entry to the BOOTP table

  1. Open DHCP.
  2. In the console tree, click BOOTP Table.

    Where?

    • DHCP
    • Applicable DHCP server
    • BOOTP Table

    If the BOOTP table does not appear, see Related Topics.

  3. On the Action menu, click New Boot Image.
  4. In the Add BOOTP Entry dialog box, enter the required information.

    To view a description of a dialog box item, right-click the item, and then click What's This?.

  5. Click Add.
  6. Repeat the previous two steps for each additional BOOTP entry you want to add, and then click Close.

Note

Related Topics


Add dynamic BOOTP client support to a scope

To add dynamic BOOTP client support to a scope

  1. Open DHCP.
  2. In the console tree, click the applicable scope.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable superscope (if used)
    • Applicable scope
  3. On the Action menu, click Properties.
  4. Click the Advanced tab.
  5. For Assign IP addresses dynamically to clients of, click either Both or BOOTP only.
  6. If needed, in Lease duration for BOOTP clients adjust the default lease length.

    The lease length is used by the DHCP server to determine how long to preserve leases made dynamically for BOOTP clients of the applicable scope.

Notes

  • Unlike DHCP, where clients can initiate a protocol message to release or renew their address lease, BOOTP clients can only obtain or negotiate their IP address lease at boot time. For this reason, it is recommended that you select a lease length for BOOTP clients that exceeds the time between when BOOTP clients are restarted on the network.

Related Topics


Change the lease time for remote access clients

To change the lease time for remote access clients

  1. Open DHCP.
  2. In the console tree, click Scope Options.

    Where?

    • DHCP
    • Applicable DHCP server
    • Applicable scope
  3. Right-click Scope Options and click Configure Options.
  4. Click Advanced.
  5. In User class, select Default remote access class.
  6. In Available Options, click the check box for 051 Lease.
  7. In Long, type the lease value in seconds.

    For example, if you want the lease time to be one hour, type: 0x3600

Note

Related Topics


Use DHCP command-line tools

  • Optimize the command prompt for use with command-line tools
  • Use DHCP commands interactively at the command prompt
  • Use DHCP commands non-interactively or in scripts


Optimize the command prompt for use with command-line tools

To optimize the command prompt for use with command-line tools

  1. Open Command Prompt.
  2. Click the upper left corner of the command prompt window and then click Properties.
  3. Click the Options tab.
  4. Modify command prompt options.

    For command history, increase Buffer Size to 500 and Number of Buffers to 5. Under edit options, click Quick Edit Mode and Insert Mode.

  5. Click the Layout tab.
  6. Increase Screen Buffer Size to 2500.
  7. Click OK to apply changes.

    When prompted, select Modify shortcut that started this window.

Notes

  • To open Command Prompt, click Start, point to Programs, and then click Command Prompt.
  • As a keyboard option for step 2, access the Command Prompt Properties dialog box by doing the following: press the ALT key and the spacebar at the same time, then press "P" to select Properties.
  • By optimizing the command prompt window using this procedure, you can use Windows Explorer features, such as scrolling, and quickly mark, copy, and paste to and from the command prompt window. By increasing the screen buffer size, you can scroll back to previous command output and more easily view command-line help text.

Related Topics


Use DHCP commands interactively at the command prompt

To use DHCP commands interactively at the command prompt

  1. Open Command Prompt.
  2. Type netsh.
  3. At the netsh> (Netshell) command prompt, type dhcp.
  4. At the dhcp> (DHCP helper) command prompt, type either server \\servername or server ip_address for the server you want to manage.

    Once a server has been successfully reached that you have rights to manage, you should see "You have Read and Write access to the server servername"

  5. Once connected, you can use any supported Netshell command for DHCP.

    Type /? or help to display the immediate DHCP subcommand menu or as an option, type list to list all Netshell subcommands available for use with DHCP.

Notes

  • To open Command Prompt, click Start, point to Programs, and then click Command Prompt.
  • The \\servername parameter is optional and can be left unspecified if you are performing commands locally at the DHCP server located on the same computer as the command is executed. If the server being managed is remote, this parameter is required and the name of the server must be specified.
  • In order to manage a DHCP server using the Netshell command-line, you must be logged on as a member of either the local Administrators group or (for Windows 2000 Server only) the local DHCP Administrators group on the applicable server computer.

Related Topics


Use DHCP commands non-interactively or in scripts

To use DHCP commands non-interactively or in scripts

  1. Open Command Prompt.
  2. At the command prompt or in scripted usage, you can use Netshell commands for DHCP non-interactively by using the following fully qualified command syntax:

    netsh dhcp server [\\servername] subcommand.

Notes

  • To open Command Prompt, click Start, point to Programs, and then click Command Prompt.
  • The \\servername parameter is optional and can be left unspecified if you are performing commands locally at the DHCP server located on the same computer as the command is executed. If the server being managed is remote, this parameter is required and the name of the server must be specified.
  • In order to manage a DHCP server using the Netshell command-line, you must be logged on as a member of either the local Administrators group or (for Windows 2000 Server only) the local DHCP Administrators group on the applicable server computer.

Related Topics


Concepts

This section provides general background information about Dynamic Host Configuration Protocol (DHCP), and server and client software provided by Microsoft and Windows 2000.

  • DHCP overview
  • Understanding DHCP
  • Using DHCP
  • Resources


DHCP overview

This section covers:

  • DHCP defined
  • Benefits of using DHCP
  • How DHCP works
  • DHCP terminology
  • DHCP tools
  • New features


DHCP defined

Dynamic Host Configuration Protocol (DHCP) is a TCP/IP standard for simplifying management of host IP configuration. The DHCP standard provides for the use of DHCP servers as a way to manage dynamic allocation of IP addresses and other related configuration details to DHCP-enabled clients on your network.

Every computer on a TCP/IP network must have a unique computer name and IP address. The IP address (together with its related subnet mask) identifies both the host computer and the subnet to which it is attached. When you move a computer to a different subnet, the IP address must be changed. DHCP allows you to dynamically assign an IP address to a client from a DHCP server IP address database on your local network:

Simple DHCP network

For TCP/IP-based networks, DHCP reduces the complexity and amount of administrator work involved in reconfiguring computers.

Windows 2000 Server provides an RFC-compliant DHCP service you can use to manage IP client configuration and automate IP address assignment on your network. For more information on the DHCP standard specifications, see DHCP RFCs.


Benefits of using DHCP

DHCP provides the following benefits for administering your TCP/IP-based network:

  • Safe and reliable configuration

    DHCP avoids configuration errors caused by the need to manually type in values at each computer. Also, DHCP helps prevent address conflicts caused by a previously assigned IP address being reused to configure a new computer on the network.

  • Reduces configuration management

    Using DHCP servers can greatly decrease time spent configuring and reconfiguring computers on your network. Servers can be configured to supply a full range of additional configuration values when assigning address leases. These values are assigned using DHCP options.

    Also, the DHCP lease renewal process helps assure that where client configurations need to be updated often (such as users with mobile or portable computers who change locations frequently), these changes can be made efficiently and automatically by clients communicating directly with DHCP servers.


How DHCP works

DHCP uses a client-server model. The network administrator establishes one or more DHCP servers that maintain TCP/IP configuration information and provide it to clients. The server database includes the following:

  • Valid configuration parameters for all clients on the network.
  • Valid IP addresses maintained in a pool for assignment to clients, plus reserved addresses for manual assignment.
  • Duration of a lease offered by the server. The lease defines the length of time for which the assigned IP address can be used.

With a DHCP server installed and configured on your network, DHCP-enabled clients can obtain their IP address and related configuration parameters dynamically each time they start and join your network. DHCP servers provide this configuration in the form of an address-lease offer to requesting clients.


DHCP terminology

Term | Description
scope | A scope is the full consecutive range of possible IP addresses for a network. Scopes typically define a single physical subnet on your network to which DHCP services are offered. Scopes also provide the primary way for the server to manage distribution and assignment of IP addresses and any related configuration parameters to clients on the network.
superscope | A superscope is an administrative grouping of scopes that can be used to support multiple logical IP subnets on the same physical subnet. Superscopes only contain a list of member scopes or child scopes that can be activated together. Superscopes are not used to configure other details about scope usage. For configuring most properties used within a superscope, you need to configure member scope properties individually.
exclusion range | An exclusion range is a limited sequence of IP addresses within a scope, excluded from DHCP service offerings. Exclusion ranges assure that any addresses in these ranges are not offered by the server to DHCP clients on your network.
address pool | After you define a DHCP scope and apply exclusion ranges, the remaining addresses form the available address pool within the scope. Pooled addresses are eligible for dynamic assignment by the server to DHCP clients on your network.
lease | A lease is a length of time that a DHCP server specifies, during which a client computer can use an assigned IP address. When a lease is made to a client, the lease is active. Before the lease expires, the client typically needs to renew its address lease assignment with the server. A lease becomes inactive when it expires or is deleted at the server. The duration for a lease determines when it will expire and how often the client needs to renew it with the server.
reservation | You use a reservation to create a permanent address lease assignment by the DHCP server. Reservations assure that a specified hardware device on the subnet can always use the same IP address.
option types | Option types are other client configuration parameters a DHCP server can assign when serving leases to DHCP clients. For example, some commonly used options include IP addresses for default gateways (routers), WINS servers, and DNS servers. Typically, these option types are enabled and configured for each scope. The DHCP console also permits you to configure default option types that are used by all scopes added and configured at the server. Most options are predefined through RFC 2132, but you can use the DHCP console to define and add custom option types if needed.
options class | An options class is a way for the server to further manage option types provided to clients. When an options class is added to the server, clients of that class can be provided class-specific option types for their configuration. For Windows 2000, client computers can also specify a class ID when communicating with the server. For earlier DHCP clients that do not support the class ID process, the server can be configured with default classes to use instead when placing clients in a class. Options classes can be of two types: vendor classes and user classes.


DHCP tools

The primary tool that you use to manage DHCP servers is the DHCP console, which is added to the Administrative Tools folder in Control Panel when you install a DHCP server for Windows 2000 Server. The DHCP console appears as a Microsoft Management Console (MMC) snap-in, to further integrate DHCP administration into your total network management.

After you install a DHCP server, you can use the DHCP console to perform these basic administrative server tasks:

  1. Create scopes.
  2. Add and configure superscopes and multicast scopes.
  3. View and modify scope properties for scopes, such as setting additional exclusion ranges.
  4. Activate scopes or superscopes.
  5. Monitor scope leasing activity occasionally by reviewing the Active Leases for each scope.
  6. Create reservations in scopes as needed for DHCP clients that require a permanent IP address for leased use.

In addition, you can also use the DHCP console to perform the following optional or advanced setup tasks:

  • Add new custom default option types.
  • Add and configure any user or vendor-defined option classes.
  • Further configure other server properties, such as audit logging or BOOTP tables.

In addition, this version of the DHCP console also contains new features and enhancements, many of which were suggested by network managers. These include enhanced server performance monitoring, more pre-defined DHCP option types, dynamic update support for clients running earlier versions of Windows, and detection of unauthorized DHCP servers on your network.

Notes

  • Windows 2000 Server includes many new features beyond those provided in earlier versions. For more information, see New features.
  • The DHCP console provides new ways to perform familiar DHCP administrative tasks previously performed in Windows NT Server 4.0 using DHCP Manager. For more information, see New ways to do familiar tasks.
  • For Windows 2000 Server, DHCP administration can also be performed using command-line based tools. For more information, see Netshell commands for DHCP or Use DHCP command-line tools.


New features

DHCP in Windows 2000 Server provides the following new features:

  • New local groups for providing limited server and console access to DHCP administrators and users.

    Two new local administrative groups are created when a DHCP server is installed on a server computer: the DHCP Users and DHCP Administrators groups. The DHCP Users group can be used to provide read-only console access to the server. Where used, this group grants members the ability to view, but not modify, server data.

    The DHCP Administrators group provides a higher level of administrative access. Members added to this group can fully manage and modify any data at the DHCP server, but are not provided full unlimited administrative access, such as if the local Administrators group were used instead to provide administrative access to the applicable DHCP server.

  • Automatic assignment of IP addresses

    For Windows 2000 (and Windows 98), DHCP-enabled clients can now configure themselves to use a temporary IP configuration if a DHCP server is unavailable to provide a lease when they start on a network. For DHCP clients running these versions of Windows, the client tries to contact a DHCP server in the background every five minutes to eventually obtain its valid IP address lease.

    Automatic assignment is always transparent to users, who are not prompted if the client fails to obtain a lease from a DHCP server. Addresses are self-assigned from a network address range that is reserved for private TCP/IP usage and not used on the Internet. For more information, see Automatic client configuration.

  • Enhanced performance monitoring and server reporting capabilities

    DHCP is critical to the success of your network infrastructure. Without working DHCP servers, IP clients can lose some or all of their ability to access or use your network. Because many experienced network administrators realize the importance of close monitoring of DHCP servers, several changes have been made to assist in this area.

    New performance monitoring counters have been added to Windows 2000 Server to help you monitor DHCP server performance on your network. For more information, see Monitoring server performance.

  • Expanded scope support for multicast scopes and superscopes

    Microsoft DHCP server now supports additional scopes that you can use to streamline your ongoing administration of IP address configurations.

    New multicast scopes make it possible for DHCP-enabled clients to lease Class D-type IP addresses (224.0.0.0 to 239.255.255.255) for participation in multicast groups. For more information, see Using multicast scopes.

    Superscopes (a late addition to Windows NT Server 4.0) are useful for creating an administrative grouping of member scopes. Superscopes can be helpful when you want to renumber or expand the IP address space on your network without disturbing currently active scopes. For more information, see Using superscopes.

  • Support for user-specified and vendor-specified option classes

    • You can use this feature to separate and distribute appropriate options for clients with similar or special configuration needs.

    For example, you might assign all DHCP-enabled clients on the same floor of your building to the same option class. You could use this class (configured with the same DHCP Class ID value) to distribute other options data during the lease process, overriding any scope or global default options. In this way, options appropriate to a set of class-member clients in the same network location (such as a specific default gateway or parent domain name) are applied as class-specific options. For more information, see Using option classes.

  • Integration of DHCP with DNS

    With Windows 2000, a DHCP server can enable dynamic updates in the DNS namespace for any of its clients that support these updates. Scope clients can then use DNS dynamic update protocol to update their host name-to-address mapping information (which is stored in zones on the DNS server) whenever changes occur to their DHCP-assigned address. For more information, see Using DNS servers with DHCP.

  • Detection of unauthorized DHCP servers through the use of Active Directory integration

    When a DHCP server is started on a network unintentionally, it can disturb normal TCP/IP network operations. This is because DHCP clients frequently use broadcasts to the network to discover a DHCP server when started. To prevent unintended problems, Windows 2000 Server provides a method of authorizing a DHCP server as well as a means to detect and shut down unauthorized servers.

    When a Windows 2000 DHCP server attempts to start on the network, Active Directory is queried and the server computer's IP address is compared to the list of authorized DHCP servers. If a match is found, the server computer is authorized as a DHCP server. If a match is not found, the server is not authorized and is identified as an unauthorized server. In this case, the DHCP Server service installed and running on the unauthorized server is automatically shut down before it can disturb the network.

    For these features to be used, you must also deploying and use Active Directory with Windows 2000 DHCP servers. Other DHCP servers do not support this feature. Server detection is performed using a DHCP server object created in Active Directory. This object lists the IP addresses of the servers authorized to provide DHCP service to clients on the network.

    For more information, see Authorizing DHCP servers.

  • Dynamic support for BOOTP clients.

    The DHCP service provides additional support for BOOTP clients in large enterprise networks through the addition of dynamic BOOTP.

    Dynamic BOOTP is an extension of the BOOTP protocol that permits the DHCP server to configure BOOTP clients without having to use explicit fixed address configuration. This feature provides easier administration of large BOOTP networks by allowing automatic distribution of IP addresses (much the same way that DHCP does) without having to change client side behavior.

    For more information on using dynamic BOOTP with your DHCP servers, see Supporting BOOTP clients.


Understanding DHCP

This section covers:

  • DHCP servers
  • DHCP clients
  • DHCP/BOOTP relay agents
  • DHCP in Windows 2000
  • DHCP options
  • Understanding user and vendor classes
  • BOOTP and DHCP
  • The DHCP database


DHCP servers

Configuring DHCP servers for a network provides the following benefits:

  • The administrator can assign and specify global and subnet-specific TCP/IP parameters centrally for use throughout the entire network.
  • Client computers do not require manual TCP/IP configuration.
  • When a client computer moves between subnets, its old IP address is freed for reuse. The client reconfigures its TCP/IP settings automatically when the computer is restarted in its new location.
  • Most routers can forward DHCP and BOOTP configuration requests, so DHCP servers are not required on every subnet in the network.

How clients use servers

A computer running Windows 2000 becomes a DHCP client if Obtain an IP address is selected in its TCP/IP properties. When a client computer is set to use DHCP, it accepts a lease offer and can receive from the server the following:

  • Temporary use of an IP address known to be valid for the network it is joining.
  • Additional TCP/IP configuration parameters for the client to use in the form of options data.

Also, if conflict detection is configured, the DHCP server attempts to ping each available address in the scope prior to presenting the address in a lease offer to a client. This ensures that each IP address offered to clients is not already in use by another non-DHCP computer that uses manual TCP/IP configuration.

How servers provide optional data

In addition to an IP address, DHCP servers can be configured to provide optional data to fully configure TCP/IP for clients. Some of the most common DHCP option types configured and distributed by the DHCP server during leases include:

  • Default gateways (routers), which are used to connect a network segment to other network segments.
  • Other optional configuration parameters to assign to DHCP clients, such as IP addresses for the DNS servers or WINS servers that the client can use in resolving network host names.

For more information, see DHCP options.


DHCP clients

This section covers:

  • Client overview
  • Microsoft DHCP clients
  • Automatic client configuration
  • How clients obtain configuration


Client overview

DHCP clients can be any Microsoft Windows-based clients, or other clients that support and comply with client behavior described in the updated DHCP standards document, RFC 2132, published by the Internet Engineering Task Force (IETF).

In most cases, no additional steps are needed to enable Windows-based clients to use DHCP configuration. If a Windows-based client computer is not configured to use DHCP (that is, it is currently configured statically for its IP address), it can be enabled to with a simple configuration change. For more information, see To configure TCP/IP for dynamic addressing.


Microsoft DHCP clients

DHCP client support is provided for computers running under any of these Microsoft operating systems:

  • Windows 2000 (all released versions)
  • Windows NT (all released versions)
  • Windows 98
  • Windows 95
  • Windows for Workgroups version 3.11 (with the Microsoft 32-bit TCP/IP VxD installed)
  • Microsoft-Network Client version 3.0 for MS-DOS (with the real-mode TCP/IP driver installed)
  • LAN Manager version 2.2c

Supported options for Microsoft DHCP clients

By default, Microsoft-based DHCP clients can recognize and use option types in two categories:

  1. Information options

    You can use the DHCP console to explicitly configure these option types and any associated values provided to clients. These options are not required and can be assigned at your discretion.

  2. Protocol options

    You implicitly configure values for these 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.

Information options

All Microsoft DHCP clients support a common set of DHCP standard options. This support is provided for all clients running released versions of Windows and MS-DOS operating systems. For Windows 2000 DHCP clients only, some additional DHCP standard and Microsoft-specific options are also supported.

The following table lists DHCP standard options that all Microsoft DHCP clients are able to support and use, if provided by the DHCP server during the lease process.

Code | Description
3 | Router
6 | DNS server
15 | DNS domain name
44 | WINS server
46 | NetBIOS node type

The following table lists additional DHCP standard options that only Windows 2000 DHCP clients are able to use when configured at the DHCP server and provided during the IP address leasing process.

Code | Description
31 | Perform router discovery
33 | Static route

When a DHCP server actively provides these options, clients receive and use the associated values in their local TCP/IP configurations for the period of leased configuration.

In addition to these standard options, you can also use or assign other Microsoft vendor-specific options when using Microsoft predefined user and vendor classes. For more information, see Microsoft options.

Protocol options

The following table shows internal option types that Microsoft DHCP clients use when communicating with a DHCP server to obtain or renew their leased configurations.

Code | Description
1 | Subnet mask
51 | IP address lease time
53 | DHCP message type
54 | Server identifier
58 | Lease renewal time
59 | Lease rebinding time

In most cases, the actual values provided with these protocol options are provided to clients based on Properties set at the applicable DHCP server where the client obtains its address lease. You can also use the DHCP console to configure or tune these options individually for defined scopes, identifying members of a specified user or vendor class, or for a single reserved client.

Note

  • For more information, see DHCP options reference.


Automatic client configuration

For Windows 2000, DHCP clients automatically configure an IP address and subnet mask when started if a DHCP server is unavailable. This feature—referred to as IP auto-configuration—can be useful for clients on small private networks, such as a small business office or home network environment.

If clients are configured to use a DHCP server (instead of being manually configured with an IP address and other parameters), then the DHCP client service engages each time the computer starts. For Windows 2000, the DHCP client service uses a two-step process to configure the client with an IP address and other configuration information:

  1. The DHCP client attempts to locate a DHCP server and obtain a configuration from it.
  2. If a DHCP server cannot be found, the DHCP client auto-configures its IP address and subnet mask using a selected address from the Microsoft-reserved class B network, 169.254.0.0, with the subnet mask, 255.255.0.0.

    The DHCP client will test for an address conflict by using a gratuitous ARP to make sure that the IP address it has chosen is not already in use on the network. If a conflict is found, the client selects another IP address to try and use. For each address conflict, the client will retry auto-configuration for up to 10 addresses.

  3. Once the DHCP client succeeds in selecting an address in the 169.254.0.0 network range not in use, it will configure the interface with this address.

    The client continues to check for a DHCP server in the background every five minutes. If later a DHCP server is found, the client abandons its auto-configured information. The DHCP client then uses an address offered by the DHCP server (and any other provided DHCP options information) to update its IP configuration settings.

In the case where the DHCP client has previously obtained a lease from a DHCP server, the following modified sequence of events occurs:

  1. If the client lease is still valid (not expired) at boot time, the client will try to renew its lease with the DHCP server.
  2. If during the renewal attempt the client fails to locate any DHCP server, it will attempt to ping the default gateway that is listed in the lease. Depending on whether the ping fails or succeeds, the DHCP client proceeds as follows:
    • If a ping of the default gateway succeeds, the DHCP client assumes that it is still located on the same network where it obtained its current lease, and continue to use the lease.

      By default, the client will next attempt in the background to renew its lease when 50 percent of its assigned lease time has expired.

    • If a ping request of the default gateway fails, the client assumes that it has been moved to a network where DHCP services are not available, such as a home network.

      The client then auto-configures its IP address as described previously. Once the client is auto-configured, it continues to try to locate a DHCP server every five minutes in the background and obtain a lease.


How clients obtain configuration

DHCP clients use two different processes to communicate with DHCP servers and obtain a configuration. The lease process steps vary depending on whether the client is initializing or renewing its lease.

The initialization process occurs when a client computer first starts and attempts to join the network. The renewal process occurs after a client has a lease, but needs to renew that lease with the server.

Initial lease process

The first time a DHCP-enabled client starts, it automatically follows an initialization process to obtain a lease from a DHCP server. The steps for this process are:

  1. The DHCP client broadcasts a DHCP discover message to the local subnet.
  2. A DHCP server can respond with a DHCP offer message (DHCPOFFER) that contains an offered IP address for lease to the client.
  3. If no DHCP servers respond to the client discovery request, the client can proceed in either of two ways:
    • If the client is running under Windows 2000 and IP auto-configuration has not been disabled, the client self-configures an IP address for use with automatic client configuration.
    • If the client is not running under Windows 2000 (or IP auto-configuration has been disabled), the client fails to initialize. Instead, if left running, it continues to resend DHCP discover messages in the background (four times every five minutes) until it receives a DHCP offer message from a server.
  4. As soon as a DHCP offer message is received, the client selects the offered address by replying to the server with a DHCP request.
  5. Typically, the offering server sends a DHCP acknowledgement message (DHCPACK), approving the lease.

    Also, other DHCP options information is included in the acknowledgement.

  6. Once the client receives acknowledgment, it configures its TCP/IP properties using the information in the reply and joins the network.

The following illustration shows the lease process between the DHCP server and client.

Initial DHCP lease process between server and client

Note

  • In rare cases, a DHCP server can alternately return a DHCP negative acknowledgment message (DHCPNAK) to the client for step 5. This can happen when a client requests an invalid or duplicate address for the network. If a client receives a negative acknowledgement, the current initialization process fails. In this case, the client starts over at step 1, repeating the process as outlined above.

Lease renewal process

When a DHCP client shuts down and restarts (on the same subnet), it typically obtains a lease for the same IP address it had prior to the shutdown.

After 50 percent of the client lease time elapses, the client tries to renew its lease with the DHCP server as follows:

  1. The client sends a DHCP request message (DHCPREQUEST) directly to the server that leased it, to renew and extend its current address lease.
  2. If the server is reachable, it typically sends a DHCP acknowledgement message (DHCPACK) to the client, which renews the current lease.

    Also, as in the initial lease process, other DHCP options information is included in this reply. If any options information has changed since the client first obtained its lease, the client updates its configuration accordingly.

  3. If the client is unable to communicate with its original DHCP server, the client waits until it reaches a rebinding state. When the client reaches this state, it attempts to renew its current lease with any available DHCP server.
  4. If a server responds with a DHCP offer message (DHCPOFFER) to update the current client lease, the client can renew its lease based on the offering server and continue operation.
  5. If the lease expires and no server has been contacted, the client must immediately discontinue using its leased IP address.
  6. The client then follows the same process used during its initial startup operation to obtain a new IP address lease.


DHCP/BOOTP relay agents

This section covers:

  • Understanding relay agents
  • Relay agent configurations
  • Relay agent design issues


Understanding relay agents

A relay agent is a small program that relays DHCP/BOOTP messages between clients and servers on different subnets. DHCP/BOOTP relay agents are part of the DHCP and BOOTP standards and function according to the Request for Comments (RFCs), standard documents that describe protocol design and related behavior. (For more information, see DHCP RFCs.)

DHCP/BOOTP router support

In TCP/IP networking, routers are used to interconnect hardware and software used on different physical network segments called subnets and forward IP packets between each of the subnets. To support and use DHCP service across multiple subnets, routers connecting each subnet should comply with DHCP/BOOTP relay agent capabilities described in RFC 1542.

To be compliant with RFC 1542 and provide relay agent support, each router must be able to recognize BOOTP and DHCP protocol messages and process (relay) them appropriately. Because routers interpret DHCP messages as BOOTP messages (such as a UDP message sent through the same UDP port number and containing shared message structure), a router with BOOTP-relay agent capability typically relays DHCP packets and any BOOTP packets sent on the network.

If a router cannot function as a DHCP/BOOTP relay agent, each subnet must have either its own DHCP server or another computer that can function as a relay agent on that subnet. In cases where it is impractical or impossible to configure routers to support DHCP/BOOTP relay, you can configure a computer running Windows NT Server 4.0 or later to act as a relay agent by installing the DHCP Relay Agent service.

In most cases, routers support DHCP/BOOTP relay. If your routers do not, contact your router manufacturer or supplier to find out if a software or firmware upgrade is available to support this feature.

How relay agents work

A relay agent relays DHCP/BOOTP messages that are broadcast on one of its connected physical interfaces, such as a network adapter, to other remote subnets to which it is connected by other physical interfaces. The following illustration shows how client C on Subnet 2 obtains a DHCP address lease from DHCP server 1 on Subnet 1.

DHCP/BOOTP relay agent
  1. DHCP client C broadcasts a DHCP/BOOTP discover message (DHCPDISCOVER) on Subnet 2, as a User Datagram Protocol (UDP) datagram using the well-known UDP server port of 67 (the port number reserved and shared for BOOTP and DHCP server communication).
  2. The relay agent, in this case a DHCP/BOOTP relay-enabled router, examines the gateway IP address field in the DHCP/BOOTP message header. If the field has an IP address of 0.0.0.0, the agent fills it with the relay agent or router's IP address and forwards the message to the remote Subnet 1 where the DHCP server is located.
  3. When DHCP server 1 on remote Subnet 1 receives the message, it examines the gateway IP address field for a DHCP scope that can be used by the DHCP server to supply an IP address lease.

  4. If DHCP server 1 has multiple DHCP scopes, the address in the gateway IP address field (GIADDR) identifies the DHCP scope from which to offer an IP address lease.

    For example, if the gateway IP address (GIADDR) field has an IP address of 10.0.0.2, the DHCP server checks its available set of address scopes for a scope range of addresses that matches the class A IP network that includes the gateway address as a host. In this case, the DHCP server would make a check for a scope of addresses between 10.0.0.1 and 10.0.0.254. If a matching scope exists, the DHCP server selects an available address from the matched scope to use in an IP address lease offer response to the client.

  5. When DHCP server 1 receives the DHCPDISCOVER message, it processes and sends an IP address lease offer (DHCPOFFER) directly to the relay agent identified in the gateway IP address (GIADDR) field.

  6. The router then relays the address lease offer (DHCPOFFER) to the DHCP client.

    The client IP address is still unknown, so it has to be broadcast on the local subnet. Similarly, a DHCPREQUEST message is relayed from client to server, and a DHCPACK message is relayed from server to client, according to RFC 1542.

Note

  • For more information, see Relay agent design issues.


Relay agent configurations

There are several relay agent configuration options available if you plan to incorporate a relay agent into your DHCP/BOOTP-enabled network. These include using other routers, Windows 2000 Routing and Remote Access service, and the DHCP Relay Agent component provided in Windows NT Server 4.0.

Third party router

This example shows a third party router configuration. The router is running a relay agent forwarding DHCP requests between Subnet A and Subnet B. Typically, the relay agent on the router must be configured with the IP Helper Address of the DHCP server.

Third party router

Windows 2000 Server Routing and Remote Access service

This example shows the Windows 2000 Server Routing and Remote Access configuration. The DHCP Relay Agent on Windows 2000 Server must be configured with the IP address of the DHCP server to relay DHCP requests between Subnet A and Subnet B. For more information about setting up the DHCP Relay Agent in Windows 2000 Server, see Configure the DHCP Relay Agent.

Windows 2000 Routing and Remote Access

Windows NT Server 4.0

This example shows how a standard IP router can be used with Windows NT Server 4.0 to relay DHCP requests between Subnet A and Subnet B.

Windows NT 4.0


Relay agent design issues

There are important design issues to consider before you set up relay agents on your network.

When you have multiple DHCP servers, Microsoft recommends that you place your DHCP servers on different subnets, to achieve a degree of fault tolerance, rather than having all of them on one subnet. The servers should not have common IP addresses in their scopes (each server should have a unique pool of addresses).

If the DHCP server on the local subnet shuts down, requests are relayed to a remote subnet, The DHCP server at that location can respond to DHCP requests if it maintains a scope of IP addresses for the requesting subnet. If the remote server has no scope defined for the requesting subnet, it cannot provide IP addresses even if it has available addresses for other scopes. If each DHCP server has a pool of addresses for each subnet, then it can provide IP addresses for remote clients whose own DHCP server is offline.

Recommended

The following relay agent implementation is recommended for best routed DHCP network performance. It uses two DHCP servers that are attached to two different subnets. The relay agents operating on each of the routers used to connect the subnets have varied delay intervals (one is set to 4 seconds, the other uses no delay). This eliminates the risk of undesirable floods of DHCP packets through randomly selected network paths.

Example: recommended DHCP/BOOTP relay agent configuration

Not recommended

The following relay agent implementation is not recommended. It has the same number of DHCP servers and subnets as in the previous example, but less caution has been used. The risk of DHCP discovery messages (DHCPDISCOVERs), which are broadcasted by the DHCP clients at startup, being randomly forwarded or duplicated when destined for the other subnets is much higher. Moreover, the relay agents do not use any delay interval. This increases the likelihood that both relay agents (routers) duplicate any client broadcasted messages, which could potentially flood the remote subnets.

Example: DHCP/BOOTP relay agent configuration not recommended


DHCP in Windows 2000

This section covers:

  • Audit logging
  • Multicast address allocation


Audit logging

Windows 2000 DHCP servers include several new logging features and server parameters that provide enhanced auditing capabilities. You can now specify the following features:

  • The directory path in which the DHCP server stores audit log files.
  • A maximum size restriction (in megabytes) for the total amount of disk space available for all audit log files created and stored by the DHCP service.
  • An interval for disk checking that is used to determine how many times the DHCP server writes audit log events to the log file before checking for available disk space on the server.
  • A minimum size requirement (in megabytes) for server disk space that is used during disk checking to determine if sufficient space exists for the server to continue audit logging.

Notes

  • You can selectively enable or disable the audit logging feature at each DHCP server. For more information, see To enable DHCP server logging.
  • Only the directory path in which the DHCP server stores audit log files can be modified using the DHCP console. To do so, first select the applicable DHCP server in the console tree. On the Action menu, click Properties. Next, click the Advanced tab and edit Audit log file path as necessary.
  • Other audit logging parameters described above are adjusted through registry-based configuration changes. For more information on the Windows 2000 DHCP server registry, see the Windows 2000 Server Resource Kit. For more information on modifying the registry, see The Windows 2000 registry.

How audit logging works

The audit logging behavior discussed in this section applies only to the DHCP Server service provided with Windows 2000 Server. It replaces the previous DHCP logging behavior used in earlier versions of Windows NT Server, which do not perform audit checks and use only a single log file named Dhcpsrv.log for logging service events.

The formatted structure of DHCP server logs and the level of reporting maintained for audited logging are the same as in earlier DHCP server versions provided with Windows NT Server. For more information, see Analyzing server log files.

Naming audit log files

The DHCP Server service bases the name of the audit log file on the current day of the week, as determined by checking the current date and time at the server.

For example, when the DHCP server starts, if the current date and time is:

Wednesday, March 5, 1998, 04:56:42 P.M.

then the server audit log file is named:

DhcpSrvLog.Wed

Starting a daily audit log

When a DHCP server starts or a new week day begins (when the local time on the computer is 12:00 A.M.), the server writes a header message in the audit log file, indicating that logging has started. Then, depending on whether the audit log file is a new or existing file, the following actions occur:

  • If the file already existed without modification for more than a day, it is overwritten.
  • If the file already existed but was modified within the previous 24 hours, the file is not overwritten. Instead, new logging activity is appended to the end of the existing file.

Disk checks

After audit logging starts, the DHCP server performs disk checks at regular intervals, to ensure both the ongoing availability of server disk space and that the current audit log file does not become too large or that log-file growth is not occurring too rapidly.

The DHCP server performs a full disk check whenever either of the following conditions occurs:

  • A set number of server events are logged.
  • When the date changes on the server computer.

By default, the DHCP server performs a periodic disk space check for every 50 events it writes to the audit log. A date change can also be detected by the DHCP server when the server computer reaches 12:00 A.M. on its locally set Date/Time clock.

Each time a disk check is completed, the server determines whether disk space is filled. The disk is considered full if either of the following conditions is true:

  • Disk space on the server computer is lower than the required minimum amount for DHCP audit logging.

    By default, if the amount of disk space remaining on the server disk reaches less than 20 megabytes, audit logging is halted.

  • The current audit log file is larger than one-seventh (1/7) of the maximum allotted space or size for the combined total of all audit logs currently stored on the server.

    At the time of the disk check, the DHCP server compares the exact size (in megabytes) of the current audit log file with a value obtained by dividing the current value for the maximum number of log files the server permits to be stored simultaneously before overwriting and discarding of older log files. By default, seven is the maximum number of log files the server permits to be stored, one for each day of the week. Assuming the default is set, the largest size that the current audit log file can reach is one megabyte.

In either case, if the disk is full, the DHCP server closes the current file and ignores further requests to log audit events until either 12:00 A.M. or until disk status is improved and the disk is no longer full.

Even if audit logged events are ignored because of a disk full condition, the DHCP server continues disk checking every 50 events (or the currently set interval) to determine whether disk conditions have improved. If subsequent disk checks determine that the required amount of server disk space is available, the DHCP server reopens the current log file and resumes logging.

Ending a daily audit log

At 12:00 A.M. local time on the server computer, the DHCP server closes the existing log and moves to the log file for the next day of the week. For example, if the day of the week changes at 12:00 A.M. from Wednesday to Thursday, the log file named DhcpSrvLog.Wed is closed and the file named DhcpSrvLog.Thu is opened and used for logging events.


Multicast address allocation

Windows 2000 DHCP servers have been extended to allow the assignment of multicast addresses, in addition to assignment of unicast addresses.

A proposed Internet Engineering Task Force (IETF) standard defines a client/server protocol, the Multicast Address Dynamic Client Allocation Protocol (MADCAP), for defining multicast address allocation between supporting servers and clients. The primary benefit of the proposed MADCAP standard is that you can use it to leverage your existing network infrastructure for assigning multicast addresses in the same way as other IP addresses are currently assigned using DHCP.

Typical applications for multicast are conferencing and audio, which usually require users to specially configure multicast addresses. Unlike IP broadcasts, which must be readable by all computers on the network, a multicast address is a group of computers, using the concept of a group membership to identify those to which the message is to be sent.

The multicast address allocation feature has two parts:

  1. A MADCAP server, which distributes multicast addresses.

    To use this feature, the administrator first configures multicast scopes and the corresponding multicast IP ranges on the server through the DHCP console. Once these scopes are administratively set and activated, the Windows 2000 DHCP Server service can provide multicast addresses in the same way it normally provides unicast IP addresses where DHCP scopes are used.

  2. Client-side application programming interfaces (APIs), which MADCAP clients can use to request, renew, or release multicast addresses.

    Applications that implement MADCAP client support can call these APIs to request a multicast address from a given multicast scope at the MADCAP server. The underlying MADCAP implementation uses protocol messages similar to the DHCP messaging format to negotiate the multicast address lease between the client and server.

For more information, see Using multicast scopes.

Notes

  • The standards for multicast address allocation are currently under review and are managed by the Multicast address-allocation (MALLOC) working group of the IETF.
  • You can obtain RFCs from the Request for Comments Web site (http://www.rfc-editor.org/).

    This Web site is currently maintained by members of the Information Sciences Institute (ISI), who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standard, proposed Internet standard (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents.


DHCP options

DHCP provides an internal framework for passing configuration information on to clients on your network. Configuration parameters and other control information are carried in tagged data items stored within protocol messages exchanged between the DHCP server and its clients. These data items are called options.

Most standard DHCP options are currently defined in Request for Comments (RFCs) published by the Internet Engineering Task Force (IETF). The full set of standard DHCP options are described specifically in RFC 2132, "DHCP Options and BOOTP Vendor Extensions."

All DHCP options mentioned in RFC 2132 are predefined for you to configure and use at any Windows 2000 DHCP server. If needed, you can also use the DHCP console to define new DHCP options at each server.

Even though most DHCP servers can assign many options, most DHCP clients are typically designed to request or support only a subset of the full RFC-specified standard options set.

  • For more information, see either DHCP RFCs or the DHCP options reference.

How options are applied

Options can be managed using different levels assigned for each managed DHCP server, including:

  • Server options These options are applied for all scopes defined at a DHCP server.
  • Scope options These options are applied specifically to all clients that obtain a lease within a particular scope.
  • Class options These options are applied only to clients that are identified as members of a specified user or vendor class when obtaining a lease.
  • Client options These options apply only for a single reserved client computer and require a reservation to be used in an active scope.

For more information, see Setting up options.


Understanding user and vendor classes

There are significant differences in the way in which vendor and user classes are available for use by DHCP clients and servers. The following table compares and contrasts the features of these classes.

User classes | Vendor classes
Part of proposed DHCP standard drafts.

For updated information, obtain the latest draft from the Request for Comments Web site (http://www.rfc-editor.org/).

 Part of accepted DHCP standard drafts (RFC 2131, 2132).

For more information, see DHCP RFCs.
Clients identify user class membership with User class information. | Clients identify vendor class membership by using the Vendor class identifier option.
User class IDs can be set and viewed at Windows 2000 DHCP clients using the ipconfig command.

For more information, see:

  • To set DHCP class ID information at a client computer
  • To show DHCP class ID information at a client computer
 Vendor class IDs are configured internally by DHCP client system vendors, such as Microsoft and other vendors.

When adding a vendor class at the server, you need to specify class data at the server that matches identically the class ID used by same-vendor clients. For more information, contact the applicable vendor.
Once you create a user class, you can selectively assign options to be provided to identifying members of it. | Once you create a vendor class, you need to add and define options to make it useful to either all or some clients of the DHCP server.
With user classes, you can take advantage of predefined classes that can be used to support specialized groups of clients, such as BOOTP or Routing and Remote Access clients.

For more information, see Microsoft predefined user classes.

 With vendor classes, Microsoft has implemented vendor classes to the provided classification of its DHCP clients by Windows 2000, Windows 98, or Microsoft DHCP clients which share the use of the Microsoft-reserved vendor prefix ("MSFT") in any class-related data used.

For more information, see Microsoft vendor classes.
User classes are typically created for administrative reasons, such as to identify all DHCP clients in a specific site or location.

For example, all computers and printers located on the same floor in an office building might be assigned or configured as part of the same user class.

 Vendor classes are typically created for the enhancement of vendor-specific DHCP functionality.

For example, Microsoft provides several additional vendor-specific options, such as the ability to disable NetBIOS over TCP/IP at Windows 2000 DHCP clients. For more information, see Microsoft vendor-specific options.
User classes are most helpful to users for managing DHCP option assignments based on their needs.

If your DHCP network is large enough to benefit from user classes, you can freely customize your DHCP environments with them. In most cases, the user class provides a way to assign and override standard DHCP option values set at either the server, scope, or reserved client level.

 Vendor classes are most helpful to vendors for managing DHCP option assignments based on vendor-specific needs without disturbing other non-vendor DHCP clients.

With a vendor class, options are passed to clients using the Vendor specific information option, which encapsulates the options it sends. This helps non-vendor clients to recognize the information as vendor-specific and ignore and discard it as needed.

Notes

  • For more information, see Using option classes or To create a new user or vendor class.


BOOTP and DHCP

The Bootstrap protocol (BOOTP) is a host configuration protocol developed before DHCP . DHCP improves on BOOTP and resolves specific limitations BOOTP had as a host configuration service. RFC 951 defines BOOTP.

BOOTP/DHCP similarities

Because of the relationship between BOOTP and DHCP, both protocols share some defining characteristics. The common elements include:

  • The format structure each uses to exchange messages between the server and clients

    BOOTP and DHCP use nearly identical request messages (sent by clients) and reply messages (sent by servers). Messages in either of these protocols use a single User Datagram Protocol (UDP) datagram of 576 bytes to enclose each protocol message. Message headers are the same for both BOOTP and DHCP with one exception: the final message header field used to carry optional data. For BOOTP, this optional field is called the vendor-specific area and is limited to 64 octets. For DHCP, this area is called the options field and can carry up to 312 octets of DHCP options information.

  • Use of well-known UDP ports for client/server communication

    Both BOOTP and DHCP use the same reserved protocol ports for sending and receiving messages between servers and clients. Both BOOTP and DHCP servers use UDP port 67 to listen for and receive client request messages. BOOTP and DHCP clients typically reserve UDP port 68 for accepting message replies from either a BOOTP server or DHCP server.

    Because DHCP and BOOTP messages use nearly identical format types and packet structures, and typically use the same well-known service ports, BOOTP or DHCP relay agent programs usually treat BOOTP and DHCP messages as essentially the same message type, without differentiating between them.

  • IP address distribution as an integral part of configuration service

    Although both BOOTP and DHCP allocate IP addresses to clients during startup, they use different methods of allocation. BOOTP typically provides fixed allocation of a single IP address for each client, permanently reserving this address in the BOOTP server database. DHCP typically provides dynamic, leased allocation of available IP addresses, reserving each DHCP client address temporarily in the DHCP server database.

BOOTP/DHCP differences

There are significant differences in the way in which BOOTP and DHCP perform host configuration. The following table compares and contrasts the features of the two protocols that vary.

BOOTP | DHCP
Designed prior to DHCP. | Designed after BOOTP.
Intended to configure diskless workstations with limited boot capabilities. | Intended to configure frequently relocated networked computers (such as portables) that have local hard drives and full boot capabilities.
Supports a limited number of client configuration parameters called vendor extensions. | Supports a larger and extensible set of client configuration parameters called options.
Describes a two-phase bootstrap configuration process, as follows:
  • Clients contact BOOTP servers to perform address determination and boot file name selection.
  • Clients contact Trivial File Transfer Protocol (TFTP) servers to perform file transfer of their boot image.
Describes a single-phase boot configuration process whereby a DHCP client negotiates with a DHCP server to determine its IP address and obtain any other initial configuration details it needs for network operation.
BOOTP clients do not rebind or renew configuration with the BOOTP server except when the system restarts. | DHCP clients do not require a system restart to rebind or renew configuration with the DHCP server. Instead, clients automatically enter a rebinding state at set timed intervals to renew their leased address allocation with the DHCP server. This process occurs in the background and is transparent to the user.


The DHCP database

The DHCP database in Windows 2000 Server uses the performance-enhanced Exchange Server Storage engine version 4.0.

There is no built-in limit to the number of records that a DHCP server can store. The size of the database is dependent upon the number of DHCP clients on the network. The DHCP database grows over time as a result of clients starting and stopping on the network.

The size of the DHCP database is not directly proportional to the number of active client lease entries. Over time, as some DHCP client entries become obsolete and are deleted, there remains some unused space.

To recover the unused space, the DHCP database must be compacted. Starting with Windows NT Server 4.0, dynamic database compaction occurs on DHCP servers as an automatic background process during idle time after a database update.

Although dynamic compacting greatly reduces the need for doing off-line compaction, it does not fully eliminate the need for off-line compacting. Off-line compaction more effectively reclaims the space and should be performed about once a month for very large and busy networks with 1,000 or more DHCP clients. For smaller networks, manual compaction can be useful when performed every few months.

Because dynamic database compaction occurs while the database is in use, stopping the DHCP server is not necessary for it to occur. However, for manual compacting, a DHCP server must be stopped and compacting performed off-line.

Notes

  • When using or upgrading DHCP databases used with earlier versions of Windows NT Server, the DHCP database requires conversion. For Windows 2000 Server, if a previous copy of the DHCP server database is detected during an upgrade, it is automatically converted to the current database version and format. For larger databases, this process can increase the time needed to complete the installation.
  • For more information on using manual compaction of the DHCP server database using Jetpack.exe, see Restoring server data.
  • For more information on the files used to support the server database, see DHCP database files.


Using DHCP

This section covers:

  • Planning DHCP networks
  • Managing DHCP servers
  • Setting up scopes
  • Supporting clients
  • Setting up options
  • Interoperability issues


Planning DHCP networks

This topic covers the following DHCP network planning issues.

  • How many DHCP servers to use
  • How to support DHCP clients on additional subnets
  • Planning for routed DHCP networks
  • Other planning considerations for enterprise networks

How many DHCP servers to use

When deciding how many DHCP servers you need, consider the location of routers on the network and whether you want a DHCP server in each subnet. When extending use of a DHCP server across more than one network, you often need to configure additional DHCP relay agents and, in some cases, use superscopes as well.

Transmission speed between the segments for which DHCP service is provided is another important factor. If you have slower WAN links or dial-up links, you typically need a DHCP server on both sides of these links to service clients locally.

There is no fixed limit to the maximum number of clients that a single DHCP server can serve. However, your network can have practical constraints based on the IP address class selected for use and other server configuration details.

When you are examining factors that could enhance DHCP server performance, consider the following:

  1. The primary contributing factor to improving DHCP server performance is the speed of the server disk drives.

    For this reason, you should carefully evaluate disk access time and average times for disk read/write operations when sizing and planning for your DHCP server hardware specifications. In many instances, this is more important than other server requirements, such as memory and processor.

  2. As a general recommendation, limit each DHCP server to having no more than 1,000 scopes defined for use.

    When adding a large number of scopes to the server, be aware that each scope creates a corresponding need for additional incremental increases to the amount of disk space used for the DHCP server registry and for the server paging file.

    For more information, see either To change the maximum size of the computer's registry or To change the size of the virtual memory paging file.

  3. For the best possible DHCP server design in most networks, it is recommended that you have, at most, 10,000 clients per server.

    This recommended per-server maximum reflects suggested baseline DHCP server performance monitoring and provides for unusual burst traffic conditions, such as after a large-scale power outage when many DHCP client computers might restart simultaneously. In addition to observing recommended server capacity baselines, split each of your scopes (such as by applying an 80/20 rule) between two to three servers for fault tolerance.

    For more information, see Configuring scopes.

For example, if you were to define 1,000 scopes for a DHCP server, each of the scopes should provide addresses actively to an average of no more than 10 clients. In any event, you need to allocate additional disk space to store the added scope information and likely would also need to change the default server registry and paging file size settings to permit increased growth when accommodating a large number of scopes and clients.

Windows 2000 Server provides added performance monitoring tools that you can use to test and monitor your servers. Also, you might want to review DHCP server performance test results that were generated by the Windows 2000 development team during product development.

For more information, see Monitoring server performance.

A DHCP planning alternative: configuring standby servers

Most networks need one primary online DHCP server and one other DHCP server acting as a secondary or backup server. If you choose not to implement two DHCP servers using the 80/20 rule for balancing scopes but want to continue to provide a measure of potential fault tolerance, you might consider implementing a backup or hot standby DHCP server as an alternative.

In the hot standby configuration, the standby DHCP server is another server computer that is installed and configured identically to your primary DHCP server. In the case of the standby, the only difference is that the standby server and its scopes are not activated for use under normal conditions. Duplicate scopes are configured but not activated except when critically needed, such as to substitute for the primary DHCP server because it has stopped or been taken offline for an extended period of time.

Because the hot standby solution requires special attention to its configuration and also manual administration for ensuring fall-over transition for DHCP clients to use it, it is less recommended as a planning alternative than the use of two to three DHCP servers that balance active scope use.

Supporting additional subnets

For DHCP service to support additional subnets on your network, you must first determine whether the routers used to connect adjoining subnets can support relaying of BOOTP and DHCP messages. If routers cannot be used for DHCP and BOOTP relay, you can set up either of the following for each subnet:

  • A computer running either Windows 2000 Server or Windows NT Server 4.0 configured to use the DHCP Relay Agent component.

    This computer simply forwards messages back and forth between clients on the local subnet and a remote DHCP server, using the IP address of the remote server. The DHCP Relay Agent service is available only on computers running Windows 2000 Server or Windows NT Server 4.0.

  • A computer running Windows 2000 Server configured as a DHCP server for the local subnet.

    This server computer must contain and manage scope and other address-configurable information for the local subnet it serves.

For more information, see Relay agent configurations.

Planning for routed DHCP networks

In routed networks that use subnets to divide network segments, planning options for DHCP services must observe some specific requirements for a full implementation of DHCP services to function. These requirements include:

  • One DHCP server must be located on at least one subnet in the routed network.
  • For a DHCP server to support clients on other remote subnets separated by routers, a router or remote computer must be used as a DHCP and BOOTP relay agent to support forwarding of DHCP traffic between subnets.

The following illustration shows a simple routed network with DHCP implemented.

Example of a routed DHCP network

Enterprise planning considerations

For an enterprise DHCP network, you should:

  • Plan the physical subnets of the network and relative placement of DHCP servers.

    This includes planning for placement of DHCP (and WINS) servers in subnets in a way that reduces b-node broadcasts across routers.

  • Specify the DHCP option types and their values to be predefined per scope for the DHCP clients.

    This can include planning for scopes based on the needs of particular groups of users. For example, a unit that frequently moves computers to different locations, like a marketing group that uses portable computers docked at different stations, shorter lease durations can be defined for the related scopes. This approach collects IP addresses that are changed frequently and disposed of and returns them to the pool of available addresses that can be used for new lease offerings.

  • Recognize the impact that slower links have on your WAN environment.

    Place DHCP, WINS, and DNS servers to maximize response time and minimize low-speed traffic.

As one example of planning for a large enterprise network, the segmenting of the WAN into logical subnets can match the physical structure of the internetwork. Then one IP subnet can serve as the backbone and, this backbone in relation to each physical subnet maintains a separate IP subnet address.


Managing DHCP servers

This section covers:

  • Authorizing DHCP servers
  • Monitoring server performance
  • Restoring server data
  • Moving a DHCP database to another server
  • Analyzing server log files
  • Clustering support for DHCP servers


Authorizing DHCP servers

Windows 2000 Server provides integrated security support for networks that use Active Directory. This support adds and uses a class of objects that is part of the base directory schema, providing the following enhancements:

  • A list of IP addresses available for the computers that you authorize to operate as DHCP servers on your network.
  • Detection of unauthorized DHCP servers and prevention of their starting or running on your network.

The following sections discuss:

  • Background information about the detection of unauthorized DHCP servers.
  • How computers are authorized in Active Directory to provide DHCP service.
  • How an unauthorized server is detected and prevented from providing DHCP service.
  • Notes and limitations for implementing DHCP service, depending on whether Active Directory service is available.

Background on unauthorized DHCP servers

When configured correctly and authorized for use on a network, DHCP servers provide a useful and intended administrative service. However, when a misconfigured or unauthorized DHCP server is introduced into a network, it can cause problems. For example, if an unauthorized DHCP server starts, it might begin either leasing incorrect IP addresses to clients or negatively acknowledging DHCP clients attempting to renew current address leases.

Either of these configurations can produce further problems for DHCP-enabled clients. For example, clients that obtain a configuration lease from the unauthorized server can fail to locate valid domain controllers, preventing clients from successfully logging on to the network.

To avoid these problems in Windows 2000, servers are verified as legal in the network before they can service clients. This avoids most of the accidental damage caused by running DHCP servers with incorrect configurations or correct configurations on the wrong network.

How DHCP servers are authorized

The authorization process for DHCP server computers in Active Directory depends on the installed role of the server on your network. For Windows 2000 Server (as in earlier versions) there are three roles or server types for which each server computer can be installed:

  • Domain controller. The computer keeps and maintains a copy of the Active Directory service database and provides secure account management for domain member users and computers.
  • Member server. The computer is not operating as a domain controller but has joined a domain in which it has a membership account in the Active Directory service database.
  • Stand-alone Server. The computer is not operating as a domain controller or a member server in a domain. Instead, the server computer is made known to the network through a specified workgroup name, which can be shared by other computers, but is used only for browsing purposes and not to provide secured logon access to shared domain resources.

If you deploy Active Directory, all computers operating as DHCP servers must be either domain controllers or domain member servers before they can be authorized in the directory service and provide DHCP service to clients.

To authorize a computer as a DHCP server, the following process steps can be used:

  1. Log on to the network using either an account that has enterprise administrative privileges or one that has been delegated authority to authorize DHCP servers for your enterprise.

    In most cases, it is simplest to log on to the network from the computer where you want to authorize the new DHCP server. This ensures that other TCP/IP configuration of the authorized computer has been set up correctly prior to authorization.

    Typically, you can use an account that has membership in the Enterprise Administrators group. The account you use must allow you to have Full Control rights to the NetServices container object as it is stored in the enterprise root of the Active Directory service.

  2. Install the DHCP service on this computer.

    For more information, see To install a DHCP server.

  3. Start the DHCP console and select the computer operating as a DHCP server that you want to have added as an authorized server in the directory service database.

    If the local computer is to be authorized, select Local computer for connection when starting the DHCP console. If another computer on your network is to be authorized, select Remote computer.

    For more information, see either To authorize a DHCP server in Active Directory or To open the DHCP console.

When a DHCP server is authorized, the server computer is added to the list of authorized DHCP servers maintained in the directory service database. You can verify that a server has been added by checking the properties using the Active Directory Sites and Services console. These properties appear under Configuration, which is a global container maintained at the following folder location relative to the enterprise root:

\Configuration\Services\NetServices

In some cases, you might choose to delegate the ability for non-enterprise administrators to have appropriate security access to this object type to create and modify the list of authorized DHCP servers. This can be useful in cases where the DHCP server is set up and prepared at another location before being shipped to a remote site for installation and authorization for service on the network.

For more information, see either To delegate ability to authorize DHCP servers to a non-enterprise administrator.

How unauthorized servers are detected

Windows 2000 DHCP servers provide detection of both authorized and unauthorized servers using the following specific enhancements for the DHCP standard:

  • The use of information messaging between DHCP servers using DHCP informational messages.
  • The addition of several new vendor-specific option types, for communicating information about the root domain.

The Windows 2000 DHCP server uses the following process to detect other DHCP servers currently running on the same network and determine if they are authorized to provide service.

When the DHCP service starts, it sends a DHCP informational message (DHCPINFORM) request to the reachable network, using the local limited broadcast address (255.255.255.255), to locate the root domain on which other DHCP servers are installed and configured.

This message includes several vendor-specific option types that are known and supported by other DHCP servers running Windows 2000 Server. When received by other DHCP servers, these option types enable the query and retrieval of information about the root domain.

When queried, other DHCP servers reply with DHCP acknowledgement messages (DHCPACK) to both acknowledge and answer with root domain information. In this way, the initializing DHCP server collects and compiles a list of all currently active DHCP servers on the reachable network, along with the root (of the root domain) used by each server.

Typically, only one single enterprise root is detected, and it is the same for all DHCP servers that are reachable and respond to acknowledge the initializing server. However, if additional enterprise roots are detected, each root is queried to determine whether the computer is authorized for DHCP service for those other enterprises discovered during this phase.

After a list of all DHCP servers running on the network is built, the next step in the detection process depends on whether a directory service is found to be available from the local computer.

If the directory service is not available (such as where the initializing DHCP server is installed in a confined network environment used for testing) the initializing server can start if no other DHCP servers are discovered on the network that are part of any enterprise. Where this condition is met, the server successfully initializes and begins serving DHCP clients.

However, the server continues every five minutes to collect information about other DHCP servers running on the network, using DHCPINFORM as it did at startup. Each time, it checks whether the directory service is available. If a directory service is found, the server ensures that it is authorized by following the procedure, depending on whether it is a member server or a standalone server.

  • For member servers (a server joined to a domain that is part of the enterprise), the DHCP server queries the directory service for the DHCP server list of addresses that have been authorized.

    If the server finds its IP address in the authorized list, it initializes and starts providing DHCP service to clients. If it does not find itself in the authorized list, it does not initialize and stops providing DHCP services.

  • For stand-alone servers (a server not joined to any domain or part of an existing enterprise), the DHCP server queries the directory service with the root of the enterprise returned by each of the other DHCP servers to see if it can find itself on the authorized list with any of the reported enterprises.

    The server initializes and starts providing DHCP services to clients only if the server finds its IP address in the authorized list for each of the enterprise roots reported by other DHCP servers. If it does not find itself in the authorized list for each of the reported enterprise roots, it does not initialize and the DHCP service is stopped.

Notes

  • The process of authorizing DHCP servers is only useful for DHCP servers running Windows 2000 Server. Authorization does not apply if DHCP servers are running:

    • Windows NT Server 4.0, and earlier versions.
    • Other DHCP server software.
  • For the directory authorization process to work properly, it is necessary that the first DHCP server introduced on to your network participate in Active Directory. This requires that the server be installed as either a domain controller or a member server. When planning or deploying Active Directory with Windows 2000 DHCP, it is important that you do not select to install your first DHCP server computer as a stand-alone server.
  • Most commonly, there will only be one enterprise root and therefore, only a single point for directory authorization of the DHCP servers. However, there is no restriction on authorizing DHCP servers for more than one enterprise root.


Monitoring server performance

Because DHCP servers are of critical importance in most environments, monitoring their performance can help in troubleshooting cases where server performance has been degraded.

Windows 2000 Server provides a set of DHCP server performance counters that can be used to measure and monitor various aspects of server activity, such as the following:

  • All types of DHCP messages sent and received by the DHCP service.
  • The average amount of processing time spent by the DHCP server per message packet sent and received.
  • The number of message packets dropped because of internal delays at a DHCP server computer.

For more information, see DHCP performance monitoring reference.

Sample DHCP server performance test results

The DHCP development and testing team compiled the following statistics as a profile of DHCP server performance during preliminary testing of Windows 2000 Server.

DHCP server performance measurements

For this test, the DHCP server and client computers used for testing were configured as follows:

  • Four client computers were positioned on a routed network to simulate DHCP client activity. Two of the computers were located locally on the same subnet as the server and two were located on a remote subnet reachable through a router.
  • All client computers were configured to run a client stress application recreating the simulated affect of ten actual DHCP client computers simultaneously sending DHCP messages on the network to the server.
  • The client computers were set up to perform sending of DHCP discovery messages (DHCPDISCOVERs) 20% of the time, such as occurs in the case of a computer newly added and started on the network and obtaining a new IP address lease. For the remaining 80% of the time, the client computers sent DHCP request messages (DHCPREQUESTs), such as are typically generated when clients renew a current IP address lease.

For the clients to perform sending of DHCP discovery messages (DHCPDISCOVERs), each of the client computers generated and included a new media access control (MAC) address in its request. To the DHCP server, the unique MAC address implies that the client is new and leases it accordingly.

Server performance was measured each hour for the first twelve hours of testing and is noted in the table below for every hour.

Hours of client stress completed | Total leases provided by server
1 hour | 489,867
2 hours | 379,319
3 hours | 378,223
4 hours | 383,694
5 hours | 352,832
6 hours | 338,830
7 hours | 340,378
8 hours | 320,391
9 hours | 301,145
10 hours | 312,588
11 hours | 317,580
12 hours | 314,683

DHCP scope performance measurements

For this test, the same test was performed four times using an increasing number of scopes at the DHCP server for each iteration. The client activity was recreated using a single client computer configured to run the client stress application operating as described for the previous sample tests.

Scope performance was measured at the server for response times for each set of 25,000 DHCP acknowledgment messages (DHCPACKs) the server returned when leasing clients. Time was measured for both initializing and renewing clients. (For more information, see How clients obtain configuration.)

Prior to performing these tests, the server registry size was increased to 100 megabytes (MB) and the server paging file size was increased to one gigabyte (GB).

The results of each of these four tests are listed in the table below.

Number of scopes | Initial lease offer time (milliseconds) | Lease renewal time (milliseconds)
100 | 87 | 87
1000 | 78 | 80
10000 | 90 | 92
250000 | 212 | 197

Caution

  • Based on these test results, it is generally not recommended to have more than 1,000 scopes on a DHCP server.

Background information on sample DHCP server tests

The list of specific hardware that the Windows 2000 DHCP development and test team used for the server computer included the following:

Hardware components | Sizing
Number of processors | two
Processor speed | 400 MHz Xeon
Amount of RAM | 2 GB (gigabytes)
Hard disk drive space | 70 GB (gigabytes)
Hard disk type | SCSI-2 RAID 0 controller
Number of disk drives in array | 17

These measurements were based on the server computer running a DHCP server and with no other additional services in use. Where other hardware specifications or software configurations are made when deploying Windows 2000 DHCP servers, your performance results are likely to vary from those documented here.

For more information on determining how to perform DHCP server capacity planning, see How many DHCP servers to use.


Restoring server data

Restoring the DHCP server database can be useful in situations where the database has either become corrupted or lost. Where DHCP database corruption or loss occurs, Windows 2000 Server provides a progressive set of recovery and repair options for restoration of DHCP data on the server computer.

In troubleshooting data corruption problems, use the following general process steps to detect corruption and restore DHCP service.

  • First, confirm the source of data loss or corruption at the DHCP server.

    To do so, you can use JetPack.exe to perform a preliminary diagnosis or useful repairs, such as offline database compaction. Additionally, verify that corruption is not related to other problems or conditions with hardware or software changes. Where data loss occurs, verify that the server computer disk drives are operating properly.

    In most cases, database corruption first appears in the form of Jet database error messages in the System event log. For more information on how to use Jetpack.exe to manually repair or compact the DHCP database, see To manually compact or repair the DHCP database and refer to Detecting DHCP Jet data corruption.

  • Second, when repair through Jetpack.exe compaction fails, you can perform a quick recovery of the DHCP server based on your available options for server backup.

    One option is to manually make an offline backup of the DHCP server database files and then copy the server database back during restoration from your archived source, such as from a recent tape backup of the server computer disk drives.

    Another option is to use the Netshell set databaserestore flag command to set the restore flag, which permits the DHCP Server service to load a copy of the DHCP database in its default backup directory when re-initialized. For more information, see Netshell commands for DHCP.

    When backing up the server computer, you can use either Windows 2000 backup and restore options or other backup and restoration software. For more information, see Backing up and restoring data.

  • Third, where other server data recovery options are not available or are tried but unsuccessful, you can use advanced DHCP recovery options.

    For more information, see Additional recovery options.

Detecting DHCP Jet data corruption

The following DHCP service messages can appear in the System event log when the DHCP server database becomes corrupted:

Event ID | Source | Description
1014 | DhcpServer | The JET database returned the following Error: -510.
1014 | DhcpServer | The JET database returned the following Error: -1022.
1014 | DhcpServer | The JET database returned the following Error: -1850.

Typically, Jet errors can be resolved by manual offline compaction of the database using the Jetpack utility. In cases where Jetpack.exe fails to repair the database, restoration of the DHCP server database as described in the previous section might be sufficient.

Additional recovery options

To recover a corrupted DHCP database, you can use the following options for restoring the database.

  • Simple recovery. Restore the database from a backup copy of the database file, Dhcp.mdb.

    This method is recommended as the preferred method of recovery because it involves less risk of losing information previously configured and stored by the DHCP server and is much simpler to perform. For more information, see Reconciling scopes.

  • Advanced recovery. Generate a new database file using the DHCP Configuration registry key.

    This method can be useful as an additional method to use for data recovery where simple restoration of the database is not possible. For more information, see Moving a DHCP database to another server.

In some cases of apparent DHCP database corruption, you might also want to determine whether the server has run out of disk space, which could prevent the DHCP server from continuing to service clients on the network until there is room to continue growth and expansion of the DHCP database.


Moving a DHCP database to another server

Windows 2000 provides the DHCP console, which allows you to manage DHCP servers installed and running on a single DHCP server computer. However, the DHCP console does not allow you to move a database from one installed DHCP server to another server computer.

This topic provides details of how to move a database from from one server computer to another server computer, assuming the DHCP database and its backup directories are on default drive and path locations.

Backing up the DHCP server database (at the source server)

Complete the following procedures at the server computer being used as the source for the DHCP database:

  1. Stop the DHCP server.

    For more information, see To start or stop a DHCP server.

  2. Disable the DHCP Server service in the list of services.

    This prevents the DHCP server from starting after the database has been transferred. To perform this task, use Computer Management and select the DHCP Server service from the list for it to be disabled.

    For more information, see To enable or disable a service for a hardware profile.

  3. Copy the DHCP server directory tree, systemroot\System32\Dhcp, to a temporary location on the new (destination) DHCP server. For example, copy the directory tree to C:\Temp\System32\Dhcp.
  4. Start the Registry Editor (Regedt32.exe) and go to the following subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer

    For more information, see To open Registry Editor.

  5. Save the specified key to a text file.

    For more information, see To save a registry key.

  6. Delete the DHCP server database folder, %SystemRoot%\System32\Dhcp, at the source server.
  7. Uninstall the DHCP server to remove it from this server.

    For more information, see To remove or uninstall DHCP.

Note

  • Steps 6 and 7 are optional.

Restoring the DHCP server database (at the destination server)

Complete the following procedures at the server computer being used as the destination for the DHCP database:

  1. If you have not already installed the DHCP server software, install it and then restart the server computer.

    For more information, see To install a DHCP server.

  2. Stop the DHCP Server service.

    For more information, see To start or stop a DHCP server.

  3. Rename the System.mdb file to System.src in the temporary folder, such as the C:\Temp\System32\Dhcp directory.
  4. Copy the DHCP server directory tree from the temporary folder to systemroot\System32\Dhcp to replace the existing DHCP server directory.
  5. Start Registry Editor (Regedt32.exe) and go to the following subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer

    For more information, see To open Registry Editor.

  6. Select the DHCPServer key (located under the Services key).
  7. Restore the registry hive information from the file you saved in Step 5 of the previous section.

    For more information, see To restore a registry key.

  8. In Restore Key, for File name specify the following:

    systemroot\System32\Dhcp\Backup\Dhcpcfg

  9. When prompted, click Yes.

    After clicking Yes to the prompt to overwrite the existing registry entries, if you have problems completing the restore operation, retry the previous step.

    Be sure that you are not attempting the restore using Registry Editor from a remote computer. Also, verify that this error was not caused by clicking Save Subtree As instead of Save Key as indicated in Step 5 in the previous section when saving registry information at the source server.

  10. Exit Registry Editor.
  11. Start the DHCP Server service.
  12. Open the DHCP console and use Reconcile All Scopes to reconcile the DHCP server database to the restored information now merged into the Windows 2000 registry.

    For more information, see To reconcile the DHCP database.

Note

  • For more information, see DHCP database files.


Analyzing server log files

Windows 2000 DHCP server log files are designed to use Audit logging to permit log files to remain enabled for use without requiring added monitoring or administering to manage log file growth or conserve disk resources.

The following section outlines the format of these log files and how they can be used to gather more information about DHCP Server service operations on the network.

DHCP server log file format

DHCP server logs are comma-delimited text files with each log entry representing a single line of text. Following are the fields (and the order in which they appear) in a log file entry:

ID, Date, Time, Description, IP Address, Host Name, MAC Address

Each of these fields is described in detail in the following table:

Field | Description
ID | A DHCP server event ID code.
Date | The date on which this entry was logged on the DHCP server.
Time | The time at which this entry was logged on the DHCP server.
Description | A description of this DHCP server event.
IP Address | The IP address of the DHCP client.
Host Name | The host name of the DHCP client.
MAC Address | The media access control address used by the network adapter hardware of the client.

DHCP server log: Common event codes

DHCP server audit log files use reserved event ID codes to provide information about the type of server event or activity logged. The following table describes these event ID codes in more detail. These events apply for both Windows 2000 DHCP servers and for servers running earlier versions of Windows.

Event ID | Description
00 | The log was started.
01 | The log was stopped.
02 | The log was temporarily paused due to low disk space.
10 | A new IP address was leased to a client.
11 | A lease was renewed by a client.
12 | A lease was released by a client.
13 | An IP address was found in use on the network.
14 | A lease request could not be satisfied because the address pool of the scope was exhausted.
15 | A lease was denied.
20 | A BOOTP address was leased to a client.

DHCP server logs: Server authorization events

The following are additional server log event ID codes and descriptions. These events can appear in logs made by Windows 2000 DHCP servers. They pertain to the applicable DHCP server and its authorization status when deployed in Active Directory environments.

Event ID Description
50 Unreachable domain

The DHCP server could not locate the applicable domain for its configured Active Directory installation.
51 Authorization succeeded

The DHCP server was authorized to start on the network.
52 Upgraded to Windows 2000

The DHCP server was recently upgraded to Windows 2000 Server and therefore the unauthorized DHCP server detection feature (used to determine whether the server has been authorized in Active Directory) was disabled.
53 Cached Authorization

The DHCP server was authorized to start using previously cached information. Active Directory was not currently visible at the time the server was started on the network.
54 Authorization failed

The DHCP server was not authorized to start on the network. When this event occurs, it is likely followed by the server being stopped.
55 Authorization (servicing)

The DHCP server was successfully authorized to start on the network.
56 Authorization failure, stopped servicing

The DHCP server was not authorized to start on the network and was shut down by Windows 2000 Server. You must first authorize the server in the directory before starting it again. For more information, see To authorize a DHCP server in Active Directory.
57 Server found in domain

Another DHCP server using the same IP address or DNS name already exists and is authorized for service in the same Active Directory domain.
58 Server could not find domain

The DHCP server could not locate the specified Active Directory domain.
59 Network failure

A network-related failure prevented the server from determining if it is authorized.
60 No DC is DS Enabled

No Windows 2000 domain controller (DC) was located. For detecting whether the server is authorized, a DC that is enabled for Active Directory is needed.
61 Server found that belongs to DS domain

Another DHCP server was found on the network that belongs to the Active Directory domain.
62 Another server found

Another DHCP server was found on the network.
63 Restarting rogue detection

The DHCP server is trying again to determine whether it is authorized to start and provide service on the network.
64 No DHCP enabled interfaces

The DHCP server has its service bindings or network connections configured so that it is not enabled to provide service. This usually means one of the following:

  1. The network connections of the server are either not installed or not actively connected to a network. For more information, see either Hardware Troubleshooter or Networking (TCP/IP) Troubleshooter.
  2. The server has not been configured with at least one static IP address for one of its installed and active network connections. For more information, see To configure TCP/IP for static addressing.
  3. All of the statically configured network connections for the server are disabled. For more information, see Multihomed DHCP servers.

Example: Excerpt from a sample DHCP server audit log

The following is a brief excerpt of sample log activity from an audit log generated by the DHCP Server service:

ID Date,Time,Description,IP Address,Host Name,MAC Address
00,04/19/99,12:43:06,Started,,,
60,04/19/99,12:43:21,No DC is DS Enabled,,MYDOMAIN,
63,04/19/99,12:43:28,Restarting rogue detection,,,
01,04/19/99,13:11:13,Stopped,,,
00,04/19/99,12:43:06,Started,,,
55,04/19/99,12:43:54,Authorized(servicing),,MYDOMAIN,

In this sample, the DHCP server could not be authorized when initially started and is subsequently stopped. Once authorized in Active Directory, the server is then able to start and service clients.

Note

  • For more information, see Audit logging.


Cluster support for DHCP servers

The Windows 2000 DHCP Server service is a cluster-aware application. You can implement additional DHCP (or MADCAP) server reliability by deploying a DHCP server cluster using the Cluster service provided with Windows 2000 Advanced Server.

By using clustering support for DHCP, you can implement a local method of DHCP server failover, achieving greater fault tolerance. You can also enhance fault tolerance by combining DHCP server clustering with a remote failover configuration, such as by using a split scope configuration.

Requirements for setting up a DHCP clustered resource

The DHCP Server service, when used in a server cluster requires the following resource types: a disk resource, an IP address resource, and a name resource.

In this type of configuration, a virtual IP address is defined for the IP address resource using the Cluster Administrator tool. This address must be a static IP address, not one obtained from another DHCP server.

The DHCP Server service then binds to this virtual IP address. This IP address must then be the one used to authorize the DHCP Server service in Active Directory so it can function correctly and service clients on the network.

Once the virtual IP is set using cluster configuration, each network adapter installed on each node (that is, a server in the cluster) needs an IP address configuration. Because the DHCP Server service does not bind to adapter IP addresses, you can either provide them through DHCP or configure them statically. If you use static configuration, the IP addresses for each linked pair of network adapters (linked node-to-node) should be from the same subnet.

Addresses that are statically configured using TCP/IP properties from the Network and Dial-up Connections folder can also be viewed through server bindings properties in the DHCP console. However, for a DHCP server cluster, the bindings information that appears in these views does not correspond to the virtual IP address used for the server cluster. Therefore, these settings do not apply.

When a scope is created for a DHCP clustered server, the virtual IP addresses used in the cluster context must be excluded so that they are not distributed to clients. Additionally. you should configure the database path, audit log file path, and the database backup path using the Cluster Administrator tool on the shared disk.

Other options for DHCP failover

Another way to implement DHCP remote failover is to deploy two DHCP servers in the same network that share a split scope configuration based on the 80/20 rule. For more information, see Using the 80/20 rule for scopes.

For more information on installing a DHCP resource type on a Windows 2000 cluster server (if you are running Windows 2000 Advanced Server), see Checklist: Installing a DHCP Service resource.

Notes

  • If you need only to remotely manage DHCP server clusters deployed on other remote computers running Windows 2000 Advanced Server, you can use Cluster Administrator to do this. For more information, see Managing server clusters remotely.
  • Additional information on configuring DHCP clustering is also available in the Windows 2000 Resource Kit.


Setting up scopes

This section covers:

  • Configuring scopes
  • Using superscopes
  • Using multicast scopes
  • Removing scopes
  • Managing leases
  • Using client reservations
  • Reconciling scopes


Configuring scopes

A scope is an administrative grouping of computers for a subnet that uses DHCP service. The administrator first creates a scope for each physical subnet and then uses the scope to define the parameters used by clients. A scope has the following properties:

  • A range of IP addresses from which to include or exclude addresses used for DHCP service lease offerings.
  • A unique subnet mask, which determines the subnet for a given IP address.
  • A scope name assigned when it is created.
  • Lease duration values, which are assigned to DHCP clients that receive dynamically allocated IP addresses.

Before adding scopes

A DHCP scope consists of a pool of IP addresses on a given subnet, such as 192.168.0.1 to 192.168.0.254, that the DHCP server can lease to clients.

Each subnet can have only a single DHCP scope with a single continuous range of IP addresses. To use several address ranges within a single scope or subnet for DHCP service, you must first define the scope and then set any needed exclusion ranges.

  • Defining the scope

    Use the entire range of consecutive IP addresses that make up the local IP subnet for which you are enabling DHCP service.

  • Setting exclusion ranges

    You should set exclusion ranges for any IP addresses within the scope that you do not want the DHCP server to offer or use for DHCP assignment. For example, you can exclude the first 10 addresses in the previous example scope by creating an exclusion for 192.168.0.1 to 192.168.0.10.

    By setting an exclusion for these addresses, you specify that DHCP clients are never offered these addresses when they request leased configuration from the server. Excluded IP addresses can be active on your network, but only by manually configuring these addresses at hosts that do not use DHCP to obtain an address.

Creating scopes

When you create a DHCP scope, you use the DHCP console to enter the following required information:

  • A scope name, assigned by you or the administrator who created the scope.
  • A unique subnet mask used to identify the subnet to which an IP address belongs.
  • A range of IP addresses contained within the scope.
  • A time interval (known as a lease duration) that specifies how long a DHCP client can use an assigned IP address before it must renew its configuration with the DHCP server

Using the 80/20 rule for scopes

For balancing DHCP server usage, a good practice is to use the "80/20" rule to divide the scope addresses between the two DHCP servers. If Server 1 is configured to make available most (approximately 80%) of the addresses, then Server 2 can be configured to make the other addresses (approximately 20%) available to clients. The following illustration is an example of the 80/20 rule:

80/20 rule

Notes

  • For detailed information on applying the 80/20 rule, see Best practices.
  • When creating a new scope, the IP address used to create it should not include addresses of existing statically configured computers. Either these static addresses should be outside the range for the scope, or they should be immediately excluded from the range.
  • Because Windows 2000 Server requires that a computer running the DHCP service have its IP address statically configured, be sure that the server computer has its IP address either outside of, or excluded from, the range of the scope.

After scopes are added

After you define a scope, you can additionally configure the scope by performing the following tasks:

  • Set additional exclusion ranges.

    You can exclude any other IP addresses that must not be leased to DHCP clients. You should use exclusions for all devices that must be statically configured. The excluded ranges should include all IP addresses that you assigned manually to other DHCP servers, non-DHCP clients, diskless workstations, or Routing and Remote Access and PPP clients.

  • Create reservations.

    You can choose to reserve some IP addresses for permanent lease assignment to specified computers or devices on your network. You should make reservations only for devices that are DHCP-enabled and that must be reserved for specific purposes on your network (such as print servers).

  • Adjust the length of lease durations.

    You can modify the lease duration to be used for assigning IP address leases. The default lease duration is eight days.

    For most LANs, the default value is acceptable but can be further increased if computers seldom move or change locations. Also, infinite lease times can be set but should be used with caution. For information about circumstances under which modifying this setting is most useful, see Managing leases.

  • Configure options and classes to be used with the scope.

    To provide full configuration for clients, DHCP options need to be configured and enabled for the scope. For more information, see Setting up options.

    For more advanced discrete management of scope clients, you can add or enable user or vendor-defined option classes. For more information, see Using option classes.

Notes

  • After you define and configure a scope, the scope must be activated before the DHCP server begins providing service to clients. However, you should not activate a new scope until you have specified the DHCP options for it. For information on how to activate a scope, see To activate a scope.
  • After you activate a scope, you should not change the range of scope addresses.


Using superscopes

A superscope is an administrative feature of Windows 2000 DHCP servers that you can create and manage through the DHCP console. Using a superscope, you can group multiple scopes as a single administrative entity. With this feature, a DHCP server can:

  • Support DHCP clients on a single physical network segment (such as a single Ethernet LAN segment) where multiple logical IP networks are used. When more than one logical IP network is used on each physical subnet or network, such configurations are often called multinets.
  • Support remote DHCP clients located on the far side of DHCP and BOOTP relay agents (where the network on the far side of the relay agent uses multinets).

In multinet configurations, you can use DHCP superscopes to group and activate individual scope ranges of IP addresses used on your network. In this way, a the DHCP server computer can activate and provide leases from more than one scope to clients on a single physical network.

Superscopes can resolve certain types of DHCP deployment issues for multinets, including situations in which:

  • The available address pool for a currently active scope is nearly depleted, and more computers need to be added to the network. The original scope includes the full addressable range for a single IP network of a specified address class. You need to use another IP network range of addresses to extend the address space for the same physical network segment.
  • Clients must be migrated over time to a new scope (such as to renumber the current IP network from an address range used in an existing active scope to a new scope that contains another IP network range of addresses).
  • You want to use two DHCP servers on the same physical network segment to manage separate logical IP networks.

Superscope configurations for multinets

The following section shows how a simple DHCP network consisting originally of one physical network segment and one DHCP server, can be extended to use superscopes for support of multinet configurations.

Example 1: Non-routed DHCP server (before superscope)

In this preliminary instance, a small local area network (LAN) with one DHCP server supports a single physical subnet, Subnet A. The DHCP server in this configuration is limited to leasing addresses to clients on this same physical subnet.

The following illustration shows this example network in its original state. At this point, no superscopes have been added and a single scope, Scope 1, is used to service all DHCP clients on Subnet A.

Example 1: Single subnet and DHCP server (before superscope)

Example 2: Superscope for non-routed DHCP server supporting local multinets

To include multinets implemented for client computers on Subnet A, the same network segment where the DHCP server is located, you can configure a superscope which includes as members: the original scope (Scope 1) and additional scopes for the logical multinets for which you need to add support (Scope 2, Scope 3).

This illustration shows the scope and superscope configuration to support the multinets on the same physical network (Subnet A) as the DHCP server.

Example 2: Superscope for non-routed DHCP server supporting local multinets

Example 3: Superscope for routed DHCP server with relay agent supporting remote multinets

To include multinets implemented for client computers on Subnet B, the remote network segment located across a router from the DHCP server on Subnet A, you can configure a superscope which includes as members: the additional scopes for the logical multinets for which you need to add remote support (Scope 2, Scope 3).

Note that since the multinets are for the remote network (Subnet B), the original scope (Scope 1) does not need to be part of the added superscope.

This illustration shows the scope and superscope configuration to support the multinets on the remote physical network (Subnet B) away from the DHCP server.

Example 3: Superscope for routed DHCP server with relay agent supporting remote multinets

Note

  • A DHCP relay agent is used for DHCP servers to support clients on remote subnets, as shown in Example 3. For more information, see Understanding relay agents.


Using multicast scopes

Multicast scopes are supported through the use of Multicast Address Dynamic Client Allocation Protocol (MADCAP), a new proposed standard protocol for performing multicast address allocation. The MADCAP protocol describes how multicast address allocation (or MADCAP) servers can dynamically provide IP addresses to other computers (MADCAP clients) on your network.

Typically, a MADCAP client might also be a multicast server (MCS) used to support IP multicasting. An MCS, such as a server computer running the Site Server Internet Location Server (ILS) service, manages the shared or group use of the allocated multicast IP address and streams data traffic to members that share the use of the specified group address.

Once an MCS is configured and allocated a group IP address to use, any multicast clients that have registered their membership with the MCS can receive streams sent to this address. By registering with the MCS, clients can participate efficiently in the stream process, such as for real-time video or audio network transmissions. The MCS also manages the multicast group list, updating its membership and status so that multicast traffic is received by all current members.

Background on multicast addresses

Ordinarily, you use DHCP scopes to provide client configurations by allocating ranges of IP addresses from the standard address classes, Class A, B, or C. By using DHCP scopes you can assign IP addresses from the ranges provided by these addresses for your DHCP clients to be configured to use unicast (or point-to-point) directed communication between other TCP/IP networked computers.

The multicast address range uses an additional address class, Class D, that includes IP addresses that range from 224.0.0.0 to 239.255.255.255 for use in IP multicasting. Addresses in this class are used for multicasting only and not for regular DHCP scopes.

In all TCP/IP networks, each host is required to first be configured with its own IP address, taken from one of the standard address classes. You must assign this required unicast IP address before you can configure a host to support and use secondary IP addresses, such as a multicast IP address.

Another difference between unicast and multicast addresses, is that a group of TCP/IP host computers are intended to be able to share the use of a multicast IP address. This is not normally the case with unicast IP addresses, which are intended to be assigned individually to only one configured host and not shared with other hosts.

When the destination address for an IP datagram is an IP multicast address, the datagram is forwarded to all members of a multicast group, which is a set of zero or more hosts identified by the address. The membership of a multicast group is dynamic in that individual hosts can join or leave the group at any time.

Membership and use of multicast groups is unrestricted and can be compared to membership and use of a group e-mail address: Group membership can be any size, and hosts can be members of many multicast groups.

You can permanently reserve multicast group addresses or temporarily assign and use them as needed on your network. For a permanent group IP address to be reserved for Internet use, you must register it with the Internet Assigned Numbers Authority (IANA).

For multicast IP addresses not permanently reserved with the IANA, all Class D addresses that remain unreserved can then be used dynamically to assign and form temporary multicast groups. These temporary groups can exist as long as one or more hosts on the network are configured with the group address and actively share its use.

For more information, see Understanding multicasting or Internet Group Management Protocol (IGMP).

Determining the ranges to use for multicast scopes

When deciding the IP address ranges to use for multicast scopes on your MADCAP server, there are two overall best practices recommended by the Multicast Allocation (malloc) working group, an IETF team of industry volunteers who help establish multicast address allocation standards. These practices include:

  • Administrative scoping This is most useful when you are using multicast IP addresses privately in your own network. It is similar to private IP addressing, as used currently in the unicast IP address spaces (such as the use of the 10.0.0.0 network address space). It is fully discussed in RFC 2365, "Administratively Scoped IP Multicast."

    With administratively scoped multicast IP, the range most recommended that you begin with is the 239.192.0.0 range. This range is known as the IPv4 Organization Local Scope and has a subnet mask of 255.252.0.0 (14-bits in length). It is intended for use by an entire organization setting multicast scopes privately for its own internal or organizational use. Starting with this address, you can create a considerable number of addresses—up to 218, or 262,144 group addresses—for use in all subnets within your organization's network.

    For more information, refer directly to the RFC, which can be obtained at the Request for Comments Web site. (http://www.rfc-editor.org/)

  • Global scoping This practice is most useful when you are using multicast group IP addresses in a public network address space, particularly the Internet.

    Because most organizations requiring one or more public addresses likely have already been assigned some public unicast IP addresses, a subnet allocation scheme has been proposed. For MADCAP, the 233.0.0.0 range of the Class D address space is recommended for use as a global scope range.

    When the 233.0.0.0 range is used, the allocation of global addresses works in the following way:

    1. A network registry, such as the Internet Assigned Numbers Authority (IANA), allocates and reserves the first 8 bits of the range (for example, the "233" portion of this range).
    2. The next 16 bits (the two middle octet numbers of addresses in this range) are based on a previously assigned Autonomous System (AS) number. This number is recorded with the applicable Internet Assigned Numbers Authority (IANA) registry for your region.

      If you already register your IP addresses with a regional network registry, you might know your AS number. You can also look it up easily using the Whois database system on the Internet. If you are obtaining IP addresses through an Internet service provider (ISP), you might contact them to find out what your AS number is.

      AS numbers are allocated to the regional registries by the IANA. If you or your ISP are located in the United States, you can apply directly to the American Registry for Internet Numbers (ARIN) to obtain an AS number. For more information, see the ARIN Web site. (http://www.arin.net/intro.html)

      For other regions, AS numbers can also be obtained from appropriate regional registries. Other regional registries include the following:

      • ARIN or <hostmaster@arin.net> for the Americas, Carribbean, and Africa.
      • RIPE-NCC <ncc@ripe.net> for Europe.
      • AP-NIC <admin@apnic.net> for the Asia-Pacific region.
    3. The last 8 bits in the address are local use bits.

      These provide the IP address range from which to configure any multicast scopes for group addresses you want to use publicly on the Internet. With this global scoping system in use, a subnet mask of 255.255.255.0 should be applied. This provides each organization with an assigned AS number of up to 255 multicast group addresses for use on the Internet.

    • For more information on either the practice of global scoping for multicast address allocation or the use and allocation of AS numbers, use the IETF Web site. (http://www.ietf.org/) For global scoping, refer directly to the current available draft entitled "Static Allocation in 233/8," and for more information on AS numbering, refer to RFC 1930, "Guidelines for creation, selection, and registration of an Autonomous System (AS)."

MADCAP and DHCP

The Windows 2000 DHCP Server service supports both the DHCP and MADCAP protocols. These protocols function separately and are not dependent on each other. For example, a DHCP client might or might not be a MADCAP client and a MADCAP client might or might not be a DHCP client.

Its also worth mentioning that the DHCP Server service can be used to deploy MADCAP servers independent of how DHCP servers are used on your network. For example, to install Windows 2000 DHCP for MADCAP service only:

  1. Create multicast scopes.
  2. Do not create other scopes or superscopes.

Only where other scopes or superscopes are configured does the server computer also function as a DHCP server.

For more information about MADCAP, see Multicast address allocation.

Important

  • Multicast scopes and MADCAP only provide a mechanism for dynamically allocating IP address configuration for multicast-ranged IP addresses. Other network configuration details are normally required to enable multicasting for your deployment needs. For more information, see Checklist: Installing IP multicast video conferencing.

Notes

  • Multicast scopes do not require or support the use of DHCP options, but can be configured with a finite lifetime, enabling the multicast scope to expire and be removed by the server.
  • For more information, see Manage multicast scopes.


Removing scopes

When a subnet is no longer in use, or any other time you want to remove an existing scope, you can remove it at the DHCP console. In most cases, scopes are removed only when you need to renumber your network to use a different IP address range.

To retire a current scope and renumber your network to use a different scope, be sure to do the following first:

  1. Create the new scope using a different range of addresses.
  2. Configure options for the new scope.
  3. Activate the new scope and deactivate the old scope.
  4. When all clients are no longer using the old scope, remove the old scope.

Before you remove a scope , you must first deactivate it for a period of time. Deactivating a scope starts lease recall on the selected scope.

Before deactivating a scope, a replacement scope should be active on the subnet. The replacement scope can be on a different DHCP server from the deactivated scope as long as the replacement scope is on the same subnet.

You must deactivate a scope before removing it. This enables clients using the scope to renew their lease in a different scope. Otherwise, clients lose their leases. If any IP address in the scope is still leased or in use, you must first keep the scope active until either the client lease expires or the client lease renewal request is denied.

After a scope is deactivated, it does not acknowledge lease or renewal requests, so existing clients lose their leases at renewal time and reconfigure with another available DHCP server. To ensure that all clients migrate smoothly to a new scope, you should deactivate the old scope for at least half of the lease time, or until you have manually renewed all clients to move them off of the inactive scope.

To move a Windows 2000-based client manually, type either ipconfig /release or ipconfig /renew at the command prompt of the client computer. For other cases, restarting the client computer might be needed.


Managing leases

IP addresses are leased by the DHCP server to its clients. Each lease has an expiration date, which the client must renew if it is going to continue to use that address.

Leases are retained in the DHCP server database approximately one day after expiration. This grace period protects a client lease in case the client and server are in different time zones, the individual computer clocks are not synchronized, or the client computer is off the network when the lease expires. Expired leases are included in the list of active leases but are distinguished by a dimmed icon.

You can delete the lease of any DHCP client in the scope. The main reason for doing so is to remove a lease that conflicts with an IP address exclusion or a client reservation that you want to add. Deleting a lease has the same effect as if the client lease expired: the next time that client computer starts, it must enter the initialization state and obtain new TCP/IP configuration information from a DHCP server. There is nothing, however, to prevent the client from obtaining a new lease for the same IP address. You must make the address unavailable before the client requests another lease.

Delete only entries for clients that are no longer using the assigned DHCP lease or that are to be moved immediately to a new address. Deleting an active client could result in duplicate IP addresses on the network, because deleted addresses will be assigned to new active clients. After you delete the lease of the client and set a reservation or exclusion, you should always use ipconfig /release on the client computer to force the client to free its IP address.

Note

  • You can view lease information for individual clients by first selecting the Active Leases folder for a scope in the DHCP console. When Active Leases for a scope is selected as the console view, the list of currently active client leases for the scope appears in the details pane.

Modifying default lease durations for a scope

When a scope is created, the default lease duration is set to eight days. In most cases, this value is sufficient. However, because lease renewal is an ongoing process that can affect the performance of DHCP clients and your network, it is sometimes useful to change the lease duration. Use the following guidelines to decide how to best modify lease duration settings for improving DHCP performance on your network:

  • If you have are a large number of IP addresses available and configurations that rarely change on your network, increase the lease duration to reduce the frequency of lease renewal queries between clients and the DHCP server. This reduces some network traffic caused by clients renewing their leases.
  • If you have a limited number of IP addresses available and if client configurations change or clients move often on your network, reduce the lease duration to promote scavenging of old IP addresses by the DHCP server. This increases the rate at which addresses are returned to the available address pool for reassignment to new clients.

Note

  • You can also set a separate lease time, different from the default scope lease time used by your DHCP clients, such as alternate lease times for supporting other types of clients such as BOOTP or Routing and Remote Access clients. For more information, see Manage BOOTP and remote access clients.


Using client reservations

With client reservations, you can reserve a specific IP address for permanent use by a DHCP client. Typically, you will need to do this if the client uses an IP address that was assigned using another method for TCP/IP configuration.

If multiple DHCP servers are configured with a scope that covers the range of the reserved IP address, the client reservation must be made and duplicated at each of these DHCP servers. Otherwise, the reserved client computer can receive a different IP address, depending on the responding DHCP server.

If you want to change a reserved IP address for a current client, you have to remove the existing address reservation of the client, and then add a new reservation. You can change any other information about a reserved client while keeping the reserved IP address.

If you are reserving an IP address for a new client, or an address that is different from its current one, you should verify that the address has not already been leased by the DHCP server. Reserving an IP address in a scope does not automatically force a client currently using that address to stop using it.

If the address is already in use, the client using the address must first release is by issuing a DHCP release message (DHCPRELEASE). To make this happen, at the command prompt of a client computer running under Windows 2000, type ipconfig /release.

Reserving an IP address at the DHCP server also does not force the new client for which the reservation is made to immediately move to that address. In this case, too, the client must first issue a DHCP request message (DHCPREQUEST). To make this happen, at the command prompt of a client computer running under Windows 2000, type ipconfig /renew.

For clients using Windows 95 or Windows 98, you can use the Winipcfg.exe program to cause release or renewal of the reserved IP address in DHCP. For clients using MS-DOS, and some clients using other operating systems, a computer must be restarted for the change to take effect.

Once these changes are made, the reserved client is leased the IP address now reserved for its permanent use each time it renews its lease with the DHCP server.

Notes

  • Reserved clients can have DHCP options configured specifically for their use. When options are configured for a reserved client, these values override any option type parameters distributed via server-based, scope-based, or class-based options assignment.
  • You can also use the ipconfig command on computers running earlier versions of Windows NT to release and renew DHCP leases. However, not all other ipconfig command options are available when executed at clients running under these earlier versions.


Reconciling scopes

Reconciling scopes can fix inconsistencies, such as incorrect or missing information for client IP addresses that are stored in scope lease information. When inconsistencies are found, the DHCP server can use duplicate scope address lease information recorded in the Windows 2000 registry to detect any lease entries not currently reflected in the DHCP server database.

To correct and repair these inconsistencies, you need to reconcile any scope inconsistencies found when performing this operation. Once you select and reconcile scope inconsistencies, the DHCP console either restores those IP addresses to the original owner or creates a temporary reservation for those addresses. These reservations are valid for the lease time assigned to the scope. When the lease time expires, the addresses are recovered for future use.

Restoring scopes using reconcile options

The Reconcile feature can also be used to restore DHCP scope data in the event of server recovery. Before using this feature to fully recover DHCP scopes, complete the following preliminary tasks on the server:

  1. Obtain and verify that you have a backup copy of the DHCP database, including all of its required files and subdirectories.
  2. Stop the DHCP server.

    For more information, see To start or stop a DHCP server.

  3. Delete all files in the currently set Database path, which can be viewed or set from the Advanced tab in Properties at the applicable DHCP server.
  4. All DHCP server registry keys must be either restored or exist and remain intact from previous service operation on the server computer.

    If you are not sure how to make a copy of the DHCP server registry keys, refer to the procedures for using Registry Editor (Regedt32.exe) to do so in Moving a DHCP database to another server.

  5. Regenerate a fresh version of the DHCP server database file in the current Database path, such as the SystemRoot\System32\Dhcp folder, on the server computer.

    A fresh copy of the DHCP server database can be generated by:

    1. Stopping the DHCP server
    2. Deleting all of the DHCP database files in the current Database path folder
    3. Restarting the DHCP server.

    When deleting server database files, it is not necessary to delete the \backup subfolder as well unless you are deliberately choosing to not have the server restore from one its previous backup copies archived there.

When the DHCP server registry information and DHCP database files have been either restored or regenerated at the server and the server restarted, you might notice that upon opening the DHCP console scope information is present but no active leases or other information for scopes is displayed.

To regain your active leases for each scope, you must use either the Reconcile feature to recover each scope or the Reconcile All Scopes feature at the applicable server. For more information, see To reconcile the DHCP database or To reconcile a scope.

If the reconcile scope option is used, the procedure needs to be repeated for each scope defined and used at the server. After reconciliation is completed, scope client lease and reservation information is added back into the Active Leases for each scope, based on DHCP scope registry information previously stored at the server computer.

After using the Reconcile feature you might notice that, when viewing properties for individual clients shown in Active Leases, client information is displayed incorrectly. This information is corrected and updated in the console as scope clients renew their leases.

Notes

  • After using the recovery methods discussed here, you can enable address conflict detection on the server for a period of time. For more information, see To enable address conflict detection.
  • Although the Reconcile feature can be used to recover scope information in the event of DHCP server disaster recovery, it is not intended to be a replacement for other traditional backup measures. It is recommended that you implement other methods (such as using backup to a tape drive) to provide offline storage and duplicate archives of your DHCP database. For information, see Restoring server data.
  • For information about the Windows 2000 registry, see The Windows 2000 registry.


Supporting clients

This section covers:

  • Supporting DHCP clients
  • Supporting Routing and Remote Access clients
  • Supporting BOOTP clients


Supporting DHCP clients

When installing a DHCP server to support a combination of DHCP clients provided by Windows and other operating systems on your network, consider some of the following issues:

  • Windows 2000 DHCP servers can assign any of the predefined options that are part of the DHCP standard set of options described in RFC 2132. Servers can also be modified to provide additional custom options as needed and requested by DHCP clients that support and request such options.
  • Microsoft DHCP clients (including those running Windows 2000) only support and request a small number of the full standard set of DHCP options in their default configuration. This subset of supported options contrasts to the larger set of options that are predefined for assigned use within the DHCP console when managing Windows DHCP servers. For more information, see Microsoft DHCP clients.
  • Other DHCP clients provided in systems supplied from other software vendors (such as UNIX or Linux clients), can request and recognize different DHCP options than those commonly supported by default for all released Microsoft DHCP clients. For these other DHCP clients, you can assign options at the server that are recognized by and configured for the supporting clients.

    Typically, if DHCP clients are unable to recognize or support an assigned DHCP option provided by the server during leasing, they silently ignore it. Another method to control options assignment is to use vendor or user-defined classes. In this arrangement, you can assign options for distribution only to identified members of the applicable class at the DHCP server. For more information, see Using option classes.

  • In some advanced deployment cases, you can tune or customize your Windows applications for Windows 2000 clients to leverage current DHCP client application programming interfaces (APIs), which are documented as part of the Microsoft Platform SDK available through the Microsoft Developers Network (MSDN).

    These published DHCP client APIs can enable you to customize DHCP client behavior, such as to enable other DHCP options to be requested and used at a Windows 2000 DHCP client. For more information on using these APIs, see the Microsoft Web site (http://www.microsoft.com/).


Supporting Routing and Remote Access clients

Windows 2000 DHCP servers provide support for Routing and Remote Access clients in two primary ways:

  • A reserved user class, the Default Remote Access class, is predefined at each server. When used, this class can provide configured options that are specific only to Windows Routing and Remote Access clients. For more information, see Microsoft predefined user classes.
  • Special DHCP client configuration behavior occurs on the part of Routing and Remote Access servers which perform proxied DHCP service for their clients that use DHCP to obtain a lease.

Optionally, you can use the Default Remote Access class to assign options specific to your remote access clients. In any instance where these clients use DHCP to obtain an IP address, they obtain a proxied IP address lease from the Routing and Remote Access server, which gathers IP addresses from the DHCP server for its distribution needs. In this process, the server provides optional values according to its own methods to its DHCP clients that use proxied leases.

For example, using either Winipcfg.exe (for Windows 95 or Windows 98) or Ipconfig.exe (for Windows 2000, earlier versions of Windows NT, or Windows 98) you can display the following information about the DHCP lease for a Routing and Remote Access client computer:

Lease Obtained:      Tue Jan 1 80 12:00:00 AM
Lease Expires:       Tue Jan 1 80 12:00:00 AM

When a Routing and Remote Access server assigns an IP address to one of its clients, either from its own static address pool or from its cached DHCP address pool, there is no effective lease time for the IP address, since it is released when the client disconnects.

However, remote access clients can still receive additional TCP/IP configuration information from the Routing and Remote Access server. For example, WINS and DNS server assignments can be delegated to the client when it connects.

Again, this information is not taken from the options given in the DHCP lease. Instead, these are taken directly from the Routing and Remote Access server settings. If a Routing and Remote Access server has WINS or DNS servers as configured entries in its dial-up connection properties, these settings are passed on to its clients.

The following table lists the options that Windows-based DHCP clients support and how each of these options has its values assigned to clients that use DHCP through connection to the Routing and Remote Access server:

Option | Description
IP address | The Routing and Remote Access server proactively obtains IP addresses from the DHCP server and builds a cached pool of DHCP leased addresses. It then distributes these cached IP addresses upon demand to dial-up clients and manages each lease accordingly. This is the only information from the DHCP server that the Routing and Remote Access client receives.
WINS server | Values provided with this option are taken from the dial-up connection properties of the Routing and Remote Access server if it is configured with WINS server addresses. The client acquires the list of WINS servers that are configured on the Routing and Remote Access server.
DNS server | Values provided with this option are taken from the dial-up connection properties of the Routing and Remote Access server if it is configured with DNS server addresses. The client acquires the first DNS server address listed in the search list.
Subnet mask | The subnet mask corresponds to the default subnet mask associated with the standard address class type (Class A, Class B, or Class C) of the given IP address.
NetBIOS scope ID | NetBIOS scope ID information is not passed to the client. If you need to modify this setting, you must change it directly on the client.
Node type | Node type is not taken from the DHCP lease but can change on the Routing and Remote Access client, depending upon WINS information. If the Routing and Remote Access server has no locally defined WINS servers, a b-node Routing and Remote Access client remains a b-node client. If the Routing and Remote Access server has locally defined WINS servers, a b-node Routing and Remote Access client switches to h-node for the duration of the connection.


Supporting BOOTP clients

The Bootstrap protocol (BOOTP) is an established TCP/IP standard for host configuration that precedes DHCP.

BOOTP was originally designed to enable boot configuration for diskless workstations on older systems. This protocol approach was necessary because clients of this type have limited ability to store configurable information required during their respective boot processes used to start and participate in a network.

Windows 2000 DHCP servers respond to both BOOTP and DHCP requests. Unlike the lease process used for DHCP clients, the initialization process for BOOTP clients is different.

For BOOTP, clients obtain their configuration in a two-phase process as follows:

  1. The BOOTP client requests an IP address and other relevant information.

    This information might typically include IP addresses for a router (default gateway) address or a DNS server. For more information, see Standard DHCP and BOOTP options.

  2. The BOOTP client also requests additional information.

    This information is needed for the client to locate a Trivial File Transfer Protocol (TFTP) server that serves its platform-specific boot image file. This file is needed by the client to complete its boot configuration.

Once all of the information requested by the BOOTP client is fulfilled by the BOOTP (or Windows 2000 DHCP) server, the client can make the separate request to its TFTP server to complete the second phase of its boot process.

The following sections cover how to configure Windows 2000 DHCP servers to support BOOTP clients during both of these phases of the BOOTP configuration process.

BOOTP clients requesting IP address information only

Previously, BOOTP client support through the DHCP server always required an explicit client reservation to be made for each BOOTP client.

With new support for dynamic BOOTP, a pool of addresses can be designated--similar to how a scope is used for DHCP clients--to dynamically manage IP address assignment for BOOTP clients. The DHCP Server service can later reclaim addresses used in the dynamic BOOTP address pool, after first verifying a specified lease time has elapsed and that each address is not still in use by the BOOTP client.

To configure your DHCP server to assign and distribute IP address information to BOOTP clients, you must first configure a BOOTP address pool within a DHCP scope on the server. For information about how to add a BOOTP address pool, see To add dynamic BOOTP client support to a scope.

Another option to the dynamic BOOTP address pool, is to add a client reservation for each non-dynamic BOOTP client within your DHCP scopes. A reservation builds an association between the BOOTP client Media Access Control (MAC) address encoded in its physical hardware and its leased IP address.

When a reserved client requests an IP address, the DHCP Server service returns the appropriate reserved IP address in the lease response based on the MAC address of the client included in the BOOTP request message.

Important

  • When configuring client reservations for use with BOOTP clients, note that DHCP options can apply equally to DHCP and BOOTP clients. Therefore, correct scope configuration is imperative.

BOOTP clients requesting boot file information

To configure Windows 2000 DHCP servers to provide boot file information to your BOOTP clients, complete the following:

  1. Add a client reservation for each BOOTP client within an active DHCP scope.

    For more information, see To add a client reservation.

  2. Add BOOTP entries for each client-specific platform in the BOOTP table on the DHCP server.

    For more information, see To add an entry to the BOOTP table.

Information stored in the BOOTP table is used by BOOTP clients to complete the second phase of their boot process. This information is returned to any requesting BOOTP clients on the network that broadcast a BOOTP request message.

If at least one BOOTP entry has been added to the BOOTP table, a Windows 2000 DHCP server replies to BOOTP client requests. If no BOOTP entries are configured, the server ignores BOOTP request messages.

Configuring the BOOTP table

Each record in the BOOTP table contains the three fields that contain the information returned to the BOOTP client:

  • Boot image file name. Identifies the generic file name (such as "unix") of the requested boot file, based on the BOOTP client hardware type.
  • Full server path to boot image. Identifies the full path of the boot file (such as "/etc/vmunix") returned to the client by the BOOTP server, using TFTP.
  • TFTP file server. Identifies the name of the TFTP server used to source the boot file.

To add these entries into the BOOTP table, use the DHCP console.

Additional BOOTP configuration details

For your Windows 2000 DHCP servers to supply boot image file and TFTP server information to BOOTP clients, some DHCP options are used by the server for the purpose of fulfilling information stored in configured BOOTP table entries.

The following table lists these options, which are used to complete BOOTP protocol messages returned to clients during their initial bootstrap sequence.

Code | Description
66 | TFTP server name
67 | Boot file name

Once you add BOOTP entries to the BOOTP table at a Windows 2000 DHCP server, you are also configuring the previous options for use in supporting your BOOTP clients. You do not need to further configure DHCP options at the server for these options to be provided and used as part of its BOOTP support.

Note

  • Windows 2000 DHCP servers provide a predefined user class, the Default BOOTP class, for assigning options specific to BOOTP clients. For more information, see Microsoft predefined user classes.


Setting up options

This section covers:

  • Assigning options
  • Using option classes


Assigning options

You can manage DHCP options at four distinct levels:

  • Predefined options. At this level, you control which types of options are predefined for the DHCP server to expose as available options for assigning from any of the option configuration dialog boxes (such as Server Options, Scope Options, or Client Options) available through the DHCP console. You can add or remove options to and from the predefined list of standard options as needed. Although options are made available in this way, they are not assigned values until administratively configured at either the server, scope, or client.
  • Server options. Assign values here (using the General tab) for options that should apply to or be inherited by all scopes and clients of the DHCP server as defaults. Options configured here can have their values overridden by different values if those values are set at either a scope, options class, or reserved client level.
  • Scope options. Assign values here (using the General tab) for options that should apply only to clients of an applicable scope selected in the DHCP console tree. Options configured here can have their values overridden by different values if those values are set at either an options class or reserved client level.
  • Client options. Assign values here (using the General tab) for options that should apply only to a specific reserved DHCP client. To use this level of assignment, you must first add a reservation for the applicable client to the applicable DHCP server and scope where the client is to obtain its IP address. These options are set for an individual DHCP client configured with an address reservation in a scope. Only properties manually configured at the client computer can override options assigned at this level.
  • Class options. When using any of the option configuration dialog boxes (Server Options, Scope Options or Client Options) you can click the Advanced tab of the applicable dialog box to configure and enable options for assignment to identifying member clients of a specified user or vendor class.

    Depending on the context, only those DHCP clients that identify themselves according to the selected class are distributed options data you have configured specifically for that class. For example, if a class-assigned option is set at a scope, only clients of that scope that indicate class membership during leasing activity are configured with class-assigned option values. Other non-member clients are configured using scope option values set from the General tab.

    Options configured here can override values assigned and set at the same context (either server, scope, or client options) or values inherited from options configured at a higher context. However, the ability of the client to indicate membership in a specific options class is typically the decisive criteria for using this level of options assignment. For more information, see Using options classes.

Guidelines for assigning options

The following guidelines can help you determine what level to assign the options you use 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 DHCP server manages many scopes for a large network, be selective when assigning Server Options. These options apply by default to all clients of a DHCP server computer, unless otherwise overridden.
  • Use Scope Options for assigning most options that clients use. In most networks, this level is typically preferred for assigning and enabling the use of DHCP options.
  • Use Class Options if you have a mixture of DHCP clients with diverse needs that are able to identify a specific class on the DHCP server when obtaining a lease. For example, if you have a limited number of client computers running Windows 2000 DHCP clients, these clients can be configured to receive vendor-specific options that other clients do not use.
  • Use Client Options for individual DHCP clients in your network that have special configuration requirements.

    For any hosts (that is, computers or other networked devices) that do not support DHCP or are not recommended to use it, you can also consider excluding IP addresses for those computers and devices and manually setting the IP address configuration directly at the applicable host. For example, you often need to statically configure the IP address for routers.

Commonly used options

After you set basic TCP/IP configuration settings (such as IP address, subnet mask, and default gateway) for clients, most clients also need the DHCP server to provide other information through DHCP options. The most common of these include the following:

  • Routers. A preferred list of IP addresses for routers on the same subnet as DHCP clients. The client can then contact these routers as needed to forward IP packets destined for remote hosts.
  • DNS servers. IP addresses for DNS name servers that DHCP clients can contact and use to resolve a domain host name query.
  • DNS domain. Specifies the domain name that DHCP clients should use when resolving unqualified names during DNS domain name resolution.
  • WINS node type. A preferred NetBIOS name resolution method for the DHCP client to use (such as b-node for broadcast only or h-node for a hybrid of point-to-point and broadcast methods).
  • WINS server. IP addresses of primary and secondary WINS servers for the DHCP client to use.

For more information, see either Microsoft DHCP clients or DHCP options reference.


Using option classes

Option classes offer an additional method for grouping DHCP-provided configuration details for clients within a scope. For Windows 2000 Server, there are two types of option classes that can be used for submanaging options:

  • User classes, for assigning options to clients identified as sharing a common need for similar DHCP options configuration.
  • Vendor classes, for assigning vendor-specific options to clients identified as sharing a commonly defined vendor type.

For more information, see Understanding user and vendor classes.

How user classes work

User classes allow DHCP clients to differentiate themselves by specifying a User Class option. When available for client use, this option includes a user-determined class ID that can help to group clients of similar configuration needs within a scope. For example, you might support users and computers with mobile computing needs by configuring a user class at the DHCP server and setting the related class ID at the client computers.

A user class is useful when you need to keep separate options that cover the special needs of identifying client computers, such as providing a shorter lease time for portable computers that move frequently or use remote access often. In this example, you could configure the DHCP server to distribute different options that are specific to the needs of clients.

For instance, shorter leases could be assigned to mobile clients. For more information, see To change the lease time for remote access clients.

The user class feature gives you greater flexibility in configuring DHCP clients on your network, but is not required for standard DHCP use. If user-defined option classes are not configured, options are provided through the applicable server, scope, or client option settings instead. For more information, see Assigning options.

Windows 2000 DHCP servers, which support recognition of user class IDs, perform the following added steps to lease clients identifying themselves according to this process:

  1. The server determines whether the user class identified by the client in its lease request is a recognized class, previously defined on the server.

    If a predefined user classes exists at the server and is configured, class-based assignment is enabled. For other user classes, you must first add and configure them at the server before they are available for use.

  2. If the user class is recognized, the server determines whether any additional DHCP options are configured for this class in the active lease context (either the scope or a client reservation) where the server is leasing the client.
  3. If the scope or reserved client options are configured to provide options for the user-defined class of the client, the server returns those options to the client as part of its DHCP acknowledgment message (DHCPACK), which is sent to confirm the lease.

Additional user class examples

For Windows 2000 computers, you can define specific user class identifiers to convey information about client software configuration, its physical location in a building, or about its user preferences. For example, an identifier can specify that DHCP clients are members of a user-defined class called "2nd floor, West," which has need for a special set of router, DNS, and WINS server settings.

You can also use the Microsoft predefined user classes for isolating configuration details specific for clients with special needs, such as BOOTP or Routing and Remote Access service. For more information, see To assign an advanced (class-based) option.

Notes

  • In addition to configuring or adding user classes at the DHCP server, in Windows 2000 you can set a DHCP user class ID at the client computer with the ipconfig /setclassid command. For more information, see To set DHCP class ID information at a client computer.
  • When you configure user classes at the DHCP server, be certain that the class identifying data you set at both the DHCP server and member client computers is identically matching binary or ASCII data. For more information, see To create a new user or vendor class.
  • The user class option only permits one class ID to be used for identifying clients. Each client computer can only be identified as a member of a single user class at the DHCP server. You can use additional user classes and make new hybrids from your other user classes, as needed.

How vendor classes work

Vendor-defined option classes can be used by DHCP clients that are configured to optionally identify themselves by their vendor type to the DHCP server when obtaining a lease. For a client to identify its membership in a vendor class, the client provides a value in the Vendor class identifier option when it requests or selects a lease from the server.

The vendor class identifier information is a string of character data interpreted by a DHCP server. Microsoft supports vendor class identification for its DHCP clients running Windows 2000 or Windows 98.

Most vendor types are derived from standard reserved hardware and operating system type abbreviation codes listed in Request for Comments (RFC) 1700. For more information, see TCP/IP RFCs.

Other vendors might choose to define their own specific vendor class IDs for either conveying vendor-specific information or handling special needs for their DHCP clients.

Windows 2000 DHCP servers, which support recognition of vendor class IDs, perform the following additional steps to lease the clients that identify themselves according to this process:

  1. The server determines whether the vendor class identified by the client in its lease request is a recognized class, previously defined on the server.

    Only Microsoft vendor classes are predefined at the server. For other vendor classes, you must manually add and configure these options at your Windows 2000 DHCP servers before they are available for use.

  2. If the vendor class is a recognized one, the server determines whether any additional DHCP options are configured for this class in the active lease context (either the scope or a client reservation) where the server is leasing the client.
  3. If the scope or reserved client options are configured to provide options for the vendor-defined class of the client, the server returns them using the Vendor specific information option as part of its DHCP acknowledgment message (DHCPACK), which is sent to confirm the lease.

Vendor classes permit other system vendors to support custom applications for DHCP in mixed vendor environments. Vendor-specific options, when provided, are used in addition to any of the standard DHCP options assigned or required for DHCP.

For more information on vendor classes, see DHCP RFCs or refer directly to RFC 2132.

Notes

  • In most cases, the default (or unspecified) vendor class, DHCP standard options, can provide a useful default for grouping any DHCP clients that do not specify or recognize vendor class IDs.
  • When you add new vendor classes at the DHCP server, be sure that the vendor class ID data you set at the server matches the actual vendor class ID used by clients for your vendor. For more information, contact the appropriate vendor.


Interoperability issues

The following section covers issues that affect the use of the Windows 2000 DHCP server with other services or network configurations on your network.

  • Using DNS servers with DHCP
  • Using Routing and Remote Access servers with DHCP
  • Multihomed DHCP servers


Using DNS servers with DHCP

When installing a Windows 2000 DHCP server, you can configure the server to perform updates on behalf of its DHCP clients to any Domain Name System (DNS) servers that support dynamic updates.

How DHCP/DNS update interaction works

The DHCP server can be used to register and update the pointer (PTR) and address (A) resource records on behalf of its DHCP-enabled clients.

This process requires the use of an additional DHCP option, the Client FQDN option (option 81). This option permits the client to provide its fully qualified domain name (FQDN) as well as instructions to the DHCP server on how it would like the server to process DNS dynamic updates (if any) on its behalf.

When this option is issued by a qualified DHCP client, such as a DHCP-enabled computer running Windows 2000, it is processed and interpreted by Windows 2000 DHCP servers to determine how the server initiates updates on behalf of the client.

For example, the server might be configured in one of the following ways to process client requests:

  • The DHCP server registers and updates client information with its configured DNS servers according to the client request.

    Once a new DHCP server is installed, this is the default configuration for Windows 2000 DHCP servers and clients. In this mode, any Windows 2000 DHCP client can request the way in which the DHCP server performs updates of its host (A) and pointer (PTR) resource records. If possible, the DHCP server accomodates the client request for handling updates to its name and IP address information in DNS.

    This can be set at the applicable DHCP server by configuring the Update DNS only if DHCP client requests option located in Properties on the DNS tab.

  • The DHCP server always registers and updates client information with its configured DNS servers.

    This is a modified configuration supported for Windows 2000 DHCP servers and clients. In this mode, the DHCP server always performs updates of the client's FQDN and leased IP address information, both its host (A) and pointer (PTR) resource records, regardless of whether the client has requested to perform its own updates.

    This can be set at the applicable DHCP server by configuring the Always update DNS option located in Properties on the DNS tab.

  • The DHCP server never registers and updates client information with its configured DNS servers.

    To set this behavior, the DHCP server must be configured to disable performance of DHCP/DNS proxied updates. By disabling this feature, no client host (A) or pointer (PTR) resource records are updated in DNS for DHCP clients.

    If necessary, this change in setting can be made at Windows 2000 DHCP servers by clearing the Automatically update DHCP client information in DNS check box, which is located in Properties on the DNS tab on the applicable DHCP server or one of its scopes. By default, updates are always performed for newly installed Windows 2000 DHCP servers and any new scopes created for them.

Additional advanced DHCP/DNS server configuration options

In addition to these standard DHCP/DNS interactions, the Windows 2000 DHCP server can be configured to perform these optional update tasks as follows:

  1. The server can selectively be configured to not send updates for discarding a client host (A) resource record when the client lease expires.

    When the DHCP server is enabled to perform DNS updates, it always sends updates to discard the client pointer (PTR) resource records when the lease expires. Whether the server does this also with client host (A) resource records when a client's lease expires (by default, the server discards these) is a configurable option.

    To modify this at the applicable DHCP server, clear the Discard forward (name-to-address) lookups when leases expires check box in Properties on the DNS tab.

  2. The server can be selectively configured to not send updates for clients unable to use the Client FQDN option (option 81), to request the way that updates are handled.

    By default, the DHCP server sends updates for clients that do not support option 81. This allows the server to perform proxy updates in DNS for all of its DHCP clients that are running earlier versions of Windows operating systems.

    To modify this at the applicable DHCP server, clear or select the Enable updates for DNS clients that do not support dynamic updates check box in Properties on the DNS tab.

Important

  • For the DHCP/DNS interaction described in the following sections to be in effect:
    1. Be certain that you are using DHCP and DNS servers running Windows 2000 Server.
    2. Make any configuration changes needed to enable the use of dynamic updates at your DHCP and DNS servers, as described in the DNS dynamic update protocol.

Windows DHCP clients and DNS dynamic update protocol

DHCP clients running Windows 2000 and earlier versions of Windows interact differently when performing the DHCP/DNS interactions previously described. The following examples and graphics show how this process varies in different cases.

Example 1: DHCP/DNS update interaction for Windows 2000 DHCP clients

Windows 2000 DHCP clients interact with DNS dynamic update protocol as follows:

  1. The client initiates a DHCP request message (DHCPREQUEST) to the server.
  2. The server returns a DHCP acknowledgment message (DHCPACK) to the client, granting an IP address lease.
  3. By default, the client sends a DNS update request to the DNS server for its own forward lookup record, a host (A) resource record.

    Alternately, the server can perform this update to the DNS server on behalf of the client if both the client and its configuration are modified accordingly.

  4. The server sends updates for the DHCP client's reverse lookup record--a pointer (PTR) resource record--using the process defined by the DNS dynamic update protocol.
Example 1: DHCP/DNS update interaction for Windows 2000 DHCP clients

Example 2: DHCP/DNS update interaction for earlier Windows DHCP clients (prior to Windows 2000)

Earlier versions of Windows DHCP clients do not support the DNS dynamic update process directly, and therefore, can not directly interact with the DNS server. For these DHCP clients, updates are typically handled as follows:

  1. The client initiates a DHCP request message (DHCPREQUEST) to the server.
  2. The server returns a DHCP acknowledgment message (DHCPACK) to the client, granting an IP address lease.
  3. The server then sends updates to the DNS server for the client's forward lookup record, which is a host (A) resource record.
  4. The server also sends updates for the client's reverse lookup record, which is a pointer (PTR) resource record.
Example 2: DHCP/DNS update interaction for earlier Windows DHCP clients (prior to Windows 2000)

Using the DnsUpdateProxy security group

As previously described, you can configure a Windows 2000 DHCP server so that it dynamically registers host (A) and pointer (PTR) resource records on behalf of DHCP clients. In this configuration, the use of secure dynamic update with Windows 2000 DNS servers might cause stale resource records.

For example, suppose the following sequence of events occurs:

  1. A Windows 2000 DHCP server (DHCP1) performs a secure dynamic update on behalf of one of its clients for a specific DNS domain name.
  2. Because the DHCP server successfully created the name, it becomes the owner of the name.
  3. Once the DHCP server becomes the owner of the client name, only that DHCP server can update the name.

In some circumstances, this might cause problems. For instance, suppose that DHCP1 later fails. If a second backup DHCP server comes online, it cannot update the client name because it is not the owner of the name.

In a similar example, suppose DHCP1 registered in DNS on behalf of its client the name "host.example.microsoft.com", and then the administrator upgraded that computer from an earlier version of Windows to Windows 2000. Since the DHCP server (DHCP1) is the owner of this name, the client cannot update its DNS records once the computer is upgraded to Windows 2000.

To solve this problem, a new built-in security group called DnsUpdateProxy is provided. Any object created by the members of this group has no security and the first user (that is not a member of the DnsUpdateProxy group) to modify the set of records associated with a client becomes its owner. Thus, if every DHCP server registering resource records for older clients is a member of this group, the problems discussed earlier are eliminated.

Adding members to the DnsUpdateProxy group

You can configure the DnsUpdateProxy security group through Active Directory Users and Computers. For more information, see To add a member to a group.

Important

  • If you are using multiple DHCP servers for fault tolerance and also securing dynamic updates, add each of the computers operating a Windows 2000 DHCP server as members of the DnsUpdateProxy global security group.

Security concerns when using the DnsUpdateProxy group

Although adding all DHCP servers as members to this special built-in group helps to resolve some DNS update concerns about maintaining secure updates, this solution also introduces some additional security concerns.

For example, any DNS domain names registered by the computer running the DHCP server are nonsecure. The host (A) resource record for the DHCP server itself is an example of such a record. This issue is more significant if the DHCP server (that is a member of the DnsUpdateProxy group) is installed on a domain controller. To protect against issue, you can manually specify a different owner for any DNS records associated with the DHCP server itself.

In this case, all service location (SRV), host (A), or alias (CNAME) resource records registered by the Netlogon service for the domain controller are nonsecure. To minimize the problem, it is recommended that you do not install a DHCP server on a domain controller.

Another strong argument against running a Windows 2000 DHCP server on a Windows 2000 domain controller is that the DHCP server has full control over all DNS objects stored in Active Directory, because the DHCP server is running under the computer (in this case, the domain controller) account.

Additional resources on DHCP and DNS interaction

Because of the close integration of DHCP and DNS described in this section, you might want to investigate or review these additional topics as resources for your deployment issues related to this feature.

For more information:

  • On the DNS dynamic update protocol and considerations for securing dynamic updates when using Active Directory, see Dynamic update.
  • On how to configure Windows 2000 DNS servers to enable some or all updates for specific zones, see To allow dynamic updates and To allow only secure dynamic updates.
  • On how to enable Windows 2000 DHCP servers to initiate updates on behalf of its clients for specific scopes (or all scopes), see To enable DNS dynamic updates for clients.
  • On how you can modify or set Windows 2000 computers to initiate dynamic updates on their own behalf, see To configure TCP/IP to use DNS.
  • On DNS resource records, see Domain Name System (DNS) or Resource records reference.

Important

  • If you are using multiple DHCP servers for fault tolerance and also securing dynamic updates, add each of the computers operating a Windows 2000 DHCP server as members of the DnsUpdateProxy global security group. For more information, see To add a member to a group.

Caution

  • For Windows 2000, the use of secure dynamic updates can be compromised by running a DHCP server on a domain controller when Windows 2000 DHCP server is configured to perform registration of DNS records on behalf of its clients. To avoid this issue, deploy DHCP servers and domain controllers on separate computers. If you are not concerned about security of reverse lookup (PTR) records, this precaution is only advisable if the DHCP server is configured to perform registration of host (A) records on behalf of its clients (which is not a default behavior).

Notes

  • Microsoft supports the DHCP/DNS update interaction currently under final review as a proposed Internet standard Request for Comment (RFC) document by the Internet Engineering Task Force (IETF).

    This interactive process is fully described in the applicable draft, "Interaction between DHCP and DNS." To obtain the current or final version of this draft, see the Request for Comments Web site (http://www.rfc-editor.org/).

  • If you are using legacy DNS servers that do not support dynamic updates, you can implement the following changes for dynamically updating and registering names and addresses for your DHCP clients:
    1. If you are also using WINS and legacy Windows DNS servers (that is, DNS servers running Windows NT Server 4.0), you might be able to use WINS lookup integration to support resolution of client names and addresses on your network that are not updated dynamically in DNS.
    2. Upgrade or replace your older DNS servers with Windows 2000 DNS servers.


Using Routing and Remote Access servers with DHCP

The DHCP Server service can be deployed along with the Routing and Remote Access service to provide remote access clients with a dynamically assigned IP address during connection. When these services are used together on the same server computer, the information provided during dynamic configuration is provided differently than in the case of typical DHCP configuration for LAN-based clients.

In LAN environments, DHCP clients negotiate and receive the following configuration information, based entirely on settings configured in the DHCP console for the DHCP server:

  • A leased IP address provided from the available address pool of an active scope on the DHCP server. The DHCP server directly manages and distributes the address to the LAN-based DHCP client.
  • Additional parameters and other configuration information provided through assigned DHCP options in the address lease. The values and list of options used correspond to option types configured and assigned on the DHCP server.

When a Routing and Remote Access server provides dynamic configuration for dial-up clients, it first performs the following steps:

  • When the Routing and Remote Access server starts with the Use DHCP to assign remote TCP/IP addresses option, it makes advance requests to the DHCP server to obtain DHCP client addresses for dial-up clients, caching these addresses.
  • The number of client addresses that are requested in advance is equal to the number of Routing and Remote Access ports set to receive calls and one additional address.

For example, if the server has two analog modem ports and two ISDN adapter ports that are set to receive calls, it requests a total of five IP addresses from the DHCP server. The first four are for assigning to clients that dial in to the analog and ISDN server ports. The fifth address is reserved for the server itself, so it can configure and use its own IP address when processing connections for dial-up clients.

When the Routing and Remote Access server uses this type of proactive caching of DHCP address leases for dial-up clients, it records the following information for each lease response it obtains from the DHCP server:

  • The IP address of the DHCP server
  • The client leased IP address (for later distribution to the Routing and Remote Access client)
  • The time at which the lease was obtained
  • the time at which the lease expires
  • The duration of the lease

All other DHCP options information returned by the DHCP server (such as server, scope, or reserved client options) are discarded. When the client dials into the server and requests an IP address (that is, when Server Assigned IP Address is selected), it uses one of these cached DHCP leases to provide the dial-up client dynamic IP address configuration.

When the IP address is provided to the dial-up client, the client is unaware that the IP address has been obtained through this intermediate process between the DHCP server and the Routing and Remote Access server. The Routing and Remote Access server maintains the lease on behalf of the client. Therefore, the only information that the client receives from the DHCP server is the IP address lease.

In dial-up environments, DHCP clients negotiate and receive dynamic configuration using the following modified behavior:

  • A leased IP address from the Routing and Remote Access server cache of DHCP scope addresses. The Routing and Remote Access server obtains and renews its cached address pool with the DHCP server.
  • If additional parameters and other configuration information provided through assigned DHCP options in the address lease is normally provided by the DHCP server, this information is returned to the Routing and Remote Access client based on TCP/IP properties configured on the Routing and Remote Access server.

Notes

  • For more information, see Supporting Routing and Remote Access clients.
  • For Windows 2000, DHCP servers provide a predefined user class, the Default remote access class, for assigning options that are specific and provided only to Routing and Remote Access clients. for more information, see Microsoft predefined user classes.


Multihomed DHCP servers

A multihomed DHCP server is a computer running Windows 2000 Server that uses the DHCP service for more than a single network connection. For a server computer to be multihomed, each network connection must attach the computer to more than a single physical network. This requires that additional hardware (in the form of multiple installed network adapters) be used on the computer.

A server running Windows 2000 Server can perform as a multihomed DHCP server. For multihomed servers, the DHCP service binds to the first IP address configured on the first network connection in use. Typically, this is the first physical network adapter interface on the server computer and appears as "Local Area Connection" in the Network and Dial-up Connections folder.

By default, the service bindings depend on whether the first network connection is configured dynamically or statically for TCP/IP. Based on the method of configuration it uses, reflected by its current settings in Internet Protocol (TCP/IP) properties, the DHCP Server service performs default service bindings as follows:

  • If the first network connection uses a manually specified IP address, the connection is enabled in server bindings. For this to occur, a value for IP address must be configured and the Use the following IP address option selected in Internet Protocol (TCP/IP) properties. In this mode, the DHCP server listens for and provides service to DHCP clients.
  • If the first network connection uses an IP address configured dynamically, the connection is disabled in server bindings. This occurs when the Obtain an IP address automatically option is selected in Internet Protocol (TCP/IP) properties. For Windows 2000, this is the typical default setting. In this mode, the DHCP server does not listen for and provide service to DHCP clients until a static IP address is configured.

Notes

  • By design, DHCP server bindings are enabled and disabled on a per-connection, not per-address basis. All bindings are based on the first configured IP address for each connection appearing in the Network and Dial-up Connections folder. If additional static IP addresses (for example, as set in Advanced TCP/IP properties) for the applicable connection, these addresses are never used by Windows 2000 DHCP servers and are inconsequential for server bindings.
  • For more information, see About Network and Dial-up Connections.
  • Windows 2000 DHCP servers never bind to any of the NDISWAN or DHCP-enabled interfaces used on the server. These interfaces are not displayed in the DHCP console under the current server bindings list because they are never used for DHCP service. Only additional network connections that have a primary static IP address configured can appear in the server bindings list (or be selectively enabled or disabled there).
  • For more information, see To selectively set DHCP server bindings for network connections.

Example: Configuring a multihomed DHCP server

The following illustration is an example of a multihomed DHCP server with three network adapters installed. Each adapter is configured to lease addresses on separate physical subnets:

Example: multihomed DHCP server

Note that in the graphic, the multihomed DHCP server has three adapters installed and configured statically with a single IP address for each. Because the IP addressing for the DHCP server also uses an adjusted or custom subnet mask value (255.255.255.224), that value is applied for all IP addresses that are configured at the server and for other computers in use on the same example private IP network. In this network example, a Class C range of IP addresses, 192.168.200.1 to 192.168.200.254, is used.

In this example, each of the three adapters connects the server to three different physical subnets (Subnets A, B, and C). To achieve the intended result of having the DHCP provide leased configuration service to all clients in each of the respective subnets, two configuration details are essential and must be verified during deployment plans:

  1. The server must use a statically configured IP address within the same range of valid IP addresses for the physical network on which it is servicing clients.
  2. The server must have each of its valid subnet IP addresses excluded from the scope used to offer leases to clients

For example, if no special subnetting is used in this environment, the selection of DHCP server IP addresses is not as critical because the IP network and IP subnet are the same. When the default subnet mask value (255.255.255.0) is used, all 254 possible host IDs are considered to be part of one single unified subnet.

In the case of this example, however, if a custom subnet mask of 255.255.255.224 is applied, the network ID and subnet ID are not the same. Whenever the subnet ID is not the same as the network ID, care and attention must be taken so that the DHCP server is provided IP address assignment within the same subnet it is intended to service.

For instance, with the mask set to 255.255.255.224 at all hosts, the first three bit places of the last notated octet (224) are taken from the full eight bit places that would normally comprise the full host ID section. These bits are used for physical subnet identification. This leaves the remaining five bit places to be used as the actual or reduced host ID field.

In the example network shown above, the three subnets in use can have a maximum of eight (or 23) potentially different subnet IDs. Likewise, each of these subnets can in turn, only support up to 32 (or 25) potential host IDs.

Because of the use of subnetting, in this example Subnet A consists of the first 32 address values in the network, from 0 to 31. Because no host IDs consisting of "all zeroes" or "all ones" in the the host ID field can actually be assigned for use to computers, the useful range of total available IP addresses for each subnet drops from 32 to 30.

Of the remaining 30 addresses, the DHCP server just needs to use one. The remaining 29 can be configured in a regular DHCP scope and used for assigning leases to subnet clients. The choice of which address to use for the DHCP server is preferential, as well as the decision to include the statically assigned IP address of the DHCP server within the scope defined for use in each subnet.

In this example, the IP addresses (192.169.200.1, 192.168.200.33, 192.168.200.65) of the multihomed server are configured using the first IP address available for each of the three subnets. In the configuration shown, these addresses are excluded from the defined boundaries of each of the scopes created for these subnets.

Alternatively, you could set up your scopes so as to include these addresses within the defined boundaries of the scope. If you do, you need to create address exclusions to exclude these server IP addresses from each of the respective scopes.

Note

  • For more information on IP subnetting, see Subnet masks or the Windows 2000 Server Resource Kit.


Resources

This section covers:

  • DHCP options reference
  • DHCP RFCs
  • DHCP database files
  • Netshell commands for DHCP
  • DHCP performance monitoring reference
  • DHCP updated technical information
  • DHCP bibliography


DHCP options reference

This section covers:

  • Standard DHCP and BOOTP options
  • Advanced and new options
  • Microsoft options


Standard DHCP and BOOTP options

The following topics provide descriptions of all predefined options available for use with Windows 2000 DHCP and all earlier versions of Microsoft-based DHCP servers. These options are defined according to the updated standards reference for DHCP options (RFC 2132, "DHCP Options and BOOTP Vendor Extensions").

  • Basic options (RFC 1497)
  • IP host options
  • IP interface options
  • Link layer options
  • TCP options
  • Application layer options
  • NetBIOS over TCP/IP options


Basic options (RFC 1497)

The following tables list basic DHCP option types originally defined in RFC 1497 for use with DHCP and BOOTP service. In BOOTP service, these option types are referred to as vendor extensions.

Pad

Code | 0
Length | (Not used)
Value | (Not used)
Description | This option type is a single octet of zero ("00") used for padding. This option differs from most DHCP option types in that it does not use a length or value field. Where used, this option causes subsequent DHCP option types as they appear in the DHCP packet to align on word boundaries. This option does not require configuration.
Structure

    Code
   +-----+
   |  0  |
   +-----+

End

Code | 255
Length | (Not used)
Value | (Not used)
Description | This option is a single octet of decimal 255 ("FF") used to indicate the end of a DHCP options area in DHCP message packets. This option differs from most DHCP option types because it does not use a length or value field. Typically, it is used at the end of the options field to indicate that there is no more options data in a DHCP message packet. It can also be used within the message, in connection with the vendor specific information (option 43), to indicate the end of an encapsulated vendor specific options subfield. This option does not require configuration.
Structure

    Code
   +-----+
   | 255 |
   +-----+

Subnet mask

Code | 1
Length | Fixed, 4 octets.
Value | Signed 32-bit integer representing the subnet mask for an IP address provided in a DHCP message.
Description | Specifies the subnet mask of the client subnet, as described in RFC 950, "Internet Standard Subnetting Procedure." The value for this option type is taken from the Subnet Mask field, as defined in a DHCP scope Properties dialog box in the DHCP console.
Structure

    Code   Len        Subnet mask
   +-----+-----+-----+-----+-----+-----+
   |  1  |  4  |  m1 |  m2 |  m3 |  m4 |
   +-----+-----+-----+-----+-----+-----+

Time offset

Code | 2
Length | Fixed, 4 octets.
Value | Signed 32-bit integer used for offset of UCT time.
Description | Specifies an offset value (in seconds) from the Universal Coordinated Time (UCT) that applies to the client subnet. This value is configured as a signed 32-bit integer. Positive offset values indicate a subnet location east of the zero meridian. Negative offset values indicate a subnet location west of the zero meridian.
Structure

    Code   Len        Time offset
   +-----+-----+-----+-----+-----+-----+
   |  2  |  4  |  n1 |  n2 |  n3 |  n4 |
   +-----+-----+-----+-----+-----+-----+

Router

Code | 3
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each router address listed.
Value | Signed 32-bit integer representing IP address of each assigned router.
Description | Specifies a list of IP addresses for routers on the subnet of the client. When more than one router is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  3  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Time server

Code | 4
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each RFC 868 time server address listed.
Value | Signed 32-bit integer representing IP address of each assigned RFC 868 time server.
Description | Specifies a list of IP addresses for RFC 868 time servers that are available to the client. When more than one time server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  4  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

IEN name server

Code | 5
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each IEN name server address listed.
Value | Signed 32-bit integer representing IP address of each assigned IEN name server.
Description | Specifies a list of IP addresses for Internet Engineering Note (IEN) name servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  5  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

DNS server

Code | 6
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each DNS server address listed.
Value | Signed 32-bit integer representing the IP address of each assigned DNS server.
Description | Specifies a list of IP addresses for Domain Name System (DNS) name servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order. DHCP client computers that are multihomed and obtain multiple DHCP leases can have only one DNS server list per host computer, not per adapter interface.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  6  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Log server

Code | 7
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each log server address listed.
Value | Signed 32-bit integer representing the IP address of each assigned log server.
Description | Specifies a list of IP addresses for MIT-LCS UDP log servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  7  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Cookie server

Code | 8
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each cookie server address listed.
Value | Signed 32-bit integer representing the IP address of each assigned cookie server.
Description | Specifies a list of IP addresses for RFC 865 cookie servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  8  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

LPR server

Code | 9
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each LPR server address listed.
Value | Signed 32-bit integer representing the IP address of each assigned LPR server.
Description | Specifies a list of IP addresses for RFC 1179 line printer servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  9  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Impress server

Code | 10
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each Impress server address listed.
Value | Signed 32-bit integer representing IP address of each assigned Impress server.
Description | Specifies a list of IP addresses for Imagen Impress servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  10 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Resource location server

Code | 11
Length | Variable, minimum length of 4 octets. Octet length increases in multiples of 4 for each resource location server address listed.
Value | Signed 32-bit integer representing the IP address of each assigned resource location server.
Description | Specifies a list of IP addresses for RFC 887 Resource Location servers available to the client. When more than one server is assigned, the client interprets and uses the addresses in the specified order.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  11 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Host name

Code | 12
Length | Length varies depending on data in value. Minimum length is 1 octet. Maximum length is limited to 63 characters, or one octet for each character used in the host name configured for use with this option.
Value | ASCII character text.
Description | Specifies a host name for the client of up to 63 characters in length. (See RFC 1035 for possible character set restrictions.) In some cases, this name can also be fully qualified by appending the name value provided here with the DNS domain name, as specified in option 15. For Windows clients, this option is not supported for use when configuring the host name of the client, which is set in Computer Name in the Network Identification Properties dialog box on the client computer.
Structure

    Code   Len                 Host name
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  12 |  n  |  h1 |  h2 |  h3 |  h4 |  h5 |  h6 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Boot file size

Code | 13
Length | Fixed, 2 octets.
Value | Unsigned 16-bit integer to indicate the number of 512-octet blocks needed to make up the boot file.
Description | Specifies the size of the default boot image file for the client.
Structure

    Code  Len   File size
   +-----+-----+-----+-----+
   |  13 |  02 |  11 |  12 |
   +-----+-----+-----+-----+

Merit dump file

Code | 14
Length | Length varies depending on data in value. Minimum length is 1 octet.
Value | ASCII character text.
Description | Specifies a path name of a file to which the core memory image of the client should be dumped in the event that the client fails. For this option type, data used for a value is ASCII character text. The length of the value field depends on the number of characters used in the file path name specified here. For example, if the path name entered has 20 characters, the value field for this option should also be 20 octets in length.
Structure

    Code   Len      Dump file pathname
   +-----+-----+-----+-----+-----+-----+---
   |  14 |  n  |  n1 |  n2 |  n3 |  n4 | ...
   +-----+-----+-----+-----+-----+-----+---

DNS domain name

Code | 15
Length | Length varies depending on data in value. Minimum length is 1 octet.
Value | ASCII character text.
Description | Specifies the domain name that the DHCP client should use when resolving host names using DNS. For this option type, ASCII character text is used for the data value. The length of the value field depends on the number of characters used in the DNS domain name specified here. For example, if the domain name has 20 characters, the value field for this option should also be 20 octets in length.
Structure

    Code   Len        Domain name
   +-----+-----+-----+-----+-----+-----+--
   |  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
   +-----+-----+-----+-----+-----+-----+--

Swap server

Code | 16
Length | Length is fixed at 4 octets.
Value | A single IP address for the swap server of the client (unsigned 32-bit integer).
Description | Specifies the IP address of the swap server.
Structure

    Code   Len    Swap server address
   +-----+-----+-----+-----+-----+-----+
   |  16 |  n  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

Root path

Code | 17
Length | Length varies depending on data in value. Minimum length is 1 octet.
Value | A single IP address for the swap server of the client (unsigned 32-bit integer).
Description | Specifies the path name that contains the root disk of the client. The path is formatted as ASCII text. For this option type, data used for a value is ASCII character text. The length of the value field depends on the number of characters used in the root path name specified here. For example, if the root path name entered has 20 characters, the value field for this option should also be 20 octets in length.
Structure

    Code   Len      Root disk pathname
   +-----+-----+-----+-----+-----+-----+---
   |  17 |  n  |  n1 |  n2 |  n3 |  n4 | ...
   +-----+-----+-----+-----+-----+-----+---

Extensions path

Code | 18
Length | Length varies depending on data in value. Minimum length is 1 octet.
Value | ASCII character text.
Description | Specifies a file that can be retrieved using Trivial File Transfer Protocol (TFTP) containing information to be interpreted in the same way as the 64-octet vendor-extension field within a BOOTP response. To allow more than 64 octets of BOOTP vendor extension information, this option can be used. When used, the length of the specified extension path file is not limited in size and all references in the extensions file to Tag 18 (such as instances of the BOOTP Extensions Path field) are ignored.
Structure

    Code   Len      Extensions pathname
   +-----+-----+-----+-----+-----+-----+---
   |  18 |  n  |  n1 |  n2 |  n3 |  n4 | ...
   +-----+-----+-----+-----+-----+-----+---

Notes

  • For all option types provided here that use a list of IP addresses as the valued options data, IP addresses are always used in order of preference by the DHCP client. The first address in the list is used first.
  • Windows 2000 DHCP servers support configuration and distribution of any of these options that are assigned using the DHCP console. By default, Microsoft DHCP-enabled clients require and provide storage and interpretation only for options 1, 3, 6, and 15 of the option types listed in this section for default client configuration. Other options are pre-defined for assignment and distribution by Windows 2000 DHCP servers, but are recognized only when clients use other DHCP software supporting these other options.


IP host options

The following table describes the DHCP options that affect operation of the IP layer on a per-host basis.

IP forwarding enable/disable

Code: 19
Length: Fixed, 1 octet.
Value: 1=enable IP forwarding, 0=disable IP forwarding.
Description: Used to determine whether the DHCP client enables or disables forwarding of datagrams at the IP layer.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  19 |  1  | 0/1 |
   +-----+-----+-----+

Non-local source routing enable/disable

Code: 20
Length: Fixed, 1 octet.
Value: 1=enable forwarding of datagrams from non-local sources, 0=disable forwarding of datagrams from non-local sources.
Description: Used to determine whether the DHCP client enables or disables forwarding of datagrams at the IP layer, based on whether a received datagram is from a local or non-local source.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  20 |  1  | 0/1 |
   +-----+-----+-----+

Policy filter

Code: 21
Length: Variable. Minimum length is 8 octets for a single destination-and-mask pairing. Length increases in multiples of 8 octets for each additional pairing used.
Value: Two, consecutive, unsigned 32-bit integers indicating a paired value, consisting of an IP address followed by a subnet mask.
Description: Specifies policy filters for non-local source routing on the client. The filters consist of a list of paired IP addresses specifying destination-and-mask pairs for which to filter source routes of any incoming datagrams. The client discards any source routed datagram with a next-hop address that does not match one of the filters. For further information about policy filtering as it applies to this option type, see RFC 1122.
Structure:

    Code   Len         Address 1                  Mask 1
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  21 |  n  |  a1 |  a2 |  a3 |  a4 |  m1 |  m2 |  m3 |  m4 |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
           Address 2                  Mask 2
   +-----+-----+-----+-----+-----+-----+-----+-----+---
   |  a1 |  a2 |  a3 |  a4 |  m1 |  m2 |  m3 |  m4 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+---

Maximum datagram reassembly size

Code: 22
Length: Fixed, 2 octets.
Value: a 16-integer specifying the maximum datagram size for reassembly. The minimum size for a datagram is 576.
Description: Specifies the maximum size datagram that the client can reassemble.
Structure:

    Code   Len      Size
   +-----+-----+-----+-----+
   |  22 |  2  |  s1 |  s2 |
   +-----+-----+-----+-----+

Default IP Time-To-Live

Code: 23
Length: Fixed, 1 octet.
Value: A number (in seconds) between 1 and 255.
Description: Specifies the default Time-To-Live (TTL) that the client uses on outgoing datagrams.
Structure:

    Code   Len   TTL
   +-----+-----+-----+
   |  23 |  1  | ttl |
   +-----+-----+-----+

Path MTU aging timeout

Code: 24
Length: Fixed, 4 octets.
Value: A 32-bit unsigned integer that specifies a time-out value (in seconds).
Description: Specifies the time-out for aging Path Maximum Transmission Unit (MTU) values. (Values are discovered by the mechanism defined in RFC 1191).
Structure:

    Code   Len           Timeout
   +-----+-----+-----+-----+-----+-----+
   |  24 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

Path MTU plateau table

Code: 25
Length: Variable, minimum length of 2 octets. Where length is more than 2, it increases in multiples of 2.
Value: A table formatted as a list of 16-bit unsigned integers, ordered from smallest to largest. The minimum tabled MTU value cannot be smaller than 68.
Description: Specifies a table of MTU sizes to use when performing Path MTU Discovered, as defined in RFC 1191.
Structure:

    Code   Len     Size 1      Size 2
   +-----+-----+-----+-----+-----+-----+---
   |  25 |  n  |  s1 |  s2 |  s1 |  s2 | ...
   +-----+-----+-----+-----+-----+-----+---


IP interface options

The following table describes the DHCP options that affect operation of the IP layer on a per-interface basis.

Interface MTU

Code: 26
Length: Fixed, 2 octets.
Value: A 16-bit, unsigned integer specifying the interface MTU. The minimum legal value for the MTU is 68.
Description: Specifies the MTU size that can be used on a specified host adapter interface.
Structure:

    Code   Len      MTU
   +-----+-----+-----+-----+
   |  26 |  2  |  m1 |  m2 |
   +-----+-----+-----+-----+

All subnets are local

Code: 27
Length: Fixed, 1 octet.
Value: 1=client assumes all subnets are local and share the same MTU size; 0=client assumes some subnets are not local and that smaller MTU sizes might be in use on remote subnets.
Description: Specifies whether the client assumes that all subnets of internetwork use are the same MTU as the local subnet on which the client is connected.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  27 |  1  | 0/1 |
   +-----+-----+-----+

Broadcast address

Code: 28
Length: Fixed, 4 octets.
Value: Typically, the limited broadcast IP address (255.255.255.255), but can be modified using legal values for broadcast addresses, as specified in section 3.2.1.3 of RFC 1122, "Requirements for Internet Hosts—Communication Layers."
Description: Specifies the broadcast address used on the subnet of the client.
Structure:

    Code   Len     Broadcast address
   +-----+-----+-----+-----+-----+-----+
   |  28 |  4  |  b1 |  b2 |  b3 |  b4 |
   +-----+-----+-----+-----+-----+-----+

Perform mask discovery

Code: 29
Length: Fixed, 1 octet.
Value: 1=client performs subnet mask discovery; 0=client does not perform subnet mask discovery.
Description: Specifies whether the client uses Internet Control Message Protocol (ICMP) for subnet mask discovery.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  29 |  1  | 0/1 |
   +-----+-----+-----+

Mask supplier

Code: 30
Length: Fixed, 1 octet.
Value: 1=client responds to subnet mask requests; 0=client does not respond to subnet mask requests.
Description: Specifies whether the client responds to subnet mask requests using ICMP.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  30 |  1  | 0/1 |
   +-----+-----+-----+

Perform router discovery

Code: 31
Length: Fixed, 1 octet.
Value: 1=client performs router discovery; 0=client does not perform router discovery.
Description: Specifies whether the client solicits routers using the router discovery method in RFC 1256.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  31 |  1  | 0/1 |
   +-----+-----+-----+

Router solicitation address

Code: 32
Length: Fixed, 4 octets.
Value: An IP address (unsigned 32-bit integer).
Description: Specifies the IP address to which the client submits router solicitation requests.
Structure:

    Code   Len            Address
   +-----+-----+-----+-----+-----+-----+
   |  32 |  4  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

Static route

Code: 33
Length: Variable, minimum length of 8 octets. Octet length increases in multiples of 8 for each additional static route provided with this option.
Value: A list of IP address pairs. Each 8 octets provides two consecutive IP addresses, pairing the destination and router addresses used for each route. The first 4 octets specifies the destination address, and the second 4 octets specifies the router for the destination address.
Description: Specifies a list of static routes the client installs in its routing cache. Any multiple routes to the same destination are listed in descending order of priority. The default route of 0.0.0.0 is an illegal destination for a static route.
Structure:

    Code   Len         Destination 1           Router 1
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  33 |  n  |  d1 |  d2 |  d3 |  d4 |  r1 |  r2 |  r3 |  r4 |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
           Destination 2           Router 2
   +-----+-----+-----+-----+-----+-----+-----+-----+---
   |  d1 |  d2 |  d3 |  d4 |  r1 |  r2 |  r3 |  r4 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+---


Link layer options

The following table describes the DHCP options that affect operation of the datalink layer on a per-interface basis.

Trailer encapsulation

Code: 34
Length: Fixed, 1 octet.
Value: 1=client attempts to use trailer; 0=client does not attempt to use trailers.
Description: Specifies whether the client negotiates the use of trailers, as described in RFC 983, when using Address Resolution Protocol (ARP).
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  34 |  1  | 0/1 |
   +-----+-----+-----+

ARP cache timeout

Code: 35
Length: Fixed, 4 octets.
Value: An unsigned 32-bit integer specifying a time-out value (in seconds).
Description: Specifies the time-out for ARP cache entries.
Structure:

    Code   Len           Time
   +-----+-----+-----+-----+-----+-----+
   |  35 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

Ethernet encapsulation

Code: 36
Length: Fixed, 1 octet.
Value: 1=client uses RFC 1042 encapsulation; 0=client uses RFC 894 encapsulation.
Description: Specifies whether the client uses Ethernet v. 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is Ethernet.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  36 |  1  | 0/1 |
   +-----+-----+-----+


TCP options

The following table details the DHCP options that affect operation of the TCP session layer on a per-interface basis.

TCP default TTL

Code: 37
Length: Fixed, 1 octet.
Value: An unsigned 8-bit integer specifying a Time-To-Live (TTL) value (in seconds). The minimum TTL value is 1.
Description: Specifies the default TTL the client uses when sending TCP segments.
Structure:

    Code   Len   TTL
   +-----+-----+-----+
   |  37 |  1  |  n  |
   +-----+-----+-----+

TCP keepalive interval

Code: 38
Length: Fixed, 4 octets.
Value: An unsigned 32-bit integer that specifies a keepalive interval (in seconds).
Description: Specifies the interval the client waits before sending a keepalive message on a TCP connection. A value of 0 indicates that the client does not send keepalive messages on connections unless specifically requested by an application.
Structure:

    Code   Len           Time
   +-----+-----+-----+-----+-----+-----+
   |  38 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

TCP keepalive garbage

Code: 39
Length: Fixed, 1 octet.
Value: 1=client sends keepalive garbage octet; 0=client does not send keepalive garbage octet.
Description: Specifies whether the client sends TCP keepalive messages with an octet of garbage data for compatibility with older implementations.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  39 |  1  | 0/1 |
   +-----+-----+-----+


Application layer options

The following table describes the DHCP options that affect operation of the application layer on a per-interface basis. These are miscellaneous options you can use to configure programs and services.

For these options, you can dynamically configure DHCP clients that have more than one interface on a per-interface basis using additional DHCP leases (one per interface) for any of these option types.

NIS domain name

Code | 40
Length | Length varies depending on data in value. Minimum length is 1 octet.
Value | ASCII character text.
Description | Specifies the Network Information Service (NIS) domain name as an ASCII string.
Structure

    Code   Len      NIS domain name
   +-----+-----+-----+-----+-----+-----+---
   |  40 |  n  |  n1 |  n2 |  n3 |  n4 | ...
   +-----+-----+-----+-----+-----+-----+---

NIS servers

Code | 41
Length | Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server address listed.
Value | Signed 32-bit integer representing IP address of NIS server.
Description | Lists the IP addresses in the order of preference for Network Information Service (NIS) servers available to the client.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  41 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

NTP servers

Code | 42
Length | Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server address listed.
Value | Signed 32-bit integer representing IP address of NTP server.
Description | Lists the IP addresses in the order of preference for Network Time Protocol (NTP) servers available to the client.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  42 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

X Window System font servers

Code | 48
Length | Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server address listed.
Value | Signed 32-bit integer representing each server IP address.
Description | Lists the IP addresses in the order of preference for X Window System font servers available to the client.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  48 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

X Window System display manager servers

Code | 49
Length | Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server address listed.
Value | Signed 32-bit integer representing each server IP address
Description | Lists the IP addresses in the order of preference for X Window System display manager servers available to the client.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  49 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

NIS+ domain name

Code | 64
Length | Length varies depending on data in value. Minimum length is 1 octet.
Value | ASCII character text.
Description | Specifies the name of the Network Information Service Plus (NIS+) domain name of the client as an ASCII string.
Structure

    Code   Len      NIS+ domain name
   +-----+-----+-----+-----+-----+-----+---
   |  64 |  n  |  n1 |  n2 |  n3 |  n4 | ...
   +-----+-----+-----+-----+-----+-----+---

NIS+ servers

Code | 65
Length | Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server address listed.
Value | Signed 32-bit integer representing IP address of NTP servers.
Description | Lists the IP addresses in the order of preference for Network Information Service Plus (NIS+) servers available to the client.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  65 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Mobile IP home agents

Code | 68
Length | Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each mobile IP home agent address listed.
Value | Signed 32-bit integer representing IP address of a mobile IP home agent.
Description | Lists the IP addresses in the order of preference for mobile IP home agents available to the client.
Structure

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   |  68 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--


NetBIOS over TCP/IP options

The following option types are used for NetBIOS over TCP/IP support. All Microsoft-based DHCP clients and DHCP servers can recognize and support the use of these option types.

WINS server

Code: 44
Length: Variable, minimum length is 4 octets. Length can be increased only by multiples of 4 for each address listed.
Value: Each 4 octets in this field contain a listed WINS server IP address, specified as an unsigned 32-bit integer.
Description: Lists the IP addresses for Windows Internet Name Service (WINS) servers or NetBIOS name servers (NBNS).
Structure:

    Code   Len           Address 1              Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
   |  44 |  n  |  a1 |  a2 |  a3 |  a4 |  b1 |  b2 |  b3 |  b4 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----

NetBIOS datagram distribution (NBDD) server

Code: 45
Length: Variable, minimum length is 4 octets. Length can be increased only by multiples of 4.
Value: Each 4 octets in this field contain a listed NBDD server IP address, specified as an unsigned 32-bit integer.
Description: Lists the IP addresses for NetBIOS datagram distribution (NBDD) servers.
Structure:

    Code   Len           Address 1              Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
   |  45 |  n  |  a1 |  a2 |  a3 |  a4 |  b1 |  b2 |  b3 |  b4 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----

NetBIOS node type

Code: 46
Length: Fixed, 1 octet.
Value: 1=b-node, 2=p-node, 4=m-node, and 8=h-node.
Description: Configures the client node type for NetBIOS over TCP/IP (NetBT) clients, as described in RFC 1001/1002. On multihomed computers, the node type is assigned for the computer, not to individual network adapters.
Structure:

    Code   Len  Node type
   +-----+-----+-----------+
   |  46 |  1  | see above |
   +-----+-----+-----------+

NetBIOS scope ID

Code: 47
Length: Variable, octet length is equal to the number of characters used in NetBIOS scope ID.
Value: Specifies the NetBIOS over TCP/IP scope identifier used by the client. The format used for these scope IDs is further described in RFCs 1001/1002. See the RFCs for character-set restrictions.
Description: Specifies a string that is the NetBIOS over TCP/IP scope ID for the client, as specified in RFC 1001/1002. On multihomed computers, the node type is assigned for the computer, not to individual network adapters.
Structure:

    Code   Len       NetBIOS scope
   +-----+-----+-----+-----+-----+-----+----
   |  47 |  n  |  s1 |  s2 |  s3 |  s4 | ...
   +-----+-----+-----+-----+-----+-----+----


Advanced and new options

The following topics provide descriptions of advanced and recent options available for use with Windows 2000 DHCP service. Some new advancements include class-related options and the support for options classes which are recent additions to the DHCP standard.

For recently added options, the DHCP console includes some additional pre-defined option types that are defined according to the updated DHCP options standard reference: RFC 2132, "DHCP Options and BOOTP Vendor Extensions". For more information, see DHCP RFCs.

  • Vendor specific options
  • User class options
  • DHCP extensions
  • Recently added options (RFC 2132)


Vendor specific options

This section describes reserved DHCP option types for assigning vendor-specific information and vendor class use, as specified in RFC 2132. Vendor classes can be added and used by the DHCP Server service to classify supporting vendor-specific DHCP clients that identify themselves using a common vendor class ID when they use DHCP service on your network.

In addition, the DHCP console provides a single default vendor class, the DHCP Standard options class, that can be used to group and classify clients that do not identify a vendor class to the DHCP service.

Vendor specific information

Code: 43
Length: Variable, minimum length of 1 octet.
Value: An opaque object of n octets (where n is equal to the length specified with this option). The definition of values stored for this option type are vendor specific, and values provided here are presumed to be interpreted by a vendor-specific code on DHCP clients and the DHCP server.
Description: This option is used by clients and servers to exchange vendor-specific information. Servers that are not equipped to interpret the information ignore it. Clients that expect but do not receive the information attempt to operate without it.

In some cases, a vendor uses this option type to send more than one information item, in which case, this option can serve as a subfield for encapsulating vendor-specific options. When encapsulating options, DHCP servers maintain the same syntax (that is, the same code, length, and value fields sequence) for each encapsulated option type as it would normally appear in the full standard options field, with the following exceptions for the encapsulated vendor-specific subfield:

  1. "Magic cookies" cannot be used.
  2. All standard option codes—other than the padding option (0) or the end option (255) may be redefined.
  3. If present, the end option (255) signifies the end of the encapsulated vendor options, but not the end of the encapsulated vendor-specific subfield. If no end option is present, the end for the encapsulated vendor-specific subfield is taken from its stated length.
Structure:

   Code   Len   Vendor-specific information
   +-----+-----+-----+-----+---
   |  43 |  n  |  i1 |  i2 | ...
   +-----+-----+-----+-----+---
When this option type uses an encapsulated vendor-specific subfield, the information bytes 1-n have the following format:

    Code   Len   Data item        Code   Len   Data item       Code
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  T1 |  n  |  d1 |  d2 | ... |  T2 |  n  |  D1 |  D2 | ... | ... |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

Vendor class identifier

Code: 60
Length: Minimum of 1 octet. Length varies according to n (that is, the number of octets used as an identifier).
Value: A value of n octets interpreted by DHCP servers that can support vendor classification of clients.
Description: Can be used by DHCP clients to identify their vendor type and configuration. When using this option, vendors can define their own specific identifier values, such as to convey a particular hardware or operating system configuration or other identifying information.

For Windows 2000, all computers that function as either DHCP servers or clients can use and support this option type. Where vendor classes are used, the DHCP server responds to identifying clients using option code 43 (described above), the reserved option type for returning vendor-specific information to the client.

DHCP servers that do not interpret this option type are expected to ignore it when it is specified by clients. For earlier Windows-based clients and other clients that do not support this option type, the DHCP service classifies these clients as part of the default vendor class, the DHCP Standard options class that is predefined for Microsoft-based DHCP servers.
Structure:

   Code   Len   Vendor class identifier
   +-----+-----+-----+-----+---
   |  60 |  n  |  i1 |  i2 | ...
   +-----+-----+-----+-----+---


User class options

This section describes the User Class option for supporting user classes in DHCP. This option is described in the proposed Internet RFC draft, "The User Class Option for DHCP", currently under review for possible approval as an Internet TCP/IP standard by the Internet Engineering Task Force (IETF).

User class information

Code: 77
Length: Variable, minimum is 2 octets.
Value: ASCII character text.
Description: A DHCP client can use this option to identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that represents the user class of which the client is a member.

You can use the DHCP console to define specific user classes. When user classes are created, each class sets an identifying string of information to be used by the DHCP Server service to classify identifying clients. Also, default user classes can be created for classifying clients that are unable to support a user class ID.

User classes can be helpful in separating client computers that have a shared or common need for similar software configuration or user preferences. For example, an identifier can specify that a particular DHCP client is a member of the class "accounting auditors," which have special service needs, such as a particular database server.

For Microsoft DHCP clients, only computers running under Windows 2000 support sending or use of this option type. Other legacy DHCP clients do not send a class ID or have the ability to recognize a user class. Therefore, these clients are assigned as members to the Default user class, which is a user class predefined for immediate use in the DHCP console. Other user classes must be manually created.
Structure:

    Code   Len      User class information
   +-----+-----+-----+-----+-----+-----+---
   |  77 |  n  |  c1 |  c2 |  c3 |  c4 | ...
   +-----+-----+-----+-----+-----+-----+---


DHCP extensions

The following option types are specific to DHCP and used to implement default protocol interaction and system behavior between servers and clients. Some of these options are implicitly set when you configure server and scope properties at the DHCP console.

Requested IP address

Code: 50
Length: Fixed, 4 octets.
Value: Single signed 32-bit integer indicating a requested IP address.
Description: Can be used by clients when sending a DHCP discovery message to request that a specific IP address be assigned by the server.
Structure:

    Code   Len   Requested IP address
   +-----+-----+-----+-----+-----+-----+
   |  50 |  n  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

IP address lease time

Code: 51
Length: Fixed, 4 octets.
Value: single signed 32-bit integer representing a client lease time in seconds.
Description: This option type is used to negotiate and exchange lease-time information between DHCP clients and servers in either of two ways:
  • Can be used in a DHCP discovery or DHCP request message sent by a client to request a lease time for its IP address.
  • Can be used in a DHCP offer message server reply sent by a server to specify a lease time the server can offer to the client.
Structure:

    Code   Len         Lease time
   +-----+-----+-----+-----+-----+-----+
   |  51 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

Option overload

Code: 52
Length: Fixed, 1 octet.
Value: predefined, accepted values for this option type include:
1='file' field is overloaded.
2='sname' field is overloaded.
3=both 'file' and 'sname' fields are overloaded.
Description: Used in messages sent by the DHCP server to indicate that either of the standard message fields in a DHCP packet for SERVER HOST NAME ('sname') and BOOT FILE NAME ('file') are to be overloaded (used to hold options).

Where this option is used, it extends the options area in each packet by indicating that unused space for one or both of these two standard fields should be allocated to the area used to carry DHCP options.
Structure:

    Code   Len  Value
   +-----+-----+-----+
   |  52 |  1  |1/2/3|
   +-----+-----+-----+

DHCP message type

Code: 53
Length: Fixed, 1 octet.
Value: Predefined, accepted values for this option type are:
1 = DHCP discovery message (DHCPDISCOVER).
2 = DHCP offer message (DHCPOFFER).
3 = DHCP request message (DHCPREQUEST).
4 = DHCP decline message (DHCPDECLINE).
5 = DHCP positive acknowledgment message (DHCPACK).
6 = DHCP negative acknowledgment message (DHCPNAK).
7 = DHCP release message (DHCPRELEASE).
8 = DHCP informational message (DHCPINFORM).
Description: This option is required for use in all DHCP messages to convey the type of message.
Structure:

    Code   Len  Type
   +-----+-----+-----+
   |  53 |  1  | 1-8 |
   +-----+-----+-----+

Server identifier

Code: 54
Length: Fixed, 4 octets.
Value: A single signed 32-bit IP address that identifies the DHCP server.
Description: This option is used in DHCP offer and DHCP request messages and sometimes appears in DHCP acknowledgment messages (that is DHCPACK, DHCPNAK). The server identifier is the IP address of a selected DHCP server. This option type is used in two possible ways:
  • Servers include this option type in DHCP lease offer messages so that clients can distinguish between multiple lease offers.
  • In turn, clients include this option type in DHCP lease request messages to select a lease and indicate between multiple lease offers, which offer is being accepted. Also, clients can use the contents of this field for unicast sending of request messages to specific DHCP servers to renew a current lease.
Structure:

    Code   Len            Address
   +-----+-----+-----+-----+-----+-----+
   |  54 |  4  |  a1 |  a2 |  a3 |  a4 |
   +-----+-----+-----+-----+-----+-----+

Parameter request list

Code: 55
Length: Minimum of 1 octet. Length increases by 1 octet for each additional option code included in the request list.
Value: List of 8-bit values each representing an option type code between 0 and 255.
Description: Used by a DHCP client to request specific option type values from the DHCP server. Each option type is requested and listed by a single octet value containing a valid or recognized DHCP option code for the server.

For clients that use this option type, the list may be ordered by preference, although the DHCP server is not required to return options in the order they are requested. However, the DHCP server attempts to insert the requested options in the order requested by the client.
Structure:

    Code   Len   Option codes
   +-----+-----+-----+-----+---
   |  55 |  n  |  c1 |  c2 | ...
   +-----+-----+-----+-----+---

Optional message

Code: 56
Length: Minimum of 1 octet. Length depends on the length of the sent message.
Value: ASCII character text.
Description: Can be used by both the DHCP server and DHCP clients in the following ways:
  • Servers can use this option type to provide and embed an error message in a DHCP negative acknowledgment message in the event of a failure.
  • Clients can use this option type in a DHCP decline message to indicate why it declined offered parameters.
The message consists of a variable length ASCII text string, which the receiving computer can then either log or display.
Structure:

    Code   Len     Text
   +-----+-----+-----+-----+---
   |  56 |  n  |  c1 |  c2 | ...
   +-----+-----+-----+-----+---

Maximum message size

Code: 57
Length: Fixed, 2 octets.
Value: A 16-bit integer indicating the maximum size in bytes/octets for a DHCP message packet. The maximum legal value for this option type is 576.
Description: Used by the client to specify the maximum length for a DHCP message packet that it can accept. A client can include this option type in DHCP discovery or DHCP request messages, however, it does not include this option type in DHCP decline messages.
Structure:

    Code   Len     Length
   +-----+-----+-----+-----+
   |  57 |  2  |  l1 |  l2 |
   +-----+-----+-----+-----+

Lease renewal time

Code: 58
Length: Fixed, 4 octets.
Value: A 32-bit unsigned integer indicating the number of seconds before the client begins to renew its address lease with the DHCP server.
Description: This time is a function typically 50% of the full configured duration (or lease time) for a client lease. To adjust this timer, you should change the length of the client lease in the properties for the client scope on the DHCP server.
Structure:

    Code   Len         T1 interval
   +-----+-----+-----+-----+-----+-----+
   |  58 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

Lease rebinding time

Code: 59
Length: Fixed, 4 octets.
Value: A 32-bit unsigned integer indicating the number of seconds before the client enters the rebinding state if it has not renewed its current address lease with the DHCP server.
Description: This time is a function (typically, 87.5%) of the full configured duration (or lease time) for a client lease. To adjust this timer you should change the length of client lease in the properties for the client scope on the DHCP server.
Structure:

    Code   Len         T2 interval
   +-----+-----+-----+-----+-----+-----+
   |  59 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+

Client unique identifier

Code: 61
Length: Variable length, minimum length is 2 octets.
Value: A series of 2 or more octets that is treated as an opaque object by the DHCP server. Servers can interpret and use this value to uniquely identify clients.
Description: Used by clients to specify their unique identifier to the server. This option type is most useful for reserved clients. When a reserved client contacts the DHCP server, it can check and match the client identifier value here to a corresponding identifier used to configure an address reservation in the server database. Where a matching reservation is found, the DHCP server returns the reserved address and its related parameters to the correct client. For this reason, the identifier of each client must be unique among all other client identifiers used on the effective DHCP network to which the client is attached (that is, the local subnet of the client and any remote subnets reachable by DHCP relay). Vendors and system administrators are responsible for choosing client identifiers that meet this requirement.

One common approach to ensuring uniqueness is to configure client reservations at the DHCP server based on the client Media Access Control (MAC) address as the client identifier value. MAC addresses are encoded in the network adapter hardware of each client and are assigned to hardware manufacturers in such a way as to ensure that they are unique for each device.
Structure:

   Code   Len   Type  Client-identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

TFTP server name

Code: 66
Length: Length varies depending on data in value. Minimum length is 1 octet.
Value: ASCII character text.
Description: In most other DHCP implementations, this option specifies the host name of the Trivial File Transfer Protocol (TFTP) server (the 'sname' field) in a DHCP message packet, when it is overloaded and used for carrying additional DHCP options.

In Windows-based DHCP server implementations, this option can be used to fill in the TFTP server IP address field, 'siaddr'--and not the 'sname' field, "sname"--in DHCP protocol messages. This option can also be configured as either an IP address or a fully-qualified domain name (FQDN). If an FQDN is used, the DHCP server will resolve the name to an IP address before including and sending the option to clients in DHCP offer messages and DHCP acknowledgment messages.

When this option is used for support of BOOTP clients, such as by adding and configuring entries in the BOOTP table at the DHCP server, the name or IP address of the TFTP server is used to provide the boot image file required to complete the second phase of the bootstrap process.
Structure:

       Code  Len   TFTP server
      +-----+-----+-----+-----+-----+---
      | 66  |  n  |  c1 |  c2 |  c3 | ...
      +-----+-----+-----+-----+-----+---

Boot file name

Code: 67
Length: Length varies depending on data in value. Minimum length is 1 octet.
Value: ASCII character text.
Description: Specifies the name of a boot image file on the TFTP server in the boot file name ('file') field of a DHCP message packet, when the message is overloaded and used for carrying additional DHCP options.

In Windows-based DHCP server implementations, this option can be used to fill in the boot file name ('file') field in DHCP offer messages. For this behavior, add and configure entries in the BOOTP table at the DHCP server. For more information, see Supporting BOOTP clients.

When this option is used for support of BOOTP clients, the boot image file must be located at a validly specified TFTP server for use in downloading the boot image file named here to complete the final phase of the BOOTP client initialization process. Microsoft does not provide TFTP servers.
Structure:

       Code  Len   Bootfile name
      +-----+-----+-----+-----+-----+---
      | 67  |  n  |  c1 |  c2 |  c3 | ...
      +-----+-----+-----+-----+-----+---

Client FQDN

Code: 81
Length: Variable, minimum of 4 octets.
Value: Specifies at least four (4) single-octet subfield values, which are always included:
  1. Length This field is standard for most DHCP options and is used to indicate the number of octets specifying the length of the data of this option within the large DHCP standard options field used, reserved for included use in protocol messaging. (1 octet)
  2. Flag This 1-octet field is used by the client to specify the way in which it requests its DNS records--host (A) and pointer (PTR) resource records(RRs)--to be updated. It can also be used by the DHCP server to indicate that it is overriding the request to update according to client request. Values: 0=client requests to update it own host (A) RR; 1=client requests that the DHCP server bear responsibility for updating its host (A) RR; 3=The DHCP server notifies the client it has assumed responsibility for updating the host (A) RR of the client. (1 octet)
  3. Result code fields (RCODE1, RCODE2) These two fields can be used by the DHCP server to indicate to the client responses related to any DNS dynamic updates it performed on behalf of the client. (2 octets)

If present, additional octets are used to store a text string value corresponding to the client fully-qualified domain name (FQDN). If null (not present), the client is either not configured with an FQDN or, did not specify one with this option.
Description: Used by supporting clients to indicate their FQDN to the server and to request the manner in which the server processes dynamic updates of client DNS name-to-address mappings. Also used by supporting DHCP servers to return response information back to the client, indicating whether the requested update policy was accepted. The server can also use this option to return response information about the result of any DNS updates it attempted to perform on behalf of the client.

This option is based on the Internet RFC draft, "Interaction between DHCP and DNS", under review by the IETF working group for DHCP.

For current information, you can find the latest draft at the Request for Comments Web site (http://www.rfc-editor.org/).
Structure:

   Code   Len    Flags  RCODE1 RCODE2   Client FQDN
   +------+------+------+------+------+------+--
   |  81  |   n  |      |      |      |       ...
   +------+------+------+------+------+------+--

Note


Recently added options (RFC 2132)

This section describes DHCP option types that are reserved and specified for use in RFC 2132, but are not pre-defined for use in DHCP Manager. These option types can be added to support other DHCP clients that recognize these options. For more information on adding these options types, see Manage options and classes.

Simple Mail Transport Protocol (SMTP) server

Code: 69
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for SMTP servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 69  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Post Office Protocol (POP3) server

Code: 70
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for POP3 servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 70  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Network News Transport Protocol (NNTP) server

Code: 71
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for NNTP servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 71  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Default World Wide Web (WWW) server

Code: 72
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for default Web servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 72  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Default Finger server

Code: 73
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for default Finger servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 73  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

Default Internet Relay Chat (IRC) server

Code: 74
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for default IRC servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 74  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

StreetTalk server

Code: 75
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for StreetTalk servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 75  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--

StreetTalk Directory Assistance (STDA) server

Code: 76
Length: Variable, minimum length is 4 octets. Octet length increases in multiples of 4 for each server IP address listed.
Value: Signed 32-bit integers representing IP addresses of servers.
Description: Lists the IP addresses in the order of preference for STDA servers available to the client.
Structure:

    Code   Len         Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+--
   | 76  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +-----+-----+-----+-----+-----+-----+-----+-----+--


Microsoft options

The following topics provide descriptions of all options and option classes that are predefined in Windows 2000 Server and provided by Microsoft as vendor-specific additions. These options and classes are only supported for Windows 2000 DHCP servers and clients.

  • Microsoft vendor-specific options
  • Microsoft vendor classes
  • Microsoft predefined user classes


Microsoft vendor-specific options

This section describes reserved DHCP option types defined by Microsoft for use. These options are only available for use with supporting Microsoft DHCP clients, such as computers running Windows 2000.

Disable NetBIOS over TCP/IP (NetBT)

Code: 1
Length: 1 octet, accepted values are either 0 or 1.
Value: 2=Disable NetBIOS over TCP/IP (NetBT) for Windows 2000 DHCP clients.
If any other value is specified, NetBT remains enabled.
Description: This option can be used to selectively enable or disable NetBT for DHCP-enabled computers running Windows 2000 only. By installation default, if this option is not present Windows 2000 enables the use of NetBT for network connections that are configured to use TCP/IP. Earlier Windows clients require NetBT and do not support this option.
Structure:

    Code     NetBT on/off
   +--------+--------+--
   |  001   |   n    |
   +--------+--------+--

Release DHCP lease on shutdown

Code: 2
Length: 1 octet, currently accepted values are 0-2.
Value: 0=Windows 2000 DHCP clients do not send a DHCP release message (DHCPRELEASE) on proper shutdown.
1=Windows 2000 DHCP clients send DHCP release (DHCPRELEASE) message on proper shutdown.
Description: This option can be used to control whether DHCP-enabled computers running Windows 2000 send a release for their current DHCP lease to the DHCP server when shutdown occurs. It is actually implemented and interpreted as a bit masked value by the DHCP Client service. In most cases, the default (that is, the functional equivalent to this option value not being used or present in DHCP messages) is that Windows 2000 clients do not send DHCP release messages on proper shutdown.
Structure:

    Code     Release on/off
   +--------+--------+--
   |  002   |    n   |
   +--------+--------+--

Default router metric base

Code: 3
Length: Variable.
Value: This value is a specified router metric base to be used for all default gateway routes used at Windows 2000 DHCP-enabled client computers.
Description: This option can be used to set the default base metric for Windows 2000 DHCP clients. When this option is set, the DHCP Client service uses the value configured here as the base metric for its default gateways.

This value can be assigned as an integer cost metric ranging from 1 through 9,999. It is used in calculating the fastest, most reliable, and least expensive routes. If a value is not specified, a default of either one (1) or the currently set interface-specific metric is used.
Structure:

    Code     Rt. metric
   +--------+--------+--
   |  003   |   n    |
   +--------+--------+--

Other Microsoft options supported

The following are other DHCP options that are not predefined but can be added to support features for other Microsoft released products.

Proxy autodiscovery (Internet Explorer 5 only)

Code: 252
Length: Variable, depending upon the length of the specified string.
Value: A URL that points to the configuration file that the client should use for automatic configuration of Internet Explorer 5. The file this URL points to can be a .pac, .jvs, .js, or .ins configuration file created by your system or Web administrator when deploying Internet Explorer 5 on your intranet. It might include settings for other Internet Explorer 5 configurable options, such as which home page to use, or settings for locating and using a proxy server.
Description: This option is used to set the location of the Internet Explorer 5 automatic configuration file.
Notes:

This option is communicated between Internet Explorer 5 client computers and the DHCP server using the DHCP information message (DHCPINFORM), which is currently only supported for Windows 2000 DHCP server and clients.

The use of additional DHCP configuration is only supported by Internet Explorer 5, not earlier versions that use different methods for automatic detection and configuration of proxy server settings.

You can also add and configure an alias (CNAME) resource record at the DNS server to support Internet Explorer 5 proxy server autodiscovery and configuration features. For more information, see Resource records reference: CNAME.

For further details, refer to the Internet Explorer 5 Resource Kit.

Note

  • These options are provided as encapsulated vendor-specific data fields within the Vendor specific information option.

    Currently, these options are only assignable in the DHCP console through the following vendor classes: Microsoft options and Microsoft Windows 2000 options. For more information, see Using option classes.


Microsoft vendor classes

For Windows 2000 Server, Microsoft has predefined several DHCP vendor classes for use when assigning DHCP options on the basis of identifying the vendor information, such as the version of Microsoft Windows that the DHCP client computer is running. Each of these classes is described in the following table.

Class name | Class data | Description
Microsoft Windows 2000 options | MSFT 5.0 | Used to classify all DHCP clients that are running Windows 2000. By default, each Windows 2000 DHCP client computer sends this as its vendor class. Options assigned for this class are only applied for Windows 2000 client computers and are not provided to clients running other versions of Windows or other operating systems.
Microsoft Windows 98 options | MSFT 98 | Used to classify all DHCP clients that are running Windows 98. By default, each Windows 98 DHCP client computer sends this as its vendor class. Options assigned for this class are only applied for Windows 98 client computers and are not provided to clients running other versions of Windows or other operating systems. Currently, vendor-specific options for Windows 98 are not defined.
Microsoft options | MSFT | Used to classify all DHCP clients that are running either Windows 98 or Windows 2000. By design, DHCP clients do not specifically identify themselves to this class, but the DHCP server can use this class to apply options for any of its clients identified as running these versions of Windows. Options assigned for this class are only applied for Windows 98 or Windows 2000 client computers and are not provided to clients running other versions of Windows or other operating systems.
DHCP standard options (Unspecified) This class is used to classify all other DHCP clients that are not running either Windows 98 or Windows 2000 or identified as members of another vendor class.

Note that for this class, options are not distributed using the reserved vendor subfield of option 43, the Vendor specific information. Instead, options in this class are communicated as part of the larger nonvendor-specific "options" field, which is always used in either of the following standard DHCP client/server messaging events:

  • When DHCP offer messages (DHCPOFFERs) are sent by servers.
  • When DHCP request messages (DHCPREQUESTs) are sent by clients.

Important

  • For computers running Windows 2000 DHCP Server service, you can create additional vendor classes at the DHCP server.

    When working with vendor classes, be sure that the class data used or set at the client matches identically the ASCII data value as it is set at the server for applicable vendor class. Also, character data used to identify the class is case sensitive and must be entered in matching case for both server and client configurations.

    For more information, see either To create a new user or vendor class or To set DHCP class ID information at a client computer.

  • For information about other DHCP vendor classes supported for other types of DHCP clients, refer to the applicable vendor-provided documentation.

Note

  • For more information, see Using option classes.


Microsoft predefined user classes

For Windows 2000 Server, Microsoft has predefined several DHCP user classes for use when assigning DHCP options to clients on the basis of identifying whether the client is a member of one of the specified user classes. Each of these classes is described in the following table.

Class name | Class data | Description
Default user class (unspecified) Used to classify clients that do not explicitly identify themselves as members of a user class defined at the DHCP server. By default, this options class is typically used where most DHCP clients are grouped and included. Clients are assigned to this class under the following conditions:
  1. DHCP clients that have no concept of a DHCP user class or a DHCP class ID. This is true for most legacy and older DHCP clients prior to Windows 2000.
  2. Windows 2000 clients configured with a DHCP class ID unknown to the DHCP server. For example, the user class that the client identifies itself for has not been defined at the DHCP server.
Default remote access class RRAS.Microsoft Used to classify clients making a PPP-type connection through a Routing and Remote Access server. Typically, this class includes most remote access clients that use DHCP to obtain a lease. Routing and Remote Access clients are assigned to this class under the following conditions:
  1. Routing and Remote Access clients that have no concept of this user class or its associated reserved class ID string ("RRAS.Microsoft"). Most remote access clients released prior to Windows 2000 fit this description.
  2. Windows 2000 clients that are operating as Routing and Remote Access clients.
Options assigned for distribution with this class are only in effect for Routing and Remote Access clients.
Default BOOTP class | BOOTP.Microsoft | Used to classify any clients recognized as BOOTP-type clients, including dynamic and non-dynamic (static) BOOTP clients. Options assigned for distribution with this class are only in effect for BOOTP clients.

Important

  • For computers running Windows 2000, you can create additional user classes at the DHCP server and set or show the DHCP class data used as matching ID strings at your DHCP clients.

    When working with user classes, be sure that the class data set at the client identically matches the ASCII data value as it is set at the server for applicable user class. Also, character data used to identify the class is case-sensitive and must be entered in matching case for both server and client configurations.

    For more information, see either To create a new user or vendor class or To set DHCP class ID information at a client computer.

Note

  • For more information, see Using option classes.


DHCP RFCs

Requests for Comments (RFCs) are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. Dynamic Host Configuration Protocol (DHCP) specifications are defined in RFCs published by the Internet Engineering Task Force (IETF) and other working groups.

The following RFCs specify the core DHCP standards:

  • RFC 2131: Dynamic Host Configuration Protocol (obsoletes RFC 1541)
  • RFC 2132: DHCP Options and BOOTP Vendor Extensions

The following RFCs might also be helpful for understanding how DHCP is used with other services on your network:

  • RFC 951: The Bootstrap Protocol (BOOTP)
  • RFC 1534: Interoperation Between DHCP and BOOTP
  • RFC 1542: Clarifications and Extensions for the Bootstrap Protocol
  • RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)
  • RFC 2241: DHCP Options for Novell Directory Services
  • RFC 2242: Netware/IP Domain Name and Information

Obtaining RFCs

You can obtain RFCs from the Request for Comments Web site. This Web site is currently maintained by members of the Information Sciences Institute (ISI) who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents.

Note

  • To see the most current RFCs related to DHCP, see the Active IETF Working Groups Web site.


DHCP database files

The DHCP server database in Windows 2000 Server uses the performance-enhanced Exchange Server storage engine. When you install DHCP service, the files shown in the following table are automatically created in the Winnt\System32\Dhcp directory.

DHCP service database files

File | Description
Dhcp.mdb | The DHCP server database file.
Dhcp.tmp | A temporary file used by the DHCP database as a swap file during database index maintenance operations. This file sometimes remains in the WINNT\System32\Dhcp directory after a system failure.
J50.log and J50#####.log | A log of all database transactions. This file is used by the DHCP database to recover data when necessary.
J50.chk | A checkpoint file.

Important

  • The J50.log file, J50#####.log file, Dhcp.mdb file, and Dhcp.tmp file should not be removed or altered.

The DHCP server database is a dynamic database that is updated as DHCP clients are assigned or as they release their TCP/IP configuration parameters. Because the DHCP database is not a distributed database like the WINS server database, maintaining the DHCP server database is less complex.

The DHCP database and related registry entries are automatically backed up at a specific interval (15 minutes by installation default). You can change this installation default by changing the value of BackupInterval in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer \Parameters.


Netshell commands for DHCP

The Netshell commands for DHCP offer a fully equivalent command-line helper tool, Dhcpmon.dll, for use in administering DHCP servers that can be used as an alternative to console-based management. This can be useful for the following situations:

  • When managing DHCP servers in wide area networks (WANs), commands can be used in interactive mode at the Netshell command prompt to better manage across slow-speed network links.
  • When managing a large number of DHCP servers, commands can be used in batch mode to help script and automate recurring administrative tasks that need to be performed for all DHCP servers.

The following tables list commands that can be used at the Netshell command prompt (which is not the same as the Windows 2000 command prompt) to manage DHCP servers. For more information on how to use Netshell commands provided for DHCP, see Use DHCP command-line tools.

For more information on Netshell, see The Netsh command-line utility.

Netshell commands for use with DHCP

The following Netshell commands are available for use in DHCP command-based server administration.

Command | Description
list | Lists all available DHCP commands.
dump | Dumps DHCP server configuration to command output or a text file.
? | Displays help.

Notes

  • The list command is available at all supported contexts within the DHCP command-line environment.
  • To redirect output of the dump command to a text file, do the following: type the command at a Windows command prompt and use the standard MS-DOS redirection operator (">").

    For example, you might type:

    netsh dump dhcp server > dhcpsrv.dmp

    to dump the current configuration for the local DHCP server on the same computer to a text file called Dhcpsrv.dmp. This file can then be copied to another new DHCP server and used to recreate the same configuration by using the exec subcommand to execute the dumped configuration as a command script.

    You could copy the file created by the previous command to a folder on the destination computer. You could then type the following command to load and execute the saved configuration for the new DHCP server installed there:

    netsh exec dhcpsrv.dmp

DHCP first-level commands

The following commands are available to be run from the dhcp>/? prompt within the Netshell command environment.

Command | Description
add server | Adds a DHCP server to the DHCP console. For more information, type add server /?
delete server | Deletes a DHCP server from the DHCP console. For more information, type delete server /?
show server | Displays all DHCP servers currently added under the DHCP console. For more information, type show server /?
server [name/address] | Shifts the current DHCP command-line context to the server specified by either its name or IP address. For more information, type help /?

DHCP server commands

The following commands are available to be run from the dhcp server>/? prompt which is rooted within the Netshell command environment.

Command | Description
add class | Adds a class to the currently specified DHCP server. For more information, type add class /?
add mscope | Adds a multicast scope to the currently specified DHCP server. For more information, type add mscope /?
add optiondef | Adds a new option type definition to the currently specified DHCP server. For more information, type add optiondef /?
add scope | Adds a new scope to the currently specified DHCP server. For more information, type add scope /?
delete class | Deletes a class from the currently specified DHCP server. For more information, type delete class /?
delete mscope | Deletes a multicast scope from the currently specified DHCP server. For more information, type delete mscope /?
delete optiondef | Deletes a new option type definition from the currently specified DHCP server. For more information, type delete optiondef /?
delete optionvalue | Deletes a new option type definition from the currently specified DHCP server. For more information, type delete optionvalue /?
delete scope | Deletes a new scope from the currently specified DHCP server. For more information, type delete scope /?
delete superscope | Deletes a new scope from the currently specified DHCP server. For more information, type delete superscope /?
initiate auth | Initiates or retries authorization of the currently specified DHCP server in Active Directory. For more information, type initiate auth /?
scope [scope_ip_address] | Switches the command context to DHCP scope specified by its IP network address, such as 169.254.1.0. For more information, see DHCP scope commands.
mscope [mscope_name] | Switches the command context to DHCP multicast scope specified by name (case-sensitive), such as 239.239.254.0. For more information, see DHCP multicast scope commands.
set auditlog | Sets the audit log path parameters for the currently specified DHCP server. For more information, type set auditlog /?
set backupinterval | Sets the backup interval of the currently specified DHCP server. For more information, type set backupinterval /?
set backupdatabasepath | Sets the database backup path to be used by the currently specified DHCP server. For more information, type set backupdatabasepath /?
set databasecleanupinterval | Sets the database cleanup interval of the currently specified DHCP server. For more information, type set databasecleanupinterval /?
set databaseloggingflag | Sets/resets database logging flag for the currently specified DHCP server. For more information, type set databaseloggingflag /?
set databasename | Sets the name of the DHCP server database file for the currently specified DHCP server. For more information, type set databasename /?
set databasepath | Sets the path of the DHCP server database file for the currently specified DHCP server. For more information, type set databasepath /?
set databaserestoreflag | Sets/resets the database restore flag for the currently specified DHCP server. For more information, type set databaserestoreflag /?
set detectconflictretry | Sets the number of conflict detection attempts made by the currently specified DHCP server. For more information, type set detectconflictretry /?
set dnsconfig | Sets the DNS dynamic update configuration for the currently specified DHCP server. For more information, type set dnsconfig /?
set optionvalue | Sets a server option value, which will be applied for all scopes defined at the currently specified server. For more information, type set optionvalue /?
set server | Sets the current server in the Server mode. For more information, type set server /?
set userclass | Sets the userclass name for use in subsequent command operations. For more information, type set userclass /?
set vendorclass | Sets the vendor class name for use in subsequent command operations. For more information, type set vendorclass /?
show all | Displays all information for the currently specified DHCP server. For more information, type show all /?
show auditlog | Displays audit log path parameters for the currently specified DHCP server. For more information, type show auditlog /?
show bindings | Displays bindings information for the currently specified DHCP server. For more information, type show bindings /?
show class | Displays all class information for the currently specified DHCP server. For more information, type show class /?
show detectconflictretry | Displays the number of conflict detection settings for the currently specified DHCP server. For more information, type show detectconflictretry /?
show dnsconfig | Displays the DNS dynamic update configuration for the currently specified DHCP server. For more information, type show dnsconfig /?
show mibinfo | Displays Management Information Base (MIB) information for the currently specified DHCP server. For more information, type show mibinfo /?
show mscope | Displays all information about multicast scopes for the currently specified DHCP server. For more information, type show mscope /?
show optiondef | Displays all defined and available options for the currently specified DHCP server. For more information, type show optiondef /?
show optionvalue | Displays all available option values currently set for the specified DHCP server. For more information, type show optionvalue /?
show scope | Displays all information about scopes for the currently specified DHCP server. For more information, type show scope /?
show server | Displays information about the currently specified DHCP server. For more information, type show server /?
show dbproperties | Displays server database configuration information for the currently specified DHCP server. For more information, type show dbproperties /?
show serverstatus | Displays status information for the currently specified DHCP server. For more information, type show serverstatus /?
show userclass | Displays the current user class setting at the specified DHCP server. For more information, type show userclass /?
show vendorclass | Displays the current vendor class setting at the specified DHCP server. For more information, type show vendorclass /?
show version | Displays current version information for the specified DHCP server. For more information, type show version /?

DHCP scope commands

The following commands are available to be run from the dhcp server scope>/?, which is rooted at the DHCP server context within the Netshell command environment.

Command | Description
add excluderange | Adds a range of excluded addresses to the current scope. For more information, type add excluderange /?
add iprange | Adds a range of IP addresses to the current scope. For more information, type add iprange /?
add reservedip | Reserves an IP address for use by a specified MAC address in the current scope. For more information, type add reservedip /?
delete excluderange | Deletes an exclusion range of previously excluded IP addresses in the current scope. For more information, type delete excluderange /?
delete iprange | Deletes a range of IP addresses from the current scope. For more information, type delete iprange /?
delete optionvalue | Removes or clears an assigned scope option value from the current scope. For more information, type delete optionvalue /?
delete reservedip | Deletes a reservation for an IP address in the current scope. For more information, type delete reservedip /?
delete reservedoptionvalue | Removes an option value assigned for a reserved client in the current scope. For more information, type delete reservedoptionvalue /?
initiate reconcile | Checks and reconciles the current scope. For more information, type initiate reconcile /?
set comment | Sets the comment for the current scope. For more information, type set comment /?
set name | Sets the name of the current scope. For more information, type set name /?
set optionvalue | Sets an option value for the current scope. For more information, type set optionvalue /?
set reservedoptionvalue | Sets the comments for the current scope. For more information, type set reservedoptionvalue /?
set scope | Sets the scope to be used in subsequent operations. For more information, type set scope /?
set state | Sets/resets the state of the current scope to either an active or inactive state. For more information, type set state /?
set superscope | Sets the superscope to be used in subsequent operations. For more information, type set superscope /?
show clients | Displays all available version 4 clients for the current scope. For more information, type show clients /?
show clientsv5 | Displays all available version 5 clients for the current scope. For more information, type show clientsv5 /?
show excluderange | Displays all currently excluded ranges of IP addresses for the current scope. For more information, type show excluderange /?
show iprange | Displays all available address ranges for the current scope. For more information, type show iprange /?
show optionvalue | Displays all option values that are set for the current scope. For more information, type show optionvalue /?
show reservedip | Displays all currently reserved IP addresses for the current scope. For more information, type show reservedip /?
show reservedoptionvalue | Displays all currently set option values for a reserved client IP address in the current scope. For more information, type show reservedoptionvalue /?
show scope | Displays information for the current scope. For more information, type show scope /?
show state | Displays the state of the current scope, indicating whether it is active or inactive. For more information, type show state /?

DHCP multicast scope commands

The following commands can be run from the dhcp server mscope>/? prompt, which is rooted at the DHCP server context within the Netshell command environment.

Command | Description
add excluderange | Adds a range of excluded addresses to the current multicast scope. For more information, type add excluderange /?
add iprange | Adds a range of IP addresses to the current multicast scope. For more information, type add iprange /?
delete excluderange | Deletes an exclusion range of previously excluded IP addresses in the current multicast scope. For more information, type delete excluderange /?
delete iprange | Deletes a range of IP addresses from the current multicast scope. For more information, type delete iprange /?
initiate reconcile | Checks and reconciles the current multicast scope. For more information, type initiate reconcile /?
set comment | Sets the comment for the current multicast scope. For more information, type set comment /?
set lease | Sets the lease duration for multicast scope IP addresses. For more information, type set lease /?
set mscope | Sets the multicast scope to be used in subsequent operations. For more information, type set mscope /?
set name | Sets the name of the current multicast scope. For more information, type set name /?
set state | Sets/resets the state of the current multicast scope to either an active or inactive state. For more information, type set state /?
set ttl | Sets the Time-To-Live (TTL) value for the current multicast scope. For more information, type set ttl /?
show clients | Displays all available clients for the current multicast scope. For more information, type show clients /?
show excluderange | Displays all currently excluded ranges of IP addresses for the current multicast scope. For more information, type show excluderange /?
show iprange | Displays all available IP address ranges for the current multicast scope. For more information, type show iprange /?
show lease | Displays the current lease duration settings for the multicast scope. For more information, type show lease /?
show mibinfo | Displays Management Information Base (MIB) information for the current multicast scope. For more information, type show mibinfo /?
show mscope | Displays information for the current multicast scope. For more information, type show mscope /?
show state | Displays the state of the current multicast scope, indicating whether it is active or inactive. For more information, type show state /?
show ttl | Displays the Time-To-Live (TTL) value for the current multicast scope. For more information, type show ttl /?

Note

  • When working within the DHCP command-line context and any of its subcontexts, you can type any of the following to list commands currently available for use: help/?, /?/?, -?/?, ?/?.


DHCP performance monitoring reference

For Windows 2000 Server, the DHCP Server service includes a set of performance counters that can be used to monitor various types of server activity. To access these counters, you must use System Monitor. For more information, see Using Performance.

By default, performance monitoring of DHCP servers is available for use after the DHCP service component is installed. DHCP performance is measured using the following metrics and counters:

Name | Description
Packets Received/sec | The number of message packets received per second by the DHCP server. A large number indicates heavy DHCP-related message traffic to the server.
Duplicates Dropped/sec | The number of duplicated packets per second dropped by the DHCP server. This number can be affected by multiple DHCP relay agents or network interfaces forwarding the same packet to the server. A large number here indicates that either clients are probably timing out too fast or the server is not responding fast enough.
Packets Expired/sec | The number of packets per second that expire and are dropped by the DHCP server. When a DHCP-related message packet is internally queued for 30 seconds or more, it is determined to be stale and expired by the server. A large number here indicates that the server is either taking too long to process some packets while other packets are queued and becoming stale, or traffic on the network is too high for the server to manage.
Milliseconds per packet (Avg.) | The average time in milliseconds used by the DHCP server to process each packet it receives. This number can vary depending on the server hardware and its I/O subsystem. A sudden or unusual increase might indicate a problem, either with the I/O subsystem becoming slower or because of an intrinsic processing overhead on the server computer.
Active Queue Length | The current length of the internal message queue of the DHCP server. This number equals the number of unprocessed messages received by the server. A large number might indicate heavy server traffic.
Conflict Check Queue Length | The current length of the conflict check queue for the DHCP server. This queue holds messages without responses while the DHCP server performs address conflict detection. A large value here might indicate that Conflict Detection Attempts has been set too high or that there is unusually heavy lease traffic at the server.
Discovers/sec | The number of DHCP discover messages (DHCPDISCOVERs) received per second by the server. These messages are sent by clients when they start on the network and obtain a new address lease. A sudden or unusual increase indicates a large number of clients are attempting to initialize and obtain an IP address lease from the server, such as when a number of client computers are started at any given time.
Offers/sec | The number of DHCP offer messages (DHCPOFFERs) sent per second by the DHCP server to clients. A sudden or unusual increase in this number indicates heavy traffic on the server.
Requests/sec | The number of DHCP request messages (DHCPREQUESTs) received per second by the DHCP server from clients. A sudden or unusual increase in this number indicates a large number of clients trying to renew their leases with the DHCP server. This might indicate that scope lease durations are too short.
Informs/sec | The number of DHCP inform messages (DHCPINFORMs) received per second by the DHCP server. DHCP inform messages are used when the DHCP server queries for the directory service for the enterprise root and when dynamic updates are being done on behalf of clients by the server.
Acks/sec | The number of DHCP acknowledgment messages (DHCPACKs) sent per second by the DHCP server to clients. A sudden or unusual increase in this number indicates that a large number of clients are being renewed by the DHCP server. This might indicate that scope lease durations are too short.
Nacks/sec | The number of DHCP negative acknowledgment messages (DHCPNAKs) sent per second by the DHCP server to clients. A very high value might indicate potential network trouble in the form of misconfiguration of either the server or clients. When servers are misconfigured, one possible cause is a deactivated scope. For clients, a very high value could be caused by computers moving between subnets, such as laptop portables or other mobile devices.
Declines/sec | The number of DHCP decline messages (DHCPDECLINEs) received per second by the DHCP server from clients. A high value indicates that several clients have found their address to be in conflict, possibly indicating network trouble. In this situation, it can help to enable conflict detection on the DHCP server. This should only be used temporarily. Once the situation returns to normal, it should be turned off.
Releases/sec | The number of DHCP release messages (DHCPRELEASEs) received per second by the DHCP server from clients. This number only exists if a DHCP client sends a release to the server. This can occur manually, such as when the ipconfig command is used at the client computer. Release messages can also be sent by the client if it is configured with the Release DHCP lease on shutdown option. Because clients rarely release their address, the value of this counter remains low for many DHCP network configurations.

Note

  • Values for the following registry key can be used by a member of the local Administrators group:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCPServer\Performance

    By changing values stored at this registry path location, you can deny or modify permissions that determine who can view System Monitor counters used for the DHCP server on the server computer. Values under this key are used by the System Monitor DLL (Perfctrs.dll) to identify each of the counters described.


DHCP updated technical information

Updated technical information for DHCP can be obtained by searching technical articles available from the Personal Support Center at the Microsoft Web site. For more information, see Updated technical information.

You can also obtain additional in-depth information on DHCP in the Windows 2000 Server Resource Kit. For more information, see Windows 2000 Resource Kit.


DHCP bibliography

For detailed technical information about using DHCP, refer to the following texts and articles:

Comer, D. Internetworking with TCP/IP, Volume I: Principles, Protocols, and Architecture. Third edition. Englewood Cliffs, NJ: Prentice Hall, 1995.

Hunt, C. and R.B. Thompson. Windows NT TCP/IP Network Administration. Sebastopol, CA: O'Reilly and Associates, 1998.

Microsoft Corporation. Managing a Microsoft Windows NT Network. Redmond, WA: Microsoft Press, 1999.

Microsoft Corporation. Optimizing Network Traffic. Redmond, WA: Microsoft Press, 1999.

Minasi, M., Lammle, T. and M. Lammle. Mastering TCP/IP For NT Server Alameda, CA: Sybex, 1997.

Parker, T. TCP/IP Unleashed. Indianapolis, IN: Sams Publishing, 1996.

Stevens, W.R. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA: Addison-Wesley, 1994.


Troubleshooting

  • Troubleshooting DHCP clients
  • Troubleshooting DHCP servers


Troubleshooting DHCP clients

What problem are you having?

The DHCP client does not have an IP address configured or indicates that its IP address is 0.0.0.0.

Cause: The client was not able to contact a DHCP server and obtain an IP address lease, either because of a network hardware failure or because the DHCP server is unavailable.

Solution: Verify that the client computer has a valid functioning network connection. First, check that related client hardware (cables and network adapters) are working properly at the client using basic network and hardware troubleshooting steps.

If the client hardware appears to be prepared and functioning properly, check that the DHCP server is available on the network by pinging it from another computer on the same network as the affected DHCP client.

See also: Hardware Troubleshooter; Networking (TCP/IP) Troubleshooter

The DHCP client appears to have automatically assigned itself an IP address that is incorrect for the current network.

Cause: The Windows 2000 or Windows 98 DHCP client could not find a DHCP server and has used the Automatic Private IP Addressing (APIPA) feature to configure its IP address.

In some larger networks, disabling APIPA might be desirable for network administration.

Solution: First, use the ping command to test connectivity from the client to the server. Your next step would be to either verify or manually attempt to renew the client lease. Depending on your network requirements, it might be necessary to disable APIPA at the client. You can learn more about APIPA and how it works prior to making this decision.

See also: To test a TCP/IP configuration by using the ping command; To verify, release, or renew a client address lease; Automatic client configuration; To configure TCP/IP for automatic addressing; To disable automatic address configuration

The DHCP client appears to be missing some network configuration details or is unable to perform related tasks, such as resolving names.

Cause: The client might be missing DHCP options in its leased configuration, either because the DHCP server is not configured to distribute them or the client does not support the options distributed by the server.

Solution: For Microsoft DHCP clients, verify that the most commonly used and supported options have been configured at the server, scope, client, or class level of options assignment.

See also: Manage options and classes; Assigning options; Microsoft DHCP clients; Supporting DHCP clients.

The DHCP client appears to have incorrect or incomplete options, such as an incorrect or missing router (default gateway) configured for the subnet on which it is located.

Cause: The client has the full and correct set of DHCP options assigned but its network configuration does not appear to be working correctly.

If the DHCP server is configured with an incorrect DHCP router option (option code 3) for the default gateway address of the client, clients running Windows NT or Windows 2000 do not use the incorrect address. However, DHCP clients running Windows 95 do use the incorrect address.

Solution: Change the IP address list for the router (default gateway) option at the applicable DHCP scope and server. If you are configuring the router option as a Server Option at the affected DHCP server, remove it there and set the correct value in the Scope Options node for the applicable DHCP scope that services the client.

In rare instances, you might have to configure the DHCP client to use a specialized list of routers different from other scope clients. In such cases, you can add a reservation and configure the router option list specifically for the reserved client.

See also: To assign a server-based option; To assign a scope-based option; To assign an option to a reserved client; To add a client reservation; Assigning options; Basic options (RFC 1497): Router.

Many DHCP clients are unable to get IP addresses from the DHCP server.

Cause: The IP address of the DHCP server was changed and now DHCP clients cannot get IP addresses.

Solution: A DHCP server can only service requests for a scope that has a network ID that is the same as the network ID of its IP address.

Make sure that the DHCP server IP address falls in the same network range as the scope it is servicing. For example, a server with an IP address in the 192.168.0.0 network cannot assign addresses from scope 10.0.0.0 unless superscopes are used.

See also: Best practices; Using superscopes; Configuring scopes.

Cause: The DHCP clients are located across a router from the subnet where the DHCP server resides and are unable to receive an address from the server.

Solution: A DHCP server can provide IP addresses to client computers on remote multiple subnets only if the router that separates them can act as a DHCP relay agent.

Completing the following steps might correct this problem:

  1. Configure a BOOTP/DHCP Relay Agent on the client subnet (that is, the same physical network segment). The relay agent can be located on the router itself or on a Windows NT Server computer running the DHCP Relay service component.
  2. At the DHCP server, do the following:
    1. Configure a scope to match the network address on the other side of the router where the affected clients are located.
    2. In the scope, make sure that the subnet mask is correct for the remote subnet.
    3. Use a default gateway on the network connection of the DHCP server in such a way that it is not using the same IP address as the router that supports the remote subnet where the clients are located.
    4. Do not include this scope (that is, the one for the remote subnet) in superscopes configured for use on the same local subnet or segment where the DHCP server resides.
  3. Make sure there is only one logical route between the DHCP server and the remote subnet clients.

See also: Best practices; DHCP/BOOTP relay agents; BOOTP and DHCP; Supporting clients.

Cause: Multiple DHCP servers exist on the same local area network (LAN).

Solution: Make sure that you do not configure multiple DHCP servers on the same LAN with overlapping scopes.

You might want to rule out the possibility that one of the DHCP servers in question is a Small Business Server (SBS) computer. By design, the DHCP Server service, when running under SBS, automatically stops when it detects another DHCP server on the LAN.

See also: Best practices; Configuring scopes.

The DHCP client appears to be affected by another problem not described above.

Cause: My problem is not described above.

Solution: Search the Microsoft Web site for updated technical information that might relate to the problem you have observed. If necessary, you can obtain information and instructions that pertain to your current problem or issue.

If you are connected to the Internet, the latest updates for Windows 2000 Server are available at the Microsoft Web site (http://www.microsoft.com/).

For obtaining the latest Service Pack updates for Windows NT Server, see the Microsoft Web site (http://www.microsoft.com/).

Familiarize yourself with other useful documentation and resources for DHCP, such as the DHCP Troubleshooter.

See also: DHCP updated technical information, DHCP, Windows 2000 Resource Kit, Microsoft Web site (http://www.microsoft.com/).


Troubleshooting DHCP servers

What problem are you having?

The DHCP server is stopped.

Cause: The DHCP server has not been authorized to operate on the network.

Solution: Authorize the DHCP server in the enterprise where it is being used.

See also: Authorizing DHCP servers; To authorize a DHCP server in Active Directory; To delegate ability to authorize servers to a non-enterprise administrator.

Cause: Configuration details might be incorrect or missing at the server.

Solution: If you have just completed setting up or administering the DHCP server, you might want to review the provided checklist to see if you have missed a crucial step in the installation process.

To help prevent the most common types of problems, review DHCP best practices for tips on deploying and managing your servers.

Because many DHCP failures are first detected as client-side errors, you might want to start by investigating the problem there.

See also: Checklist: Installing a DHCP server; Best practices; Troubleshooting DHCP clients.

Cause: The DHCP server has been stopped.

Solution: Check the system event log and DHCP server audit log files for details.

When the DHCP Server service either stops or cannot start, useful explanatory information about the source of the service failure or shutdown can generally be found in these logs.

See also: Audit logging; Analyzing server log files; Using Event Viewer; To search for specific events

The DHCP server is unable to provide service to clients.

Cause: The server is a multihomed computer and is not providing service on one or more of its network connections.

Solution: Review Windows 2000 DHCP server binding defaults for network connections based on whether you have elected to either statically or dynamically configure TCP/IP for any or all installed connections on the server computer. Also, review an example of multihomed DHCP server configuration to see if you have missed any critical details.

See also: Multihomed DHCP servers; To selectively set DHCP server bindings for network connections.

Cause: Scopes or superscopes on the DHCP server have not been either configured or activated for use.

Solution: Add scopes and make sure that they are correctly configured along with any DHCP scope options that need to be assigned for client use.

See also: Configuring scopes; To create a new scope; To assign a scope-based option.

Cause: The server is located on a different subnet as some of its clients and is not providing service to clients on remote subnets.

Solution: If you are using a DHCP server in a routed network, you might want to review issues related to DHCP relay agents and the appropriate use of superscopes.

See also: DHCP/BOOTP relay agents; Using superscopes; To create a superscope.

Cause: The scope in use is full and can no longer lease addresses to requesting clients.

Solution: If the DHCP server does not have IP addresses available to provide to its clients, it returns DHCP negative acknowledgment messages (DHCPNAKs) to them. When this occurs, consider the following possible solutions:

  1. Expand the address range by increasing the End IP address for the current scope.
  2. Create a new additional scope and a superscope, then add the current scope and the new scope to the superscope.
  3. Create a new scope or extend the range. Optimally, you could renumber your current IP network. Deactivate the old scope as needed, and then configure and activate the new one.
  4. Reduce the lease duration. This can help to expedite the reclaiming of lapsed scope addresses.

Other DHCP-related procedures and techniques might also help to accelerate or ease the transition from an existing scope being retired to a new scope created to take its place at the server. These include deleting client leases from the scope being retired, excluding addresses from that scope, and then deactivating it once the new scope has been activated. This ensures that the DHCP client obtains leasing from the new scope.

See also: Managing leases; Removing scopes; To delete a client lease; To exclude an address from a scope; To activate a scope; To deactivate a scope.

Cause: The range of IP addresses being offered by the DHCP server is in conflict with the range of addresses being offered by another DHCP server on the network.

You can confirm that this is the likely cause if DHCP server logs still indicate that DHCP negative acknowledgment messages (DHCPNAKs) are being returned to requesting clients or if you have tried unsuccessfully at the client to renew its lease manually.

Solution: Modify the scope address pool for the scopes at each DHCP server to ensure that scope IP addresses do not overlap. You can add exclusions to the scopes as necessary, delete client leases, and temporarily enable server-side conflict detection to assist in solving the problem.

See also: To delete a client lease; To exclude an address from a scope; To enable address conflict detection; Best practices.

The DHCP server appears to have suffered some data corruption or loss.

Cause: The DHCP server database has become corrupted or is missing server data, possibly reporting Jet database errors.

Solution: Use DHCP server data recovery options to restore the database and correct any of the reported errors. You can also use the Reconcile feature in the DHCP console to verify and reconcile any database inconsistencies that the server is able to find.

See also: Restoring server data; DHCP database files; Reconciling scopes; To reconcile the DHCP database; To reconcile a scope.

The server appears to be affected by another problem not described above.

Cause: My problem is not described above.

Solution: Search the Microsoft Web site for updated technical information that might relate to the problem you have observed. You can obtain information and instructions that pertain to your current problem or issue.

If you have connection to the Internet, the latest updates for Windows 2000 Server are available at the Microsoft Web site (http://www.microsoft.com/).

For obtaining the latest Service Pack updates for Windows NT Server, see the Microsoft Web site (http://www.microsoft.com/).

Familiarize yourself with other useful documentation and resources for DHCP, such as the DHCP Troubleshooter.

See also: DHCP updated technical information, DHCP, Windows 2000 Resource Kit, Microsoft Web site (http://www.microsoft.com/).