Event ID 1035

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.

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

Table of Contents

Reading Progress
0 of 10

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.

Event Viewer - Application Log
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
Profile Creation
New setups blocked
Mobile Sync
ActiveSync affected
Feature Discovery
OOF, Free/Busy broken

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-List

Step 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 Detailed

Quick 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

If you're using a wildcard certificate (*.domain.com), ensure the Autodiscover URL uses a subdomain format (mail.domain.com/autodiscover) rather than autodiscover.domain.com, unless autodiscover is explicitly in your certificate SANs.

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

In multi-domain environments, ensure SCP objects are in the correct configuration partition and that all DCs have replicated. Use repadmin /showrepl to verify replication status.

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 autodiscover

Solution 3: Fix Certificate Issues

Obtain and assign a certificate with correct SANs:

⚠️ Danger Zone

Changing the SSL certificate will briefly interrupt client connections. Schedule this during a maintenance window and notify users of a potential 1-2 minute disruption.
# 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 /noforce

Solution 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.StatusCode

Solution 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

Split DNS eliminates NAT hairpin issues where internal clients try to reach external IPs. Internal DNS should resolve Exchange names to internal IP addresses.

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

Get Exchange Connectivity Support →

Frequently Asked Questions

Autodiscover is a service that automatically configures email clients (Outlook, mobile devices) with the correct server settings. Without it, users must manually enter server names, ports, and authentication settings. Autodiscover failures prevent new Outlook profile creation and can break existing profiles when settings change.

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 us
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