Autodiscover SCP Issues

Autodiscover SCP Issues in Exchange - Fix Guide 2025

Complete troubleshooting guide for Autodiscover Service Connection Point (SCP) issues in Exchange Server. Learn how to diagnose and fix Active Directory SCP configuration problems preventing Outlook from discovering Exchange settings.

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

Table of Contents

Reading Progress
0 of 9

Autodiscover Service Connection Point (SCP) issues prevent domain-joined Outlook clients from automatically discovering Exchange server settings. When SCP is misconfigured, users experience profile creation failures, repeated credential prompts, and connectivity problems. This guide shows you how to diagnose and fix SCP issues in Active Directory.

Our Exchange Connectivity Services team resolves SCP configuration issues daily with a 99% first-contact resolution rate. This guide provides the same diagnostic workflow we use.

What is Autodiscover SCP?

Service Connection Point (SCP) is an Active Directory object created during Exchange Server installation. It stores the internal Autodiscover URL that domain-joined Outlook clients query first when configuring mailbox connections.

How SCP Autodiscover Works

1

Outlook Queries Active Directory

Domain-joined computer performs LDAP query for SCP objects in the Configuration partition

2

SCP Returns Autodiscover URL

AD returns the AutoDiscoverServiceInternalUri (e.g., https://mail.company.com/autodiscover/autodiscover.xml)

3

Outlook Connects to Exchange

Outlook retrieves Autodiscover XML with EWS, MAPI, OAB URLs and configures the profile

SCP Object Location in Active Directory
CN=<ServerName>,CN=Autodiscover,CN=Protocols,CN=<ServerName>,
   CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
   CN=Administrative Groups,CN=<Organization>,CN=Microsoft Exchange,
   CN=Services,CN=Configuration,DC=company,DC=com

Key Attribute: The serviceBindingInformation attribute contains the Autodiscover URL that Outlook uses.

Symptoms & Business Impact

What Users Experience:

  • Outlook profile wizard takes extremely long (minutes) before failing
  • "Cannot find the email server" or "The name cannot be resolved" errors
  • Outlook works when connected via VPN but fails on corporate network
  • New employee onboarding delayed due to Outlook configuration failures
  • Mobile devices and web clients work, but desktop Outlook fails

What Admins See:

  • SCP records point to decommissioned or renamed Exchange servers
  • Multiple SCP records from old Exchange installations
  • AutoDiscoverServiceInternalUri empty or incorrect
  • LDAP queries timing out in network traces

⚠️ Business Impact: SCP issues specifically affect domain-joined computers in your corporate environment. Remote workers using non-domain devices may not experience issues, making the problem appear intermittent. This often delays diagnosis as IT focuses on the wrong components.

Common Causes of SCP Issues

1. Orphaned SCP Records (40% of cases)

Most Common Cause: Exchange servers decommissioned without properly removing their SCP records from Active Directory. Outlook tries these dead URLs first, causing timeouts.

Identified by: Multiple SCP records in AD, some pointing to non-existent servers

2. Incorrect AutoDiscoverServiceInternalUri (30% of cases)

Common Issue: The SCP URL points to wrong hostname, uses HTTP instead of HTTPS, or doesn't match the certificate's Subject Alternative Name.

Identified by: Get-ClientAccessService shows URL that doesn't match your certificate SANs

3. AD Replication Lag (15% of cases)

Multi-Site Issue: SCP changes haven't replicated to all domain controllers. Users at remote sites get old SCP information.

Identified by: Inconsistent behavior between sites, repadmin shows replication delays

4. Firewall Blocking LDAP/GC (10% of cases)

Network Issue: Clients cannot reach domain controllers to query SCP. LDAP (389/636) or Global Catalog (3268/3269) ports blocked.

Identified by: Outlook falls back to DNS Autodiscover after long delay

5. SCP Scoping Misconfigured (5% of cases)

Advanced Scenario: SCP objects scoped to wrong Active Directory site or organizational unit, making them invisible to certain clients.

Identified by: SCP works for some users but not others in specific locations

Quick Diagnosis: PowerShell Commands

📌 Version Compatibility: This guide applies to Exchange 2016, Exchange 2019, Exchange 2022. Commands may differ for other versions.

Run these commands in Exchange Management Shell (run as Administrator) to identify SCP issues:

Step 1: Check Current SCP Configuration
# View all Exchange servers and their Autodiscover URLs
Get-ClientAccessService | Format-List Name, AutoDiscoverServiceInternalUri

# Check for servers with empty or wrong URLs
Get-ClientAccessService | Where-Object {
    [string]::IsNullOrEmpty($_.AutoDiscoverServiceInternalUri) -or
    $_.AutoDiscoverServiceInternalUri -notlike "*https://*"
}

What to look for:

  • All servers should have valid https:// URLs
  • URL hostname must match your SSL certificate SANs
  • Decommissioned servers shouldn't appear in the list
Step 2: Query SCP Directly from Active Directory
# Get SCP objects from AD Configuration partition
$RootDSE = [ADSI]"LDAP://RootDSE"
$ConfigNC = $RootDSE.configurationNamingContext

$SCPs = Get-ADObject -SearchBase "CN=Configuration,$ConfigNC" -LDAPFilter "(objectClass=serviceConnectionPoint)" -Properties serviceBindingInformation,keywords |
    Where-Object { $_.keywords -like "*Exchange*" -and $_.keywords -like "*Autodiscover*" }

$SCPs | Select-Object Name, serviceBindingInformation | Format-Table -AutoSize

What to look for:

  • SCP records for servers that no longer exist
  • Duplicate or conflicting Autodiscover URLs
  • URLs that don't resolve or return errors
Step 3: Test Autodiscover from Client Perspective
# Simulate Outlook SCP lookup
$email = "user@company.com"
$cred = Get-Credential

# Test using Outlook's exact method
Test-OutlookWebServices -Identity $email -MailboxCredential $cred |
    Select-Object Type, Result, Message | Format-Table -AutoSize
Step 4: Check AD Replication Status
# Verify SCP changes have replicated to all DCs
repadmin /replsummary

# Force replication if needed
repadmin /syncall /AdeP

Quick Fix (10 Minutes) - Correct SCP URL

⚠️ Only use this if:

  • SCP URL is incorrect but the Exchange server is functioning
  • No orphaned SCP records from old servers
  • You know the correct Autodiscover URL

Solution: Update AutoDiscoverServiceInternalUri

Fix SCP URL for Exchange Server
# Set correct Autodiscover URL (replace with your values)
$serverName = "EXCH01"
$correctUrl = "https://mail.company.com/autodiscover/autodiscover.xml"

# Update the SCP
Set-ClientAccessService -Identity $serverName -AutoDiscoverServiceInternalUri $correctUrl

# Verify the change
Get-ClientAccessService -Identity $serverName | Format-List Name, AutoDiscoverServiceInternalUri

# Force AD replication
repadmin /syncall /AdeP

# Wait 2-3 minutes for replication, then test-3 minutes for replication, then test
Start-Sleep -Seconds 180
Test-OutlookWebServices -Identity "testuser@company.com" -MailboxCredential (Get-Credential)

✅ Expected Result:

  • Get-ClientAccessService shows the correct URL
  • Test-OutlookWebServices completes successfully
  • New Outlook profiles configure without delays

Detailed Solution: Advanced SCP Troubleshooting

If the quick fix didn't resolve the issue, follow these advanced troubleshooting steps:

Scenario 1: Remove Orphaned SCP Records

⚠️ Warning: Deleting SCP records affects all domain-joined Outlook clients. Ensure you're removing records for servers that no longer exist. Always backup before making AD changes.

Find and Remove Orphaned SCP Records
# Step 1: List all Exchange Autodiscover SCPs
$RootDSE = [ADSI]"LDAP://RootDSE"
$ConfigNC = $RootDSE.configurationNamingContext

Get-ADObject -SearchBase "CN=Microsoft Exchange,CN=Services,CN=Configuration,$ConfigNC" `
    -LDAPFilter "(objectClass=serviceConnectionPoint)" `
    -Properties serviceBindingInformation, whenCreated |
    Select-Object Name, serviceBindingInformation, whenCreated |
    Format-Table -AutoSize

# Step 2: Test each URL to identify dead ones
# Note: Manually verify each URL before deletion

# Step 3: Remove orphaned SCP (replace DN with actual distinguished name)
# BACKUP FIRST: Export-ADObject to CSV
$orphanedSCP = "CN=OLDSERVER,CN=Autodiscover,CN=Protocols,CN=OLDSERVER,CN=Servers,..."
Remove-ADObject -Identity $orphanedSCP -Confirm:$true

# Step 4: Force replication
repadmin /syncall /AdeP

Scenario 2: Configure SCP Site Scoping

In multi-site environments, you may want Outlook to prefer local Exchange servers. Use SCP site scoping to direct clients to the nearest server.

Scope SCP to Specific AD Site
# View current site configuration
Get-ClientAccessService | Format-List Name, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope

# Scope SCP to specific AD site
Set-ClientAccessService -Identity "EXCH01" `
    -AutoDiscoverSiteScope "HeadquartersSite","DataCenterSite"

# For multi-site with site-specific URLs:-specific URLs:
# Site A server
Set-ClientAccessService -Identity "EXCH-SITEA" `
    -AutoDiscoverServiceInternalUri "https://mail-sitea.company.com/autodiscover/autodiscover.xml" `
    -AutoDiscoverSiteScope "SiteA"

# Site B server
Set-ClientAccessService -Identity "EXCH-SITEB" `
    -AutoDiscoverServiceInternalUri "https://mail-siteb.company.com/autodiscover/autodiscover.xml" `
    -AutoDiscoverSiteScope "SiteB"

Scenario 3: Use ADSI Edit for Manual SCP Repair

Manual SCP Modification via ADSI Edit
# Open ADSI Edit
adsiedit.msc

# Navigate to:
# Configuration > CN=Services > CN=Microsoft Exchange > CN=<Organization> >
# CN=Administrative Groups > CN=Exchange Administrative Group > CN=Servers >
# CN=<ServerName> > CN=Protocols > CN=Autodiscover > CN=<ServerName>

# Modify the 'serviceBindingInformation' attribute:
# Set to: https://mail.company.com/autodiscover/autodiscover.xml

# Alternative: PowerShell direct AD modification
$DN = "CN=EXCH01,CN=Autodiscover,CN=Protocols,CN=EXCH01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Company,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com"

Set-ADObject -Identity $DN -Replace @{serviceBindingInformation="https://mail.company.com/autodiscover/autodiscover.xml"}

Scenario 4: Disable SCP Lookup (Client-Side Workaround)

If you cannot immediately fix server-side SCP issues, you can disable SCP lookup on specific clients. This forces Outlook to use DNS-based Autodiscover.

Disable SCP Lookup via Registry (Client-Side)
# Disable SCP lookup for Outlook (per-user)
# Path varies by Outlook version:
# Outlook 2016/2019/365: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover2019/365: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

$regPath = "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover"0\Outlook\AutoDiscover"

# Create key if it doesn't exist
if (!(Test-Path $regPath)) {
    New-Item -Path $regPath -Force
}

# Disable SCP lookup (1 = exclude)
Set-ItemProperty -Path $regPath -Name "ExcludeScpLookup" -Value 1 -Type DWord

# Alternative: Enable only specific Autodiscover methods
# ExcludeHttpRedirect = 1 (disable HTTP redirect)
# ExcludeSrvRecord = 1 (disable SRV record lookup)
# ExcludeHttpsAutoDiscoverDomain = 1 (disable https://domain.com/autodiscover)

# Deploy via Group Policy for multiple machines

💡 Pro Tip: Use the Outlook Autodiscover test (Ctrl+Right-click Outlook icon → Test Email AutoConfiguration) to see exactly which Autodiscover method Outlook is using. This helps confirm whether SCP is being queried and what URL it returns.

Verify the Fix

After applying fixes, run these verification tests:

Verification Commands
# 1. Verify SCP configuration
Get-ClientAccessService | Format-List Name, AutoDiscoverServiceInternalUri

# 2. Test Autodiscover from Exchange server
Test-OutlookWebServices -Identity "testuser@company.com" -MailboxCredential (Get-Credential)

# 3. Test from a domain-joined client (run as regular user)-joined client (run as regular user)
# Hold CTRL and right-click Outlook system tray icon
# Select "Test E-mail AutoConfiguration"
# Check "Use AutoDiscover" and enter email/password
# Look for "SCP" in the results

# 4. Check AD replication completed
repadmin /showrepl

# 5. Query SCP from client perspective
$searcher = New-Object DirectoryServices.DirectorySearcher
$searcher.Filter = "(&(objectClass=serviceConnectionPoint)(keywords=*Autodiscover*))"
$searcher.SearchRoot = "LDAP://CN=Configuration,DC=company,DC=com"
$searcher.FindAll() | ForEach-Object { $_.Properties["servicebindinginformation"] }

✅ Success Indicators:

  • All Get-ClientAccessService entries show correct, valid URLs
  • Test-OutlookWebServices returns "Success" for all tests
  • Outlook AutoConfiguration test shows SCP lookup succeeding
  • New Outlook profiles configure in under 30 seconds
  • No orphaned SCP records in Active Directory

Prevention: Avoid Future SCP Issues

1. Proper Exchange Server Decommissioning

Always uninstall Exchange properly instead of just shutting down servers. This removes SCP and other AD objects.

Proper Exchange Uninstall Process
# Before uninstalling Exchange:
# 1. Move all mailboxes off the server
Get-Mailbox -Server OLDSERVER | New-MoveRequest -TargetDatabase "NewDB"

# 2. Remove server from DAG (if applicable)
Remove-MailboxDatabaseCopy -Identity "DB\OLDSERVER"
Remove-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer OLDSERVER

# 3. Run Exchange uninstall (removes SCP automatically)
# Control Panel > Programs > Microsoft Exchange Server > Uninstall

# 4. Verify SCP removed
Get-ClientAccessService | Where-Object {$_.Name -eq "OLDSERVER"}

2. Document SCP Configuration

  • Maintain inventory of all Exchange servers and their SCP URLs
  • Include SCP verification in Exchange maintenance checklists
  • Export SCP objects before making changes

3. Monitor SCP Health

SCP Health Check Script
# Scheduled task to verify SCP health weekly
$servers = Get-ClientAccessService

foreach ($server in $servers) {
    $url = $server.AutoDiscoverServiceInternalUri

    if ([string]::IsNullOrEmpty($url)) {
        Write-Warning "Server $($server.Name) has no Autodiscover URL configured"
        continue
    }

    try {
        $response = Invoke-WebRequest -Uri $url -Method HEAD -TimeoutSec 10 -UseDefaultCredentials
        if ($response.StatusCode -ne 200) {
            Write-Warning "Server $($server.Name): Autodiscover URL returned $($response.StatusCode)"$response.StatusCode)"
        }
    } catch {
        Write-Error "Server $($server.Name): Cannot reach Autodiscover URL - $($_.Exception.Message)"$_.Exception.Message)"
    }
}

4. Use Consistent Naming

  • Use a single Autodiscover URL (mail.company.com) across all servers
  • Point all SCP records to load balancer VIP for high availability
  • Ensure URL matches certificate Subject Alternative Names

Complex SCP Issues? Get Expert Help

SCP problems in complex Active Directory environments can involve multiple domains, forests, and trust relationships. Our Exchange specialists can audit your entire Autodiscover configuration and implement fixes across your organization.

Get SCP Configuration Help

Average Resolution Time: 30 Minutes

Frequently Asked Questions

Service Connection Point (SCP) is an Active Directory object that stores the Autodiscover URL for Exchange Server. Domain-joined computers use SCP lookup as the first method to find Exchange Autodiscover endpoint, making it critical for Outlook profile configuration in enterprise environments.

Can't Resolve Autodiscover SCP Issues?

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