The firewall flipped to Public and broke everything: Network Location Awareness and the domain-detection race

A laptop boots on the corporate LAN. The user signs in. The line-of-business app cannot reach its server. The file share times out. The printer is gone. Nothing on the device changed overnight, and nothing on the network changed either.

You open Windows Defender Firewall and the answer is sitting there in plain sight. The network is classified Public. Every firewall rule your team scoped to the Domain profile is inert, because as far as Windows is concerned this machine is sitting in an airport lounge.

This is not a firewall bug. It is a classification outcome. Windows decides what kind of network you are on before it decides which firewall rules apply, and that decision is a race. This post is about that race: what makes the decision, what "Domain" actually costs to earn, where the evidence lives, and which mitigations Microsoft actually supports.

The problem: the Domain profile silently is not there

Windows Firewall has three profiles: Domain, Private and Public. A profile is just a named bucket of settings and rules. Windows picks the bucket based on how it classified the network the traffic is going over.

Microsoft states the rule plainly in the Windows Firewall overview: "The domain network profile is automatically applied to a device that is joined to an Active Directory domain, when it detects the availability of a domain controller. This network profile cannot be set manually."

Read that second sentence again. There is no switch, no checkbox and no registry value that says "this is the corporate network, trust me". Domain is a status the device has to earn, every time, on every network change. When it fails to earn it, Microsoft's own support guidance lists exactly the symptoms you are seeing.

• The network status shows as "Unidentified network" in the system tray.
• An incorrect firewall profile is applied. The Public profile applies even though the machine is domain-joined.
• Firewall rules configured under the Domain profile are not applied, causing connectivity failures.
• Connectivity to internal applications fails because the Domain profile is not active.

The reason this is so hard to catch is that it is usually transient. The device classifies Public, then a few seconds later corrects itself to DomainAuthenticated. By the time the user calls the helpdesk and you remote in, the machine looks fine. Here is what that correction looks like in the event log on a real domain-joined Windows 11 device.

Eighteen seconds does not sound like much. It is plenty. A logon script, a mapped drive, a management agent check-in and an app that opens a socket at startup all happen inside that window. They fail, the user sees the failure, and the evidence evaporates before you look.

Why it happens: Domain is earned by an LDAP bind

Two components share this job, and it helps to keep them apart.

NCSI is the Network Connectivity Status Indicator. It answers "is there internet, and is it real internet or local-only?" using an HTTP request to a probe endpoint (the "active probe") plus passive inspection of inbound packets (the "passive probe"). NCSI is why you get the globe with no internet icon.

NLA is Network Location Awareness. Microsoft describes the NLA service provider as the thing that "enables Windows Sockets 2 applications to identify the logical network to which a Windows computer is attached". The part that matters to you is that it performs the domain authentication step that decides whether a network is Domain.

Here is the chain, in order, from a network event to a firewall profile.

1. Something changes on the network stack. Microsoft lists the triggers: an IP route is added or removed, an IP address is added or removed, an adapter disconnects or reconnects, an adapter is disabled or re-enabled, a DHCP event occurs (lease renewal, DNS server added or removed), or an NCSI setting changes.
2. That change triggers NCSI detection, which works out the connectivity level.
3. In parallel, domain detection starts. The service calls the DsGetDcName function to retrieve a DC name. Under the covers that is a DNS SRV lookup for a name of the form _ldap._tcp.<SiteName>._sites.dc._msdcs.<DomainName>.
4. If DNS returns a DC, the machine opens a TCP connection to that DC on port 389.
5. Inside that connection it sends an LDAP bind request. Only when the bind succeeds does the machine "identify itself in the domain network".
6. The resulting category is written to the network profile, and Windows Firewall applies the matching profile.

Every one of those six steps can be slow or fail while the adapter is otherwise perfectly up. That is the entire story of this bug.

The three categories, and their numbers

Windows exposes the category through the Network List Manager API as the NLM_NETWORK_CATEGORY enumeration. These are the documented values, and they are the same numbers you will see in the registry later.

