Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix Event ID 1129

Event ID 1129: Group Policy runs before the network is ready at boot

11 min read Updated October 4, 2026 Windows Server: AD, DNS & Group Policy

Fix it now

Microsoft publishes 1129 as “The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition.” The documented cause is that policy processing starts before the network is usable. Make the network ready sooner first, and only then buy the machine more time.

Run these on an affected machine, in an elevated prompt, after the fixes below

gpupdate /sync
gpresult /r /scope:computer
  1. Install the current driver for the network adapter, or enable PortFast on the switch ports. Microsoft gives both as the first resolution, because the network stack and the adapter start at about the same time and link arbitration and MAC uniqueness checks can outlast the wait.
  2. If policy still runs too early, extend the wait. In Group Policy, under Computer Configuration, Administrative Templates, System, Group Policy, enable “Specify startup policy processing wait time”; for machines that reach the domain over an external network the companion setting is “Specify workplace connectivity wait time for policy processing”.
  3. Where you cannot deploy policy to fix policy, set GpNetworkStartTimeoutPolicyValue as a REG_DWORD under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, decimal, starting at 60, then restart.
  4. Check what was actually missed. gpupdate /boot and gpupdate /logoff exist because some extensions only run at startup or at logon.

Microsoft also warns about one specific misconfiguration here: if DisabledComponents has been set to an incorrect value while disabling IPv6, startup is delayed. Do not disable IPv6 to fix this.

If two clean reboots produce no new 1129, you are done. If not, the next section covers what is actually racing what.

Why it happens

Group Policy foreground processing can be synchronous or asynchronous. Microsoft’s definition is precise: in synchronous mode the computer does not complete system start until computer policy is applied successfully and the user logon does not complete until user policy is applied, while in asynchronous mode the computer can complete the start sequence before computer policy has finished. Event 1129 is what asynchronous processing looks like when the network was not there yet.

The reason it is not there yet is timing, and Microsoft names the contributors. The network stack and adapter initialisation start at about the same time, and some network adapters and switches run link arbitration and MAC address uniqueness checks that take longer to complete than the wait allowed for network connectivity to be detected. Health-check systems that verify a new member before letting it onto the network add to it, 802.1X authentication delays it further, and a slow DHCP response delays the interface appearing at all.

Windows compensates by processing policy again in the background once the network is available, which is why the usual response is that a manual refresh works perfectly. It does. But Microsoft also states that not all Group Policy extensions are processed during a background refresh: folder redirection processing occurs only when a user logs on, and software installation policy occurs only when a computer starts and when a user logs on. So a machine can report a clean policy result and still never have received the application it was meant to get.

That is the reason 1129 is worth chasing rather than filtering out of a monitoring rule. The events tell you that a cycle was abandoned; the extensions that matter tell you nothing at all, because from their point of view they were simply never called.

The adapter or the switch port is slow to come up

You have this one if 1129 at nearly every boot on wired desktops, and everything works normally once you are signed in.

  1. Install the most current driver for the network adapter, which is Microsoft’s first documented resolution.
  2. Enable PortFast on the switch ports, which is the other half of the same resolution.
  3. Reboot twice and confirm the event has gone rather than moved.

This is the fix that actually removes the problem. Everything below buys the machine more time to wait for a network that is arriving late.

Something authenticates or inspects the machine before it is allowed on

You have this one if 1129 on a network with 802.1X, network access control, or a pre-connection health check.

  1. Microsoft names 802.1X and health-verification systems as documented causes: they delay the connection and your ability to reach a domain controller.
  2. Adjust firewall or IPSec configuration so that domain controller connectivity is permitted once the client has an address.
  3. Then extend the wait, using the startup policy processing wait time setting, rather than expecting the machine to be quicker.

The machine has no network before sign-in at all

You have this one if Laptops on wireless, or remote machines that only reach the domain once a tunnel is up after the user signs in.

  1. Make the machine itself able to connect before anyone signs in, rather than relying on a connection the user establishes.
  2. Where the domain is only reachable through a tunnel, use one that comes up before user sign-in if your platform supports it.
  3. If neither is possible, stop depending on startup-time extensions for those machines and deliver that configuration another way.

Extending the wait on a machine that has no network before sign-in buys nothing. It only makes every sign-in slower while waiting for something that is not coming.

IPv6 was disabled incorrectly

You have this one if A consistent startup delay across machines that were hardened with a registry change to disable IPv6.

  1. Check DisabledComponents. Microsoft states that setting it to an incorrect value of 0xfffffff delays system startup by five seconds, and that the intended value is 0xff.
  2. Delete the value or correct it.
  3. Microsoft’s position is explicit: IPv6 is a mandatory part of current Windows and should not be disabled.

Full reference

The events

Event Status What it says
1129 Published by Microsoft The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected
1054 Not published Read the entry for what it names. Functionally, the locator could not produce a domain controller for policy processing
1053 Published by Microsoft The processing of Group Policy failed. Windows could not resolve the user name. Named causes: name resolution failure on the current domain controller, and Active Directory replication latency where an account created on another DC has not replicated
4202 Not published A TCP/IP entry about an adapter. Useful only for comparing timestamps against the 1129 entries

