Event ID 1035: Autodiscover Failed - Complete Fix Guide
Complete troubleshooting guide for Exchange Server Event ID 1035 Autodiscover failures. Learn to diagnose SCP issues, DNS configuration, certificate problems, and restore automatic Outlook profile configuration.
Table of Contents
Understanding Event ID 1035: Autodiscover Failed
📌 Version Compatibility: This guide applies to Exchange Server 2016, Exchange Server 2019, Exchange Server 2022 (SE). Commands may differ for other versions.
Event ID 1035 indicates that Exchange Server's Autodiscover service failed to respond to a client request. Autodiscover is the critical service that enables Outlook and mobile devices to automatically configure email settings, including server addresses, authentication methods, and feature availability. When Autodiscover fails, users cannot create new Outlook profiles and existing clients may lose functionality.
Log Name: Application Source: MSExchange Autodiscover Event ID: 1035 Level: Error Description: Autodiscover failed for email address user@domain.com. Error: The Autodiscover service couldn't be located by using the Service Connection Point (SCP) lookup method. Additional Info: Calling user identity: DOMAIN\user Target user: user@domain.com Endpoint: https://mail.domain.com/autodiscover/autodiscover.xml
Symptoms & Detection
Primary Symptoms
- ●Outlook shows "An encrypted connection to your mail server is not available"
- ●New Outlook profile creation fails with "We couldn't find a server"
- ●●Mobile devices cannot add Exchange account automatically
- ●Out of Office and Free/Busy information not working
- ●Outlook Connection Status shows "Disconnected" or "Trying to connect"
Outlook Autodiscover Test Dialog
Hold Ctrl and right-click the Outlook system tray icon, select "Test E-mail AutoConfiguration":
Results: ✗ Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml Failed: The remote server returned an error: (401) Unauthorized. ✗ Autodiscover to SCP lookup Failed: The Service Connection Point in Active Directory could not be found. ✗ Local XML file check Not found. Protocol: Exchange Server: <not determined>
Common Causes
1. Service Connection Point (SCP) Issues
SCP objects in Active Directory are missing, corrupted, or pointing to wrong URLs. Domain-joined clients query SCP first, and if these AD objects are misconfigured, Autodiscover fails silently before trying DNS-based lookup.
2. DNS Configuration Problems
Missing autodiscover.domain.com DNS record, CNAME pointing to wrong host, or SRV records not configured. External clients rely on DNS, and internal clients use DNS as fallback when SCP fails.
3. Certificate Name Mismatch
SSL certificate doesn't include autodiscover.domain.com in Subject Alternative Names (SANs). Clients reject the connection if the certificate doesn't match the URL they're connecting to, causing both security warnings and connection failures.
4. Virtual Directory Misconfiguration
Autodiscover virtual directory has incorrect Internal/External URLs, wrong authentication settings, or is deleted entirely. IIS binding issues can also prevent the virtual directory from responding to requests.
5. Firewall/Proxy Blocking
Firewall rules blocking port 443 to Exchange server, proxy requiring authentication for Autodiscover URLs, or load balancer not forwarding /autodiscover/ path correctly.
Diagnostic Steps
Step 1: Test Autodiscover from Exchange Server
Run the built-in Autodiscover test cmdlet:
# Test Autodiscover for a specific user
Test-OutlookWebServices -Identity user@domain.com | Format-List
# More detailed test with all virtual directories
Test-OutlookConnectivity -Protocol HTTP -GetDefaultsFromAutodiscover $true |
Format-List Scenario, Result, Latency, Error
# Check Autodiscover virtual directory settings
Get-AutodiscoverVirtualDirectory | Format-List Server, Name, InternalUrl, ExternalUrl,
InternalAuthenticationMethods, ExternalAuthenticationMethods
# Test Autodiscover XML response directly
$cred = Get-Credential
$uri = "https://mail.domain.com/autodiscover/autodiscover.xml"
Invoke-WebRequest -Uri $uri -Credential $cred -Method Post -ContentType "text/xml" -Body @"
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>user@domain.com</EMailAddress>
<AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
</Request>
</Autodiscover>
"@Step 2: Check Service Connection Point (SCP)
Verify SCP objects in Active Directory:
# Get all Exchange Autodiscover SCPs
Get-ClientAccessService | Get-AutodiscoverVirtualDirectory |
Select-Object Server, AutoDiscoverSiteScope, AutoDiscoverServiceInternalUri
# Query AD directly for SCP objects
$root = [ADSI]"LDAP://RootDSE"
$configNC = $root.configurationNamingContext
$searcher = New-Object DirectoryServices.DirectorySearcher
$searcher.SearchRoot = [ADSI]"LDAP://CN=Configuration,$($configNC)"
$searcher.Filter = "(&(objectClass=serviceConnectionPoint)(keywords=67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68))"-4fa7-BFAC-E1D7794C1F68))"
$searcher.FindAll() | ForEach-Object {
$obj = $_.Properties
Write-Host "Server: $($obj.cn)"
Write-Host " URL: $($obj.serviceBindingInformation)"
Write-Host " Site: $($obj.keywords | Where-Object {$_ -like 'Site=*'})"-Object {$_ -like 'Site=*'})"
Write-Host ""
}
# Check SCP permissions
$scpPath = "CN=Autodiscover,CN=Protocols,CN=YOURSERVER,CN=Servers,CN=Exchange Administrative Group..."
Get-ACL "AD:$scpPath" | Format-ListStep 3: Verify DNS Records
Check DNS configuration for Autodiscover:
# Check A/CNAME record for autodiscover
Resolve-DnsName -Name autodiscover.domain.com -Type A
Resolve-DnsName -Name autodiscover.domain.com -Type CNAME
# Check SRV record (alternative method)
Resolve-DnsName -Name _autodiscover._tcp.domain.com -Type SRV
# Test from client perspective (external DNS)
nslookup autodiscover.domain.com 8.8.8.8
# Verify DNS matches Exchange server
$dnsResult = Resolve-DnsName -Name autodiscover.domain.com
$exchangeIP = (Get-NetIPAddress -InterfaceAlias "Ethernet" -AddressFamily IPv4).IPAddress
if ($dnsResult.IPAddress -eq $exchangeIP) {
Write-Host "DNS correctly points to this Exchange server" -ForegroundColor Green
} else {
Write-Host "DNS mismatch! Points to $($dnsResult.IPAddress), not $exchangeIP"$exchangeIP" -ForegroundColor Red
}Step 4: Check SSL Certificate
Verify certificate includes Autodiscover names:
# Get certificate assigned to IIS
Get-ExchangeCertificate | Where-Object {$_.Services -match "IIS"} |
Format-List Subject, CertificateDomains, NotAfter, Services
# Check specific certificate details
$cert = Get-ExchangeCertificate | Where-Object {$_.Services -match "IIS"}
Write-Host "Subject: $($cert.Subject)"
Write-Host "SANs: $($cert.CertificateDomains -join ', ')"-join ', ')"
Write-Host "Expires: $($cert.NotAfter)"
# Verify autodiscover is in the certificate
$autodiscoverNames = @("autodiscover.domain.com", "autodiscover")
$certDomains = $cert.CertificateDomains
$missing = $autodiscoverNames | Where-Object {$_ -notin $certDomains}
if ($missing) {
Write-Host "MISSING from certificate: $($missing -join ', ')"-join ', ')" -ForegroundColor Red
} else {
Write-Host "All Autodiscover names present in certificate" -ForegroundColor Green
}
# Test HTTPS connection
Test-NetConnection -ComputerName autodiscover.domain.com -Port 443 -InformationLevel DetailedQuick Fix (5-15 minutes)
🚀 Immediate Resolution: Reconfigure Autodiscover URLs
The fastest fix is to reset Autodiscover virtual directory URLs to match your certificate:
# Set correct Internal and External URLs for Autodiscover
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -InternalUrl "https://mail.domain.com/autodiscover/autodiscover.xml" -ExternalUrl "https://mail.domain.com/autodiscover/autodiscover.xml"
# Restart IIS to apply changes
Restart-Service W3SVC, WAS -Force
# Verify the change
Get-AutodiscoverVirtualDirectory | Format-List Server, InternalUrl, ExternalUrl
# Quick test
Test-OutlookWebServices -Identity user@domain.com -TargetAddress user@domain.com |
Select-Object Type, Result, Message💡 Pro Tip
Detailed Solutions
Solution 1: Fix Service Connection Point (SCP)
Repair or recreate the SCP object in Active Directory:
# View current SCP configuration
Get-ClientAccessService | Format-List Name, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope
# Set the correct Autodiscover SCP URI
Set-ClientAccessService -Identity "YOURSERVER" -AutoDiscoverServiceInternalUri "https://mail.domain.com/autodiscover/autodiscover.xml"
# Configure site scope (for multi-site environments)
Set-ClientAccessService -Identity "YOURSERVER" -AutoDiscoverSiteScope "Default-First-Site-Name"-Site-Name", "Branch-Site"
# Force AD replication
Invoke-Command -ComputerName DC01 -ScriptBlock {
repadmin /syncall /APed
}
# Verify SCP is accessible
$filter = "(&(objectClass=serviceConnectionPoint)(keywords=67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68))"-4fa7-BFAC-E1D7794C1F68))"
Get-ADObject -LDAPFilter $filter -SearchBase "CN=Configuration,DC=domain,DC=com" -Properties serviceBindingInformation |
Select-Object Name, @{N='URL';E={$_.serviceBindingInformation}}💡 Pro Tip
Solution 2: Configure DNS for External Autodiscover
Set up proper DNS records for external client access:
# Option 1: CNAME record (recommended)
# In your DNS zone, create:
# autodiscover.domain.com -> CNAME -> mail.domain.com
# Verify CNAME works
Resolve-DnsName autodiscover.domain.com -Type CNAME
# Option 2: SRV record (for redirect scenarios)
# Create SRV record in DNS:
# _autodiscover._tcp.domain.com -> SRV -> 0 0 443 mail.domain.com0 443 mail.domain.com
# Verify SRV record
Resolve-DnsName _autodiscover._tcp.domain.com -Type SRV
# Option 3: A record (if using dedicated IP)
# autodiscover.domain.com -> A -> 192.168.1.100168.1.100
# Test external resolution
$externalDNS = "8.8.8.8"8.8.8"
Resolve-DnsName -Name autodiscover.domain.com -Server $externalDNS
# Create redirect for HTTP to HTTPS (IIS)
# This handles clients that try HTTP first
New-WebBinding -Name "Default Web Site" -Protocol "http" -Port 80 -HostHeader "autodiscover.domain.com"
# Add URL Rewrite rule to redirect to HTTPS
$site = "IIS:\Sites\Default Web Site"
Set-WebConfigurationProperty -PSPath $site -Filter "system.webServer/httpRedirect" -Name "enabled" -Value "false" # Use URL Rewrite instead for autodiscoverSolution 3: Fix Certificate Issues
Obtain and assign a certificate with correct SANs:
⚠️ Danger Zone
# Generate a certificate request with Autodiscover name
$certRequest = New-ExchangeCertificate -GenerateRequest -SubjectName "CN=mail.domain.com" -DomainName mail.domain.com, autodiscover.domain.com, owa.domain.com, domain.com -PrivateKeyExportable $true
# Save request to file for CA submission
Set-Content -Path "C:\CertRequest.txt" -Value $certRequest
# After receiving certificate from CA, import it
Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes("C:\NewCert.cer"))
# Get the thumbprint of new certificate
$newCert = Get-ExchangeCertificate | Where-Object {$_.Subject -eq "CN=mail.domain.com"} |
Sort-Object NotAfter -Descending | Select-Object -First 1
# Enable the certificate for Exchange services
Enable-ExchangeCertificate -Thumbprint $newCert.Thumbprint -Services IIS, SMTP, POP, IMAP
# Verify services are assigned
Get-ExchangeCertificate -Thumbprint $newCert.Thumbprint | Format-List Services, CertificateDomains
# Restart IIS to apply
iisreset /noforceSolution 4: Recreate Autodiscover Virtual Directory
If the virtual directory is corrupted, remove and recreate it:
# Remove existing Autodiscover virtual directory
Get-AutodiscoverVirtualDirectory -Server YOURSERVER | Remove-AutodiscoverVirtualDirectory -Confirm:$false
# Create new Autodiscover virtual directory
New-AutodiscoverVirtualDirectory -WebSiteName "Default Web Site" -Server YOURSERVER
# Configure the URLs
Get-AutodiscoverVirtualDirectory -Server YOURSERVER | Set-AutodiscoverVirtualDirectory -InternalUrl "https://mail.domain.com/autodiscover/autodiscover.xml" -ExternalUrl "https://mail.domain.com/autodiscover/autodiscover.xml"
# Set authentication methods
Get-AutodiscoverVirtualDirectory -Server YOURSERVER | Set-AutodiscoverVirtualDirectory -InternalAuthenticationMethods Ntlm, Basic, Negotiate -ExternalAuthenticationMethods Ntlm, Basic, Negotiate -WindowsAuthentication $true -BasicAuthentication $true
# Restart IIS
Restart-Service W3SVC, WAS -Force
# Verify virtual directory is functional
$uri = "https://mail.domain.com/autodiscover/autodiscover.xml"
$response = Invoke-WebRequest -Uri $uri -Method GET -UseDefaultCredentials
$response.StatusCodeSolution 5: Configure Split DNS
For environments where internal and external URLs differ:
# Configure different internal/external URLs
Set-AutodiscoverVirtualDirectory -Identity "YOURSERVER\autodiscover (Default Web Site)" -InternalUrl "https://mail.domain.local/autodiscover/autodiscover.xml" -ExternalUrl "https://mail.domain.com/autodiscover/autodiscover.xml"
# Create internal DNS zone for domain.com (split DNS)
# On internal DNS server:
Add-DnsServerPrimaryZone -Name "domain.com" -ZoneFile "domain.com.dns"
# Add internal A record for mail
Add-DnsServerResourceRecordA -ZoneName "domain.com" -Name "mail" -IPv4Address "192.168.1.100"168.1.100"
Add-DnsServerResourceRecordA -ZoneName "domain.com" -Name "autodiscover" -IPv4Address "192.168.1.100"168.1.100"
# Or use CNAME
Add-DnsServerResourceRecordCName -ZoneName "domain.com" -Name "autodiscover" -HostNameAlias "mail.domain.com"
# Test internal resolution
Resolve-DnsName autodiscover.domain.com -Server DC01.domain.local
# Test external resolution
Resolve-DnsName autodiscover.domain.com -Server 8.8.8.8💡 Pro Tip
Verification Steps
Confirm Autodiscover is Working
# Comprehensive Autodiscover test
Test-OutlookWebServices -Identity user@domain.com | Format-Table Type, Result, Message -AutoSize
# Test specific Autodiscover methods
$email = "user@domain.com"
# Test 1: SCP lookup (internal)
Write-Host "Testing SCP Lookup..." -ForegroundColor Cyan
$scp = Get-ClientAccessService | Select-Object -First 1 -ExpandProperty AutoDiscoverServiceInternalUri
Write-Host "SCP URL: $scp"
# Test 2: DNS A/CNAME
Write-Host "`nTesting DNS..." -ForegroundColor Cyan
$dns = Resolve-DnsName autodiscover.domain.com -ErrorAction SilentlyContinue
if ($dns) { Write-Host "DNS: OK - $($dns.IPAddress)" -ForegroundColor Green }
else { Write-Host "DNS: FAILED" -ForegroundColor Red }
# Test 3: HTTPS connectivity
Write-Host "`nTesting HTTPS..." -ForegroundColor Cyan
$uri = "https://autodiscover.domain.com/autodiscover/autodiscover.xml"
try {
$response = Invoke-WebRequest -Uri $uri -UseDefaultCredentials -Method Get -TimeoutSec 10
Write-Host "HTTPS: OK - Status $($response.StatusCode)" -ForegroundColor Green
} catch {
Write-Host "HTTPS: $($_.Exception.Message)" -ForegroundColor Red
}
# Test 4: Certificate validation
Write-Host "`nTesting Certificate..." -ForegroundColor Cyan
$cert = Get-ExchangeCertificate | Where-Object {$_.Services -match "IIS"}
if ($cert.CertificateDomains -contains "autodiscover.domain.com") {
Write-Host "Certificate: OK - autodiscover.domain.com in SANs" -ForegroundColor Green
} else {
Write-Host "Certificate: WARNING - autodiscover name not in SANs" -ForegroundColor Yellow
}
# Test from client perspective
Test-OutlookConnectivity -Protocol Http | Format-List✓ Success Indicators
- • Test-OutlookWebServices returns Success
- • Outlook profile creation works automatically
- • Mobile devices discover settings
- • No certificate warnings in clients
- • Event ID 1035 errors stop appearing
✗ Requires Further Action
- • Tests still fail with authentication errors
- • Certificate warnings persist
- • Only some users affected (permissions)
- • External access works but internal fails
- • Mobile devices still can't connect
Prevention Strategies
📊 Monitoring
- • Monitor Event ID 1035 occurrences
- • Set up synthetic Autodiscover tests
- • Alert on certificate expiration (30 days)
- • Track SCP replication status
- • Monitor DNS resolution times
🔧 Configuration
- • Document all Autodiscover URLs
- • Use consistent naming across sites
- • Include all names in certificates
- • Configure proper site scopes
- • Maintain DNS record documentation
🔐 Security
- • Use trusted CA certificates
- • Enforce HTTPS for Autodiscover
- • Disable Autodiscover redirect to HTTP
- • Configure proper authentication
- • Audit Autodiscover access logs
🔄 Change Management
- • Test Autodiscover after any URL change
- • Verify certificate before expiration
- • Update SCP when moving servers
- • Check DNS after IP changes
- • Document firewall rules for 443
When to Escalate
Professional Exchange Connectivity Support Required If:
- 🔴Autodiscover works internally but fails externally (complex network/firewall issues)
- 🔴Multi-domain or multi-forest Autodiscover configuration required
- 🔴Certificate chain issues or PKI infrastructure problems
- 🔴Active Directory SCP corruption affecting multiple servers
- 🔴Hybrid Exchange/Microsoft 365 Autodiscover configuration
- 🔴Large-scale user impact preventing email access organization-wide
Expert Exchange Autodiscover Recovery
Microsoft-certified engineers resolve complex Autodiscover issues with 15 Minutes response time, 24/7
Frequently Asked Questions
Related Exchange Server Errors
Can't Resolve Event ID 1035?
Exchange errors can cause data loss or extended downtime. Our specialists are available 24/7 to help.
Emergency help - Chat with usMedha 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.