You should not need to expose HTTPS services to the internet after you’ve migrated all mailboxes (and public folders) to Exchange Online. However, people often overlook this important part of housekeeping after a migration.

In this article, I’ll show you how to make sure you can move important configuration across so that you can safely remove rules to publish Exchange Servers to the outside world.

Typically, when you perform a full Hybrid configuration, you will publish Exchange Servers to the internet so that you can perform mailbox moves, and so that clients that aren’t VPN connected can use on-premises Autodiscover where their mailbox resides as you migrate.

Below, you’ll see a high-level view of this configuration. In this example, our SMTP domain (and UPN suffix) is and our Exchange environment has an Autodiscover record created in DNS that corresponds to the load-balanced HTTPS endpoint.

A diagram showing autodiscover records pointing to on-premises Exchange Server published to the internet
A typical implementation of full Exchange Hybrid immediately after a migration

This has a SAN (Subject Alternative Name) SSL certificate so that the name can be used by clients, alongside the primary HTTPS name, that MAPI, ActiveSync, OWA and other Exchange Services are configured to use.

Our Exchange Server also have a Service Connection Point for Autodiscover in Active Directory. This record is found by Outlook clients that can reach an AD Domain Controller and is set using the Exchange cmdlet Set-ClientAccessService with the parameter AutodiscoverServiceInternalURI.

A little background to why you’d expect to see this configuration and how it works

