Wednesday, October 28, 2015

How to remove the Exchange Autodiscover SCP

Consider a scenario where you moved all your user’s mailboxes to Exchange Online, for instance after a cutover or staged migration and want to remove any dependencies on the local Exchange server. You may find that Outlook still connects to the local Exchange server for Autodiscover lookups, this is because Outlook is hard-coded to query an AD Service Connection Point to locate a server with the Autodiscover service. When this fails Outlook falls back to the next DNS based methods or uses a local XML file.

Exchange Management Shell

There are multiple ways to prevent Outlook from contacting the local Exchange server first, some of them make more sense than others. The preferred way is to use the Exchange Management Shell to clear the entry for the Client Access server from the SCP.

Set-ClientAccessServer –Identity ServerName -AutoDiscoverServiceInternalUri $null

image

This removes the SCP entry for this Exchange server.

ADSIEdit

If the above method can no longer be used a low level AD editor as EDSIEdit can be used to remove the SCP manually. The full path of the SCP is:

CN=ServerName,CN=Autodiscover,CN=Protocols,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName,DC=Suffix

This object to remove has the Class type serviceConnectionPoint.

image

Alternative methods

One of the above steps is basically all you need to do. Alternatives include adding an ExcludeScpLookup value to the \Autodiscover registry key (KB article) and some articles even let you remove the Autodiscover virtual directory from IIS. This will of course make Outlook unable to query the local Exchange server for Autodiscover but why should you if you can simply remove the SCP.

How to verify?

As always, the proof is in the pudding. Use the Outlook test E-mail AutoConfiguration feature to verify the clients behavior. We’re specifically interested in the Log tab where we should see that Outlook is no longer able to query the SCP to obtain the Autodiscover url.

To start the Test E-mail AutoConfiguration tool, follow these steps:

  1. Start Outlook.
  2. Hold down the Ctrl key, right-click the Outlook icon in the notification area, and then click Test E-mail AutoConfiguration.
  3. Verify that the correct email address is in the E-mail Address box.
  4. In the Test E-mail AutoConfiguration window, click to clear the Use Guessmart check box and the Secure Guessmart Authentication check box.
  5. Click to select the Use AutoDiscover check box, and then click Test.

Earlier I wrote a short article about this tool, unfortunately available in Dutch only: Autodiscover testen met Outlook. But you’ll get the general idea. Focus on the first or third tab when you’re interested in the Autodiscover results, read the Log tab when you're interested in the Autodiscover process.

5 comments:

Jeremy Bradshaw said...

So much slicker than using GPO's for Outlook registry settings.

Jeremy Bradshaw said...

I want to say, a better solution, if you still have an Exchange server on-premises, is to set the autodiscoverserviceinternaluri to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml instead of $null. It gives the speed benefit of SCP back to users, and is the fastest performance as long as SCP is left in the users' registry as the default 1st lookup attempt.

Anonymous said...

Hi Jeremy, That makes sense to do that but do you know if MS would support it? What if they change the URL at some point? Even with GPOs, you can prevent the Mac clients or non domain joined computers from connecting right?

Jetze Mellema said...

I don't see how they would not support this, it is a valid Autodiscover endpoint. My only concern is that Microsoft made some changes in the way they implemented Autodiscover in Office 365 in the past, there's a (small) change that at some point they would change the url that is now static in your SCP.

Another thing is the performance benefit. Modern versions of Outlook connect to the last known url simultaneously with the Autodiscover lookup. I doubt that users will see an actual performance improvement after Outlook connected to Exchange Online for the first time.

And finally, I recommend to manage Autodiscover with DNS (or SCP) when possible and prevent making changes to the Outlook behavior with GPO or registry keys.

Unknown said...

Hi all, this has been very helpful, but has not resolved for me. I have an on-premise Exchange 2007 machine and we have moved to O365. However it's still using the local autodiscover, rather than autodiscover.outlook.com.

I have run these commands in Exchange PS:

Set-ClientAccessServer -Identity "SERVER01" -AutoDiscoverServiceInternalUri $null
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null

but I still get local autodiscover when I run Test Email AutoConfg in Outlook (or when I try to add an account).

Any assistance would be very much appreciated!

Cheers,
Chris