Troubleshooting IPv6 Resolution in Windows Server Environment When IPv6 is Disabled


2 views

In my Windows Server infrastructure consisting of a Domain Controller (DC), Exchange Server, and Applications Server, I encountered unexpected IPv6 resolution despite having IPv6 disabled across all Network Interface Cards (NICs). The behavior manifests differently depending on the communication direction:

# Ping behavior observed:
DC ↔ Any Server: IPv4 response (expected)
Exchange ↔ Apps Server: IPv6 response (unexpected)

All servers run Windows Server 2019 with the following configuration:

  • IPv6 disabled in NIC properties (unchecked in GUI)
  • Active Directory-integrated DNS
  • BlackBerry Enterprise Server (BES) installed on Apps Server

The IPv6 resolution causes complete communication failure between BES and Exchange when using hostnames:

# Successful connection using explicit IPv4
Set-BESConfig -ExchangeServer "192.168.1.100" # Works

# Failed connection using hostname
Set-BESConfig -ExchangeServer "EXCH01" # Fails

Through network tracing (netsh trace) and DNS debugging (nslookup), I discovered several key points:

# DNS query results in PowerShell
Resolve-DnsName EXCH01 | Format-Table -AutoSize

Name Type TTL Section IPAddress
---- ---- --- ------- ---------
EXCH01 AAAA 1200 Answer fe80::a1b2:c3d4:e5f6
EXCH01 A 1200 Answer 192.168.1.100

The Windows TCP/IP stack prioritizes IPv6 even when disabled in GUI, due to:

  • Link-Local IPv6 addresses being automatically generated
  • Default address selection policy favoring IPv6
  • DNS client behavior in Windows Server

1. Registry Modifications to Disable IPv6

Create a .reg file with the following content:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:ffffffff

2. DNS Configuration Adjustments

Remove IPv6 records from DNS:

# PowerShell to remove IPv6 records
Get-DnsServerResourceRecord -ZoneName "domain.local" -Name "EXCH01" -RRType "AAAA" | 
Remove-DnsServerResourceRecord -ZoneName "domain.local" -Force

3. Network Binding Order Adjustment

Using PowerShell to modify binding order:

# Get current binding order
Get-NetIPInterface | Sort-Object -Property InterfaceMetric | 
Format-Table -AutoSize -Property ifIndex,InterfaceAlias,AddressFamily,InterfaceMetric

# Set IPv4 to higher priority
Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 10
Set-NetIPInterface -InterfaceIndex 12 -AddressFamily IPv6 -InterfaceMetric 100

4. Application-Specific Workarounds

For BES configuration, implement a hosts file entry:

# Add to %SystemRoot%\System32\drivers\etc\hosts
192.168.1.100 EXCH01.domain.local EXCH01

After implementing all changes, verify with:

# Check IPv6 state
Get-NetAdapterBinding -ComponentID "ms_tcpip6"

# Test connectivity
Test-NetConnection EXCH01 -TraceRoute -InformationLevel Detailed

# Check DNS resolution
nslookup -type=A EXCH01
nslookup -type=AAAA EXCH01

The complete solution ensures consistent IPv4 communication while maintaining all server functionality. Remember to reboot servers after registry changes and test all dependent services.

Recently while configuring a BlackBerry Enterprise Server (BES) installation, I encountered a peculiar networking behavior where Windows servers were resolving hostnames to IPv6 addresses despite having IPv6 disabled in NIC properties. Here's what my environment looked like:

Network Topology:
- DC01 (Domain Controller): IPv4-only communication
- EXCH01 (Exchange Server): Unexpected IPv6 responses
- APPS01 (Application Server): BES installation failing

Key observations that pointed to an underlying issue:

  • Ping from DC01 → EXCH01/APPS01: IPv4 response (expected)
  • Ping between EXCH01 ↔ APPS01: IPv6 response (unexpected)
  • BES configuration failing on hostname resolution despite working with hardcoded IPv4

After extensive testing, I discovered several important factors:

1. netsh interface ipv6 show interface
   -> Revealed IPv6 was still active on some interfaces

2. Checking registry settings:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
   -> DisabledComponents value was missing

The core issue stems from Windows Server's dual-stack implementation where unchecking IPv6 in NIC properties doesn't fully disable IPv6 at the TCP/IP stack level.

To properly disable IPv6 and force IPv4 resolution:

# PowerShell - Full IPv6 Disable Script
$registryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters"
$name = "DisabledComponents"
$value = "0xffffffff" # All IPv6 components disabled

if (-not (Test-Path $registryPath)) {
    New-Item -Path $registryPath -Force | Out-Null
}
Set-ItemProperty -Path $registryPath -Name $name -Value $value -Type DWord

# Restart required for changes to take effect
Write-Host "IPv6 completely disabled. System restart required."

After implementing the fix:

  1. Confirm IPv6 is disabled: Get-NetAdapterBinding -ComponentID ms_tcpip6
  2. Clear DNS cache: Clear-DnsClientCache
  3. Test resolution: Test-NetConnection EXCH01 -TraceRoute

The BES installation completed successfully after these changes, with all communication properly using IPv4 addresses.

For environments where IPv6 cannot be completely disabled:

# Force IPv4 precedence in DNS resolution
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "AddrConfigControl" -Value 0

# Modify prefix policies to prefer IPv4
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 4
netsh interface ipv6 set prefixpolicy 2002::/16 40 3
netsh interface ipv6 set prefixpolicy ::/0 30 1