Mixed DCs running Windows Server 2022 and 2025 causing 2025 members to fail secure channel to the domain?

Question

Mixed DCs running Windows Server 2022 and 2025 causing 2025 members to fail secure channel to the domain?

Simon 25

On WS2025 members, the Netlogon client uses the new Kerberos-based secure channel by default. If the client fails to use the new RPC call, which means that it is probably trying to connect to a 2022 DC, it uses the old Netlogon secure channel. According to this article this is how it should work: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/event-id-5719-when-netlogon-service-restarts

But with my tests, the fall back doesn't work and causes the client to lose its secure channel and the client to lose its secure session. According to the article above, Microsoft Support wants this information :)
" Important

If the error recurs outside of NetLogon restarts, or it coincides with domain trust or authentication failures, investigate further. Collect the log data, as described in Collecting log data, and then contact Microsoft Support."

Has anyone experienced the same? What I tried on the WS2025 member server:
nltest /sc_reset:lab\DC01
nltest /sc_query:lab
nltest /sc_change_pwd:lab

If the WS2025 member server has the secure channel established with a WS2025 DC, but on the commands above starts going to a WS2022 DC, it will fail:
nltest /sc_reset:lab\DC01
I_NetLogonControl failed: Status = 5 0x5 ERROR_ACCESS_DENIED
Test-ComputerSecureChannel -Verbose
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "WS2025-member". False VERBOSE: The secure channel between the local computer and the domain lab is broken.
nltest /sc_change_pwd:lab I_NetLogonControl failed: Status = 5 0x5 ERROR_ACCESS_DENIED

I have logs and pktmon captures but I don't really want to upload them here.

0 comments

Answer accepted by question author

Daphne Huynh (WICLOUD CORPORATION) 1,305 Microsoft External Staff Moderator

Welcome to Microsoft Q&A!

Thank you for taking the time to share the detailed test results and observations.

Based on the information you've provided, the behavior you are seeing appears to be different from the scenario described in the Event ID 5719 article.

The article describes a transient Event ID 5719 (0xC00000E5, STATUS_INTERNAL_ERROR) that may occur when the Netlogon service restarts on a Windows Server 2025-member server and initially attempts to establish the new Kerberos-based secure channel with an earlier-version domain controller. In that scenario, the client is expected to automatically fall back to the legacy Netlogon secure channel, successfully re-establish trust, and continue normal domain operations. The event is temporary and should not result in a persistent secure channel failure.

In your testing, however, the outcome appears different:

nltest /sc_reset returns ERROR_ACCESS_DENIED (0x5)
nltest /sc_change_pwd fails
Test-ComputerSecureChannel reports that the secure channel is broken
The issue occurs when the Windows Server 2025 member communicates with a Windows Server 2022 domain controller

These symptoms suggest an actual trust or authentication failure rather than the transient condition described in the article.

As part of the investigation, I would recommend verifying the following:

Confirm that all Windows Server 2022 and Windows Server 2025 domain controllers are fully updated with the latest cumulative updates.
Determine whether the issue occurs against all Windows Server 2022 domain controllers or only specific ones.
Review Active Directory replication health using tools such as repadmin /replsummary and dcdiag.
Confirm that the computer account password is consistent across all domain controllers.
Review Netlogon and Kerberos operational logs on both the member server and the domain controller involved in the failure.
Collect the Netlogon debug logs and pktmon traces referenced in the Microsoft article.

Since the documented fallback mechanism should preserve the secure channel, a reproducible failure when a Windows Server 2025 member communicates with a Windows Server 2022 domain controller could indicate either an environmental issue (for example, replication, machine account password, authentication policy, or patch-level differences) or potentially a product issue that requires deeper analysis.

Given the nature of the issue and the fact that you already have diagnostic logs and packet captures available, I would recommend opening a Microsoft Support case. While the community may be able to offer suggestions, Microsoft Q&A has limited ability to perform in-depth analysis of Netlogon traces, packet captures, and other diagnostic data. A support engineer can securely review the collected logs and determine whether the Kerberos-based secure channel negotiation is failing during the fallback process or whether another underlying factor is contributing to the trust failure.

I appreciate the thorough testing you've already performed. The diagnostic data you've collected should be very valuable in helping to narrow down the root cause.

If you find this information helpful, please consider clicking Accept Answer.

Thank you for using Microsoft Q&A.

Simon 25 Reputation points

2026-09-03T08:05:03.3133333+00:00

Thanks Daphne. The AD is healthy, so I do believe this is "proof" that the fall back doesn't work as it should, in our scenario. The AD is very slim and default values/standards. I will go further and contact Microsoft Support to get a correct analyze. Have a nice day!

1 additional answer

Your answer

Simon 25 Reputation points

2026-09-03T08:05:03.3133333+00:00

Thanks Daphne. The AD is healthy, so I do believe this is "proof" that the fall back doesn't work as it should, in our scenario. The AD is very slim and default values/standards. I will go further and contact Microsoft Support to get a correct analyze. Have a nice day!

Answer 1

Yes. For the specific case documented by Microsoft, Event ID 5719 with 0xC00000E5 (STATUS_INTERNAL_ERROR) during a NetLogon restart in a mixed environment is expected and harmless only if the secure channel is successfully established afterward and domain operations continue normally.

That documented behavior applies to:

Windows Server 2025 member servers
authenticating against Windows Server 2022 or Windows Server 2019 DCs
a single Event ID 5719 during NetLogon restart
automatic fallback to the legacy NetLogon method

Microsoft also states that if the error:

recurs outside of NetLogon restarts, or
coincides with domain trust or authentication failures

then it should be investigated further, logs should be collected, and Microsoft Support should be contacted.

The reported ERROR_ACCESS_DENIED on nltest /sc_reset and nltest /sc_change_pwd, together with Test-ComputerSecureChannel returning False, does not match the harmless one-time fallback scenario described in the article. In the documented scenario, the secure channel is re-established and normal domain operations resume.

Supported next steps are:

Do not treat this as the benign Event ID 5719 case if the secure channel is actually breaking.
Collect the relevant logs Microsoft asks for:
- System event log entries for Event ID 5719
- NetLogon debug logs

Collect Event ID 5719 entries with:

   wevtutil qe System "/q:*[System[(EventID=5719)]]" /f:text /c:50

Enable NetLogon debug logging with:
```
   nltest /dbflag:0x2080ffff
```
The log is written to %systemroot%\debug\NetLogon.log.
After reproducing the issue, turn off debug logging with:
```
   nltest /dbflag:0x0
```
Check whether the NetLogon log shows the expected pattern:
- initial Kerberos secure channel attempt
- failure of that first attempt
- fallback to NetLogon
- successful secure channel establishment

A related indicator is Security-NetLogon Event ID 9005 in Applications and Service Logs\Microsoft\Windows\Security-NetLogon\Operational, which records:

secure channel setup failed with Kerberos
falling back to NetLogon

If that fallback is not followed by a successful secure channel, the behavior is outside the documented harmless case.

There is also an optional workaround to suppress this specific Event ID 5719 logging by temporarily setting:

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
UseKerberosForSecureChannels = 0 (REG_DWORD)

Command Prompt:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters" /v UseKerberosForSecureChannels /t REG_DWORD /d 0 /f

PowerShell:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters" -Name "UseKerberosForSecureChannels" -Value 0 -Type DWord

This is only a temporary workaround and modifies the registry. Incorrect registry changes can cause serious problems. Microsoft says to use it only temporarily and remove it after enough Windows Server 2025 or newer Kerberos-capable DCs are deployed.