Windows startup and sign-in: wait for network with Group Policy

Network initialization can lag behind Windows startup or sign-in, so foreground-dependent Group Policy changes such as folder redirection or managed software installation may need a later sign-in. Enable Always wait for the network at computer startup and logon to wait for network initialization and process Group Policy synchronously in the foreground. Sign-in may take longer.

When this helps

Normally clients use cached credentials for existing users without waiting for full network initialization, then apply Group Policy asynchronously in the background when the network becomes available. First sign-ins on a computer and users with a roaming profile, home directory, or user-object logon script wait for initialization. Changes to these user properties can also take up to two sign-ins to be detected.

DHCP, Wi-Fi or wired network authentication can delay connectivity. Software installation can report application management error %%1274 when its installer share or connection is unavailable. Startup Group Policy event 1129 can indicate an unreachable domain controller (DC); DNS, DC, LDAP, firewall and other connection faults have other causes. Check DNS, DC and share access and connectivity first; consider this policy when initialization timing is the issue. It does not guarantee connectivity, DC access, mapped-drive reconnection, or a fix for either error.

On Windows Server 2008 and later, startup policy is already synchronous and waits for network initialization; this setting is ignored at startup. At server sign-in it applies only when the Remote Desktop Session Host role service is installed and configured and “Allow asynchronous user Group Policy processing when logging on through Terminal Services” is enabled. Otherwise server sign-in policy is synchronous and this setting is ignored.

Steps

  1. Open gpedit.msc on the target computer and go to Computer Configuration > Computer Configuration › Administrative Templates › System › Logon.
  2. Open the policy, select Enabled, and apply it.
  3. Restart and sign in again. Check the effective policy with gpresult /r and inspect the Group Policy Operational event log for startup and sign-in processing.
  4. To undo, restore the prior state or select Not Configured. A domain GPO can override local settings.

Registry alternative

This edits the same computer policy: registry value. Run regedit as administrator. Select the existing target key, or an existing parent key if the target is missing. Choose File > Export, save a .reg file, and record whether the value existed and its previous type and data. Create missing keys and the DWORD value if needed, set it to 1, then restart and verify as above.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon
SyncForegroundPolicy  REG_DWORD
1 = enabled
0 = disabled

A SyncForegroundPolicy DWORD of 1 enables the policy’s foreground wait for the network; 0 disables the policy. With the policy disabled, clients generally process policy asynchronously, with the documented exceptions above. Manually setting 0 is not the same as leaving the policy not configured.

To undo, restore the previous type and data, or delete only the value you created, not the whole key. A domain GPO can overwrite manual edits.

Based on Windows 11 version 26H2 policy templates (checked 2026-11-04). The policy is in Logon.admx; its CSP mapping is device-scoped and lists Windows Pro, Enterprise, Education and IoT Enterprise.

References