Netlogon 5719

I recently discovered a solution to reoccuring Netlogon 5719 errors in the System log on our Windows 7 clients.
The errors only occur during system boot and they have a somewhat unexpected explanation.

The error message says:

This computer was not able to set up a secure session with a domain controller in domain YOUR DOMAIN due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. 

After some troubleshooting I discovered the source of the error to be dhcp. (!)

I must point out that this error message did not cause any other problems on the client. Authentication and group policy application on both computer and user level was working which is why this error seemed a little peculiar. (In some cases Group Policy application errors were seen although quite rarely.)

It turns out Windows 7 by default requests a dhcp-reply to be sent as a unicast response, however during startup Windows Firewall rejects unicast packets from outside it’s own subnet. No Windows Firewall rule block rule can be seen in the GUI, this is from what I can tell a built-in feature. In this situation the DHCP-request time out and the request is re-sent this time asking for a response to be sent as a broadcast packet. This time it succeeds.

There seems to be no Hotfix for this issue nor is it solved in SP1. So if your clients are not on the same subnet as your DHCP-server you might want to keep reading.


Make Windows 7 request a response from the DHCP server to be sent as a broadcast by setting the following registry entries:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpConnForceBroadcastFlag = 1 (0 for unicast, 1 for broadcast).


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpConnEnableBcastFlagToggle = 0 (32bit DWORD) (This value prevents Windows from changing the DhcpConnForceBroadcastFlag back to 0 (the default)).

You need to set both registry values for every adapter on the machine.

Big thanks to Systems Administrivia for creating this blog post which lead me to the solution.
Through that blog post I found this DHCP Team blog post describing it further.


It seems this error is intermittent and that is somewhat correlated to another bug or at least had me confused with it. So the solution/workaround described above won’t prevent  the error from occuring permanently.
Have a look at this MS Knowledge Base article to see if it is something that you might consider as well.
In our environment these issues seem to occur in our Branch Offices only where servers aren’t available on the same subnets as the clients.

  1. Posted by John M

    Excellent post- this is exactly what was happening to me. The worst part is that there was no way to configure the windows firewall to allow this besides disabling it. Microsoft released a hotfix that is NOT part of Windows 7 Service Pack 1.


    • Posted by Martin Wahlberg

      Thanks for your comment John and thanks for the Hotfix-link.

  2. Posted by Thorsten L

    Did this hotfix help you at any time?
    We still had the issue after the installed hotfix.
    Any other news on this topic Martin?

  3. Posted by Martin Wahlberg

    Hi Thorsten,

    I’m sorry I havn’t had the chance to investigate this error further. In our situation the error didn’t cause any permanent damage or slow logons or anything so we focused on other issues.
    Maybe John have more info regarding this?

  4. Posted by Joe Flick

    We have the same issue on Windows 7 Enterprise x64 SP1 machines and have managed to resolve it. Search engines have been more helpful than Microsoft. I opened a case and all they could give me was information I already found and to update the NIC drivers on all my servers and workstations.

    I do not know the EXACT cause of the issue is other than a timing issue with when the network comes up compared to when the machine checks for the domain and runs GPOs. In our environment, we had to do all of the things below (I tested them individually before combining them) for the NetLogon 5719 errors to go away, as these errors were impacting applications (Citrix XenDesktop Virtual Desktop Agent aka Remote PC, specifically).

    1. Microsoft KB 938449 – Resolution 1 (PortFast enabled on switches – didn’t do NIC drivers). Resolution 2 – Both regkeys (ExpectedDialupDelay value = 600). Resolution 3. Resolution 4 (Win7 DHCP Hotfix – the download has version 3 and 4, we installed version 4).

    2. – Set the “Startup policy processing wait time” GPO setting to 60. Set the workstation NIC setting (in Device Manager, Advanced tab of NIC) to Wait for Link = On.

    In short, 5 things; PortFast on switch(es), NIC setting, 3 regkeys, a GPO setting and a Win7 Hotfix.

  5. Posted by pc support services

    Great blοg уou haѵе got
    here.. Ӏt’s hard to find quality writing like yours these days. I really appreciate individuals like you! Take care!!

    Here is my web site – pc support services

Add Your Comment