There is a companion enumeration, NLM_DOMAIN_TYPE, and it is the one that explains the middle state everybody trips over.

Value 1 is the flap made visible. Windows can see that this is an Active Directory network and still refuse to treat it as one, because the bind has not succeeded. In the network adapter properties this shows up as the network name followed by "(Unauthenticated)".

What changed in Windows 11

If you learned this feature on Windows 7 or Windows 10, one thing has moved. Microsoft's support article states it directly: "Starting from Windows 11, the NLA service is no longer responsible for detecting the domain profile. Instead, the Network List Manager does this job." The NCSI documentation says the same thing from the other side: "As of Windows 11, NCSI is hosted within the Network List Manager service, also known as the Network Profile Manager. Previous OS iterations were hosted in the Network Location Awareness (NLA) service."

That is not a trivia point. It changes which binary you look at, which service you restart when you are testing, and which svchost group hosts the code. On a Windows 11 Enterprise device running build 26200.9168 the registry confirms it: both the NlaSvc and netprofm services have ServiceDll set to C:\Windows\System32\netprofmsvc.dll, and both have ImagePath of svchost.exe -k netprofm -p. There is no nlasvc.dll on disk at all.

The race, and why negative caching makes it stick

The race itself is documented. Microsoft's Netlogon and Group Policy troubleshooting article says the behaviour "may be caused by a race condition between network initialization, locating a Domain Controller and processing Group Policy. If the network isn't available, a Domain Controller won't be located, and Group Policy processing will fail." The same article lists the underlying causes, and all of them apply equally to NLA's domain detection because both depend on the same DC reachability.

• The network stack and adapter initialisation start at roughly the same time, and some adapters and switches have link arbitration and MAC uniqueness checks that take longer than the wait allowed.
• 802.1X authentication delays connections to domain controllers.
• The client waits on DHCP for an address, which delays the interface appearing at all.
• Health-verification solutions (NAC and similar) hold the new member in a quarantine network first.

Now the part that turns a two-second glitch into a ten-minute outage: caching of the failure. Microsoft's article on the VPN variant of this bug spells out the sequence, and names two caches with documented defaults.

So the first attempt fails because the route or the DNS server was not ready yet. The failure is cached. The retry fails against the cache rather than the network. The device stays Public until something else forces a fresh evaluation.

The VPN case, which is chronic rather than occasional

Microsoft documents this specifically for third-party VPN clients, in KB4550028. The cause is "a time lag in some third-party VPN clients", and the lag "occurs when the client adds the necessary routes to the domain network".

The flow Microsoft describes is worth internalising because it is the same shape as the boot-time race, just triggered by a tunnel instead of a link-up. The VPN interface is created and gets an address. The VPN client is responsible for adding the routes that make the VPN DNS server reachable. The first route change already triggers NCSI detection and domain detection. If the SRV lookup happens before the route to the VPN DNS server exists, DsGetDcName returns ERROR_NO_SUCH_DOMAIN and that result is cached.

Registry: the whole NetworkList surface

Everything Windows remembers about networks lives under one parent key. Microsoft's support article confirms the location: "The information gathered by NLA is curated by the Network List Service (NLS) service and stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList."

One more genuine observation worth reporting: on a live domain-joined device, a profile with Managed = 1 and a signature under Signatures\Managed can still carry Category = 0. The device remembers the network as corporate and remembers the last category it settled on as Public. That combination in the registry is the fossil record of a flap.

System files, services and the scheduled task

These are the binaries actually in the flow. All of them were confirmed present on Windows 11 Enterprise 25H2, build 26200.9168, and the descriptions are the ones Windows itself reports in the file version resource.

The services, with their short and display names, and the state you should expect.

There is exactly one scheduled task in this feature area, and it exists on Windows 11 today: \Microsoft\Windows\NlaSvc\WiFiTask. It runs %SystemRoot%\System32\WiFiTask.exe with the argument nla, and Windows describes it as a "Background task for performing per user and web interactions". It is a supporting task, not the classification engine, and there is nothing in it for you to tune. Do not disable it as a troubleshooting step.

