DHCP TROUBLESHOOTING

what are the problem are you having?

The DHCP server has 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.
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.
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.

Cause:The server is a multihomed computer and is not providing service on one or more of its network connections.
Solution: Review Windows Server 2003 DHCP 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.
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.

Cause:The DHCP server is not authorized in Active Directory.
Solution: If the DHCP server is a domain member, authorize the server in Active Directory. In some circumstances you might accidentally have a standalone server and a domain member server on the same subnet. When the standalone server detects the domain member server, it attempts to verify that it is authorized in Active Directory. Even if a domain controller resides on the same subnet as the standalone DHCP server, the DHCP server cannot verify its status with the domain controller because the DHCP server is not a domain member. When the standalone server is unable to access a domain controller to discover whether it is authorized, it stops servicing clients and displays the red icon in the DHCP console that indicates the server is unauthorized. If you want the standalone server to service clients on the subnet, remove the authorized DHCP server from the subnet.

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.

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 members of the Windows Server 2003 family are available at the Microsoft Web site.

The DHCP Relay Agent service provided with Multi-Protocol Routing (MPR) does not provide a TCP/IP address from a remote DHCP server

The DHCP Relay Agent service is running on the same computer as the DHCP service. Because both services listen for and respond to BOOTP and DHCP messages sent using UDP ports 67 and 68, neither service works reliably if both are installed on the same computer.

Install the DHCP service and the DHCP Relay Agent component on separate computers.

When the DHCP console displays the lease expiration time for reserved clients for a scope, it indicates one of the following:

If the scope lease time is set to an infinite lease time, the reserved client's lease is also shown as infinite.
If the scope lease time is set to a finite length of time (such as eight days), the reserved client's lease uses this same lease time.

The lease term of a DHCP reserved client is determined by the lease assigned to the reservation.
To create reserved clients with unlimited lease durations, create a scope with an unlimited lease duration and add reservations to that scope.
DHCP server uses broadcast to respond to all client messages

The DHCP server uses broadcast to respond to all client configuration request messages, regardless of how each DHCP client has set the broadcast bit flag. DHCP clients can set the broadcast flag (the first bit in the 16-bit flags field in the DHCP message header) when sending DHCPDiscover messages to indicate to the DHCP server that broadcast to the limited broadcast address (255.255.255.255) should be used when replying to the client with a DHCPOffer response.

A new scope has been added at the DHCP server for the purposes of renumbering the existing network. However, DHCP clients do not obtain leases from the newly defined scope. This situation is most common when you are attempting to renumber an existing IP network.
For example, you might have obtained a registered class of IP addresses for your network or you might be changing the address class to accommodate more computers or networks. In these situations, you want clients to obtain leases in the new scope instead of using the old scope to obtain or renew their leases. Once all clients are actively obtaining lease in the new scope, you intend to remove the existing scope.
When superscopes are not available or used, only a single DHCP scope can be active on the network at one time. If more than one scope is defined and activated on the DHCP server, only one scope is used to provide leases to clients.
The active scope used for distributing leases is determined by whether the scope range of addresses contains the first IP address that is bound and assigned to the DHCP server's network adapter hardware. When additional secondary IP addresses are configured on a server using the Advanced TCP/IP Properties tab, these addresses have no effect on the DHCP server in determining scope selection or responding to configuration requests from DHCP clients on the network.

This problem can be solved in the following ways:

Configure the DHCP server to use a superscope that includes the old scope and the new scope. If you cannot change the primary IP address assigned on the DHCP server's network adapter card, use superscopes to effect scope migration for DHCP clients on your network. Superscope support was added for Windows NT Server 4.0 with Service Pack 2 and is available for Windows 2000 Server. Superscopes provide ease and assistance in migrating DHCP scope clients. To effectively migrate clients from an old scope to a new scope using a superscope:

1.Define the new scope.
2.Assign and configure options for the new scope.
3.Define a superscope and add the new scope and the old scope (that is, the scope that corresponds to the primary or first IP address assigned to the DHCP server on its TCP/IP Properties tab).
4.Activate the superscope.
5.Leave the original scope active and exclude all the addresses within that scope.

After renumbering in this manner using superscopes, the DHCP server, upon receiving a renewal request:

1.Checks to see if the client's IP address belongs to a scope it is aware of. Since the superscope includes the old scope, the server finds the scope and checks to see that this IP address has been marked as excluded.
2.The server checks if the client lease exists in its database. Since this server previously allocated the lease to this client, it sends a DHCPNack in response to the renewal request.
3.The client is forced to request a new address (the client broadcasts a DHCPDiscover message).
4.The server responds to the DHCPDiscover with a lease from the new scope. The second step in this process (when the server checks the existence of the lease in its database), is what differentiates a renumbering scenario from a using multiple servers on the same subnet:

If the server finds the lease in its database, it sends a DHCPNack to the renewal request.

If the server does not find the lease, it ignores the renewal request. For more information about using superscopes, see the section "Superscopes."

Troubleshooting a DHCP failure

Finding an address

DHCP failure prevention

back to top