Troubleshooting Autodiscover Issues in Outlook

Problems with Autodiscover Function in Outlook on Individual Client Machines

Problems with the Autodiscover function in Outlook on individual client machines are usually related to differences in network settings, security configuration, or system status. The most likely causes are blocking of ports 80/443, SSL/TLS certificate issues, security policy differences, or DNS cache anomalies. Given that working computers receive multiple requests and successfully return configuration, while problematic ones only receive one request, this indicates differences in client behavior when attempting connections.

Table of Contents

• Main causes of the problem
• Checking network connections and ports
• Analyzing security configuration
• DNS and caching diagnostics
• Software version differences
• Authentication issues
• Practical troubleshooting steps

Main causes of the problem

Differences in Outlook behavior between working and non-working machines can be caused by several factors:

Port blocking at the client level - Problematic machines may have a firewall or antivirus configured to block additional requests after the first failed one. Outlook typically tries to connect through several different methods (AutoDiscover, SCP, DNS) and ports (80, 443, 6001-6004), but on some systems, subsequent requests may be blocked.

SSL/TLS certificate issues - If the server uses a self-signed or untrusted certificate, Outlook on some machines may accept it, while on others it may refuse to connect after the first attempt due to strict security settings.

Security policy differences - Group policies (GPO) at the individual computer or user level may contain settings that limit the number of connection attempts or allow only a specific Autodiscover method.

DNS cache anomalies - The DNS cache on problematic machines may be corrupted or outdated, leading to incorrect handling of server responses.

Checking network connections and ports

Testing ports 80 and 443

First, you need to check port availability from problematic machines:

# Check port 80 (HTTP)
Test-NetConnection mail.yourdomain.com -Port 80

# Check port 443 (HTTPS)
Test-NetConnection mail.yourdomain.com -Port 443

If ports are available but requests stop after the first one, check:

Windows Firewall settings - Ensure that incoming and outgoing connections are allowed for ports 80 and 443. Sometimes antivirus programs (especially Kaspersky, ESET, Dr.Web) block additional connections after the first failed attempt.

Proxy settings - A proxy may intercept the first request but not handle subsequent ones. Check proxy settings in:

• Internet Options → Connections → LAN Settings
• netsh winhttp show proxy

TLS/SSL settings - Check the TLS version on the client machine:

# Check supported SSL/TLS versions
[System.Net.ServicePointManager]::SecurityProtocol

TLS 1.2 and TLS 1.3 should be enabled. Older versions may cause issues with modern servers.

Analyzing security configuration

Comparing security policies

Perform a comparison of security policies between working and problematic machines:

# Export security policies
secedit /export /cfg C:\temp\security_policy.txt

# Compare policies
Compare-Object (Get-Content C:\temp\working_policy.txt) (Get-Content C:\temp\broken_policy.txt)

Pay attention to the following parameters:

WinHTTP settings - Issues may be related to WinHTTP configuration:

# Check WinHTTP configuration
netsh winhttp show proxy
netsh winhttp reset proxy

Internet Explorer security zone settings - Even if you’re using Outlook, it relies on IE settings for some web connections:

• Internet Options → Security → Local intranet → Sites → Advanced
• Ensure the mail domain is added to the zone and the security level is not too high

SSL/TLS configuration at the system level - Check the registry:

# Check SSL settings in the registry
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"

DNS and caching diagnostics

Clearing DNS cache and other caches

Clear the following caches on problematic machines:

# Clear DNS cache
ipconfig /flushdns

# Clear Winsock cache
netsh winsock reset

# Clear BITS (Background Intelligent Transfer Service) cache
netsh http flush

# Clear authentication cache
Clear-Item -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfig" -Force

Checking Autodiscover through a browser

Check Autodiscover through a browser from the problematic machine:

https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml
https://yourdomain.com/autodiscover/autdiscover.xml

If you get a certificate error in the browser, this may be the cause of Outlook issues. Check:

• Certificate validity
• Certificate name matching the domain
• Certificate trust chain

Using the Test-OutlookAutodiscover utility

Download and use the Microsoft Remote Connectivity Analyzer for detailed Autodiscover diagnostics.

Software version differences

Comparing Outlook and Windows versions

Check software versions on problematic and working machines:

# Outlook version
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*Microsoft Office*" | Select-Object DisplayName, DisplayVersion

# Windows version
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select-Object ProductName, CurrentVersion, CurrentBuildNumber

Security updates - Sometimes Windows or Office updates contain fixes for network connection issues. Check for the latest updates on problematic machines.

32/64-bit version differences - If some machines are running 32-bit Outlook and others 64-bit, this may cause behavioral differences.

Add-ins and plugins - Compare installed Outlook add-ins:

# List of Outlook add-ins
Get-ChildItem -Path "HKCU:\Software\Microsoft\Office\*\Outlook\Addins" | Select-Object PSChildName

Authentication issues

Analyzing login format issues

Given that “normal authorization and configuration retrieval only occurs when Outlook tries the domain\login pair,” this indicates issues with authentication methods.

Exchange authentication settings - Check supported methods on the Exchange server:

• Basic Authentication
• NTLM
• Kerberos
• OAuth 2.0

Client configuration - Problematic machines may have a login format different from domain\login. Check:

• File → Account Settings → Account Settings → Change → More Settings → Security
• Always prompt for user name and password parameter

Kerberos issues - If Kerberos authentication is used, check:

• DC (Domain Controller) availability
• SPN (Service Principal Names) settings
• Kerberos ticket configuration:

# Check Kerberos tickets
klist purge
klist

Practical troubleshooting steps

Step-by-step diagnostics

1. Comparing network activity - Use Wireshark to capture traffic from working and problematic machines when starting Outlook. Pay attention to:

   • Number of requests to ports 80 and 443
   • Differences in HTTP request headers
   • Differences in server response handling

2. Testing with administrator rights - Run Outlook as an administrator on the problematic machine. If the problem disappears, check:

   • Security policies for regular users
   • Registry permissions
   • Antivirus settings

3. Creating a new Outlook profile - Create a new mail profile on the problematic machine. If the problem disappears, check:

   • Damage to the old profile
   • Conflicts with add-ins
   • Configuration cache issues

4. Temporarily disabling antivirus - Disable antivirus software during testing. If the problem disappears, add exceptions for:

   • Ports 80 and 443
   • The OUTLOOK.EXE process
   • Exchange domains

5. Resetting network settings - Perform a network settings reset:

   powershell

   # Reset TCP/IP stack
   netsh int ip reset
   
   # Reset Winsock
   netsh winsock reset
   
   # Restart the computer
   shutdown /r /t 0
   

Specific recommendations for your situation

Based on the fact that only one request comes to problematic machines while several come to working ones, I recommend:

1. Check the “Attempt to automatically detect and configure server settings” setting in Exchange account parameters. On problematic machines, this setting may be disabled or not working correctly.

2. Analyze the Outlook log - Enable advanced Outlook logging and compare logs on working and problematic machines:

   HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General
   Create the EnableLogging parameter with value 1
   

3. Check proxy settings - Sometimes the difference in the number of requests is related to proxy server configuration. Compare proxy settings on working and problematic machines.

4. Testing in safe mode - Run Outlook in safe mode:

   outlook /safe
   

   If the problem disappears, check for add-in conflicts.

5. Check the autoconfiguration service configuration - Ensure that the BITS (Background Intelligent Transfer Service) service is running and working correctly, as it is used to download the Autodiscover configuration.

Sources

1. Microsoft - Configure Autodiscover for Exchange Server
2. Microsoft - Troubleshoot Autodiscover issues
3. Microsoft - Test-OutlookAutodiscover PowerShell cmdlet
4. Microsoft - Remote Connectivity Analyzer
5. Microsoft - Understanding the Autodiscover process

Conclusion

When troubleshooting Autodiscover issues on individual client machines, it’s necessary to conduct systematic diagnostics, comparing the configuration of problematic and working systems. The main areas of check include network connections, security settings, DNS configuration, and software version differences. Given the specifics of your situation (different number of requests and the need to try login formats), the most likely causes are port blocking at the client firewall or antivirus level, SSL/TLS certificate issues, or security policy differences.

To effectively solve the problem, I recommend sequentially checking network settings, clearing caches, comparing security configurations, and testing Outlook in safe mode. As a quick temporary solution, you can create a new Outlook profile on problematic machines or temporarily disable excessive antivirus security checking.