Event Viewer: the complete catalog

Four channels matter, and two of them are where you will spend your time. Provider metadata below was read from the live providers on Windows 11 25H2, so these are the real IDs and the real message templates.

The other two channels are Microsoft-Windows-NCSI/Operational and Microsoft-Windows-NCSI/Analytic for connectivity-level questions, and Microsoft-Windows-NetworkLocationWizard/Operational for the interactive "make this network private" prompt. Neither decides the Domain category.

How to verify: read the category, then read the events

Work in this order. Current state first, because it is one command and it either exonerates or convicts the theory immediately.

This first command asks Windows what category each connected network is in right now, and what that means for the firewall. Get-NetConnectionProfile returns one object per connected network; NetworkCategory is the documented property, with accepted values Public, Private and DomainAuthenticated.

If the category is wrong, walk the same three steps Windows walks. Each command below tests exactly one link in the chain, so whichever one fails first is your root cause.

Now the timeline. This is the query that proves flapping happened, and when.

Finally, the registry. This is where you find evidence of a flap that happened before the event channel wrapped, because the stored profile keeps the last category it settled on.

The fix: shrink the window, then stop depending on the DC

There are two families of mitigation and they are not alternatives. The first shrinks the race window so the device is far more likely to classify correctly on the first attempt. The second removes the dependency on DC reachability entirely for the purpose of naming the network. Do the first everywhere. Do the second if you have remote and VPN users, which you do.

Fix 1: make startup wait for the network

The setting is "Always wait for the network at computer startup and logon", and it is worth being precise about what it does, because its name oversells it. It does not set a firewall profile and it does not force a category. What it changes is whether Group Policy processing is synchronous. Microsoft's wording: "If you enable this policy setting, computers wait for the network to be fully initialized before users are logged on. Group Policy is applied in the foreground, synchronously." By default on client computers that processing is asynchronous, users log on with cached credentials, and policy is applied in the background afterwards.

The reason it helps here is indirect but real: holding logon until the network is genuinely initialised means the domain-detection attempt is far less likely to run before routes, DNS and DC reachability exist. It buys the classification a fair race. The cost is slower logons, and you should measure that before you deploy it broadly.

In the Group Policy Editor:

1. Open the Group Policy Management Console on a management workstation, or gpedit.msc for a single machine.
2. Create or edit a GPO linked to the OU holding your domain-joined Windows 11 devices.
3. Expand Computer Configuration, then Policies, then Administrative Templates, then System, then Logon.
4. Double-click Always wait for the network at computer startup and logon.
5. Select Enabled, then Apply and OK.
6. On a test device run gpupdate /force, restart twice, and confirm the value at HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon value name SyncForegroundPolicy.

In Intune this is an ADMX-backed policy, so it goes in as a custom OMA-URI rather than a Settings Catalog toggle:

1. Sign in to intune.microsoft.com as at least an Intune Administrator.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Platform Windows 10 and later, profile type Templates, then Custom, then Create.
4. Name it something you will recognise in six months, such as Win11 - Wait for network at startup.
5. On Configuration settings choose Add.
6. OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ADMX_Logon/SyncForegroundPolicy
7. Data type String. The value is the ADMX-backed enable payload, <enabled/>. Microsoft's "Understanding ADMX-backed policies" page has the exact SyncML shape if you need to wrap it.
8. Save, assign to a pilot group of no more than twenty devices, and create the profile.
9. After a sync, confirm on a device with the same registry check as step 6 above.

Fix 2: give Group Policy explicit wait times

Two related policies let you override the wait times Windows computes for itself. Microsoft's Netlogon and Group Policy article recommends both by name for exactly this class of problem: "Specify startup policy processing wait time" for corporate LAN and WLAN, and "Specify workplace connectivity wait time for policy processing" for external LAN and WLAN.

