Forum Discussion
Prepare Exchange 2019 for Hybrid Configuration Wizard
- Dec 23, 2022
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
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
- Lussy150Jan 03, 2023Copper Contributor
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,
- Ahmed_Masoud97Jan 04, 2023Iron Contributorhello 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.
- Lussy150Dec 29, 2022Copper Contributor
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!
- Ahmed_Masoud97Dec 29, 2022Iron Contributor
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
- Lussy150Dec 29, 2022Copper Contributor
I do have one more question for which I couldn't find a clear answer.
Regarding on-prem domain joined clients and Autodiscover. Would, with Exchange 2019, an internal Autodiscover URL and DNS entry even be required? Or would AD DS SCP lookup work anyways without any additional configuration?
Because if so, wouldn't it be almost impossible to break on-prem Autodiscover for domain joined clients since the first thing the clients query for, before any URL's, is the SCP?
Thanks!