1053 is about the user name and names replication latency as a cause, so a 1053 on a newly created account that has not replicated to the domain controller the client is using is not a network problem at all. Treat it separately from 1129 rather than as its companion.

Microsoft’s documented remedies, in order

Remedy Where it lives
Current network adapter driver, or PortFast on the switch The network, and the first thing Microsoft lists
Firewall or IPSec adjustment so the client can reach a DC once it has an address Where a health check or NAC sits in front of the network
Specify startup policy processing wait time Computer Configuration, Administrative Templates, System, Group Policy
Specify workplace connectivity wait time for policy processing The same folder; for external LAN or WLAN
GpNetworkStartTimeoutPolicyValue REG_DWORD under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, decimal, suggested initial value 60
ExpectedDialupDelay REG_DWORD under HKLM\System\CurrentControlSet\Services\Netlogon\Parameters, in seconds, default 0, range 0 to 600
ArpRetryCount REG_DWORD under HKLM\System\CurrentControlSet\Services\TcpIp\Parameters, set to 1 to shorten the wait for address uniqueness. Default 3
NegativeCachePeriod Under the Netlogon parameters key. Microsoft suggests a low value such as 3 seconds, or 0 on a LAN

These are levers, not a checklist. Set the ones that match the delay you have measured, one at a time, and take the boot timings before and after. Applying all of them at once leaves you with a machine that boots differently and no idea which change did it.

What actually gets missed

Extension When Microsoft says it processes
Folder redirection Only when a user logs on
Software installation Only when a computer starts and when a user logs on
Most registry-based policy On the background refresh cycle as well

That table is the whole reason this event matters. A background refresh will pick up almost everything, so the machine looks compliant in every report you run. What it will not pick up is the software that was supposed to be installed and the folder redirection that was supposed to be applied, and neither of those produces a complaint until someone notices they are missing.

Forcing the cases the background refresh will not

Command What Microsoft says it does
gpupdate /sync Causes the next foreground policy application to be done synchronously. /force and /wait are ignored when you use it
gpupdate /boot Restarts the computer after settings are applied. Required for extensions that only process at computer startup, such as computer-targeted software installation
gpupdate /logoff Signs the user out after settings are applied. Required for extensions that only process at logon, such as user-targeted software installation and folder redirection
gpupdate /wait:<seconds> How long to wait for processing before returning. Default 600, 0 not to wait, -1 to wait indefinitely

Proving you fixed it

One clean boot proves nothing, because the race you are trying to win is a race. Reboot several times, at different times of day if the network is busy at some of them, and check the operational log each time for a completed cycle rather than for the absence of the error. Then confirm the thing that was actually failing: the startup script that never ran, or the application that never arrived. If those now appear, the fix is real; if only the event has gone, you may simply have moved the timing by a second or two.

Every code this article covers

Code What it points at Source
Event ID 1129 Group Policy processing failed because of lack of network connectivity to a domain controller. Microsoft describes it as possibly transient, with a success message generated once the machine reaches a DC Microsoft Learn
Event ID 1054 Logged when policy processing could not obtain a domain controller. No acceptable vendor page publishes the text, so read the entry for what it names not published by the vendor
Event ID 1053 Group Policy processing failed: Windows could not resolve the user name. Microsoft names name resolution failure on the current domain controller and Active Directory replication latency as causes Microsoft Learn
Event ID 4202 A TCP/IP entry logged about a network adapter. Not published by the vendor; useful for comparing timestamps against the policy failures rather than as a diagnosis not published by the vendor

Confirm the fix worked

  1. No new 1129 entries appear after several reboots rather than one.
  2. The Group Policy operational log shows a completed processing cycle at startup.
  3. gpresult /r /scope:computer lists the policies you expect for the machine.
  4. A startup script or software installation that previously never ran now does.
  5. Boot time is still acceptable, so that the fix has not simply been paid for out of the user’s morning.

Questions people ask about this

Can I ignore 1129 if a manual refresh works?

Not if you use folder redirection or software installation. Microsoft states that not all extensions are processed during a background refresh: folder redirection processes only at user logon, and software installation only at computer start and user logon. Those are exactly the ones a failed startup cycle loses.

What is Microsoft’s first recommended fix?

Install the most current driver for the network adapter, or enable PortFast on the network switches. Both address the documented cause, which is that link arbitration and MAC uniqueness checks outlast the wait for network connectivity.

Which policy setting extends the wait?

“Specify startup policy processing wait time” under Computer Configuration, Administrative Templates, System, Group Policy for a corporate LAN or WLAN, and “Specify workplace connectivity wait time for policy processing” for an external one.

Is there a registry equivalent?

Yes. GpNetworkStartTimeoutPolicyValue, a REG_DWORD under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, entered in decimal with a suggested starting value of 60. Increase it if a startup script still does not run.

Should I disable IPv6 to simplify the startup?

No. Microsoft states IPv6 is a mandatory part of current Windows and should not be disabled, and specifically warns that an incorrect DisabledComponents value delays startup rather than speeding it up.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix Event ID 7016: a Group Policy client-side extension never finishes processing License Error Error 8614 tombstone lifetime exceeded: a DC that stayed offline far too long Free Fix LDAP 533 and 532: binds refused because of the account state in AD Free Fix Error 0x8009480F: the request lacks the DNS name the template demands
← Back to Knowledge Base