Do the same Outlook registry settings work for Outlook 2016, 2019, 2021, and Microsoft 365 Apps?

Yes. Classic Outlook for Windows from 2016 onward uses the 16.0 registry hive, so the same Autodiscover values apply across Outlook 2016, 2019, 2021, 2024, and Microsoft 365 Apps. New Outlook for Windows is managed differently and does not use these values.

Which registry values control how Outlook finds Autodiscover?

Under HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover and the matching Policies path, the DWORD values include ExcludeScpLookup, ExcludeHttpsRootDomain, ExcludeHttpsAutoDiscoverDomain, ExcludeHttpRedirect, ExcludeSrvRecord, ExcludeLastKnownGoodURL, ExcludeExplicitO365Endpoint, and PreferLocalXML. A value of 1 excludes that lookup method.

How do I push Outlook settings to only one Active Directory site?

Create a Group Policy Object with Group Policy Preferences registry items and either link it to the AD site in Group Policy Management, or add Site item-level targeting to each registry item. Users restart Outlook for the change to take effect.

Why do domain-joined computers still connect to the old Exchange server after a migration?

Domain-joined Outlook clients query Active Directory for a Service Connection Point first. If the old server's SCP still points at it, Outlook uses that answer. Fix the SCP, or set ExcludeScpLookup to 1 so Outlook skips the lookup.

How to Push Outlook Autodiscover and Sign-In Changes to Desktops with GPO, PowerShell, and Intune (Outlook 2016 and Later)

Key takeaway: Classic Outlook for Windows from 2016 onward (Outlook 2016, 2019, 2021, 2024, and Microsoft 365 Apps) shares one registry hive, 16.0, so a single set of settings covers all of them. You can deliver those settings with Group Policy Preferences (scoped to an AD site), a PowerShell script, Intune, or Configuration Manager. The settings control which Autodiscover methods Outlook tries and in what order, which is how you steer desktops to a new Exchange or Exchange Online entry point. Test with a pilot group first, because the wrong value can stop Outlook from finding the mailbox at all.

What This Covers and What It Does Not
How Outlook Finds Its Mailbox
Fix the Source First, Then the Desktops
Step 1: See What Your Desktops Are Doing Now
Step 2: Decide Which Settings You Need
Method 1: Group Policy (Best for Domain-Joined Desktops in a Site)
Method 2: PowerShell Script
Method 3: Intune and Cloud Management
Method 4: Configuration Manager and Other Tools
Profile Creation and Sign-In Behavior
Verify on a Pilot Machine
Roll Out in Rings
Troubleshooting
Checklist

When a mailbox moves to Exchange Online, a server is replaced, or a namespace changes, the mailbox is not the problem. The desktops are. Outlook remembers where it found Autodiscover last time, and domain-joined machines ask Active Directory first. This guide shows how to find out what your desktops are doing, how to change it for every machine in a site, and how to clean up the ones that do not follow.

What This Covers and What It Does Not

Client	Covered here?	Notes
Outlook 2016, 2019, 2021, 2024 (MSI or Click-to-Run)	Yes	All use the `16.0` registry hive. Outlook 2016 and 2019 reached end of support in October 2025, so plan upgrades
Outlook in Microsoft 365 Apps	Yes	Same `16.0` hive
Outlook 2013 and earlier	No	Uses `15.0` and earlier hives and is out of support
New Outlook for Windows	No	Configured through the cloud account and Microsoft 365 or Intune policy, not these registry values
Outlook for Mac, iOS, Android	No	Managed through MDM and their own settings
Outlook on the web	No	Nothing to push

How Outlook Finds Its Mailbox

When Outlook starts, or when it is told its connection needs refreshing, it uses Autodiscover to learn the mailbox server, the sign-in method, and the URLs for features such as free/busy. According to Microsoft, Outlook can try these methods, in roughly this order depending on topology:

