2025 Network Profile KB ID 0001918

Problem

If you have a domain controller running Windows server 2025 you may find that after a reboot the network profile changes from Domain to Public. This can cause a myriad of problems.

2025 Network Profile Group Policy Failures

• Symptoms: Group Policy Objects (GPOs) may fail to apply or update.

• Reason: The system doesn’t recognize it’s part of a domain, so it won’t retrieve policies from the domain controller (including its own policies).

2025 Network Profile Active Directory Replication Issues

• Symptoms: DCs can’t replicate with other DCs.

• Reason: Domain profile allows AD ports (e.g., TCP 135, 389, 636, 3268, etc.); Public profile has restrictive firewall rules.

2025 Network Profile DNS Failures

• Symptoms: DNS server on the DC might not respond to queries.

• Reason: Public firewall profile may block DNS port (TCP/UDP 53), making the server unreachable for name resolution.

2025 Network Profile Domain Join and Authentication Failures

• Symptoms: Clients can’t join the domain or authenticate.

• Reason: Public firewall blocks Kerberos (TCP/UDP 88), LDAP (TCP 389), and other domain services.

2025 Network Profile Remote Management Blocked

• Symptoms: You can’t manage the DC remotely (e.g., via MMC, PowerShell Remoting, or RDP).

• Reason: Public profile disables many inbound management services (RDP, WMI, etc.).

SYSVOL and Netlogon Share Unavailable

• Symptoms: Clients can’t access logon scripts or policy files.

• Reason: These shares are blocked by default in Public firewall mode.

Failures in Server Roles or Applications

• Symptoms: Roles or applications dependent on domain access (e.g., file servers, certificate services) may fail.

• Reason: Services rely on the DC being fully domain-aware and reachable.

Solution : 2025 Network Profile

Theres TWO Solutions for this problem, either run a statup script to restart any NIC set to ‘public’, OR add an IPv6 address and make three registry changes.

Option 1 – Startup Script to Restart Network Adaptors

Despite a lot of posts about delaying the start of the NLA (network location awareness) service, or making it dependant on DNS, or changing a raft of registry keys, NONE of those solutions worked for me, even Microsoft say, the way to fix this is to disable and re-enable the network adaptor, like so.

Well that’s great but not very practical! So instead (until its fixed properly) I’ve written a startup script that will check the network cards and if they come up with a public profile and not a domain one, it will restart the card. I’ve tested it in the lab and it works.

Save the following PowerShell in a file called Fix-NetworkCategory.ps1 save it into C:\Startup-Scripts

$profiles = Get-NetConnectionProfile

foreach ($profile in $profiles) {
    if ($profile.NetworkCategory -eq "Public") {
        $interfaceAlias = $profile.InterfaceAlias
        Write-Host "Restarting adapter: $interfaceAlias (Public network)"
        Restart-NetAdapter -Name $interfaceAlias -Confirm:$false
    }
}

So it looks like this.

Create a new scheduled task (Basic Task) > Call it Reset-NIC > Set it to “When the computer starts” > Start a program > set the program script to.

powershell.exe -ExecutionPolicy Bypass -File "C:\Startup-Scripts\Fix-NetworkCategory.ps1"

Because we are setting other parameters you will get the following prompt, click yes.

Finish.

Note: If you have any problems with the script executing simply change the run as parameter to SYSTEM.

Then don’t forget to reboot to test!

Option 2 – Add an IPv6 Address, and Change Some Registry Settings

This problem is actually caused by…..

The issue involves an LDAP packet attempting to reach the loopback address (::1) via the IPv6 interface. However, the packet is being dropped. This situation results in a timeout when connecting to the loopback address, which in turn leads to the domain controller experiencing prolonged boot times and incorrect detection of the Network Location Awareness (NLA) status for the network interface and firewall profile. This behaviour was initially identified in Windows Server 2019, addressed in Server 2022, but has re-emerged in the 2025 release.

However, adding an IPv6 address fd12:3456:789a:0001:0000:0000:0000:0063/64 * (on its own) did not work, for me.

*Note: This is a Prefix: fd00::/8 it’s reserved for Unique Local Addresses, the IPv6 equivalent of IPv4 private addresses (like 192.168.0.0/16 or 10.0.0.0/8).

For this to work, you also need to set the following THREE Registry keys.

# Set NegativeCachePeriod to 0 (disables Netlogon domain discovery negative caching)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" `
    -Name "NegativeCachePeriod" -Value 0 -PropertyType DWord

# Set MaxNegativeCacheTtl to 0 (disables DNS negative caching)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
    -Name "MaxNegativeCacheTtl" -Value 0 -PropertyType DWord -Force

# Set AlwaysExpectDomainController to 1 (ensures NLA expects a domain controller)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters" `
    -Name "AlwaysExpectDomainController" -Value 1 -PropertyType DWord -Force

THEN the IPv6 solution will work.

Related Articles, References, Credits, or External Links

NA