# Event ID 1129: Group Policy Failed, No Connectivity to a DC

Source: https://srvscripts.com/guides/event-id-1129-group-policy/
Updated: 2026-10-07
Publisher: srvScripts (https://srvscripts.com/)

**Short answer:** Event ID 1129 means Group Policy processing failed because the computer had no network connectivity to a domain controller when it tried. If it appears only at startup and a success event (1500 or 1502) follows minutes later, the network came up after Group Policy started. Fix it with current NIC drivers, PortFast on switch ports, or a longer startup wait. If it never clears, the computer cannot reach a DC on LDAP port 389 or cannot find one in DNS.

Commands checked against the official documentation (linked below) on 7 October 2026; not yet run on our lab servers.

## What event ID 1129 means

| Property | Value |
| --- | --- |
| Log | System |
| Source (provider) | Microsoft-Windows-GroupPolicy |
| Level | Error |
| Symbolic name | gpEvent_NO_NETWORK |
| Logged on | The computer whose policy processing failed |

The message text from Microsoft’s current troubleshooting guide:

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 to the domain controller and Group Policy has successfully processed. If you do not see a success Message for several hours, then contact your administrator.

There are no placeholders. The event says only that no DC was reachable when processing started, not why. You get the “why” from timing (was it right after boot?) and from connectivity tests.

## Common causes

Microsoft’s article on Netlogon 5719 and Group Policy 1129 lists the startup causes. The last two below come from its Group Policy troubleshooting guide and from everyday operations:

- **Network not ready at startup.** The adapter is still negotiating its link, or the switch port is still in spanning-tree listening/learning, when Group Policy starts.

- **802.1X or NAC checks.** Network authentication or a health check delays access to the DCs beyond the wait time.

- **Slow DHCP.** The interface has no IP address yet.

- **LDAP blocked.** Port 389 to the DC is blocked, so the bind fails at the TCP handshake. This one does not clear by itself.

- **Off the corporate network.** Laptops that boot at home before the VPN connects log 1129 every time. That is expected.

## How to find the cause

The quickest test is the timeline. This lists boots (event 12), 1129, Netlogon 5719 and the success events for the last seven days in order:

```
Get-WinEvent -FilterHashtable @{LogName='System'; Id=12,1129,5719,1500,1501,1502,1503; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue |
  Sort-Object TimeCreated |
  Format-Table TimeCreated, Id, ProviderName, @{n='Message'; e={($_.Message -split "`r?`n")[0]}} -AutoSize
```

Read it like this:

- **12 (Kernel-General boot), then 1129 within a minute or two, then 1500/1502 a few minutes later:** a startup race. The network came up late.

- **1129 at every refresh, all day, never a success:** a real connectivity problem. Test it now.

- **1129 only on laptops, only on some days:** they started off-network.

Pull just the 1129 events with their EventData fields:

```
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'; Id=1129} -MaxEvents 10 |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time   = $_.TimeCreated
      Fields = ($x.Event.EventData.Data | ForEach-Object { "$($_.Name)=$($_.'#text')" }) -join '; '
    }
  } | Format-List
```

Then test connectivity from the affected machine:

```
ipconfig /all                                   # real address, not 169.254.x.x; AD DNS servers
nltest /dsgetdc:contoso.local
Test-NetConnection dc01.contoso.local -Port 389
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.local
```

For deeper detail, Microsoft’s guide enables Group Policy service logging. Set `GPSvcDebugLevel` (REG_DWORD, 0x30002) under `HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics`, create `%windir%\debug\usermode` if missing, and read `gpsvc.log` there. A line such as `GetLdapHandle: Failed to connect <DC>` points at LDAP being blocked. Remove the value when you are done.

**In the console:** Event Viewer > Windows Logs > System > Filter Current Log, event IDs `12,1129,1500-1503`. Sort by Date and Time to see the order.

## How to fix it

### Startup race (success follows later)

- Update the network adapter driver. This is Microsoft’s first resolution.

- Turn on PortFast (or your switch vendor’s equivalent edge-port setting) on access ports for workstations.

- Give Group Policy longer to find the network: Computer Configuration > Administrative Templates > System > Group Policy > Specify startup policy processing wait time. Base the value on how long the adapter really takes.

- If startup scripts or software installs must run at boot, enable Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon.

Microsoft’s article also documents the `GpNetworkStartTimeoutPolicyValue` registry value (DWORD, seconds, under `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon`; their example is 60). Prefer the policy setting so the change is managed centrally. Back up the registry before editing it by hand.

### 802.1X, NAC or slow DHCP

Measure how long authentication or the DHCP lease takes, and set the wait time above that. Ask the network team whether the quarantine VLAN can reach the DCs during the check.

### LDAP blocked

If `Test-NetConnection` to 389 fails while ping works, a firewall is dropping LDAP. Open it on the host firewall, network firewalls and VPN rules between clients and DCs. Our [Windows Firewall Group Policy guide](/guides/windows-firewall-group-policy/) shows how to deploy rules centrally.

### Laptops off the network

No fix is needed if 1129 is followed by success once the VPN connects. If remote machines never get policy, make the VPN connect before logon or use an always-on VPN. Also check that it hands out your AD DNS servers.

## Check that it worked

Restart the computer (startup races only show at boot), wait a few minutes, then rerun the timeline query. After the latest event 12 you want 1500 or 1502 and no 1129. For a quick check without a reboot:

```
gpupdate /force
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'; Id=1129,1500,1502} -MaxEvents 3 |
  Format-Table TimeCreated, Id -AutoSize
```

### Common problems

- **Startup scripts still do not run:** they need the network at boot. Enable “Always wait for the network” or increase the wait time.

- **Fine on wired, 1129 on Wi-Fi:** Wi-Fi profiles that authenticate as the user connect only after logon. Use machine authentication for the Wi-Fi profile.

- **1129 plus 1030 or 1054:** the network is up but DNS is wrong. See our Event ID 1030 page.

## Related events

| Event ID | Source | What it means |
| --- | --- | --- |
| 12 | Microsoft-Windows-Kernel-General | The operating system started. Use it as the boot marker. |
| 5719 | NETLOGON | Could not set up a secure session with a DC. Per Microsoft, Windows 10 and later no longer log it in the startup case; Netlogon.log has the detail instead. |
| 1030 | Microsoft-Windows-GroupPolicy | Could not retrieve the GPO list (DNS, ports, authentication). |
| 1054 | Microsoft-Windows-GroupPolicy | Could not obtain the name of a domain controller. |
| 1058 | Microsoft-Windows-GroupPolicy | Could not read gpt.ini from SYSVOL. |
| 1500-1503 | Microsoft-Windows-GroupPolicy | Policy processed successfully (computer 1500/1502, user 1501/1503). |

**Official documentation:** [Event ID 1129: Group Policy Preprocessing (Networking)](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc727335(v=ws.10)) · [Netlogon event ID 5719 or Group Policy event 1129 at startup](https://support.microsoft.com/kb/938449) · [Applying Group Policy troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance)

**Related:** [Group Policy Not Applying: 12 Checks with gpresult and Events](/guides/group-policy-not-applying/) · [Force gpupdate Remote Computers: 5 Methods for Every OU](/guides/force-gpupdate-remote-computers/) · [PowerShell Logon Script Group Policy: 4 Reliable Ways to Run Scripts](/guides/powershell-logon-script-group-policy/) · [Deploy Software with Group Policy: MSI Install, Upgrade and Removal](/guides/deploy-software-with-group-policy/)

**See also:** [Event ID 1058: Group Policy Failed to Read gpt.ini (Fix)](/guides/event-id-1058-group-policy/) · [Event ID 1030: Group Policy Processing Failed (Causes and Fix)](/guides/event-id-1030-group-policy/) · [Event ID 5805: Netlogon Session Setup Failed to Authenticate](/guides/event-id-5805-netlogon/)

## Frequently asked questions

### Is event ID 1129 harmful?

A single 1129 at boot followed by a success event is harmless; background refresh applied policy a few minutes later. What breaks is anything that only runs at startup, such as startup scripts and software installation.

### Why do I get event 1129 but the network works after logon?

Group Policy started before the adapter, switch port, 802.1X check or DHCP was ready. Once the link is up, the next refresh succeeds.

### What does “Always wait for the network at computer startup and logon” do?

It makes Windows wait for the network before finishing startup and logon, so policy applies in the foreground. Startup and logon may take a little longer.

### Does event 1129 mean the domain controller is down?

Not necessarily. It means this computer could not reach one when it tried. Check whether other computers log it at the same time before suspecting the DC.