Test-MigrationServerAvailability Failing
Mayo, Bill
As mentioned in an earlier post, we are working to migrate to M365. We are still in the stage where we are trying to get the initial configuration completed and have run into a roadblock that we are having trouble getting past.
When we run the Test-MigrationServerAvailability command, it comes back with:
https://contoso.com /EWS/mrsproxy.svc failed. --> The HTTP request was forbidden with client authentication scheme 'Negotiate'.
The IIS logs then shows a 401 unauthorized:
2025-12-09 16:11:49 W3SVC1 severname 192.168.1.1 GET /ews/MRSProxy.svc &CorrelationID=<empty>;&cafeReqId=9b790e31-5b7c-467a-92ce-2bdXXXXX; 443 - 149.102.252.43 HTTP/1.1 - - contoso.com 401 0 0 454 90 16
The account under which the command is running has Organization Management permissions, but notably does not have a mailbox (3rd party we are working with indicates this is the account to use). In the way of troubleshooting, we have run commands to confirm the proper URLs, that the certificate is not expired, and confirmed that Windows Authentication is enabled on all servers with Negotiate, NTLM as the providers. One thing here that is maybe an x-factor is that we are behind a load balancer doing SSL bridging, where the load balancer has the public certificate and the internal servers are using an internal certificate authority certificate, but we do believe that is all properly configured and people are currently using ActiveSync and OWA with no issues.
Any help, pointers, or suggestions would be appreciated.
Bill Mayo
Michael B. Smith
I would say that you are doing off-loading with re-encryption, not bridging, since you aren’t using the same certificate.
Off-loading isn’t supported with MRSProxy.
Pre-authentication also isn’t supported with MRSProxy.
If you haven’t seen it yet, this is a good document: https://techcommunity.microsoft.com/blog/exchange/troubleshooting-hybrid-migration-endpoints-in-classic-and-modern-hybrid/953006
Generally, what I recommend folks to do is setup a specific IP address for a migration server that doesn’t go through a fancy LB/FW. I’m also pretty darn sure that the migration account needs a mailbox, but I can’t find any documentation on that. Very easy to test though.
--
You received this message because you are subscribed to the Google Groups "ntexchange" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntexchange+...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/ntexchange/6ae15beb4c144635a64addf5db08440b%40pittcountync.gov.
Mayo, Bill
Ok, so would you expect it to work if the same certificates were at both the load balancer and the Exchange servers? We do believe the configuration is in place to not do pre-authentication for the URLs involved here and that does seem to have been confirmed so far.
I hear what you are saying about the different IP, but it is not immediately obvious from what I have seen how you would get the traffic to it, since everything seems to want the same domain name/URL that clients use.
From: ntexc...@googlegroups.com <ntexc...@googlegroups.com>
On Behalf Of Michael B. Smith
Sent: Tuesday, December 9, 2025 2:33 PM
To: ntexc...@googlegroups.com
Subject: [ntexchange] RE: Test-MigrationServerAvailability Failing
|
EXTERNAL EMAIL: This email originated from outside of Pitt County Government. Do not click any links or open any attachments unless you trust the sender and know the content is safe. |
To view this discussion visit https://groups.google.com/d/msgid/ntexchange/48eb826ce68447ad8d44287173a2d057%40smithcons.com.
Michael B. Smith
If that is the only issue, yes.
For the separate IP – if the main exchange servers are mail.contoso.com, then you stand up a specific migration server named exch.contoso.com. Four hours of work, tops. Directly route to/from it for migration. All this hassle goes away. It’s not for mail flow – it’s just for migration.
To view this discussion visit https://groups.google.com/d/msgid/ntexchange/152b4cc441f6482096aeb141e0f4cc15%40pittcountync.gov.
Mayo, Bill
Great, thanks.
Let me just say that I absolutely trust what you are saying, but some of the things we are doing seem to want the URL to match what is in Get-WebServicesVirtualDirectory, for example. Is it not true that this matters, or do you have to update one or more of these attributes?
From: ntexc...@googlegroups.com <ntexc...@googlegroups.com>
On Behalf Of Michael B. Smith
Sent: Tuesday, December 9, 2025 3:00 PM
To: ntexc...@googlegroups.com
Subject: [ntexchange] RE: Test-MigrationServerAvailability Failing
If that is the only issue, yes.
For the separate IP – if the main exchange servers are mail.contoso.com, then you stand up a specific migration server named exch.contoso.com. Four hours of work, tops. Directly route to/from it for migration. All this hassle goes away. It’s not for mail flow – it’s just for migration.
From: ntexc...@googlegroups.com <ntexc...@googlegroups.com>
On Behalf Of Mayo, Bill
Sent: Tuesday, December 9, 2025 2:48 PM
To: ntexc...@googlegroups.com
Subject: [ntexchange] RE: Test-MigrationServerAvailability Failing
Ok, so would you expect it to work if the same certificates were at both the load balancer and the Exchange servers? We do believe the configuration is in place to not do pre-authentication for the URLs involved here and that does seem to have been confirmed so far.
I hear what you are saying about the different IP, but it is not immediately obvious from what I have seen how you would get the traffic to it, since everything seems to want the same domain name/URL that clients use.
From: ntexc...@googlegroups.com <ntexc...@googlegroups.com>
On Behalf Of Michael B. Smith
Sent: Tuesday, December 9, 2025 2:33 PM
To: ntexc...@googlegroups.com
Subject: [ntexchange] RE: Test-MigrationServerAvailability Failing
I would say that you are doing off-loading with re-encryption, not bridging, since you aren’t using the same certificate.
To view this discussion visit https://groups.google.com/d/msgid/ntexchange/09fbf1ab94a240d998555a1bc59a437e%40smithcons.com.
Michael B. Smith
So the migration server is literally a separate namespace. Instead of mail.contoso.com namespace, it’s exch.contoso.com namespace. Yes, you will have to configure the various vdirs to match the separate namespace. If the exchange server name matches the separate namespace, then you don’t even have to do that – they’ll be named properly to start with. Then the migration server PROXIES to all the other servers as necessary. Again, since it’s not used for mailflow, only for migration, it’s seamless.
To view this discussion visit https://groups.google.com/d/msgid/ntexchange/b6e23626536548c49f4f42dbd65d7904%40pittcountync.gov.
Mayo, Bill
Thank you for all that great information.
To view this discussion visit https://groups.google.com/d/msgid/ntexchange/c3b02bcec5c24717bb083ac27c6f38f9%40smithcons.com.
Mayo, Bill
In this scenario, is it just the WebServicesVirtualDirectory (EWS) that would have to be updated? Looking at the ones we have reviewed, it doesn’t seem you would update OWA or ActiveSync. I am not as sure about ECP.
To view this discussion visit https://groups.google.com/d/msgid/ntexchange/c3b02bcec5c24717bb083ac27c6f38f9%40smithcons.com.