Hello,

The DFSR Event 5002 with Kerberos failures after upgrading to Windows Server 2025 usually indicates that the DFSR service is unable to authenticate with its partner using the machine account, even though the secure channel test looks fine. This is often tied to SPN binding or residual metadata after an in-place upgrade. Collect DFSR debug logs from %systemroot%\debug\dfsr*.log and enable tracing with DFSRDiag.exe /setlogginglevel /all:5 to confirm. If replication remains blocked, the supported remediation is a non-authoritative restore (D2) on the affected partner, which preserves data and topology.

For DHCP failover, the “Access Denied” error during replication is typically linked to AD authorization inconsistencies or mismatched partner metadata. Use Get-DhcpServerInDC to verify AD entries and check for CNF-tagged duplicates in ADSI Edit under Configuration\Services\NetServices. If you see inconsistent partner names (FQDN vs IP), normalize them to FQDN on both sides, as mismatches can break replication. Initiating replication with Invoke-DhcpServerv4FailoverReplication from the authoritative partner is the supported method.

Direct upgrades from 2016 to 2025 are supported, but they increase the chance of leftover metadata issues compared to staged upgrades through 2022. If corrections to SPNs, AD authorization, and failover metadata do not resolve the problem, rebuilding DFSR topology or DHCP failover relationships may be required.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HP.

Hola Ilias,

I think there are two different issues here, and I wouldn’t jump to rebuilding DFSR or recreating DHCP failover yet.

For DHCP, your error helps a lot:

Invoke-DhcpServerv4FailoverReplication

Failed to enumerate failover relationships...

WIN32 5 - Access Denied

Because it fails while enumerating the relationships, before replication even starts, I’d first treat this as a management/API authorization problem rather than a failover transport problem. Microsoft’s DHCP failover documentation requires that the command be run with elevated administrative rights on the DHCP server.

So the simplest thing I’d verify is that the PowerShell session is elevated and the account is a local Administrator on the DHCP server named in -ComputerName. I’d also try the command locally on that DHCP server from an elevated PowerShell window.

I would not rebuild the failover relationship just because one view shows an FQDN and another shows an IP address. Microsoft explicitly allows the failover partner to be configured using a NetBIOS name, DNS name, or IP address, so that representation isn’t inherently invalid.

The fact that the relationship itself reports State = Normal and TCP 647 succeeds also argues against the partner identity being the first thing to change.

The DFSR side is more interesting.

Event 5002 with Error 5, combined with a 4625 on the receiving partner for the remote computer account, indicates that DFSR is reaching the authentication stage and that the machine-account logon is being rejected. A healthy Test-ComputerSecureChannel doesn’t completely rule that out because DFSR runs as Local System and authenticates using the computer account, while your interactive Kerberos tests are using your user context.

I would not do a D2 restore at this point. A non-authoritative DFSR restore repairs the replicated data state; it won’t fix a Kerberos/machine-account authentication failure.

One change that is especially relevant in 2026 is Microsoft’s Kerberos RC4 hardening. The July 2026 security updates moved Windows domain controllers into enforcement mode for the RC4 changes related to CVE-2026-20833. Microsoft specifically warns that workloads still depending on RC4 can begin failing authentication once enforcement is active.

I’d check the two DFSR server computer accounts for AES support: Get-ADComputer SERVERNAME -Properties msDS-SupportedEncryptionTypes | Select-Object Name,msDS-SupportedEncryptionTypes

If one of those upgraded machine accounts doesn’t have usable AES keys or has stale encryption-type metadata, that could explain why a machine-account Kerberos logon is failing even though ordinary connectivity looks healthy. Microsoft specifically notes that older accounts may need their password/key material regenerated to create modern AES keys. For a computer account, the supported way to do that is to reset the machine-account password: Reset-ComputerMachinePassword -Server <DCName> -Credential (Get-Credential)

I would only do that on one affected DFSR server first, during a maintenance window, and then reboot it. That is much less destructive than rebuilding DFSR and directly addresses the identity that your 4625 event says is failing.

Before doing even that, though, there’s one field from Event 4625 that would be very useful: SubStatus. 0xC000006D is only the generic STATUS_LOGON_FAILURE code. Microsoft documents that SubStatus usually indicates whether the failure is due to a bad password, an unknown account, a logon restriction, etc.

Thanks,

James

Issue 1 – DFSR

·         DFSR Event ID 5002 is generated for the replication group.

·         The event reports Error 5: Access is denied while communicating with the replication partner.

·         DFSR debug logs repeatedly show EstablishConnection failures with Error 5 (0x5) / Access is denied.

·         The debug log shows the expected partner DNS name and attempts to establish the DFSR connection.

·         DFSR configuration and replicated-folder configuration are present on the server.

·         Kerberos tickets can be obtained for CIFS, and basic domain connectivity/secure-channel checks have not indicated a simple network outage.

Representative event:

DFSR Event ID: 5002 Error: 5 (Access is denied) The DFS Replication service encountered an error communicating with partner <PARTNER> for replication group <GROUP>.

Question for Microsoft: before performing a non-authoritative DFSR restore (D2), which AD/Kerberos/DFSR metadata checks do you recommend to distinguish a stale post-upgrade member/connection object from an SPN or machine-account authentication issue? If D2 is required, please provide the supported Windows Server 2025 procedure and validation steps.

Issue 2 – DHCP Failover

·         Both DHCP failover relationships are visible through Get-DhcpServerv4Failover and report State = Normal.

·         The environment uses Hot Standby failover.

·         TCP port 647 connectivity between the DHCP partners succeeds.

·         An explicit forced failover replication attempt fails before replication starts.

Representative command and error:

Invoke-DhcpServerv4FailoverReplication -ComputerName "<DHCP-SERVER>" -Force Failed to enumerate failover relationships on DHCP server <DHCP-SERVER>. FullyQualifiedErrorId: WIN32 5 ... Error: Access Denied

·         The failover configuration has also shown an inconsistency where one partner is represented by FQDN in one context and by IP address in another.

·         Get-DhcpServerInDC successfully returns the domain DHCP authorization list.

Question for Microsoft: can WIN32 5 during failover-relationship enumeration be caused by stale DHCP authorization/NetServices metadata or inconsistent partner identity after an in-place upgrade, even when the relationship state is Normal and TCP 647 succeeds? Please provide the supported remediation sequence and confirm whether the failover relationship must be recreated if metadata normalization does not resolve it.

Checks already performed

·         DFSR Event Log reviewed.

·         DFSR debug log reviewed and Access Denied confirmed during connection establishment.

·         DFSR configuration/topology queried.

·         Kerberos ticket cache reviewed.

·         Relevant SPNs reviewed on the affected server objects; domain-wide duplicate-SPN validation is being coordinated with AD administrators.

·         DHCP failover state queried.

·         DHCP TCP 647 connectivity tested successfully.

·         DHCP AD authorization list queried.

·         Forced DHCP failover replication attempted and WIN32 5 reproduced.