The nightly restarts are most likely caused by Windows Update–initiated reboots, with the Netlogon and Group Policy errors being side effects of the machine coming up before full network/domain connectivity is available.
From the provided events:
- Netlogon 5719 and GroupPolicy 1129 typically indicate that at boot time the machine could not contact a domain controller in time to process Group Policy. This often happens when the network stack or DC connectivity is delayed during startup and does not itself cause the reboot.
- These events are consistent with a race condition between network initialization, DC discovery, and Group Policy processing during startup.
To address the domain-related errors and stabilize Group Policy processing after the nightly restart:
- If IPv6 has been disabled via
DisabledComponentswith an incorrect value (0xFFFFFFF), correct or remove it:- Check
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents. - If set to
0xfffffff, either delete the value or change it to0xff. Incorrectly disabling IPv6 can delay startup by 5 seconds and affect components that rely on it.
- Check
- Increase the wait time for network availability before Group Policy processing:
- Open Registry Editor.
- Navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. - Create a new DWORD value named
GpNetworkStartTimeoutPolicyValue. - Set Base to Decimal and Value data to
60(seconds) to allow more time for the network and DC discovery before Group Policy runs. - Restart the device and, if startup scripts or policies still fail, increase the value further.
- Understand that if domain logon is ultimately successful and the user can work normally, Netlogon 5719 can be safely ignored. After the network is fully up, the machine will typically locate a domain controller and Group Policy background refresh will succeed.
Separately, to stop the nightly restarts themselves, review and adjust Windows Update restart behavior and any maintenance schedules:
- Check Group Policy for scheduled update installs and forced restarts:
- Under
Computer Configuration > Administrative Templates > Windows Components > Windows Update > Configure Automatic Updates, see if option 4 – Auto download and schedule the install is configured with a specific install time that matches the nightly restart. - Also review
Computer Configuration > Administrative Templates > Windows Components > Maintenance Schedulerto see if automatic maintenance is scheduled during the night and triggering restarts.
- Under
- If managing via registry (for example on a single device), verify:
-
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU→AuOptions = 4andScheduledInstallTimeset to a night hour. - Check if
AlwaysAutoRebootAtScheduledTimeandAlwaysAutoRebootAtScheduledTimeMinutesare configured, which will force a restart after the scheduled install time and show a countdown to the signed-in user.
-
- For a broader view of why the device is rebooting:
- Use the System event log to distinguish normal scheduled restarts from unexpected ones. Review Event IDs 12, 13, 6005, and 6009 around the time of the nightly reboot to confirm that the restart is a normal, OS-initiated reboot rather than a crash or power loss.
If the user can log on to the domain after the restart and work normally, focus on:
- Adjusting Windows Update/maintenance schedules to avoid unwanted nightly restarts.
- Applying the registry-based delay (
GpNetworkStartTimeoutPolicyValue) and correcting any IPv6 misconfiguration to eliminate the Netlogon 5719 and Group Policy 1129 noise at boot.
References: