Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Firewall Rules Stopped After a Move? Check the Profile

Technical article
Troubleshooting

Direct answer: Windows Firewall rules are enabled per profile: Domain, Private and Public. Windows picks the profile per network connection. A domain-joined server gets the Domain profile on a connection only when it can find and authenticate to a domain controller through it; Microsoft states a new network is Public by default. A rule enabled only for the Domain profile then does not apply, and services that worked before a migration, restore, NIC replacement or re-addressing can be refused. Read each connection's category with Get-NetConnectionProfile, trace which domain-detection step fails (domain controller discovery, TCP 389, LDAP bind) and fix that dependency. The category is one explanation to test, not the only one; prove access with a test from a client that should be allowed. Do not widen rules to every profile or turn the firewall off.

Why it matters

The symptom looks like a network or application fault: Remote Desktop refuses connections, an application port times out, shares disappear, monitoring goes red. The rules did not change, so a rule review finds nothing wrong. Microsoft's symptom list for this case: network status shows "Unidentified network", the public profile is applied although the machine is joined to the domain, "Firewall rules configured under the domain profile aren't applied, leading to connectivity issues", and internal applications fail.

How it works

Three profiles, one category per connection

Microsoft describes three network location types:

  • Public: "By default, the public network location type is assigned to any new network when the computers are first connected."
  • Private: a local administrator can select it manually for a network not directly accessible to the public.
  • Domain: detected when the computer is a domain member and "can authenticate to a DC for that domain through one of its network connections. An administrator can't manually assign this network location type."

Get-NetConnectionProfile reports this as NetworkCategory with the accepted values Public, Private and DomainAuthenticated. The Set-NetConnectionProfile reference states: "You cannot set the DomainAuthenticated type by using this cmdlet."

Each connection has its own category. A server with two adapters can be Domain on one and Public on the other.

What triggers detection

Microsoft lists the events that trigger network location detection: adding or removing an IP route or address, disconnecting or reconnecting the adapter, disabling or re-enabling it, DHCP events, and changes to Network Connectivity Status Indicator settings. A migration, a restore onto a new virtual NIC or a re-addressing produces several of these.

How Domain is decided, and where the version boundary sits

Microsoft's domain-profile article describes these steps:

  1. Windows calls DsGetDcName to find a domain controller, using DNS records such as _ldap._tcp.<SiteName>._sites.dc._msdcs.<DomainName>.
  2. It opens TCP port 389 to that controller.
  3. It sends an LDAP bind. When the bind succeeds, the connection is identified as the domain network.

If a step fails, the connection does not get DomainAuthenticated.

Version boundary: this is a Windows Client article. It states the location types for Windows 7, Windows Server 2008 R2 and later, and that "Starting from Windows 11, the NLA service is no longer responsible for detecting the domain profile", the Network List Manager does. It does not say whether Windows Server 2025 follows the Windows 11 change, so treat the service that performs detection on Server 2025 as unconfirmed. The three steps are the documented basis for the checks below on every release in scope.

Rule scope and stores

Microsoft's rule guidance is to create rules in all three profiles but enable them only on the profiles that suit the scenario, and to restrict remote addresses where possible. A rule enabled only for Domain does nothing while the connection is Public; the firewall is working as designed.

Rules come from several stores. The Get-NetFirewallRule reference describes ActiveStore as the sum of all policy stores that apply to the computer and RSOP as the read-only sum of all GPOs. The firewall tools page documents a separate failure: with "Process even if the Group Policy objects haven't changed" enabled, if processing fails, "Local Firewall settings are applied instead of group policy settings". A correct profile and an enabled rule therefore do not alone prove the effective policy.

Read-only checks

None of these was run for this article. Run them in Windows PowerShell on the affected server (step 3 from an elevated prompt). Steps 3 to 5 send network traffic to the domain controller but change no configuration.

  1. Category per connection: Get-NetConnectionProfile Note InterfaceAlias, Name and NetworkCategory for each connection. A domain member's production connection is expected to show DomainAuthenticated.
  2. Which rules apply now: Get-NetFirewallRule -PolicyStore ActiveStore Find the rule for the refused service and read its Profile and Enabled values. Compare the profile with step 1, and check the RSOP store to see whether the rule comes from Group Policy.
  3. Domain controller discovery (Microsoft's command; /force asks for fresh discovery rather than a cached result): nltest /dsgetdc:<DomainName> /force A controller name in the output is success. Microsoft gives ERROR_NO_SUCH_DOMAIN as the result when DNS name resolution fails; treat it as a discovery failure and confirm the cause with steps 4 and 5 rather than assuming DNS.
  4. DNS records: resolve _ldap._tcp.<SiteName>._sites.dc._msdcs.<DomainName> with the server's configured resolvers, and confirm those resolvers are reachable from the new network.
  5. TCP 389: Microsoft's example is Telnet <DCName or IP> 389. Without Telnet, the Test-NetConnection cmdlet supports a TCP port test (-Port) and reports TcpTestSucceeded: Test-NetConnection <DCName> -Port 389
  6. LDAP bind: in Network Connections, an adapter shown as <domain> (Unauthenticated) means the bind failed. Read the Microsoft-Windows-NetworkProfile/Operational log for errors.

A note on the registry

Microsoft's domain-profile article also points to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles and gives value meanings 0, 1 and 2 for a "category". Those meanings (not an Active Directory network; an AD network without authentication; authenticated) match the Windows API's NLM_DOMAIN_TYPE enumeration, not NLM_NETWORK_CATEGORY, where 0 is Public, 1 Private and 2 DomainAuthenticated. Because the two enumerations use the same numbers for different meanings, this article does not interpret raw registry numbers; use Get-NetConnectionProfile, which returns the category by name.

Candidate causes

Each is a hypothesis until the evidence confirms it.

Cause Evidence Layer
Domain controller discovery fails nltest returns ERROR_NO_SUCH_DOMAIN; SRV lookup or resolver reachability fails DNS settings or path to resolvers
TCP 389 blocked between server and controller Port test fails while discovery succeeds Network firewall or routing
LDAP bind fails "(Unauthenticated)"; NetworkProfile log errors Computer account or controller health
New virtual NIC classified as a new network New profile name; category Public Domain detection on the new connection; for non-domain servers, a deliberate category decision
Rule enabled only for Domain Profile value Domain; connection Public No rule change needed once the category is right
Firewall policy processing failed Rule absent from RSOP/ActiveStore as expected; tools-page condition Group Policy processing
Something other than the host firewall Correct category and rule, but the allowed-client test still fails Network path, service, other filters

Decision guidance

Everything in this section is a change, needs a change record, and was not executed for this article.

  • Domain member, detection failing: correct the failing dependency (DNS client settings, resolver reachability, the path to TCP 389, or the computer account) through the team that owns it. Detection runs again on the triggers Microsoft lists. Microsoft notes that disabling and re-enabling the adapter, or restarting the Network List Service, may also resolve it; both interrupt connectivity, so plan them from a console session in a window.
  • Non-domain server on a network you control: setting the category to Private with Set-NetConnectionProfile -InterfaceAlias <alias> -NetworkCategory Private is a security decision. Record why the network qualifies.
  • Rule scoped wrongly from the start: correct that rule only, in the store it comes from (the GPO if it appears in RSOP), and keep remote address restrictions.
  • Firewall policy processing failure: treat as a Group Policy problem; see the related Group Policy article.

Then prove the result: from a client that should be allowed, connect to the service itself, and from one that should not, confirm it is still refused.

What not to do

  • Do not enable rules on all profiles to make the symptom disappear; that exposes services on a connection Windows considers public.
  • Do not disable Windows Firewall.
  • Do not try to force DomainAuthenticated; the cmdlet cannot set it.
  • Do not set a domain member's connection to Private to work around failing detection.
  • Do not interpret raw NetworkList registry numbers as profile names.
  • Do not restart the adapter over the Remote Desktop session that uses it.

Limitations

  • No command was run for this article; lab validation is outstanding.
  • The domain-detection mechanism comes from a Windows Client article; Windows Server 2025 behaviour is not separately documented in the retrieved sources.
  • Other host or network filters, Get-NetFirewallProfile and per-profile default actions are not covered.
  • DNS cutover planning and Kerberos failures are covered in separate articles.

Acceptance checklist

  • [ ] Each domain member's production connection shows DomainAuthenticated, or the reason it does not is recorded.
  • [ ] nltest /dsgetdc succeeds from the server.
  • [ ] Each refused service has a rule enabled for the profile its connection uses, in the intended store.
  • [ ] No rule was widened to all profiles as a workaround.
  • [ ] Any Private category on a non-domain server is recorded with the reason.
  • [ ] An allowed client reaches each service, and a client that should be refused is refused.

Sources

Displayed dates as shown when accessed on 30 October 2026.

Related articles

Learning notes

  1. Rules apply per profile, and Windows chooses the profile per connection.
  2. Domain needs controller discovery, TCP 389 and a successful LDAP bind; a new network starts Public.
  3. ERROR_NO_SUCH_DOMAIN is a discovery failure; confirm DNS and reachability before naming the cause.
  4. Read the category by name; registry numbers belong to two different enumerations.
  5. The proof is a real connection from an allowed client, not a profile label.