As we are performing a hybrid mailbox migration, we haven’t updated our configuration to point autodiscover to the cloud so while some mailboxes were on-premises and some mailboxes were in Exchange Online, our on-premises Exchange Server could provide a redirect. For example, if our tenant name is then we’d expect the Autodiscover redirect to follow steps like this:

  1. An Exchange client attempts to discover where the mailbox is located, and uses:
    • A Service Connection Point – a look up to the configuration container in Active Directory, for the full HTTPS name of the Autodiscover endpoint for each Exchange Server in the Active Directory site the user is attached to (
    • DNS records for the domain name A record (, the autodiscover DNS A record or CNAME record (, or the SRV record (in this instance, not set, but in the format
    • If the mailbox is in Exchange Online and is licensed, and Autodiscover fails, Outlook 2016 and above will attempt to connect directly to Exchange Online using a feature known as Direct Connect. Read more about this here.
  2. When the Autodiscover record is on-premises, Outlook attempts to sign-in as the user. If the mailbox is in Exchange Online, a mailbox won’t exist on-premises and the Exchange Server cannot provide configuration details. Instead, the user account will have attributes that designate it a Remote Mailbox. One attribute in particular, the Remote Routing Address (or targetAddress, to name the actual attribute) will be retrieved and provided back to the Outlook client. This is typically in the form
  3. Outlook begins Autodiscover again but this time looking up DNS records based on the Remote Routing Address. In our example, Outlook would find a DNS CNAME record for that is an alias for
  4. Outlook then attempts to connect to using HTTPS, and the request fails by design. A second attempt is made using HTTP, and a redirect is provided to
  5. Outlook finally attempts sign-in to over HTTPS and is provided the configuration details for the Exchange Online mailbox.

After moving mailboxes, what comes next?

So, you’ve moved mailboxes to Exchange Online and if you had them, Public Folders too. What you should do now is stop publishing HTTPS services for Exchange Server to the internet. If you can, it might even make sense to stop internal clients from accessing these services as well.

Unfortunately, you can’t remove the last Exchange Server yet, so unless Active Directory & Azure AD Connect are on your decommission list, then you’ll need to keep the server around for ongoing recipient management (and maybe SMTP relay). However, you should be moving to an architecture similar to the one show below:

A diagram showing autodiscover records pointing to Exchange Online
In use Exchange HTTPS names moved to Exchange Online

In the above scenario, we’re no longer load-balancing our internal Exchange Servers, as they are just for recipient management.

Our key change prior to removing any external publishing for Exchange is to update our Autodiscover DNS records.

The Autodiscover records in our example, are updated in DNS to a CNAME record as an alias of as per Microsoft’s guidance.

If you compare the diagram above to the first diagram, you’ll see the Service Connection Point record isn’t listed either. To keep things extremely simple, we’ve updated the value for the SCP to $null (nothing) so that clients will follow the DNS method of Autodiscover only.

To make that change against each server, using the following Exchange Management Shell cmdlet:

Set-ClientAccessService -Identity <Exchange Server Name> -AutoDiscoverServiceInternalUri:

Once this change has been made, domain-joined clients will follow these steps when attempting to find Exchange Online:

  1. Outlook begins Autodiscover and finds a SCP record that directs the client to
  2. Outlook attempts sign-in to over HTTPS and is provided the configuration details for the Exchange Online mailbox.

Non-domain joined clients will follow a separate process, but still connect to Exchange Online first, before getting a HTTPS redirect:

  1. Outlook begins Autodiscover, and find a DNS CNAME record for that is an alias for
  2. Outlook then attempts to connect to using HTTPS, and the request fails by design.
  3. A second attempt is made using HTTP, and a redirect is provided to
  4. Outlook finally attempts sign-in to over HTTPS and is provided the configuration details for the Exchange Online mailbox.

Other configurations, such as the External URLs for Exchange On-Premises, can be updated should you wish, and you could choose to clear these values. If you no longer load-balance Exchange on-prem, you could also choose to reset the Internal URL values to the server names. This isn’t necessary though because no clients have mailboxes on-premises and no Public Folders are on-premises either. Clients won’t attempt to get configuration via on-premises Autodiscover, and therefore the settings are moot.

As a final check though, examine your Exchange Servers’ IIS logs to see if any clients are still accessing Autodiscover – or other services. Although DNS does take a while to update, you should see a drop-off in clients using Autodiscover via on-premises within 24 hours (or less, if your DNS time-to-live records are configured with a short duration).

With Autodiscover records pointed at Exchange Online, and no clients accessing on-premises, you should now be able to safely remove firewall rules that publish Exchange Server to the internet.

About the Author

Steve Goodman

Technology Writer and Chief Editor for AV Content at Practical 365, focused on Microsoft 365. A 12-time Microsoft MVP, author of several technology books and regular Microsoft conference speaker. Steve works at Advania in the UK as Field Chief Technology Officer, advising business and IT on the best way to get the most from Microsoft Cloud technology.


  1. Nordean

    Very Good article, thank you

  2. Scott Haigh

    We have completed the mailbox migration and are using a hybrid onprem server for management and mail relay. We’ve also restricted inbound HTTPS access to the Microsoft Exchange online pool of IP addresses in order to maintain microsoft’s recommended port configuration for hybrid exchange. So we’ve blocked inbound HTTPS from the public internet, but if we’re no longer migrating mailboxes or focusing autodiscover onprem, is there any need whatsover to allow 365 services to access the onprem environment via https?

  3. Pete

    Quick question, All mailboxes are moved to the cloud and we are keeping exchange around for “Support” of exchange attributes and using it as a relay for internal applications.

    If we remove https/https from the internet as the article suggest, do we even need to install/maintain the hybrid configuration (other than just keeping an exchange server running for the above mentioned reasons). I don’t see how they hybrid configuration wizard would even connect if the hybrid server is not accessible form the internet on http/https.

    Thank you

    1. Steve Goodman


      The HCW will connect outbound from the machine it’s ran on, and won’t require a connection inbound from the internet simply to make sure the configuration is updated (e.g. if you make changes or Microsoft need you to re-run it to update, say, Send Connectors after a cert update).


  4. khalil

    Hello Sir, My main issue is the on premise exchange server is being used for sending invoices and email alerts and system notification by many servers and those servers does not have internet access and only access the exchange Ip and Port 25 to use exchange relay – Are there any solution to completely remove the last exchange and still use some kind of email relay or email solution for the company ,

    we can’t remove the last exchange because of exchange relay being used / any solution suggested by experts and Microsoft yet?

    Appreciate you comment

    1. Steve Goodman

      The main reason you can’t remove the last Exchange Server is, if you run Active Directory, and use Azure AD Connect, you have Hybrid Identity. While you do, you still need an Exchange Server on premises to manage attributes. It doesn’t, however, need outside access from then internet if your mailboxes have been migrated.

      1. Matthew Prentice

        “you still need an Exchange Server on premises to manage attributes”

        “Need” is a strong word. To be fully supported, per Microsoft, you need the Exchange Server.

        In reality you can use ADUC’s Attribute Editor tab, PowerShell against AD, or a third-party tool such as Easy365Manager to achieve what you need.

        We continue to struggle with justifying to customers the need to have a separate Exchange server, and pay any associated costs with it (e.g., MSP management fees). We have spent many hours debating the supported solution vs the best solution for our customers.

        1. Steve Goodman

          I’ll stand by “Need”. “Fully supported” isn’t 100% correct, it’s that doing another way is to quote Microsoft “not supported”. I’d agree that if you buy a tool where the vendor will commit to supporting that aspect can offset the risk, but managing attributes for Mailboxes via ADUC attribute edit or ADSIEdit is not a good strategy unless you are willing to fully take on that support burden yourself and ensure you always ensure every attribute that Exchange would have managed is managed *identically*.

          I’ve never struggled to justify why it’s a good idea to remain supported by Microsoft, and customers too small to run an single server for management, should be looking towards going full into Azure AD and removing AD.

          Every time this is stated, there’s always debate. But unfortunately it isn’t a debate that has any other answers than:
          – Use a server for management, and remain supported
          – Carefully select a vendor of a third-party tool to manage attributes, including understanding what their support process will be, should they (for example) miss a change Microsoft make, or implement something incorrectly. – Take on the personal risk of managing the attributes manually (i.e. by hand, or custom script) if it’s you as an IT pro, or as an MSP, if you do that as a service.
          In the last two cases, you might need to, at some point, re-install Exchange 2016 (or start the server again) and perform an update from Microsoft to decommission in a specific way. Therefore I or you should be able to, at any point install an Exchange server and manage those recipients without causing any issue or risk. If that’s a worry then the last two options aren’t viable.

  5. lennart

    Hello, great article.

    I’ve got a question however; we still use on prem printers and other devices that still authenticate to the on prem server for direct smtp traffic to the outside world, i am struggling to find the solution for this. I asume these clients should use o365 smtp authentication but can you someone point me in the right direction? my goal is to only allow SMTP from on prem to MS servers and deny http/https.



    1. Steve Goodman

      At the moment, this is still an ideal use for an Exchange server. Even if they could authenticate directly, using modern authentication or you might not want to allow so many devices access through the firewall, so some on-premises solution might be required..

      1. Matthew Prentice

        One option is to use the Windows Server IIS SMTP component. You can configure it with some restrictions and then have that one server go through the firewall to the receive connector at Exch Online. Your mileage may very.

        1. Steve Goodman

          Installing the fairly dated Windows Server IIS SMTP component will indeed work – and if you are familiar with Exchange 2003 management, it will be a breeze. Why you’ll do that instead of an Exchange 2016 server – mailbox or Edge role – is debatable. Personally, knowing the Microsoft will be coming with a solution here when the time is right – I’d go with a solution that is generally agreed to be the right one – so that anyone with Exchange skills can pick it up and manage it.

  6. Justin Benson


    We have a Full Hybrid (Classic) setup and previously tried setting our Autodiscover to M365 but found we had trouble creating users on-premises and then migrating their mailbox to the cloud. Do you have any experience with that? Or should we be creating AD users on-prem and then creating a remote mailbox for them after they AAD Connect sync to the cloud, instead of migrating a mailbox?

    Thanks for any advice!

    1. Steve Goodman

      You are quite right with that latter suggestion. That’s the way to do it.

      Create them on-premises as an AD user either with New-RemoteMailbox or first in ADUC (or a provisioning tool) then add the required attributes with Enable-RemoteMailbox. Then allow it to sync, and licence.

      1. Justin Benson

        Awesome, thank you!

      2. Matthew Prentice

        Or create the new user and remote mailbox directly within the on-prem Exchange Admin Center assuming you have Exch 2016 (or maybe 2013).

        1. Steve Goodman

          Well, yes – that’s what New-RemoteMailbox and Enable-RemoteMailbox do. The UI in the EAC runs those commands.

  7. Aster

    If we move the autodiscover to the cloud. And some of the application server is still using exchange onprem. Is there any issue?
    Note: We are using Exchange onprem to create user mailbox directly to O365.

    1. Steve Goodman

      I hate to state the obvious (given the title of the article) but if you haven’t finished moving your mailboxes yet, you probably can’t remove autodiscover. However, if it’s just an application mailbox and the application doesn’t use Autodiscover, then you’ll probably be fine moving Autodiscover to the cloud.

  8. MikaelJones

    Many people mention to set AutoDiscoverServiceInternalUri to $null when you have moved the last mailbox. Comment? I’ve tried to find some official info regarding this from Microsoft but have not yet found any.

Leave a Reply