1. In the same GPO, expand Computer Configuration, then Policies, then Administrative Templates, then System, then Group Policy.
2. Open Specify startup policy processing wait time, set Enabled, and enter a value in minutes. The ADMX permits 1 to 600. Base it on how long your slowest site actually takes to reach a DC, measured, not guessed.
3. Open Specify workplace connectivity wait time for policy processing, set Enabled, and enter a value in seconds. Same 1 to 600 range. This is the one that matters for VPN and Always On VPN users.
4. Both write to HKLM\SOFTWARE\Policies\Microsoft\Windows\System, as GpNetworkStartTimeoutPolicyValue and CorpConnStartTimeoutPolicyValue.

Note the different units. The startup policy is expressed in minutes and the workplace connectivity policy in seconds. Getting that backwards is a very easy way to configure a ten-hour wait.

Fix 3: stop caching the failure

This is Microsoft's documented workaround for the VPN variant, and it is the one to reach for when the classification does not self-correct rather than merely correcting late. KB4550028's instruction is to "disable negative cache to help the Network Location Awareness (NLA) service when it retries domain detection".

Fix 4: the modern answer, and the one to actually plan for

Everything above makes the DC-dependent race more likely to be won. This one removes the dependency. The NetworkListManager Policy CSP lets you nominate an internal HTTPS endpoint; if the device can resolve and reach it over HTTPS, "the network would be considered authenticated" and you supply the name that network is given. Microsoft's firewall documentation points at this explicitly as "another option to detect the domain network", and notes that it "applies to Microsoft Entra joined devices too".

Microsoft's requirements for the endpoint are specific, and every one of them is a real-world failure mode if you skip it. The HTTPS endpoint must not require any further authentication such as sign-in or MFA. It must be an internal address not reachable from outside the organisational network. The client must trust the server certificate, so the issuing CA must be in the machine root store. The certificate must not be a public certificate. Microsoft's own test is that Invoke-WebRequest -Uri https://nls.corp.contoso.com -Method get -UseBasicParsing -MaximumRedirection 0 returns StatusCode 200.

1. Stand up the internal HTTPS endpoint first and prove it with the Invoke-WebRequest test above from a client that trusts your internal CA. Do not configure policy against an endpoint you have not tested.
2. In intune.microsoft.com go to Devices, then Configuration, then Create, then New policy.
3. Platform Windows 10 and later, profile type Settings catalog, then Create.
4. Name it, for example Win11 - Network List Manager TLS authentication.
5. On Configuration settings choose Add settings and search the picker for Network List Manager.
6. Select Allowed Tls Authentication Endpoints and Configured Tls Authentication Network Name. Add Unidentified Networks Location Type and Identifying Networks Location Type if you also want to control those.
7. Fill in your endpoint URL or URLs, and the network name. If you use Always On VPN Trusted Network Detection, the name must be the DNS suffix configured in the profile's TrustedNetworkDetection attribute, because that is what the VPN stack compares against.
8. If the setting is not in your tenant's picker, fall back to a Custom profile with the OMA-URIs in the table. For a custom profile Microsoft's documented list format is <![CDATA[https://nls.corp.contoso.com&#xF000;https://nls.corp.fabricam.com]]>.
9. Assign to a pilot group, sync a device, and verify with Get-NetConnectionProfile that the network now reports the name you configured.

Fix 5: the second, different GPO location

This is the one people miss, because it is not in Administrative Templates at all. Network List Manager Policies is a security extension. Microsoft documents the location precisely: "The Network List Manager Policies are located at the following path in Group Policy Object Editor: Computer Configuration | Windows Settings | Security Settings | Network List Manager Policies."

1. In the GPO editor expand Computer Configuration, then Windows Settings, then Security Settings, then Network List Manager Policies.
2. Open Unidentified Networks. On the Network Name tab set Location type to Private or Public, and set User permissions to allow or block users changing it.
3. Open Identifying Networks and set its Location type. This governs the temporary state while Windows is still working the network out, which is the "Identifying..." entry in your event log.
4. Open All Networks to control whether users can change the network name, location or icon for any network.
5. Because this is a security extension rather than an ADMX template, there is no Administrative Templates path and no documented registry value name to verify against. Confirm the applied result with Get-NetConnectionProfile and with gpresult /h, not by hunting for a registry value.

Fix 6: for VPN fleets, wire up Trusted Network Detection

If you run Always On VPN, the classification problem and the tunnel-trigger problem are the same problem. Trusted Network Detection is configured through VPNv2/<ProfileName>/TrustedNetworkDetection in the VPNv2 CSP and takes a list of DNS suffixes. The VPN stack compares the physical interface's connection profile against that list; if it matches and the network is Private or provisioned by MDM, the VPN does not trigger. That is why Microsoft's CSP documentation says the ConfiguredTlsAuthenticationNetworkName value "must be the DNS suffix that is configured in the TrustedNetworkDetection attribute" when you use the two together. Configure them as a pair or neither will behave the way you expect.

Proof it worked: a real run on a real device

The companion script for this post is Get-NetworkCategoryHistory.ps1. It is read-only by design: it never sets a category, never touches a firewall setting, never starts or stops a service and never writes a registry value. It gathers the current category per interface, the firewall profile state, the stored NetworkList profiles with decoded connect times, the policy state for every setting discussed above, and the recent identification events, then gives you a flapping verdict.

It fails loud. If it is not elevated it aborts rather than printing empty tables that look like a healthy device, and if any individual read fails it says so and exits non-zero rather than letting you read a partial report as a clean one.

The following is genuine output from an elevated run on Windows 11 Enterprise 25H2, build 26200.9168, with the computer name, network names and interface GUIDs replaced. Nothing here is invented.

The second half of the run is the event timeline, and this is where the mechanism stops being theory.

That is the whole diagnosis in one screen. The device is domain-managed. It remembers the corporate network twice. The stored category on the managed profile is Public. Domain detection was failing with LDAP errors while off-network, and when it did succeed it succeeded as a category change rather than as the initial classification. No mitigation is configured. If a user on this device reported that a Domain-scoped rule was not working after a boot, you would now be able to say when, for how long, and why.

Grab the script here: github.com/Imran76Awan/Windows-11-Scripts. Run it elevated. It changes nothing.

References

• Domain-joined machines can't detect the domain profile - the definitive walkthrough of the DsGetDcName, TCP 389 and LDAP bind chain, the NetworkList registry keys, and the Windows 11 change of ownership from NLA to the Network List Manager.
• Windows Firewall overview - the three profiles, the statement that Domain cannot be set manually, and the pointer to the NetworkListManager CSP.
• NetworkListManager Policy CSP - every OMA-URI, allowed value and endpoint requirement for TLS-based network authentication.
• Firewall profile doesn't switch to Domain when you use a third-party VPN (KB4550028) - the route-timing cause and the NegativeCachePeriod and MaxNegativeCacheTtl workaround with documented defaults.
• Netlogon event ID 5719 or Group Policy event 1129 - the documented race condition between network initialisation, DC location and Group Policy, plus the wait-time policies and GpNetworkStartTimeoutPolicyValue.
• ADMX_Logon Policy CSP - SyncForegroundPolicy, its exact wording, its System > Logon location and its Winlogon registry value.
• Network List Manager policies - the Security Settings GPO path and the Unidentified Networks, Identifying Networks and All Networks options.
• NLM_NETWORK_CATEGORY and NLM_DOMAIN_TYPE - the category and domain-type numeric values.
• Network Connectivity Status Indicator overview - active and passive probing, the NlaSvc\Parameters\Internet registry path, and the confirmation that NCSI moved into the Network List Manager service on Windows 11.
• Network Location Awareness Service Provider (NLA) - what NLA is, in Microsoft's own words.
• VPNv2 CSP - the TrustedNetworkDetection node used with ConfiguredTlsAuthenticationNetworkName.

No community or MVP deep-dive on this specific mechanism verified as both reachable and genuinely on topic during research for this post, so no MVP reference table is included rather than risk pointing you at something that does not cover it.