In production environments, domain controllers are almost always configured with static IP addresses. However, in test and lab environments, it is sometimes desirable to allow a primary domain controller to obtain its IP address via DHCP, such as when running inside virtualized lab setups.

We will walk through a real troubleshooting scenario where a Windows Server domain controller appeared to have DHCP enabled, but continued to receive a 169.254.x.x APIPA address, causing network failures and misleading “The RPC server is unavailable” errors. We will explain why this happens and how to fix it using only the Windows GUI.

Environment Overview

• Windows Server 2025 Datacenter Edition
• Installed in VMware Workstation Pro
• Server promoted to Primary Domain Controller
• Networking provided via VMware NAT
• Intended for test lab use only

Symptoms

After promoting the server to a domain controller, the following symptoms were observed:

• No valid IPv4 address assigned
• APIPA address (169.254.x.x)
• No default gateway
• “The RPC server is unavailable” errors
• Event Viewer errors referencing DHCP Client and WinHTTP services
• ipconfig /all showing DHCP Enabled: No, even though DHCP was enabled in IPv4 properties

In this scenario, other virtual machines on the same VMware Workstation host continued to receive DHCP addresses without issue.

Why This Happens

When a Windows Server is promoted to a domain controller, Windows makes several assumptions that are appropriate for production environments but not always desirable in labs. One of those assumptions is that a domain controller should use a static IP address.

During domain controller promotion or after network stack changes, the DHCP Client service may become disabled, stopped, or fail to bind correctly to the network adapter. This can lead to a confusing state where:

• IPv4 is configured to obtain an address automatically
• The DHCP Client service is not actively requesting or applying DHCP leases
• The server silently falls back to APIPA
• Higher-level services such as RPC begin to fail as a downstream symptom

In many cases this is not a VMware networking issue and not a driver problem. It is a service state and binding issue inside the guest operating system.

Renable DHCP

This fix does not require any command line tools.

Step 1: Confirm IPv4 Is Set to DHCP

1. Open Network Connections.
2. Right-click the active Ethernet adapter and select Properties.
3. Double-click Internet Protocol Version 4 (TCP/IPv4).
4. Confirm the following settings are selected:

• Obtain an IP address automatically
• Obtain DNS server address automatically

If these options are already selected, leave them as-is and continue to the next step.

Step 2: Start and Enable the DHCP Client Service

1. Press Win + R.
2. Type services.msc and press Enter.
3. Locate DHCP Client.
4. Double-click it to open its properties.
5. Set Startup type to Automatic.
6. If the service is stopped, click Start.
7. Click OK to apply the changes.

Once the DHCP Client service is running, the network adapter should immediately request a DHCP lease. In most cases, the APIPA address will be replaced within a few seconds.

Verification

After enabling and starting the DHCP Client service:

• The server should receive a valid IPv4 address from DHCP
• A default gateway should be present
• DNS settings should populate automatically
• RPC-related errors should resolve
• Domain services should begin functioning normally

If the server still does not receive an address, verify that the VMware network adapter is connected and that the selected VMware network (NAT or Bridged) is functioning correctly.

Important Notes

Using DHCP on a domain controller is not recommended in production environments. Domain controllers rely heavily on stable IP addressing for DNS, replication, and service discovery.

However, for isolated test labs, learning environments, and short-lived virtual machines, this configuration can be acceptable and significantly reduce setup friction.