Medha Cloud
Medha Cloud Exchange Server Team
Exchange Database Recovery Team8 min read

Slow Exchange performance often stems from NTLM authentication bottlenecks, where every connection requires Domain Controller validation. This guide shows you how to identify authentication bottlenecks and optimize Exchange for faster performance.

Our Exchange Performance Team specializes in authentication optimization and performance tuning.

Error Overview: NTLM vs Kerberos

NTLM and Kerberos are authentication protocols. NTLM requires the server to contact a DC for every authentication, while Kerberos uses tickets that can be cached and reused.

Authentication Comparison
# NTLM Authentication Flow (slow):
# 1. Client sends credentials to Exchange
# 2. Exchange contacts Domain Controller
# 3. DC validates credentials
# 4. DC responds to Exchange
# 5. Exchange allows access
# = 2 network round trips per authentication

# Kerberos Authentication Flow (fast):
# 1. Client obtains ticket from DC (cached)
# 2. Client presents ticket to Exchange
# 3. Exchange validates ticket locally
# = 1 round trip, ticket reused for duration

Symptoms & Business Impact

What Users Experience:

  • Outlook takes long to open or refresh
  • Delays when switching folders
  • Slow calendar and free/busy lookups
  • OWA pages load slowly
  • Mobile sync is sluggish

What Admins See:

  • High NTLM authentication load on DCs
  • Exchange RPC latency elevated
  • Users in remote offices more affected
  • Performance improves during off-hours
Check Authentication Method
# Check IIS authentication settings
Import-Module WebAdministration
Get-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" -Filter system.webServer/security/authentication/windowsAuthentication -Name providers | ForEach-Object { $_.Collection }

# Check for NTLM vs Negotiate
Get-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site" -Filter system.webServer/security/authentication/windowsAuthentication -Name enabled

Common Causes

1. Kerberos Not Working (40%)

Missing or incorrect SPNs, time skew between servers, or configuration forcing NTLM fallback.

2. Network Latency to DC (25%)

Remote office users experience delays as each NTLM auth requires DC communication over WAN.

3. DC Overload (20%)

Domain Controllers overwhelmed with authentication requests, especially during peak hours.

4. Load Balancer Issues (15%)

Load balancers not configured for Kerberos delegation, forcing NTLM fallback.

Quick Diagnosis

Step 1: Check Current Authentication Type
# On Domain Controller, check authentication statistics
Get-Counter -Counter "\Security System-Wide Statistics\NTLM Authentications", "\Security System-Wide Statistics\Kerberos Authentications" -SampleInterval 5 -MaxSamples 10 | ForEach-Object {
    $_.CounterSamples | Select-Object Path, CookedValue
}

# High NTLM relative to Kerberos indicates bottleneck
Step 2: Check SPN Configuration
# Check SPNs for Exchange server
$exchangeServer = $env:COMPUTERNAME
setspn -L $exchangeServer

# Check for HTTP SPNs (needed for Kerberos)
# Should see: HTTP/mail.domain.com, HTTP/servername.domain.local

# Check for duplicate SPNs (breaks Kerberos)
setspn -X
Step 3: Test Kerberos
# From client, check if Kerberos ticket exists for Exchange
klist tickets | Select-String "exchange|mail|http"

# If no ticket, Kerberos is not working
# Get a ticket manually
klist get http/mail.domain.com

# Check from Outlook connection status
# Ctrl+Right-click Outlook tray > Connection Status > Authn column should show "Nego""Nego"

Quick Fix

Enable Negotiate Authentication
# Configure IIS to use Negotiate (Kerberos preferred)
Import-Module WebAdministration

