Nov 13 2023 06:11 AM - edited Dec 07 2023 02:26 AM
Hi experts,
I'm trying to complete the upgrade process from Exchange 2013(on-premise) to Exchange 2019(on-premise).
I did all the steps that are explained in Best Practice for Upgrade and the Upgrade Assistant from Microsoft experts. Also, I'd like to thank you for them.
But what is my question?
There are 2 Exchange 2013 servers in my domain with more than 2000 users. I installed new Exchange servers and all work fine in the organization.
Regarding our business, I can not take a risk and start mailbox migration directly and would like to test all things in the new environment first, like OWA, Outlook, and all related things to the new environment. I created some databases on the new servers and some users on them to test mail flow on these servers.
The problem that I have is, that I can connect directly to new servers in OWA to newserver.mydomain.com and work with test users, and mail flow there works fine. But when I try to use Outlook to test, it can not find new servers.
I think my issue is autodiscover record in DNS but I can not change it at the moment, because the old environment is working. When I change this record on the new servers to itself(newserver.mydomain.com) and try to configure a profile on Outlook manually and set the mail servers on the new server directly, Outlook still can not find the servers.
What is your suggestion to have a test way in my case? I searched so many articles to find a way but it seems in this way, there is no solution. I don't want to create a new zone for the test, because in the External mail flow test, I will need an SSL certificate.
I appreciate any help or ideas that you can provide.
Kind Regards,
Hassan
Nov 13 2023 06:30 AM
Hi @hassanshakeri,
regarding your question, you can use the Test-Mailflow Powershell cmdlet to diagnose whether mail can be successfully sent from and delivered to the system mailbox on a Mailbox server.
You can also use this cmdlet to verify that email is sent between Mailbox servers within a defined latency threshold.
Here are the steps to test mail flow in Exchange 2019 in an existing Exchange 2013 environment:
Open the Exchange Management Shell on the Exchange 2019 server.
Run the following command:
Test-Mailflow -TargetEmailAddress <email_address>
Replace <email_address> with the email address of the recipient mailbox.
Verify that the test message was delivered to the recipient mailbox.
You can also use the Test-OutlookConnectivity cmdlet to test Outlook connectivity. Here are the steps to test Outlook connectivity:
Open the Exchange Management Shell on the Exchange 2019 server.
Run the following command:
Test-OutlookConnectivity -ProbeIdentity OutlookSelfTestProbe
Verify that the test was successful.
Test-Mailflow (ExchangePowerShell) | Microsoft Learn
Best Practices for Migrating from Exchange Server 2013 to Exchange Server 2019 - Microsoft Community...
Mail Flow issues after mailbox migration Exchange 2013 to 2019 (spiceworks.com)
Please click Mark as Best Response & Like if my post helped you to solve your issue.
This will help others to find the correct solution easily. It also closes the item.
If the post was useful in other ways, please consider giving it Like.
Kindest regards,
Leon Pavesic
(LinkedIn)
Nov 14 2023 06:24 AM
Hi @LeonPavesic
thanks a lot for your answer. But it seems my question was not clear.
The mail flow is working fine and all emails are sending and receiving between mailboxes in both server environments. I can test and check them in OWA.
The problem is, when I create a profile for Outlook in the Mail option in the control panel, and then I Open the Outlook app, it can not find the new servers to connect. It stays there for a long and at the end tells me in an error, that I can not find the proxy server security.
Outlookselftest from the new servers has successful results. 🙄
This is my main issue and I can not find the reason why Outlook can not find the servers. Is there something wrong with the configurations? I have no more idea.
I compared all settings between old and new servers and all seem right.
Best,
Hassan
Nov 14 2023 03:01 PM
Nov 14 2023 10:59 PM
Thanks for your reply. I edited the host file to address Outlook to the new servers before. But it still can not find the servers. I pointed the mx and autodiscover record to the new servers. If there is any other DNS that should be pointed to the new environment?
Kind Regard,
Hassan
Nov 15 2023 01:39 PM
Nov 21 2023 01:48 AM
Hi @Dan_Snape and thanks a lot for the time to answer me.
What I don't understand is, if my way is the right way.
short explanation again:
There are 2 servers in a domain configured on an LB. ex1 and ex2 in production. So we have an MX record for this area.
servers : ex1.mydomain.com & ex2.mydomain.com
mx record: mx.mydomain.com
autodiscover: autodicover.mydomain.com
Now, I installed 2 new servers as Exchange 2019. What do I want to test? I created some mailboxes on the new servers' databases and I want to test mail flow just on these two servers.
I have a test laptop and I edited the host file to:
.
.
.
new server IP mx.mydomain.com
new server IP autodiscover.mydomain.com
In this way, my goal is that the test laptop will just connect to the new server.
As I on top mentioned, I can connect directly to the servers per browser with 443. But when I run Outlook, I get those errors. This I can not understand.
I'm sorry to bother you with the long post but I appreciate it if you have any ideas here.
Kind regards, 🙂
Hassan
Nov 21 2023 02:02 PM
Dec 07 2023 02:24 AM
SolutionHi,
As I finally found and solved the issue, I'd like to share my work with you.
Maybe in future, some one need to know it.
The issue was so less simple than I thought and was just alternative names in the certificate. I created another SAN self-signed certificate with alternative names like the certificate in our live environment and set it in IIS.
With this script:
New-SelfSignedCertificate -DnsName "server1name","server2name","mxRecord","autodiscover.domain.com" -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(10) -FriendlyName "certificateName"
After binding the certificate, Outlook works and all errors are gone.
I hope in this Artikel you can find any solution that helps you to solve the same issues.
Regards,
Hassan
Dec 07 2023 02:24 AM
SolutionHi,
As I finally found and solved the issue, I'd like to share my work with you.
Maybe in future, some one need to know it.
The issue was so less simple than I thought and was just alternative names in the certificate. I created another SAN self-signed certificate with alternative names like the certificate in our live environment and set it in IIS.
With this script:
New-SelfSignedCertificate -DnsName "server1name","server2name","mxRecord","autodiscover.domain.com" -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(10) -FriendlyName "certificateName"
After binding the certificate, Outlook works and all errors are gone.
I hope in this Artikel you can find any solution that helps you to solve the same issues.
Regards,
Hassan