When your OWA server in the DMZ keeps connecting to geographically distant domain controllers despite having local DCs available, you're witnessing a common Active Directory site topology issue. The Windows Server's default DC locator process doesn't always respect physical proximity when sites aren't properly configured in Active Directory Sites and Services.

First, confirm your AD site structure with PowerShell:

# Check which site your server believes it's in
nltest /dsgetsite

# Verify all domain controllers and their sites
Get-ADDomainController -Filter * | Select-Object Name,Site

For Exchange OWA specifically, you can implement these solutions:

Option 1: Registry Modification

# Create/modify this registry key
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" 
    -Name "SiteName" -Value "YourLocalSiteName"

# For immediate effect without reboot
Restart-Service Netlogon

Option 2: Hosts File Enforcement

# Add to %SystemRoot%\System32\drivers\etc\hosts
192.168.1.10    preferred-dc.yourdomain.com # Your local DC IP and FQDN

Create a GPO specifically for DMZ servers with these settings:

# PowerShell to configure via GPO
$gpo = "DMZ_Servers_Policy"
Set-GPRegistryValue -Name $gpo -Key "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" 
    -ValueName "AvoidPdcOnWan" -Type DWord -Value 1
Set-GPRegistryValue -Name $gpo -Key "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" 
    -ValueName "LdapSrvWeight" -Type DWord -Value 100

# Check which DC is being used for authentication
klist

# Continuous monitoring script
while($true) {
    $logonServer = $env:LOGONSERVER
    $currentTime = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$currentTime - Authenticating against: $logonServer" | Out-File "C:\logs\DCLog.txt" -Append
    Start-Sleep -Seconds 300
}

When your OWA server resides in a DMZ without local domain controllers, Windows' default site-aware DC discovery mechanism may fail to prioritize nearby DCs. This occurs because:

• DMZ networks often have different Active Directory sites than internal LANs
• Firewall rules may inadvertently affect DC communication
• NetLogon service uses complex algorithms for DC selection

For Exchange OWA servers, we can implement DC targeting through these methods:

Method 1: Registry Modification

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters]
"SiteName"="YOUR_LOCAL_SITE_NAME"
"DynamicSiteName"=dword:00000000
"SiteCoverage"="YOUR_LOCAL_SITE_NAME"

Method 2: PowerShell Scripting

# Force OWA to use specific DC
$preferredDC = "dc01.yourdomain.local"
$services = @("MSExchangeServiceHost","W3SVC","IISADMIN")

foreach ($service in $services) {
    sc.exe config $service depend= "RPCSS/Netlogon/$preferredDC"
}

# Validate DC connection
Test-Connection $preferredDC -Count 1
nltest /dsgetdc:yourdomain.local /server:$preferredDC

Combine these technical solutions with proper network design:

• Ensure correct AD site/subnet mapping in Active Directory Sites and Services
• Configure firewall rules to allow only necessary ports (LDAP, Kerberos, etc.)
• Set proper DNS priorities for DC resolution

For Exchange OWA servers specifically:

# Exchange 2016/2019 specific configuration
Set-ExchangeServer -Identity "OWASERVER" -StaticDomainControllers "dc01.yourdomain.local"
Set-ExchangeServer -Identity "OWASERVER" -StaticConfigDomainControllers "dc01.yourdomain.local"
Set-ExchangeServer -Identity "OWASERVER" -StaticExcludedDomainControllers "*.remote.site"

Implement these verification steps:

# Check current DC usage
Get-EventLog -LogName System -Source "NetLogon" -After (Get-Date).AddHours(-1) | 
    Where-Object {$_.Message -like "*Selected domain controller*"}

# Continuous monitoring script
while($true) {
    $dc = (nltest /dsgetdc:yourdomain.local)[3].Split(':')[1].Trim()
    Write-Host "$(Get-Date) - Connected to: $dc"
    Start-Sleep -Seconds 300
}