Error 400: Bad Request in Exchange - Fix Guide 2025

HTTP Error 400 Bad Request prevents users from accessing Outlook Web App (OWA), Exchange Admin Center (ECP), or Exchange Web Services (EWS). This error indicates the server cannot process the request due to malformed syntax, oversized headers, or corrupted cookies. This guide shows you how to quickly diagnose and fix Error 400 issues.

Our Exchange Web Access Services team resolves Error 400 issues within minutes. This guide provides the same diagnostic process we use.

Error Overview: What HTTP 400 Means

HTTP 400 Bad Request is a client error response indicating the server cannot or will not process the request due to something perceived as a client error. In Exchange environments, this typically involves request formatting, cookie corruption, or header size limits.

HTTP Error 400.0 - Bad Request
The request could not be understood by the server due to malformed syntax.
The client should not repeat the request without modifications.

Most likely causes:
- The request contained invalid characters
- The request headers are too large
- The request URL is too long

Symptoms & Business Impact

What Users Experience:

• Browser shows "400 Bad Request" when accessing OWA login page
• OWA loads partially then fails with Error 400
• ECP (Exchange Admin Center) inaccessible to administrators
• ActiveSync devices showing sync failures
• Third-party apps using EWS cannot connect

What Admins See:

• IIS logs show HTTP 400 responses with sc-status 400
• Specific users affected while others work normally
• Error appears after browser or Windows updates
• Intermittent errors that resolve after browser restart

Common Causes of Error 400

1. Corrupted Browser Cookies (40% of cases)

Most Common Cause: Browser cookies for the Exchange site become corrupted or contain invalid data that the server cannot parse.

Identified by: Error clears when using incognito/private browsing mode

2. Request Header Too Large (25% of cases)

IIS Limit: Accumulated cookies or long authentication headers exceed IIS default maxRequestLength (16KB) or maxAllowedContentLength limits.

Identified by: Error appears after logging into many Exchange accounts in same browser

3. Browser Extensions/Add-ons (15% of cases)

Interference: Security extensions, ad blockers, or VPN browser extensions modify requests in ways Exchange cannot handle.

Identified by: Error clears when extensions are disabled

4. Proxy or Security Gateway (10% of cases)

Network Issue: Web proxy, firewall, or security appliance modifies or blocks portions of the HTTP request.

Identified by: Error appears for users behind specific network devices

5. IIS Request Filtering (10% of cases)

Server Configuration: IIS request filtering rules are too restrictive, blocking legitimate Exchange requests.

Identified by: Error affects all users after IIS or Exchange configuration change

Quick Diagnosis Steps

# Find 400 errors in IIS logs
$logPath = "C:\inetpub\logs\LogFiles\W3SVC1"
Get-ChildItem $logPath -Filter "*.log" | Sort-Object LastWriteTime -Descending | Select-Object -First 1 |
    Get-Content | Select-String " 400 " | Select-Object -Last 20

# Check for specific 400 substatus codes
Get-Content (Get-ChildItem $logPath -Filter "*.log" | Sort-Object LastWriteTime -Descending | Select-Object -First 1).FullName |
    Select-String "400 0|400 1|400 2"0|400 1|400 2" | Select-Object -Last 10

# Check current request limits
Import-Module WebAdministration

# Get maxAllowedContentLength (default 30MB)
Get-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/owa' -filter "system.webServer/security/requestFiltering/requestLimits" -name "maxAllowedContentLength"

# Get maxUrl and maxQueryString
Get-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/owa' -filter "system.webServer/security/requestFiltering/requestLimits" -name "maxUrl"
Get-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/owa' -filter "system.webServer/security/requestFiltering/requestLimits" -name "maxQueryString"

Quick Fix (5 Minutes) - Clear Browser Data

⚠️ Try this first if:

• Error appears in one browser but not another
• Private/incognito mode works
• Other users on same network can access OWA

Solution: Clear Cookies for Exchange Site

✅ Expected Result:

• OWA login page loads without Error 400
• User can authenticate and access mailbox
• No errors in browser developer console (F12)

Detailed Solution: Server-Side Fixes

If client-side fixes don't work, or if Error 400 affects multiple users, check server configuration:

Scenario 1: Increase IIS Request Limits

# Import IIS module
Import-Module WebAdministration

# Increase maxUrl limit (default 4096)
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/owa' -filter "system.webServer/security/requestFiltering/requestLimits" -name "maxUrl" -value 8192

# Increase maxQueryString (default 2048)
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/owa' -filter "system.webServer/security/requestFiltering/requestLimits" -name "maxQueryString" -value 4096

# Do the same for ECP
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/ecp' -filter "system.webServer/security/requestFiltering/requestLimits" -name "maxUrl" -value 8192

# Restart IIS
iisreset /restart

Scenario 2: Fix Request Filtering Rules

# List current denied URL sequences
Get-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/security/requestFiltering/denyUrlSequences" -name "."

# Remove overly restrictive rule (example)
# Remove-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/security/requestFiltering/denyUrlSequences" -name "." -AtElement @{sequence=".."}-pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/security/requestFiltering/denyUrlSequences" -name "." -AtElement @{sequence=".."}

# Allow double escaping if needed for special characters
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/security/requestFiltering" -name "allowDoubleEscaping" -value $true

# Restart IIS
iisreset /restart

Scenario 3: Reset OWA Virtual Directory

# Get current OWA settings
Get-OwaVirtualDirectory | Format-List *Url*

# Remove and recreate OWA virtual directory
Remove-OwaVirtualDirectory -Identity "EXCH01\owa (Default Web Site)" -Confirm:$false
New-OwaVirtualDirectory -WebSiteName "Default Web Site" -InternalUrl "https://mail.company.com/owa" -ExternalUrl "https://mail.company.com/owa"

# Restart IIS
iisreset /restart

# Test access
Start-Process "https://mail.company.com/owa"

Verify the Fix

# 1. Test OWA from server
$url = "https://mail.company.com/owa"
try {
    $response = Invoke-WebRequest -Uri $url -UseDefaultCredentials -TimeoutSec 30
    "OWA Status: $($response.StatusCode)"
} catch {
    "Error: $($_.Exception.Message)"
}

# 2. Check IIS logs for new 400 errors400 errors
$logPath = "C:\inetpub\logs\LogFiles\W3SVC1"
$recentLog = Get-ChildItem $logPath -Filter "*.log" | Sort-Object LastWriteTime -Descending | Select-Object -First 1
Get-Content $recentLog.FullName | Select-String " 400 " | Select-Object -Last 5

# 3. Test from different client
# - Ask affected user to clear cookies and retry
# - Test from another workstation
# - Verify in private browsing mode

✅ Success Indicators:

• OWA login page loads without Error 400
• Users can authenticate successfully
• No new 400 errors in IIS logs
• ECP and EWS also working

Prevention: Avoid Future Error 400

1. Regular Browser Maintenance

• Encourage users to periodically clear browser cookies
• Avoid using multiple Exchange accounts in same browser profile
• Use browser profiles for different Exchange organizations

2. Appropriate IIS Configuration

• Don't reduce default IIS request limits
• Test request filtering changes in lab before production
• Document any IIS customizations for troubleshooting

3. Browser Extension Management

• Whitelist Exchange URLs in security extensions
• Disable unnecessary extensions when accessing OWA
• Test OWA access after installing new extensions