# Set authentication for OWA
$sites = @("owa", "ecp", "ews", "Microsoft-Server-ActiveSync"-ActiveSync", "rpc", "mapi")
foreach ($site in $sites) {
    $path = "IIS:\Sites\Default Web Site\$site"
    if (Test-Path $path) {
        # Remove NTLM-only and add Negotiate
        Set-WebConfigurationProperty -PSPath $path -Filter system.webServer/security/authentication/windowsAuthentication/providers -Name "." -Value @{value="Negotiate"}
        Write-Host "Configured $site for Negotiate"
    }
}

iisreset /noforce

Detailed Solutions

Solution 1: Configure SPNs Correctly

Register Required SPNs
# Register SPNs for Exchange
# Run on Domain Controller as Domain Admin

$exchangeServer = "EXCH01"
$exchangeFQDN = "exch01.domain.local"
$externalNames = @("mail.domain.com", "autodiscover.domain.com", "owa.domain.com")

# Register server name SPNs
setspn -S HTTP/$exchangeServer $exchangeServer
setspn -S HTTP/$exchangeFQDN $exchangeServer

# Register external name SPNs
foreach ($name in $externalNames) {
    setspn -S HTTP/$name $exchangeServer
    Write-Host "Registered SPN: HTTP/$name"
}

# Verify SPNs
setspn -L $exchangeServer

Solution 2: Configure for Load Balancer

Load Balancer Kerberos Configuration
# For load-balanced Exchange, use Alternate Service Account (ASA)
# Create ASA credential object

# On all Exchange servers, set the same ASA
$credential = Get-Credential -Message "Enter ASA credentials"

# Configure ASA on each CAS
Set-ClientAccessService -Identity EXCH01 -AlternateServiceAccountCredential $credential
Set-ClientAccessService -Identity EXCH02 -AlternateServiceAccountCredential $credential

# Register SPNs to ASA account instead of individual servers
$asaAccount = "DOMAIN\ExchangeASA"
$loadBalancerName = "mail.domain.com"
setspn -S HTTP/$loadBalancerName $asaAccount

Solution 3: Reduce NTLM Load

Optimize NTLM Performance
# If Kerberos cannot be used, optimize NTLM

# Ensure Exchange servers have nearby DC connectivity
nltest /dsgetdc:domain.local /force

# Add RODC in remote offices to reduce NTLM latency

# Configure Extended Protection for Authentication
Get-OutlookAnywhere | Set-OutlookAnywhere -ExtendedProtectionFlags None -ExtendedProtectionSPNList $null -ExtendedProtectionTokenChecking None

# Consider enabling NTLM v2 only (more secure and faster)
# Via Group Policy: Network Security: LAN Manager authentication level
# Set to: Send NTLMv2 response only. Refuse LM & NTLM

Verify the Fix

Verify Kerberos is Working
# Check authentication counters after changes
Write-Host "Monitoring authentication for 60 seconds..."
$samples = Get-Counter -Counter "\Security System-Wide Statistics\NTLM Authentications", "\Security System-Wide Statistics\Kerberos Authentications" -SampleInterval 10 -MaxSamples 6

$samples | ForEach-Object {
    $ntlm = ($_.CounterSamples | Where-Object { $_.Path -like "*NTLM*" }).CookedValue
    $kerb = ($_.CounterSamples | Where-Object { $_.Path -like "*Kerberos*" }).CookedValue
    Write-Host "NTLM: $ntlm / Kerberos: $kerb"$kerb"
}

# On client, verify Kerberos ticket
klist tickets | Select-String "http"

# Check Outlook connection status shows "Nego" authentication

Prevention Tips

Best Practices

  • Always use Negotiate authentication (Kerberos with NTLM fallback)
  • Properly configure SPNs during Exchange deployment
  • Document SPN configuration in runbooks
  • Monitor authentication counters on DCs
  • Place DCs near Exchange servers and remote offices
  • Use ASA for load-balanced deployments

When to Escalate

Contact Exchange specialists if:

  • Kerberos cannot be enabled due to complex topology
  • Load balancer delegation issues persist
  • Performance remains poor after optimization
  • Multi-forest or cross-domain scenarios

Need Expert Help?

Our Exchange Performance Team provides comprehensive authentication optimization including Kerberos configuration and load balancer integration.

Frequently Asked Questions

NTLM requires a round-trip to the Domain Controller for each authentication, creating latency. With many concurrent connections, this becomes a bottleneck. Kerberos uses cached tickets, reducing DC load and improving performance.

Still Stuck? We Can Help

Our Exchange Server experts have resolved thousands of issues just like yours.

  • Remote troubleshooting in 95 minutes average
  • No upfront commitment or diagnosis fees
  • Fix-it-right guarantee with documentation
Get Expert Help
95 min
Average Response Time
24/7/365 Availability
Medha Cloud

Medha Cloud Exchange Server Team

Microsoft Exchange Specialists

Our Exchange Server specialists have 15+ years of combined experience managing enterprise email environments. We provide 24/7 support, emergency troubleshooting, and ongoing administration for businesses worldwide.

15+ Years ExperienceMicrosoft Certified99.7% Success Rate24/7 Support