Forum Discussion
Prepare Exchange 2019 for Hybrid Configuration Wizard
Greetings!
This particular environment is new to me and I'm assigned the task of migrating to Exchange Hybrid. After an initial assessment, I concluded that I require your feedback since the environment needs some changes first (or so I at least believe), before it's ready to be migrated to hybrid via the HCW.
Scenario:
Current EX: 2019 CU12
Mail Flow inbound: Internet > Smarthost > Exchange Server
Mail Flow outbound: Exchange Server > Smarthost > Internet
MX Record is pointing to the smarthost.
3 MX records for subdomains are setup separately, also pointing to the smarthost.
My concerns, and the items I believe need attention, are:
- None of the virtual directories have an external URL configured with the exception of OWA, which is mail.domain.com.
- How would I go about configuring all the external URL's without breaking the current configuration? I read that Exchange Online requires all the virtual directories to have a working external URL to communicate with it?
- Autodiscover is not reachable from off-prem, only reachable from on-prem. However, configuring a users Outlook on-prem, it will then work off-prem as well (?).
- Trying to figure out how to configure Autodiscover the 'proper' way, so it's reachable from on- and off-prem. Any links to a guide about this, very much appreciated. I Google'd plenty, but there so much different information available...
- Not sure what the Exchange public FQDN is, which is required by the HCW. The smarthost is publicly visible at smarthost.domain.com.
- What SAN's does the certificate need? I'm assuming I'm leaving the current ones in place but adding the Exchange Online domains, and of course requesting the certificate from a CA such as Letsencrypt. What will happen to the domain internal .local domains with a publicly signed certificate?
- What are the required additional domains? Would *.domain.com do? Do I need to add .onmicrosoft.domain.com as well?
- Once the migration is complete, can I leave the three subdomain mx records pointing to the smarthost instead of Exchange Online, or will that break?
- Would it be possible, in theory, to have the domain.com MX record stay pointing to the Smarthost in a Hybrid environment?
I want to avoid running the HCW and basically crippling the Exchange environment because it wasn't ready to be migrated. I have heard that HCW errors out if something isn't ready, however, I've also ready horror stories of it completing, just to find yourself in a mess.
Thank you,
Hello Lussy150
here is Ahmed a community visitor 😉
Let me try to help you 🙂
There are a few steps you can take to ensure that your environment is ready for the migration:
Configure external URLs for all virtual directories: You can use the Exchange Management Console or the Exchange Management Shell to configure external URLs for all virtual directories. This will allow Exchange Online to communicate with your on-premises Exchange server.
Configure Autodiscover: You can use the Exchange Management Console or the Exchange Management Shell to configure Autodiscover so that it is reachable from both on-premises and off-premises. You may also want to consider using a split DNS configuration to ensure that Autodiscover is reachable from both on-premises and off-premises.
Obtain a certificate: You will need to obtain a certificate that includes the required subject alternative names (SANs) for your Exchange server. The SANs should include your Exchange server's public FQDN, as well as the Exchange Online domains. You can use a publicly signed certificate from a trusted certificate authority (CA) such as Let's Encrypt, or you can use a self-signed certificate.
Configure DNS records: You will need to update your DNS records to reflect the new configuration of your Exchange server. This may include updating the MX records for your domain and subdomains to point to Exchange Online.
Run the Hybrid Configuration Wizard: Once you have completed the above steps, you can run the Hybrid Configuration Wizard (HCW) to complete the migration to.
Best of the best 🙂Ahme:D
7 Replies
Hello Lussy150
here is Ahmed a community visitor 😉
Let me try to help you 🙂
There are a few steps you can take to ensure that your environment is ready for the migration:
Configure external URLs for all virtual directories: You can use the Exchange Management Console or the Exchange Management Shell to configure external URLs for all virtual directories. This will allow Exchange Online to communicate with your on-premises Exchange server.
Configure Autodiscover: You can use the Exchange Management Console or the Exchange Management Shell to configure Autodiscover so that it is reachable from both on-premises and off-premises. You may also want to consider using a split DNS configuration to ensure that Autodiscover is reachable from both on-premises and off-premises.
Obtain a certificate: You will need to obtain a certificate that includes the required subject alternative names (SANs) for your Exchange server. The SANs should include your Exchange server's public FQDN, as well as the Exchange Online domains. You can use a publicly signed certificate from a trusted certificate authority (CA) such as Let's Encrypt, or you can use a self-signed certificate.
Configure DNS records: You will need to update your DNS records to reflect the new configuration of your Exchange server. This may include updating the MX records for your domain and subdomains to point to Exchange Online.
Run the Hybrid Configuration Wizard: Once you have completed the above steps, you can run the Hybrid Configuration Wizard (HCW) to complete the migration to.
Best of the best 🙂Ahme:D
I did some testing and changed all the virtual directory url's to mail.domain.com and also replaced the Exchange certificate to a new one signed by an official CA.
They were then accessible just fine and https worked.
However, upon starting Outlook, it through an SSL name mismatch error. Outlook is still trying to connect to the old mail.localdomain.local, but of course now with the new certificate, that will not authenticate.
Is it the receive connectors "FQDN:
Specify the FQDN this connector will provide in response to HELO or EHLO." in the SCOPE tab that needs to be manually changed from the (current) mail.localdomain.com to mail.domain.com?Thank you,
- hello Lussy150
hmmm a good questions
To troubleshoot the SSL name mismatch error when trying to connect Outlook to your Exchange server, you can try changing the FQDN of the receive connectors to mail.domain.com. Before making this change, make sure to create the necessary DNS entries to support the new FQDN. Once you have confirmed that the DNS entries are in place, you can update the FQDN of the receive connectors to mail.domain.com
If you continue to experience issues after making this change you may need to update other components such as the Outlook Anywhere and Autodiscover virtual directories or the SSL certificate on the Exchange server.
Thank you for your reply.
Only a few more questions left which I would appreciate help with.
- Autodiscover currently does not have an internal or an external URL configured. It is working though (internally on-prem only) through an SRV record and an existing SCP entry. Will adding/setting an external URL mess with the internal on-prem Autodiscover service in any way? And since we are on topic, what, if anything, triggers the SCP entry in ADDS to change?
- For a hybrid environment, will a certificate work that has both the .local and the .com SANs? I have not mixed local and public domains in a certificate before.
Thanks!
Hello Lussy150,
Thanks for updating me...
I'v checked for you:
Configure Autodiscover: You can use the Exchange Management Console or the Exchange Management Shell to configure both an internal and an external Autodiscover URL. This will ensure that Autodiscover is reachable from both on-premises and off-premises. You may also want to consider using a split DNS configuration to ensure that Autodiscover is reachable from both on-premises and off-premises.
Obtain a certificate: You will need to obtain a certificate that includes the required subject alternative names (SANs) for your Exchange server and Exchange Online. The SANs should include the FQDNs for both your on-premises Exchange server and the Exchange Online domains. It is generally recommended to use a publicly signed certificate from a trusted certificate authority (CA) rather than a self-signed certificate.
I hope I could answer your questions! Otherwise, please let me know!
Best of the Best:)
Ahme:D
