Ah, my apologies! You've hit a crucial point regarding the differences between Exchange versions.
The error "A parameter cannot be found that matches parameter name 'InternalUrl'." when running Set-AutodiscoverVirtualDirectory means that the InternalUrl parameter does not exist on Exchange 2013's version of that cmdlet.
This is a key distinction:
- In Exchange 2013, Autodiscover virtual directory URLs are not set directly on the Autodiscover virtual directory itself. Instead, they are typically inherited or determined through other means, primarily the Service Connection Point (SCP) in Active Directory.
- The
InternalUrl and ExternalUrl parameters for Set-AutodiscoverVirtualDirectory were introduced in later versions of Exchange (Exchange 2016/2019).
So, the fact that Get-AutodiscoverVirtualDirectory shows blank URLs on EX2013 is expected and by design for that version, and not the problem.
Let's pivot our troubleshooting based on this new information.
If the Autodiscover URLs are "blank" by design on Exchange 2013, but Test-MigrationServerAvailability is failing because "Autodiscover failed to detect the migration endpoint," then the issue lies in how Autodiscover is being published and resolved for your Exchange 2013 environment.
Here's the revised action plan:
1. Verify the Service Connection Point (SCP) in Active Directory for Exchange 2013 Autodiscover:
Exchange 2013 clients (and other Exchange servers within the forest) primarily use the SCP in Active Directory to locate the Autodiscover service.
From your Domain Controller or a server with Active Directory tools (or even EMS on EX2013):
Open ADSI Edit.
- Connect to
Configuration naming context.
- Navigate to:
CN=Configuration,DC=yourdomain,DC=local
CN=Services
CN=Microsoft Exchange
CN=<Your Exchange Organization Name> (e.g., CN=Argo Field)
CN=Administrative Groups
CN=Exchange Administrative Group (FYDIBOHF23SPDLT)
CN=Servers
CN=EX2013 (your Exchange 2013 server)
CN=Protocols
CN=HTTP
CN=Autodiscover
- Right-click on the
CN=Autodiscover object and select Properties.
- Look for the
keywords attribute. Its value should contain the Autodiscover URL(s). It often looks like https://autodiscover.argofield.co.uk/Autodiscover/Autodiscover.xml or https://mail.argofield.co.uk/Autodiscover/Autodiscover.xml.
If the SCP keywords attribute is missing or incorrect for Autodiscover on EX2013:
You'll need to set it. You can do this with Set-ClientAccessService (from EMS, targeting EX2013).
Set-ClientAccessService -Identity EX2013 -AutoDiscoverServiceInternalUri "https://autodiscover.argofield.co.uk/Autodiscover/Autodiscover.xml"
Again, adjust autodiscover.argofield.co.uk to the correct FQDN that your internal clients and Exchange 2019 are expected to use for Autodiscover on EX2013. This FQDN must be covered by your EX2013 certificate and resolvable via internal DNS to the EX2013 CAS IP.
After setting this, it might take a little while for AD replication, and an iisreset on EX2013 is still a good idea.
2. Verify Internal DNS Resolution:
Even if the SCP is correct, if your internal DNS isn't resolving autodiscover.argofield.co.uk (or whatever FQDN you use for Autodiscover) to the correct internal IP of your EX2013 server, then Autodiscover will fail.
3. Test Connectivity from Exchange 2019 to Exchange 2013's EWS/Autodiscover Endpoint:
Since the Test-MigrationServerAvailability is complaining about Autodiscover, and we know Autodiscover eventually points to EWS for the MRS Proxy, let's try a direct test to the EWS endpoint that should be available.
From your Exchange 2019 EMS, use a web browser or Invoke-WebRequest to test the Autodiscover and EWS endpoints on EX2013.
- Autodiscover Endpoint (XML response expected):
Try navigating to https://autodiscover.argofield.co.uk/Autodiscover/Autodiscover.xml (or https://mail.argofield.co.uk/Autodiscover/Autodiscover.xml if that's what you decided to use) in a browser from the Exchange 2019 server. You should be prompted for credentials and then get an XML response (even an error XML is better than nothing).
- EWS Endpoint (Should prompt for credentials):
Try navigating to https://mail.argofield.co.uk/EWS/Exchange.asmx in a browser from the Exchange 2019 server. You should be prompted for credentials.
If these don't work (e.g., certificate errors, timeouts, connection refused), then you have a fundamental network/certificate issue between 2019 and 2013.
Summary of the revised likely culprit:
The Service Connection Point (SCP) in Active Directory for EX2013's Autodiscover is likely missing or incorrect, or your internal DNS is not correctly resolving the Autodiscover FQDN to your EX2013 server. The InternalUrl parameter issue confirms that we're dealing with Exchange 2013's specific way of handling Autodiscover URLs.
Focus on step 1 (SCP verification/setting) and step 2 (DNS resolution).
