Server 2022 DHCP server stops handing out IP addresses

When this error hits

You're running Windows Server 2022 with the DHCP role installed. Everything's been working fine for months. Then one morning, users start complaining they can't get online. You check a workstation and see it's pulling a 169.254.x.x APIPA address. On the server, you open Event Viewer and find Event ID 10020 under Windows Logs > System. The description says something like: "The DHCP service failed to see a directory server for authorization."

This usually happens after a domain controller reboot, a time sync issue, or a network change that breaks the DHCP server's connection to AD. The server's authorized, but the service can't confirm it.

Root cause

Windows Server DHCP won't hand out IP addresses unless it's authorized in Active Directory. That's a security feature. The DHCP service checks authorization every 15 minutes by default. If it can't reach a domain controller, or if the authorization record in AD is missing or corrupted, the service stops handing out leases.

But here's the real kicker: sometimes the authorization is still there, but the service throws a false positive. The cause could be a stale DNS entry for the domain controller, a Kerberos ticket that expired, or the DHCP server's computer account lost its permissions in AD. I've also seen this happen when the server's clock drifts more than 5 minutes from the domain controller.

Step-by-step fix

I've broken this into phases. Do them in order. Skip ahead only if a step doesn't apply.

Phase 1: Verify the service and authorization

1. Open Services console (services.msc). Locate DHCP Server. Make sure the Status says Running. If it's stopped, right-click and select Start. If it's already running, right-click and Restart it anyway. After restart, wait 2 minutes and check Event Viewer for new Event ID 10020. If you see one, move on.
2. Open DHCP console (dhcpmgmt.msc). Right-click your server name at the top and choose Authorize. If it's already authorized, you'll see an option to Unauthorize instead — that means it's authorized. Skip to step 3. If you see Authorize, click it. After clicking, you should see a brief "Authorizing" message in the status bar at the bottom. Wait 30 seconds. Right-click the server again — it should now show Unauthorize. If it doesn't, right-click and check All Tasks > Refresh. Still not showing? Move to Phase 2.
3. Run netsh dhcp show server from an elevated command prompt. This lists all authorized DHCP servers in AD. Look for your server's hostname or IP. If it's missing, jump to Phase 2.

Phase 2: Force re-authorization via netsh (real fix)

Skip the GUI here. It's flaky. The command line is more direct and usually works when the GUI fails.

1. Open an elevated command prompt (right-click Command Prompt, choose Run as administrator).
2. Type netsh dhcp server 10.0.1.10 init auth — replace 10.0.1.10 with your DHCP server's actual IP address. Then press Enter. You should see Command completed successfully.
3. Now type netsh dhcp show server again. Your server should appear in the list. If it doesn't, run netsh dhcp add server 10.0.1.10 YOUR-SERVER-NAME (replace IP and name). Then re-run netsh dhcp server 10.0.1.10 init auth.
4. Restart the DHCP service: net stop dhcpserver && net start dhcpserver.
5. Wait 2 minutes. Check Event Viewer. No new 10020 events? Good. Test from a workstation: ipconfig /release && ipconfig /renew. You should get a proper IP.

Phase 3: If the server still won't authorize

This means the authorization record in AD is stuck or corrupted.

1. On a domain controller, open Active Directory Users and Computers (dsa.msc). From the View menu, enable Advanced Features.
2. Navigate to System > Services > NetServices. Look for an object named DHCP-YourServerIP-YourServerName. If you see it, right-click and Delete. Confirm the deletion.
3. Back on the DHCP server, open an elevated command prompt. Run netsh dhcp server 10.0.1.10 init auth again.
4. Restart the service: net stop dhcpserver && net start dhcpserver.
5. Check Event Viewer. You should see Event ID 1007 (authorization successful).

Phase 4: Database corruption — the nuclear option

If none of the above works, the DHCP database is probably corrupt. This is rare, but it happens after a hard crash or disk error.

1. Stop the service: net stop dhcpserver.
2. Back up the database: robocopy C:\Windows\System32\dhcp C:\Backup\dhcp_backup /E.
3. Delete the database files in C:\Windows\System32\dhcp. Keep only the backup folder inside it — that's where the service looks for a restore.
4. Restart the service: net start dhcpserver. The service will automatically recreate the database from the backup folder. If that fails, you'll need to restore from a full backup or rebuild your DHCP scopes manually.
5. After the service starts, check the DHCP console. Your scopes should be intact. Test with a workstation. If scopes are missing, restore the backup folder and try again, or rebuild them.

Still failing? Check these

If you've gone through all four phases and the server still won't hand out IPs, look at these:

• Time sync: On the DHCP server, run w32tm /query /status. Compare the time to a domain controller. If it's off by more than 5 minutes, Kerberos breaks. Fix with w32tm /resync.
• DNS: The DHCP server needs to resolve the domain controller's hostname. Run nslookup yourdomaincontroller.yourdomain.local. If it fails, check your DNS server's forwarders and root hints.
• Firewall: Between the DHCP server and domain controllers, ensure ports 389 (LDAP) and 3268 (Global Catalog) are open. The authorization check uses LDAP.
• AD permissions: The DHCP server's computer account needs Read access to the NetServices container. Check with ADSI Edit if you're comfortable — usually this isn't the issue unless someone messed with permissions.

If you still see Event ID 10020 after all this, your best bet is to call Microsoft support. There's a known bug in Server 2022 with KB5025230 (released May 2023) that caused this for some people. Installing the latest cumulative update fixed it for them. So check Windows Update first.