How to setup local Autodiscover XML file to points to On-Prem Exchange solving office 365 persistence redirecting Autodiscover URL to the cloud.

Outlook 2016 / 2019 / 2021 / 2024 / Microsoft 365 connected to an on-premises Exchange keeps finding autodiscover.outlook.com instead of your own server. This guide shows how to point Outlook at the on-prem Autodiscover with a local Autodiscover XML file, using the domain example.com and the server autodiscover.example.com as an example. A ready-made script is at the end. It asks for the user’s email address and configures everything from that, including Outlook profiles that also have a Microsoft 365 mailbox.

Why Outlook goes to Office 365

Starting with Outlook 2016, Autodiscover first tries the Office 365 endpoint (Direct Connect to Office 365), and only then SCP and DNS. If the domain is verified in any Microsoft 365 / Entra tenant (even one used only for Teams or Intune), or an autodiscover DNS record is a CNAME to autodiscover.outlook.com, Outlook never reaches your Exchange server.

With a local XML, the lookup order becomes:

Before you start

• autodiscover.example.com must resolve to the Exchange server (or load balancer) and be included in the Exchange certificate. If it is not, use mail.example.com in the URL.
• Open https://autodiscover.example.com/autodiscover/autodiscover.xml in a browser. A login prompt or HTTP 401 is expected and means the service is alive.
• All settings are per user (HKCU). Run them as the Outlook user, not as a different admin account.

Step 1: Create the local XML file

The XML holds no fixed server settings. It is a redirect, so Outlook still gets MAPI/HTTP and EWS settings from Exchange itself, and the file works for every user in the domain.

Create the folder %LOCALAPPDATA%\Autodiscover inside the user’s profile (C:\Users\<user>\AppData\Local\Autodiscover). The user owns that folder, so no admin rights are needed. Save the XML there as autodiscover-example.com.xml (UTF-8). Name one file per domain, so a user with several on-prem domains gets one XML for each.

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
      <AccountType>email</AccountType>
      <Action>redirectUrl</Action>
      <RedirectUrl>https://autodiscover.example.com/autodiscover/autodiscover.xml</RedirectUrl>
    </Account>
  </Response>
</Autodiscover>

Step 2: Registry settings

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover (16.0 covers Outlook 2016, 2019, 2021 and Microsoft 365).

ExcludeScpLookup is not set. SCP stays on, which is the default and correct for domain-joined PCs.

The same settings as a .reg file for on-prem only. Replace USERNAME with the user’s folder name. Backslashes are doubled in .reg syntax only.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"PreferLocalXML"=dword:00000001
"ExcludeLastKnownGoodURL"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeExplicitO365Endpoint"=dword:00000001
"example.com"="C:\\Users\\USERNAME\\AppData\\Local\\Autodiscover\\autodiscover-example.com.xml"

Outlook with an additional Microsoft 365 account

Many users have their on-prem mailbox and a Microsoft 365 mailbox in the same Outlook. The Autodiscover registry values are global: they apply to every account in Outlook, not to a single domain. So:

• ExcludeExplicitO365Endpoint=1 turns off Direct Connect for the Microsoft 365 account too. That account then falls back to DNS lookups, which are slower, and it fails if the tenant domain’s autodiscover CNAME isn’t set up.
• It isn’t needed for the on-prem domain anyway. With PreferLocalXML=1, Outlook checks the local XML first, before the Office 365 endpoint, for any domain that has a mapping.

The script detects this case itself. It reads the accounts in all Outlook profiles and checks each domain against Microsoft’s login realm service (getuserrealm.srf). If any account is in a Microsoft 365 tenant, co-existence mode is offered as the default. It also logs whether the on-prem domain itself is registered in a tenant, which is the usual reason Outlook went to Office 365 in the first place.

Step 3: Clear the cache and re-add the account

1. Close Outlook completely (check Task Manager).
2. In %LOCALAPPDATA%\Microsoft\Outlook\16\, delete the cached Autodiscover *.xml files that contain @example.com. If there’s no Microsoft 365 account in Outlook, you can delete them all.
3. If the on-prem account was already created against Office 365, remove only that account (File → Account Settings → Remove) and add it again. Other accounts, including Microsoft 365, can stay. If Outlook has only that one account, creating a new profile is cleaner: Control Panel → Mail → Show Profiles → Add.

Step 4: Verify

1. Open Outlook, hold Ctrl, right-click the Outlook icon in the system tray, and choose Test E-mail AutoConfiguration.
2. Enter the email address and password, uncheck both Guessmart options, and click Test.
3. On the Log tab you should see the local XML being used and a redirect to autodiscover.example.com. On the Results tab, the server URLs should be your Exchange, not outlook.office365.com.

Automated script (download)

The ZIP contains a PowerShell script and a launcher that do steps 1–3 for the logged-on user, for any domain:

1. Asks for the email address. On a domain-joined PC it suggests the address from Active Directory, so the user can just press Enter.
2. Finds the server. It takes the domain from the address and tests https://autodiscover.<domain> and https://mail.<domain>. A 401 response counts as success. The user picks one, or types another host name.
3. Checks for Microsoft 365. It looks for Microsoft 365 accounts in the Outlook profiles and chooses on-prem only or co-existence mode.
4. Writes the XML. It creates %LOCALAPPDATA%\Autodiscover\ in the user’s profile and writes autodiscover-<domain>.xml there.
5. Writes the registry values for that domain and mode.
6. Clears the cache. It closes Outlook (after asking) and deletes only the cached Autodiscover files for that domain.
7. Logs everything to %TEMP%\Set-LocalAutodiscover.log.

Run it again with another address to add more on-prem domains. /remove rolls back.

⬇ Download Outlook-Local-Autodiscover.zip

Usage (extract all files to one folder first):

:: Simple - double-click, as the logged-on user (NOT "Run as administrator")
Setup-Autodiscover.cmd

:: Undo everything the script configured
Setup-Autodiscover.cmd /remove

# PowerShell - no prompts, server and mode chosen automatically
powershell -ExecutionPolicy Bypass -File .\Set-LocalAutodiscover.ps1 -Email user@example.com -Force

# Fixed server, Outlook also has a Microsoft 365 mailbox
powershell -ExecutionPolicy Bypass -File .\Set-LocalAutodiscover.ps1 `
  -Email user@contoso.com -AutodiscoverHost mail.contoso.com -Mode CoexistM365

# Remove one domain only
powershell -ExecutionPolicy Bypass -File .\Set-LocalAutodiscover.ps1 -Remove -Email user@contoso.com

Mass deployment with GPO

• Script: run Set-LocalAutodiscover.ps1 -Force as a User Logon script (User Configuration → Windows Settings → Scripts → Logon). It reads each user’s address from the AD mail attribute, so one GPO covers everyone. Add -Mode CoexistM365 if users also have Microsoft 365 mailboxes.
• Or with Group Policy Preferences:
  • Use Files to copy the XML to %LOCALAPPDATA%\Autodiscover\autodiscover.xml.
  • Use Registry (User Configuration) to create the values from Step 2.
• For the policy path, use HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover. Users can’t change it, and it takes precedence over the preference path.

Troubleshooting and rollback

Rollback: run Setup-Autodiscover.cmd /remove, or delete the values above from the registry and delete the XML file.