SCP lookup. Domain-joined computers query Active Directory for a Service Connection Point published by Exchange.
HTTPS root domain query, such as https://contoso.com/autodiscover/autodiscover.xml.
HTTPS Autodiscover domain query, such as https://autodiscover.contoso.com/autodiscover/autodiscover.xml.
Local XML file, if configured.
HTTP redirect method.
SRV record query.
Cached URL from the Outlook profile, used by Outlook 2010 14.0.7140.5001 and later.
Direct connect to Microsoft 365, used by Outlook 2016 16.0.6741.2017 and later.

This explains the common symptoms after a migration. A domain-joined PC still finds the old on-premises SCP first, gets an answer from the wrong server, and either shows certificate warnings, prompts for credentials, or connects to the old server. A PC outside the domain skips the SCP and works fine. Fixing that difference is the whole job.

Fix the Source First, Then the Desktops

Registry changes on desktops are the second step. First make sure the sources of truth are right, or you will be masking a problem.

DNS. For an Exchange Online mailbox, autodiscover.contoso.com should be a CNAME to autodiscover.outlook.com. For on-premises or hybrid, it should resolve to your Exchange or reverse proxy, and the certificate must match (see the PKI and Exchange guide). Check both internal and external DNS if you use split DNS.
The SCP in Active Directory. On a live on-premises server, set it to the namespace you want clients to use:

Get-ClientAccessService | Format-List Name, AutoDiscoverServiceInternalUri
Set-ClientAccessService -Identity EX01 `
  -AutoDiscoverServiceInternalUri "https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml"

If you have fully moved to Exchange Online and are retiring Exchange, the SCP objects of the old servers must not keep pointing at servers that are gone. Removing an Exchange server correctly removes its SCP. If you keep a management server, make sure its SCP is not advertised to clients, or use the policy in Step 2 to make desktops ignore it.

The on-premises mailbox record. For a mailbox that has moved to the cloud in a hybrid deployment, the on-premises remote mailbox must have the correct targetAddress (the contoso.mail.onmicrosoft.com address) so on-premises Autodiscover redirects the client to the cloud.
Test from the outside. Use Microsoft Remote Connectivity Analyzer's Autodiscover test, and Outlook's own test described under "Verify on a Pilot Machine" below, before touching a single desktop.

Step 1: See What Your Desktops Are Doing Now

Find out which Autodiscover values already exist on your machines. A leftover value from an old migration is a classic cause of "it works for everyone but these PCs." Microsoft's guidance is to check both of these subkeys:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

The values that may be present are all DWORDs: PreferLocalXML, PreferProvidedEmailInAutoDiscoverAuthPrompts, ExcludeHttpRedirect, ExcludeHttpsAutoDiscoverDomain, ExcludeHttpsRootDomain, ExcludeScpLookup, ExcludeSrvRecord, ExcludeLastKnownGoodURL, and ExcludeExplicitO365Endpoint. A value of 1 excludes that method. A value of 0 or absent means Outlook uses it.

A note on names: some blogs and vendor guides refer to a value called ExcludeSrvLookup. Microsoft says that value does not exist in Outlook. Only ExcludeSrvRecord controls the SRV lookup. If you find ExcludeSrvLookup on a machine, it does nothing.

Run this to report the current state on a computer (for the logged-on user):

$paths = 'HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover',
         'HKCU:\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover'
foreach ($p in $paths) {
  Write-Host "== $p"
  if (Test-Path $p) { Get-ItemProperty $p | Select-Object * -ExcludeProperty PS* | Format-List }
  else { Write-Host "(not present)" }
}

For a fleet, run the same check through your remote execution tool or an Intune remediation detection script and collect the output into a CSV.

Step 2: Decide Which Settings You Need

Your situation	Settings to push	Why
Fully moved to Exchange Online; Exchange removed or being removed	`ExcludeScpLookup = 1`; also `ExcludeHttpsRootDomain = 1`	Stops domain-joined PCs asking AD for an SCP that points at old servers. Skipping the root-domain query avoids a slow query against your public website
Hybrid; most users still on-premises	Usually nothing. Keep the SCP correct. Optionally `ExcludeExplicitO365Endpoint = 1`	Prevents the direct-connect-to-Microsoft-365 step from prompting on-premises mailbox users for a Microsoft 365 sign-in when your domain is Microsoft 365-enabled
Hybrid; Autodiscover prompts for Microsoft 365 sign-in on every start	Check `ExcludeExplicitO365Endpoint`, and see "Sign-in behavior" below	Often a mismatch between where DNS points and where the mailbox lives
On-premises only, new namespace	Fix the SCP and DNS. For machines that cannot use them, add the redirect value (below)	Gives Outlook an explicit URL for the domain
Stale values left from a previous project	Remove them (set to 0 or delete)	Old exclusions can block the method you now want
New desktops that should create their profile automatically	`ZeroConfigExchange = 1` (see "Profile creation")	Outlook sets up the account from Autodiscover without prompting

Two warnings. Excluding a method that your environment relies on will stop Outlook from finding the mailbox. Do not turn off methods "to be safe." Also, the policy path (Software\Policies) is the right place for values you want users unable to change. Write there when you manage the setting centrally.

Redirecting a Domain to a Specific Autodiscover URL

If you need Outlook to use an explicit URL for a mail domain, add a string value under the AutoDiscover key. The value *name* is the domain and the value *data* is the URL:

Name:  contoso.com
Type:  REG_SZ
Data:  https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Use this sparingly. It overrides discovery, so when the URL changes again you must push the new value.

Method 1: Group Policy (Best for Domain-Joined Desktops in a Site)

Group Policy Preferences can write registry values reliably across all Outlook versions, and they can be scoped to an Active Directory site.

1a. Prepare the Group Policy Object

Open Group Policy Management. Create a new GPO named Outlook - Autodiscover - <Site name>.
Link it to the site if you want it to apply to every computer and user in that AD site: expand Sites in the console (if it is empty, right-click Sites and choose Show Sites), right-click the site, and choose Link an Existing GPO. Alternatively, link it to the OU that holds the users and use item-level targeting (below).
User settings apply to the user, so make sure the User Configuration section is enabled and security filtering includes the users (Authenticated Users by default).

1b. Add the Registry Preferences

Edit the GPO. Go to User Configuration, Preferences, Windows Settings, Registry.
Right-click, choose New, Registry Item, and set:

Field	Value
Action	Update
Hive	`HKEY_CURRENT_USER`
Key Path	`Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover`
Value name	`ExcludeScpLookup`
Value type	`REG_DWORD`
Value data	`1` (Decimal)

Repeat for each value you chose in Step 2.
To remove a stale value, use the Delete action on the same key and value name.

1c. Limit It to the Right Machines and Versions (Item-Level Targeting)

On the Common tab of each registry item, select Item-level targeting, then Targeting, and add:

Site: the AD site name (so the item only applies when the computer is in that site). This is the cleanest way to roll out one site at a time using a single GPO.
Optionally Registry Match or a security group target, to limit it to a pilot group.

Because Outlook 2016, 2019, 2021, 2024, and Microsoft 365 Apps all use 16.0, you do not need a separate item per version.

1d. Apply and Verify

gpupdate /force
gpresult /r /scope user
reg query "HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover"

Close and reopen Outlook. The values are read when Outlook starts, so a running session does not change behavior until it restarts.

About the Office Administrative Templates

Microsoft publishes one download of ADMX/ADML files for Microsoft 365 Apps, Office 2019, 2021, and 2024. Copy them to your central store (\\yourdomain\SYSVOL\yourdomain\Policies\PolicyDefinitions) to manage many Outlook and Office settings with the normal policy editor. Do not assume the Autodiscover exclusion values appear as dedicated settings in every version of the templates. Writing the registry values with Group Policy Preferences, as above, works regardless.

Method 2: PowerShell Script

Use a script when the machines are not all domain-joined, when you need to run it through a deployment tool, or when you want to change values for users who are not logged on.

2a. Per-User Script (Runs as the Signed-In User)

This is the simplest form, suitable for a logon script or an Intune script set to run in the user context:

$key = 'HKCU:\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover'
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name ExcludeScpLookup      -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $key -Name ExcludeHttpsRootDomain -Value 1 -PropertyType DWord -Force | Out-Null

2b. Machine-Wide Script (Runs as Administrator or SYSTEM)

This version applies to every profile on the computer: users currently signed in, users who are not signed in, and the default profile that new users copy. Test it with -WhatIf first.

[CmdletBinding(SupportsShouldProcess)]
param(
  [hashtable]$Values = @{ ExcludeScpLookup = 1; ExcludeHttpsRootDomain = 1 },
  [switch]$Remove,
  [string]$OfficeVersion = '16.0'
)

$sub = "Software\Policies\Microsoft\Office\$OfficeVersion\Outlook\AutoDiscover"

function Set-Hive([string]$root) {
  $path = "Registry::$root\$sub"
  foreach ($name in $Values.Keys) {
    if ($Remove) {
      if ($PSCmdlet.ShouldProcess("$path\$name", 'Remove')) {
        Remove-ItemProperty -Path $path -Name $name -ErrorAction SilentlyContinue
      }
    } else {
      if ($PSCmdlet.ShouldProcess("$path\$name", "Set to $($Values[$name])")) {
        if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
        New-ItemProperty -Path $path -Name $name -Value $Values[$name] -PropertyType DWord -Force | Out-Null
      }
    }
  }
}

# 1. Users who are signed in (hives already loaded)
Get-ChildItem Registry::HKEY_USERS |
  Where-Object { $_.PSChildName -match '^S-1-5-21-[\d-]+$' } |
  ForEach-Object { Set-Hive $_.Name }

# 2. Users who are not signed in, plus the Default profile (load each hive, then unload)
$offline = @(Get-CimInstance Win32_UserProfile | Where-Object { -not $_.Special -and -not $_.Loaded } |
  ForEach-Object { Join-Path $_.LocalPath 'NTUSER.DAT' })
$offline += 'C:\Users\Default\NTUSER.DAT'
foreach ($dat in $offline) {
  if (-not (Test-Path $dat)) { continue }
  reg load HKU\TempOutlook "$dat" | Out-Null
  try { Set-Hive 'HKEY_USERS\TempOutlook' }
  finally { [gc]::Collect(); Start-Sleep -Milliseconds 300; reg unload HKU\TempOutlook | Out-Null }
}

To pass your own values, call it like .\Set-OutlookAutodiscover.ps1 -Values @{ExcludeScpLookup=1}. To undo, run it again with -Remove and the same names.

2c. Run It Against Many Computers

$computers = Get-Content C:\Migration\outlook-pilot.txt
Invoke-Command -ComputerName $computers -FilePath .\Set-OutlookAutodiscover.ps1

This requires PowerShell remoting to be allowed. For machines you cannot reach this way, use a deployment tool.

Method 3: Intune and Cloud Management

Scripts. In the Intune admin center, go to Devices, Scripts and remediations, Platform scripts, and add the PowerShell. Choose to run in the user context for the per-user script, or the system context for the machine-wide script.
Remediations. Use a detection script (the audit script from Step 1, exiting with an error when the values are wrong) with a remediation script (Method 2). This keeps checking and fixing drift on a schedule, which handles machines that return after being offline.
Policy. If you use the Microsoft 365 Apps cloud policy service or ADMX-backed policies for other Office settings, use them for settings that appear there. Write other values with scripts or remediations.
Scope. Use a device or user group, and deploy first to a pilot group.

Method 4: Configuration Manager and Other Tools

In Configuration Manager, create a Configuration Item with a registry value setting for the current user, set it to be remediated, and add it to a baseline targeted at a collection. Any endpoint management tool that can run PowerShell or set a registry value in a user context can apply the same values.

Profile Creation and Sign-In Behavior

Autodiscover settings affect what Outlook finds. Sometimes the existing profile also needs to be refreshed, or the sign-in needs help.

Refreshing a Stuck Profile

Delete cached Autodiscover files so Outlook asks again. They are in %LOCALAPPDATA%\Microsoft\Outlook and have names ending in Autodiscover.xml. Close Outlook first.

Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Outlook" -Filter '*Autodiscover*.xml' | Remove-Item -Force

If the profile still points to the old server, create a new profile (Control Panel, Mail, Show Profiles, Add). Outlook then runs Autodiscover from scratch and picks the new settings. You can also enable first-run auto-configuration for new profiles by setting ZeroConfigExchange to 1 under the AutoDiscover key. Test this on a pilot machine first, as behavior depends on how your accounts are set up.
If the mailbox was moved, restart Outlook. A moved mailbox normally prompts a restart on its own once Autodiscover answers correctly.

Sign-In Behavior

Modern authentication. Outlook 2016 and later use modern authentication with Microsoft 365 by default. If Outlook keeps prompting, the usual causes are cached credentials and a stale token cache rather than a missing setting.
Hybrid Autodiscover. For hybrid environments, Microsoft documents a registry value AlwaysUseMSOAuthForAutoDiscover (DWORD 1) under HKCU\Software\Microsoft\Exchange to force modern authentication for Autodiscover requests. Use it if Outlook shows a basic credentials prompt for Autodiscover during hybrid sign-in.
Account email or UPN. If the sign-in prompt shows the wrong name, the PreferProvidedEmailInAutoDiscoverAuthPrompts value controls whether the configured email or the UPN is used.
Clear cached credentials and tokens when a user is stuck in a prompt loop: sign out of Office, close Outlook, remove MicrosoftOffice16_Data entries in Credential Manager, and delete the identity cache folder under %LOCALAPPDATA%\Microsoft\IdentityCache, then sign in again.

cmdkey /list | Select-String 'MicrosoftOffice16'

Verify on a Pilot Machine

Check the registry. Run the audit script from Step 1 and confirm the values are present in the Policies path.
Run Outlook's own test. Hold Ctrl, right-click the Outlook icon in the notification area, and choose Test E-mail AutoConfiguration. Confirm the email address, clear Use Guessmart and Secure Guessmart Authentication, and select Test. The Log tab lists every method Outlook tried, including the ones your settings excluded, and the Results tab shows the final URLs.
Check where Outlook is connected. Hold Ctrl, right-click the icon, and choose Connection Status. The server name should be the Exchange Online or new on-premises endpoint.
Run it twice. Once on a domain-joined computer inside the site and once on one outside, to confirm both paths.
Check for prompts. Start Outlook cold (after a reboot) and look for credential or certificate prompts.

Roll Out in Rings

Pilot (5 to 10 users across Outlook versions). Run for several days.
One site using a site-scoped GPO or targeting.
Remaining sites, one at a time, with a rollback plan ready.
Rollback. Keep the removal version of the script (-Remove) or switch the GPP item action to Delete. Tell the helpdesk what changed and how to test (see "Verify on a Pilot Machine").
Document the settings in your change record. Autodiscover exclusions are easy to forget, and they cause confusing problems years later, so add a reminder to review them when the environment changes again.

Troubleshooting

Symptom	Likely cause
Domain PCs connect to the old server, others work	The SCP in AD still points at the old server. Fix it or set `ExcludeScpLookup = 1`
Outlook shows "The connection to Microsoft Exchange is unavailable" after a migration	Autodiscover cannot return the new settings. Check DNS and the Test E-mail AutoConfiguration log
Outlook never finds the mailbox after you set exclusions	You excluded the method your environment relies on. Remove the values and retest
Values are set but nothing changed	Outlook was not restarted, the GPO is not applying (check `gpresult`), or the policy was written under the wrong Office version number
Certificate warning on first start	Autodiscover reaches a server with a name-mismatched certificate. See the Exchange certificate guide
Microsoft 365 sign-in window appears for on-premises mailboxes	The direct connect to Microsoft 365 step is being tried. Consider `ExcludeExplicitO365Endpoint = 1`
One user is wrong while the site is right	Stale per-user values or a cached XML file. Run the audit script and clear the cache
Setting `ExcludeSrvLookup` has no effect	That value is not used by Outlook. Use `ExcludeSrvRecord`
It works for Outlook 2016 but not for new Outlook	New Outlook is configured differently and ignores these registry values

Checklist

[ ] DNS, SCP, and certificate verified before changing any desktop
[ ] Current values audited on a sample of machines, stale values identified
[ ] Settings chosen for your scenario and written into the change record
[ ] GPO created and scoped to the site (or script/Intune scope prepared)
[ ] Pilot group tested with Test E-mail AutoConfiguration on and off the domain
[ ] Rollback script or GPO action ready
[ ] Rolled out site by site, with users told to restart Outlook
[ ] Cached Autodiscover files and credentials cleared for any stuck users
[ ] Old SCPs and stale registry values cleaned up after the migration is complete

If you would like help with an Exchange Online cutover, a hybrid Autodiscover problem, or a desktop rollout across several sites, get in touch.

← All Articles Free Assessment

How to Push Outlook Autodiscover and Sign-In Changes to Desktops with GPO, PowerShell, and Intune (Outlook 2016 and Later)

In This Article

What This Covers and What It Does Not

How Outlook Finds Its Mailbox

Fix the Source First, Then the Desktops

Step 1: See What Your Desktops Are Doing Now

Step 2: Decide Which Settings You Need

Redirecting a Domain to a Specific Autodiscover URL

Method 1: Group Policy (Best for Domain-Joined Desktops in a Site)

1a. Prepare the Group Policy Object

1b. Add the Registry Preferences

1c. Limit It to the Right Machines and Versions (Item-Level Targeting)

1d. Apply and Verify

About the Office Administrative Templates

Method 2: PowerShell Script

2a. Per-User Script (Runs as the Signed-In User)

2b. Machine-Wide Script (Runs as Administrator or SYSTEM)

2c. Run It Against Many Computers

Method 3: Intune and Cloud Management

Method 4: Configuration Manager and Other Tools

Profile Creation and Sign-In Behavior

Refreshing a Stuck Profile

Sign-In Behavior

Verify on a Pilot Machine

Roll Out in Rings

Troubleshooting

Checklist

Have a Microsoft 365 question?

How to Push Outlook Autodiscover and Sign-In Changes to Desktops with GPO, PowerShell, and Intune (Outlook 2016 and Later)

In This Article

What This Covers and What It Does Not

How Outlook Finds Its Mailbox

Fix the Source First, Then the Desktops

Step 1: See What Your Desktops Are Doing Now

Step 2: Decide Which Settings You Need

Redirecting a Domain to a Specific Autodiscover URL

Method 1: Group Policy (Best for Domain-Joined Desktops in a Site)

1a. Prepare the Group Policy Object

1b. Add the Registry Preferences

1c. Limit It to the Right Machines and Versions (Item-Level Targeting)

1d. Apply and Verify

About the Office Administrative Templates

Method 2: PowerShell Script

2a. Per-User Script (Runs as the Signed-In User)

2b. Machine-Wide Script (Runs as Administrator or SYSTEM)

2c. Run It Against Many Computers

Method 3: Intune and Cloud Management

Method 4: Configuration Manager and Other Tools

Profile Creation and Sign-In Behavior

Refreshing a Stuck Profile

Sign-In Behavior

Verify on a Pilot Machine

Roll Out in Rings

Troubleshooting

Checklist

Related services

Have a Microsoft 365 question?