Event ID 20291: DHCP failover partners rejecting each other’s binding updates

Fix it now

One failover partner sent a BINDING-ACK carrying a reject reason and the other logged receiving it. Where the reason is “Outdated binding information”, Microsoft states these events can be ignored: they do not indicate an error and do not affect leases or the partner update. Check the reject reason before changing anything.

Get-DhcpServerv4Failover
w32tm /query /status

1. Open the event and read the reject reason in brackets. “Outdated binding information” is the benign case, and the usual cause is more than one relay agent forwarding the same client broadcast to both nodes within the same second.
2. Confirm the relationship itself is healthy: both partners should report a normal state, and the last communication should be recent.
3. Look for Event ID 20253 in the same log. That is the partner reporting it is out of time synchronisation, and it states the offset in seconds, so you do not have to infer skew from anywhere else.
4. Only if state or scopes genuinely differ, push the configuration from the server you trust: Invoke-DhcpServerv4FailoverReplication -ComputerName <server> -Force. Replication overwrites the partner, so run it on the server whose settings you want to keep.

These events live in Applications and Services Logs, Microsoft, Windows, DHCP-Server, under the Admin channel – not in the System log.

If the reject reason is the outdated-binding one and the relationship is in a normal state, you are done. The next section explains what the two servers are exchanging and which failures are real.

Why it happens

DHCP failover partners keep two independent lease databases in step by exchanging binding messages over a persistent TCP connection on port 647. When one server tells the other about a lease, the partner answers with a BINDING-ACK. If it cannot accept what it was told, that acknowledgement carries a reject reason, and both ends log it: 20291 on the server that sent the rejection, 20292 on the server that received it.

The most common reject reason is “Outdated binding information”, and Microsoft’s guidance on it is explicit. It does not indicate an error, it does not affect the address lease or the update of the partner server, and the usual cause is several relay agents forwarding the same client broadcast to both failover nodes. The relay copies arrive fractions of a second apart with different relay agent addresses; failover has a time granularity of seconds, so the second copy looks like stale news. Configuring a delay on one of the relay agents also helps.

That leaves the rejections that are real. Failover has a set of events for messages refused because the message digest failed to compare, was not configured, or was not present – one pair per message type, covering BINDING-UPDATE, BINDING-ACK, CONNECT, CONNECTACK, STATE, CONTACT and the update messages. Those are shared-secret problems, and they stop replication properly.

Full reference

The failover events worth knowing by number

Two channels, two kinds of entry

Under Applications and Services Logs, Microsoft, Windows, DHCP-Server there are two channels that matter here. The Admin channel carries state transitions and the operational health of the relationship. The Operational channel carries configuration auditing, such as a scope being added to or removed from a relationship. If you are asking “what changed”, read Operational; if you are asking “what is it doing now”, read Admin.

What failover requires

• Both partners must be running at least Windows Server 2016.
• TCP 647 must be open between the partners, in both directions, for the persistent connection.
• Failover supports DHCPv4 scopes only. DHCPv6 scopes cannot be failover-enabled.
• A failover relationship is always between exactly two servers, though one server can hold several relationships.
• Scope changes are not replicated automatically. If you edit a failover-enabled scope, you must replicate it yourself.

Hot standby, load balance, and the reserve

In hot standby mode one server serves the scope and the partner holds a reserve percentage of the addresses – five per cent by default – for the case where the active server stops answering. In load balance mode both serve, and the servers hash the client’s hardware address to decide which of them replies. That hashing is why, in a healthy load-balanced pair, one server logs an audit entry saying it deliberately did not answer a client: it is not a fault, it is the other half of the pair taking that client.

The maximum client lead time governs how long a partner may extend a lease on its own authority when it cannot reach the other server. It is why a standby server hands out short leases during an outage rather than full-length ones, and why lease durations look wrong for a while after a partner comes back.

Before you rebuild a relationship

1. Read the reject reason. If it is “Outdated binding information”, nothing is broken.
2. Check 20254 and 20255 to see whether contact has genuinely been lost, and when.
3. Check 20253 for a time offset, and fix time first if there is one.
4. Check the message digest events for a shared secret mismatch.
5. Only then consider deleting and re-creating the relationship, and replicate from the server whose configuration you want to keep.

Every code this article covers

Confirm the fix worked

1. The reject reason in the events is read and recorded, not assumed.
2. Get-DhcpServerv4Failover on both partners reports the same relationship in a normal state.
3. No new 20253 events appear, and w32tm /query /status on both servers names a sensible source.
4. No message digest rejection events (20256 to 20284) are being written.
5. A test client leases and renews, and the lease is visible on both partners.

Questions people ask about this