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 practical365.com and our Exchange environment has an Autodiscover record created in DNS that corresponds to the load-balanced HTTPS endpoint.
This has a SAN (Subject Alternative Name) SSL certificate so that the autodiscover.practical365.com name can be used by clients, alongside the primary HTTPS name, outlook.practical365.com 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 practical365.onmicrosoft.com then we’d expect the Autodiscover redirect to follow steps like this:
- 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 (https://autodiscover.practical365.com/Autodiscover/Autodiscover.xml)
- DNS records for the domain name A record (practical365.com), the autodiscover DNS A record or CNAME record (autodiscover.practical365.com), or the SRV record (in this instance, not set, but in the format _autodiscover._tcp.practical365.com)
- 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.
- 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 alias@tenantname.mail.onmicrosoft.com.
- 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 autodiscover.practical365.mail.onmicrosoft.com that is an alias for autodiscover.outlook.com.
- Outlook then attempts to connect to autodiscover.outlook.com using HTTPS, and the request fails by design. A second attempt is made using HTTP, and a redirect is provided to autodiscover-s.outlook.com.
- Outlook finally attempts sign-in to autodiscover-s.outlook.com 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:
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, autodiscover.practical365.com are updated in DNS to a CNAME record as an alias of autodiscover.outlook.com 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:https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.XML
Once this change has been made, domain-joined clients will follow these steps when attempting to find Exchange Online:
- Outlook begins Autodiscover and finds a SCP record that directs the client to autodiscover-s.outlook.com.
- Outlook attempts sign-in to autodiscover-s.outlook.com 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:
- Outlook begins Autodiscover, and find a DNS CNAME record for autodiscover.practical365.com that is an alias for autodiscover.outlook.com.
- Outlook then attempts to connect to autodiscover.outlook.com using HTTPS, and the request fails by design.
- A second attempt is made using HTTP, and a redirect is provided to autodiscover-s.outlook.com.
- Outlook finally attempts sign-in to autodiscover-s.outlook.com 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.
Very Good article, thank you
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?
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
Pete
Hiya,
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).
Steve
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
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.
“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. https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange#can-third-party-management-tools-be-used
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.
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.
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.
regards,
Lennart
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..
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.
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.
Steve,
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!
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.
Awesome, thank you!
Or create the new user and remote mailbox directly within the on-prem Exchange Admin Center assuming you have Exch 2016 (or maybe 2013).
Well, yes – that’s what New-RemoteMailbox and Enable-RemoteMailbox do. The UI in the EAC runs those commands.
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.
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.
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.
I’d normally recommend setting it to $null too – however, until we get to the bottom of the Autodiscover flaw case, I opted to advise that you set it to the direct endpoint instead until we know more. You can read more on this here: https://practical365.com/why-a-potential-autodiscover-flaw-is-just-the-tip-of-an-iceberg/