The error message "A version mismatch was detected (Actual:6, Expected:5)." when trying to create migration jobs from Exchange 2013 to Exchange 2019 is a common issue. This typically indicates a problem with the migration mailbox (also known as the arbitration mailbox) or an inconsistency in how the Exchange servers perceive the migration process.

Here's a breakdown of the likely cause and common solutions:

Understanding the Error:

• Actual:6, Expected:5: This usually refers to the version of the Exchange Mailbox Replication Service (MRS) or a related component. Exchange 2013 uses a different internal version than Exchange 2019. The migration process needs to be handled by an MRS proxy that understands both versions.
• Migration Mailbox: Exchange uses a special system mailbox named "Migration" (or similar, like Migration.8f3e7716-2011-43e4-96b1-aba62d229136) to manage mailbox move requests. This mailbox needs to be on the target Exchange server (Exchange 2019 in your case) for migrations to work correctly. If it's still on the old Exchange 2013 server, or if it's corrupted, you'll see this version mismatch error.

Common Solutions:

1. Move the Migration Mailbox to Exchange 2019: This is the most common and effective solution. The "Migration" arbitration mailbox needs to reside on the Exchange 2019 server.

   • Identify the Migration Mailbox: Open Exchange Management Shell (EMS) and run:

     Get-Mailbox Migration* -Arbitration | Format-List Name,Database,AdminDisplayVersion
     

     This will show you the name of the migration mailbox, which database it's on, and its current version. You'll likely see it's on an Exchange 2013 database (version 15.0).

   • Move the Migration Mailbox: Once you've identified the migration mailbox, move it to a database on your Exchange 2019 server. Replace "YourExchange2019DatabaseName" with the actual name of a database on your Exchange 2019 server.

     Get-Mailbox Migration* -Arbitration | New-MoveRequest -TargetDatabase "YourExchange2019DatabaseName"
     

     You can monitor the move request status with Get-MoveRequest.

   • Verify the Version: After the move is complete, run the Get-Mailbox Migration* -Arbitration | Format-List Name,Database,AdminDisplayVersion command again. The AdminDisplayVersion should now show 15.2 (for Exchange 2019), indicating it's correctly on the new server.

2. Ensure Exchange 2019 has the Latest Cumulative Update (CU): Always ensure both your source Exchange 2013 and target Exchange 2019 servers are running the latest recommended Cumulative Updates. This helps ensure compatibility and resolves known issues.

3. Check MRS Proxy on Exchange 2019: The Mailbox Replication Service (MRS) Proxy needs to be enabled on your Exchange 2019 Client Access servers for remote move requests to function.

   Get-WebServicesVirtualDirectory -Identity "YourExchange2019ServerName\EWS (Default Web Site)" | Format-List MRSProxyEnabled
   

   If it's $false, enable it:

   Set-WebServicesVirtualDirectory -Identity "YourExchange2019ServerName\EWS (Default Web Site)" -MRSProxyEnabled $true
   

4. Consider PrepareAD (Use with Caution): In some rare cases, if the migration mailbox is completely missing or severely corrupted and moving it doesn't work, you might consider running Setup.exe /PrepareAD from your Exchange 2019 server. However, use this as a last resort and ensure you have proper backups, as it can make significant changes to your Active Directory schema.

5. Restart Services: After making changes, especially moving the migration mailbox, it's a good idea to restart the Microsoft Exchange Mailbox Replication service on both the source (Exchange 2013) and target (Exchange 2019) servers. You might even consider rebooting the Exchange servers during a maintenance window.

6. Check Message Size Limits (Less Common for this specific error): While less likely to cause a direct "version mismatch," incorrect message size limits in web.config files for EWS can sometimes interfere with migration processes. However, this usually manifests as timeouts or other errors.

Important Considerations:

• Active Directory Health: Before any Exchange migration, ensure your Active Directory environment is healthy (DNS, replication, etc.).
• Permissions: The account you're using to perform the migration must have the necessary permissions (e.g., Organization Management role).
• Logs: Check the event logs on both Exchange 2013 and Exchange 2019 servers for more detailed error messages that might provide further clues.

By following these steps, particularly moving the migration mailbox to Exchange 2019, you should be able to resolve the "version mismatch" error and proceed with your user migrations.

You're not alone! Many administrators only encounter the need to enable the MRS Proxy when performing specific types of migrations. It's often disabled by default for security reasons, as it opens a specific endpoint on your Exchange servers.

Let's break down why it's needed for this scenario and why you might not have encountered it before:

What is the MRS Proxy?

MRS stands for Mailbox Replication Service. This service is responsible for moving mailboxes within and between Exchange organizations. The MRS Proxy is a component of the MRS that specifically handles remote move requests.

Why is it needed for Exchange 2013 to 2019 Migrations (specifically with your error)?

Even though you're migrating within the same Active Directory forest (presumably), the migration from Exchange 2013 to Exchange 2019 is considered a "cross-version" or "remote" move from the perspective of the MRS.

• Version Mismatch: Your "Actual:6, Expected:5" error hints at the MRS on the Exchange 2019 server trying to communicate with a component on the Exchange 2013 server that it perceives as an older version. The MRS Proxy acts as a bridge or a compatible endpoint that allows the newer MRS to "talk" to the older one.
• Pull vs. Push Moves: Mailbox moves can be initiated from the source (push) or the target (pull). In the context of your migration (moving from 2013 to 2019, where 2019 is your target), Exchange 2019 is "pulling" the mailboxes from Exchange 2013. For this to happen, the MRS Proxy needs to be enabled on the source Exchange servers, which in this case, is your Exchange 2013 server's Client Access (CAS) role (or combined Mailbox/CAS role if that's how it's configured).

When is MRS Proxy typically needed?

You'll generally need the MRS Proxy enabled for:

1. Cross-Forest Mailbox Moves: Moving mailboxes between two entirely separate Exchange organizations in different Active Directory forests.
2. Remote Move Migrations to/from Exchange Online (Hybrid Deployments): This is where it's most commonly discussed. When you migrate mailboxes to or from Microsoft 365 (Exchange Online), the MRS Proxy is essential for the Mailbox Replication Service in Exchange Online to communicate with your on-premises Exchange servers.
3. Cross-Version On-Premises Migrations (like yours): While not strictly "cross-forest," the version difference between Exchange 2013 and 2019 requires the MRS Proxy for successful internal moves, especially if the migration process is initiated from the newer Exchange 2019 environment.

Why you might not have needed it before:

• Same-Version Moves: If you've only performed migrations within the same Exchange version (e.g., Exchange 2013 to Exchange 2013 on a different database), the MRS Proxy typically isn't explicitly required. The internal MRS communication handles it without needing the "proxy" endpoint.
• Other Migration Methods: If you used third-party migration tools or specific cutover methods that didn't rely on the Exchange MRS for remote moves, you wouldn't have encountered this requirement.

Action to take:

Given your error, the most direct approach is to enable the MRS Proxy on your Exchange 2013 Client Access Servers (or combined Mailbox/CAS servers). This allows your Exchange 2019 MRS to properly communicate and pull the mailboxes from your 2013 environment.

The commands I provided earlier are correct:

To check the status:

Get-WebServicesVirtualDirectory -Identity "YourExchange2013ServerName\EWS (Default Web Site)" | Format-List MRSProxyEnabled

(Replace "YourExchange2013ServerName" with the actual name of an Exchange 2013 server.)

To enable it:

Set-WebServicesVirtualDirectory -Identity "YourExchange2013ServerName\EWS (Default Web Site)" -MRSProxyEnabled $true

After enabling, remember to perform an IISRESET on the Exchange 2013 server(s) where you enabled it to ensure the change takes effect immediately.

You're right to be persistent! The "version mismatch" error is notoriously tricky because it can stem from several underlying issues, even after you've seemingly addressed the obvious ones like MRS Proxy.

Since you've confirmed MRS Proxy is enabled on both sides (and a restart of IIS or the MRS service would be good measure if you haven't done that), the next most likely culprit is indeed the migration mailbox (or arbitration mailbox). This is the key element for managing move requests, and its state and location are critical.

Here's a systematic approach to troubleshoot further:

1. Verify the Migration Mailbox Location and Version (Crucial):

This is paramount. The "Migration" arbitration mailbox must be on an Exchange 2019 database.

• On Exchange 2013 EMS, run:

  Get-Mailbox -Arbitration | Format-List Name,Database,AdminDisplayVersion,ExchangeVersion
  

  Look for a mailbox named Migration* (e.g., Migration.8f3e7716-2011-43e4-96b1-aba62d229136).

  • What Database is it on? It must be on an Exchange 2019 database.
  • What is AdminDisplayVersion? For Exchange 2013, it's typically Version 15.0 (Build xxx.xx), for Exchange 2019, it's Version 15.2 (Build xxx.xx). The migration mailbox needs to reflect the target version.
  • What is ExchangeVersion? This should also reflect the target version.

• If the Migration Mailbox is NOT on Exchange 2019: This is almost certainly your problem. You need to move it.

  Get-Mailbox Migration* -Arbitration | New-MoveRequest -TargetDatabase "YourExchange2019DatabaseName"
  

  • Important: Replace "YourExchange2019DatabaseName" with the actual name of one of your healthy Exchange 2019 mailbox databases.
  • Monitor the move request: Get-MoveRequest | Format-List Identity,Status,PercentComplete
  • Once complete, verify its location and version again with Get-Mailbox -Arbitration | Format-List Name,Database,AdminDisplayVersion,ExchangeVersion.

2. If the Migration Mailbox is Already on Exchange 2019 but the Error Persists:

This is less common but can happen if the mailbox itself is corrupted or its internal state is wrong.

• Option A: Recreate the Migration Mailbox (More Aggressive, Use with Caution) This is often the solution if a move doesn't fix it. You would delete the existing migration mailbox and then force Exchange to recreate it.

  • Get the exact name:

    Get-Mailbox Migration* -Arbitration
    

  • Disable (soft delete) the mailbox:

    Disable-Mailbox -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" -Arbitration -Confirm:$false
    

    (Replace with the actual identity of your migration mailbox.)
  • Clean up from Active Directory (if necessary, after a short delay): Sometimes you might need to manually remove the associated AD object if it doesn't clean up fully.

    Get-User "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" | Remove-ADObject
    

    (Again, replace with the actual identity.)
  • Recreate the arbitration mailboxes (including Migration): Run Setup.exe /PrepareAD from your Exchange 2019 installation media, in an elevated command prompt. This will recreate all default arbitration mailboxes.

    <Exchange 2019 Installation Media Path>\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
    

    Note: Running /PrepareAD updates your Active Directory schema and configuration. Ensure you understand the implications and have backups. It should be run from an Exchange 2019 server with appropriate permissions.
  • Move the newly created Migration mailbox to an Exchange 2019 database: After PrepareAD, the new migration mailbox will likely be on a 2013 database initially. You'll need to move it to a 2019 database as per step 1.

• Option B: Check for Authentication Issues: While less common for this specific error message after MRS Proxy is enabled, authentication problems between the MRS on 2019 and the EWS on 2013 can sometimes cause general migration failures.

  • Ensure that Windows Integrated Authentication is enabled on the EWS virtual directory on your Exchange 2013 servers.
  • You can verify this with:

    Get-WebServicesVirtualDirectory -Identity "YourExchange2013ServerName\EWS (Default Web Site)" | Format-List *Authentication*
    

  • And set it if needed (though usually it's correct):

    Set-WebServicesVirtualDirectory -Identity "YourExchange2013ServerName\EWS (Default Web Site)" -WindowsAuthentication $true
    

3. Test Migration Server Availability:

After each change, use this cmdlet from Exchange 2019 EMS to test the connection to your 2013 server for migration purposes.

Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress <an_email_address_on_Exchange_2013> -Credentials (Get-Credential)

When prompted, provide credentials for an account that has permissions to manage mailboxes on both Exchange 2013 and 2019 (e.g., a member of Organization Management). This test is invaluable for pinpointing where the communication breaks down.

4. Check for Cumulative Updates (CUs):

Ensure both your Exchange 2013 and Exchange 2019 servers are on the latest (or very recent) Cumulative Updates. Missing CUs can lead to unpredictable behavior and subtle compatibility issues.

Summary of the most likely fix:

Even though you enabled MRS Proxy, the Migration arbitration mailbox is still the prime suspect for this specific error. Ensure it's not just present, but actually residing on an Exchange 2019 database and has successfully updated its internal version to reflect Exchange 2019. If it's already on 2019 but still giving the error, consider recreating it via PrepareAD.

Okay, this is an excellent step forward because the Test-MigrationServerAvailability output gives us a much clearer direction!

The error message: "AutoDiscover failed with a configuration error: The migration service failed to detect the migration endpoint using the Autodiscover service."

This tells us that the problem isn't necessarily the MRS Proxy itself being enabled or disabled anymore (though it needs to be enabled for the connection to work once Autodiscover is fixed). The immediate blocker is that the Exchange 2019 server cannot properly discover the necessary endpoints (specifically the MRS Proxy endpoint) on the Exchange 2013 server via Autodiscover.

Key areas to investigate for Autodiscover issues during migrations:

1. Internal and External DNS:

   • Internal DNS: This is the most critical for on-premises migrations. Your Exchange 2019 server needs to resolve the Autodiscover URL for your Exchange 2013 environment.
     • What is your internal Autodiscover URL for Exchange 2013? (e.g., autodiscover.yourdomain.local or autodiscover.yourpublicdomain.com).
     • From your Exchange 2019 server, can you ping or nslookup that Autodiscover FQDN and does it resolve to the correct Exchange 2013 CAS IP address?
   • External DNS (Less likely for internal moves, but worth checking): If your internal users typically use the external Autodiscover URL (e.g., autodiscover.yourpublicdomain.com), ensure it points correctly to your Exchange 2013 CAS (via your firewall/load balancer if applicable).

2. Autodiscover Virtual Directory Health on Exchange 2013:

   • InternalURL: Check the internal URL for the Autodiscover virtual directory on your Exchange 2013 server.

     Get-AutodiscoverVirtualDirectory -Server EX2013 | Format-List InternalURL,ExternalURL
     

     Ensure the InternalURL is correct and resolvable from your Exchange 2019 server.
   • Authentication: Ensure basic and Windows authentication are enabled on the Autodiscover virtual directory.

     Get-AutodiscoverVirtualDirectory -Server EX2013 | Format-List *Authentication*
     

3. Certificates:

   • Validity: Is the SSL certificate on your Exchange 2013 CAS server valid, not expired, and trusted by the Exchange 2019 server?
   • Subject Alternative Names (SANs): Does the certificate include all necessary FQDNs, including:
     • Your internal server FQDNs (e.g., EX2013.argofield.local)
     • Your Autodiscover FQDN (e.g., autodiscover.argofield.co.uk)
     • Your OWA/ECP FQDN (e.g., mail.argofield.co.uk or webmail.argofield.co.uk)
   • You can check the certificate bound to the default website on Exchange 2013:

     Get-ExchangeCertificate | Format-List Services,Subject,CertificateDomains,Thumbprint,NotBefore,NotAfter
     

     Look for the certificate with "IIS" in the Services column and verify its validity and CertificateDomains.

4. Exchange 2013 EWS Virtual Directory Internal URL (Again): While you enabled MRS Proxy, ensure the InternalURL for the EWS virtual directory on Exchange 2013 is properly configured and resolvable from Exchange 2019. The MRS relies on EWS for communication.

   Get-WebServicesVirtualDirectory -Identity "EX2013\EWS (Default Web Site)" | Format-List InternalURL,ExternalURL
   

   If InternalURL is empty or incorrect, set it:

   Set-WebServicesVirtualDirectory -Identity "EX2013\EWS (Default Web Site)" -InternalURL "https://ex2013.argofield.local/EWS/Exchange.asmx"
   

   (Adjust the FQDN to your internal FQDN for EX2013.)

5. Test Autodiscover from a Client (e.g., Microsoft Connectivity Analyzer): Use the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com) to perform an "Outlook Autodiscover" test (or a specific Exchange Web Services test) from an external perspective.

   • Select "Exchange Server" > "Outlook Connectivity" or "Exchange Web Services" > "Synchronization, Notification, Availability, and Automatic Replies" and provide credentials for a test mailbox on Exchange 2013.
   • This will help identify if the external Autodiscover is working.
   • For internal testing, you can use the Microsoft Connectivity Analyzer (available for download) on a client machine within your network, or from the Exchange 2019 server itself.

6. Restart IIS/Services: After making any changes to virtual directories or certificates, perform an iisreset on the Exchange 2013 server. Also, restart the "Microsoft Exchange Mailbox Replication" service on both Exchange 2013 and Exchange 2019.

Steps to focus on now:

1. From your Exchange 2019 server, open a command prompt and try to ping/nslookup your Exchange 2013 Autodiscover FQDN. (e.g., ping autodiscover.argofield.co.uk or whatever your internal autodiscover name is for the 2013 environment). Ensure it resolves to the correct 2013 CAS IP.
2. Verify the InternalURL for AutodiscoverVirtualDirectory and WebServicesVirtualDirectory on EX2013 using the Get- commands above. Ensure they are populated and use FQDNs that are resolvable internally.
3. Check the certificate on EX2013 for validity and correct SANs.

Once you resolve the Autodiscover connectivity, Test-MigrationServerAvailability should pass, and then you can revisit your migration jobs. The "version mismatch" error will likely disappear once the underlying communication can be established.

You are absolutely right to point that out! The screenshot shows that the EWS (Default Web Site) virtual directory on EX2013 does have both InternalURL and ExternalURL configured, and Enable MRS proxy endpoint is checked.

This means my previous assumption that the EWS URLs were missing was incorrect, based on the previous command output which only showed MRSProxyEnabled for EWS. My apologies for that oversight.

Given that:

1. MRS Proxy is enabled on both ARGEX2 (2019) and EX2013 (2013).
2. The EWS virtual directory on EX2013 has its InternalURL and ExternalURL correctly configured.
3. The Test-MigrationServerAvailability is still failing with "AutoDiscover failed with a configuration error".
4. And your Get-AutodiscoverVirtualDirectory on EX2013 still shows blank for InternalURL and ExternalURL.

The root cause is almost certainly the missing InternalURL (and potentially ExternalURL) on the Autodiscover (Default Web Site) virtual directory on your EX2013 server.

Why this is critical:

• Autodiscover is the first point of contact: When Exchange 2019 tries to perform a remote move, it uses Autodiscover to find the necessary endpoints on the source (Exchange 2013) server.
• Blank URLs mean Exchange can't publish its service: Even if the underlying Autodiscover service is running, if its virtual directory doesn't have InternalURL configured, it cannot properly tell other Exchange servers (like your 2019 server) or clients where to connect to the Autodiscover service itself.
• EWS works, but Autodiscover doesn't: You might have functioning mailboxes and OWA on Exchange 2013 because those services (OWA, ECP, EWS for clients) might be configured directly or are able to infer their URLs from other settings. However, the migration service specifically relies on Autodiscover for initial discovery of the entire environment, and if Autodiscover itself isn't configured with its own URL, it breaks the chain.

Action Plan:

You need to explicitly set the InternalURL for the Autodiscover (Default Web Site) on your EX2013 server.

1. Determine the correct FQDN for Autodiscover: Based on your EWS configuration, it looks like you're using mail.argofield.co.uk as your external/internal FQDN. It's common practice to use autodiscover.yourdomain.com for Autodiscover, but if mail.argofield.co.uk is used consistently for all services (and your certificate covers it), you can potentially use that for Autodiscover too, or autodiscover.argofield.co.uk if that's what your certificate covers and your internal DNS points it to EX2013.

   Let's assume the common autodiscover.argofield.co.uk pattern.

   • Verify DNS: Ensure autodiscover.argofield.co.uk (or mail.argofield.co.uk if you choose to use that) resolves to the internal IP address of your EX2013 server from your Exchange 2019 server.

2. Set the InternalURL for Autodiscover: Run this in Exchange Management Shell (EMS) on your Exchange 2013 server, or from your Exchange 2019 server with appropriate permissions:

   Set-AutodiscoverVirtualDirectory -Identity "EX2013\Autodiscover (Default Web Site)" -InternalUrl "https://autodiscover.argofield.co.uk/Autodiscover/Autodiscover.xml"
   

   VERY IMPORTANT: Replace autodiscover.argofield.co.uk with the FQDN that your internal clients and Exchange 2019 should use to reach Autodiscover on EX2013. This FQDN must be included in the SSL certificate on EX2013 and must resolve to the internal IP of EX2013 via your internal DNS.

   If you also have external clients using Autodiscover, you should set the ExternalURL as well:

   Set-AutodiscoverVirtualDirectory -Identity "EX2013\Autodiscover (Default Web Site)" -ExternalUrl "https://autodiscover.argofield.co.uk/Autodiscover/Autodiscover.xml"
   

3. Perform an iisreset on EX2013: This is crucial for the changes to take effect immediately.

   iisreset
   

4. Re-run Test-MigrationServerAvailability from Exchange 2019 EMS:

   Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress [email protected] -Credentials (Get-Credential)
   

Expected Result:

After these steps, the Test-MigrationServerAvailability command should ideally succeed. Once Autodiscover is properly configured and functional on EX2013, the Exchange 2019 MRS should be able to discover the necessary endpoints, including the MRS Proxy, and your "version mismatch" error during migration job creation should finally be resolved.

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.

• From your Exchange 2019 server, and from a client joined to your domain:

  nslookup autodiscover.argofield.co.uk
  

  (Or whatever FQDN you expect for Autodiscover on EX2013). Confirm that it resolves to the internal IP address of your Exchange 2013 CAS role. If it resolves to an external IP, or fails to resolve, that's a DNS problem.

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).

When you run a Set- cmdlet with the -Identity "EX2013...", you are instructing the command to run against the Exchange 2013 server, regardless of which management shell (2019 or 2013) you are in, assuming you've got remote PowerShell set up correctly.

Therefore, the error A parameter cannot be found that matches parameter name 'InternalUrl' is still occurring because the Set-AutodiscoverVirtualDirectory cmdlet, when targeting an Exchange 2013 server, does not support the InternalUrl parameter. This is consistent behaviour.

So, let's discard the Set-AutodiscoverVirtualDirectory -InternalUrl command entirely for Exchange 2013. It's simply not how you configure Autodiscover URLs for that version.

The core problem remains that Autodiscover is failing for the migration. We need to fix how Exchange 2013 advertises its Autodiscover service.

Revised & Corrected Focus for Exchange 2013 Autodiscover:

For Exchange 2013, the primary method for clients and other Exchange servers within the same Active Directory forest to discover the Autodiscover endpoint is through the Service Connection Point (SCP) in Active Directory.

The cmdlet to configure the SCP for Autodiscover on an Exchange 2013 Client Access Server (CAS) is Set-ClientAccessService.

Action Plan (Corrected):

1. Identify the current Autodiscover SCP for EX2013: From Exchange Management Shell (EMS) on either EX2013 or ARGEX2 (2019, but make sure the session is connected to EX2013 if running there, or it targets EX2013 by default if it's the only one of that version):

   Get-ClientAccessService -Identity EX2013 | Format-List AutoDiscoverServiceInternalUri
   

   This should show you what URL (if any) Exchange 2013 is advertising via its SCP. If this is blank or incorrect, that's your problem.

2. Set or Correct the Autodiscover SCP for EX2013: Based on your earlier EWS configuration, you're using mail.argofield.co.uk. While autodiscover.argofield.co.uk is the conventional Autodiscover FQDN, if mail.argofield.co.uk is used and included in your certificate, it can work. Let's assume for now you want to use autodiscover.argofield.co.uk as it's the standard.

   Before running this, ensure:

   • autodiscover.argofield.co.uk is an FQDN included in the SSL certificate on your EX2013 server.
   • autodiscover.argofield.co.uk resolves via your internal DNS to the internal IP address of your EX2013 server. This is crucial.

   Run the following in EMS, targeting EX2013:

   Set-ClientAccessService -Identity EX2013 -AutoDiscoverServiceInternalUri "https://autodiscover.argofield.co.uk/Autodiscover/Autodiscover.xml"
   

   If you prefer to use mail.argofield.co.uk for Autodiscover (which is less common but sometimes done if it's the only FQDN on the cert and you don't want to add more):

   Set-ClientAccessService -Identity EX2013 -AutoDiscoverServiceInternalUri "https://mail.argofield.co.uk/Autodiscover/Autodiscover.xml"
   

   Pick ONE FQDN (either autodiscover.argofield.co.uk or mail.argofield.co.uk) and ensure it's in the certificate and resolvable by internal DNS.

3. Confirm the change (optional, after a short delay for AD replication):

   Get-ClientAccessService -Identity EX2013 | Format-List AutoDiscoverServiceInternalUri
   

   It should now show the URL you just set.

4. Restart IIS on EX2013:

   iisreset
   

   This ensures the web services pick up the new configuration from Active Directory.

5. Re-run the Test-MigrationServerAvailability from ARGEX2 (Exchange 2019 EMS):

   Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress [email protected] -Credentials (Get-Credential)
   

This approach aligns with how Autodiscover URLs are configured and published in Exchange 2013 environments. The "Autodiscover failed with a configuration error" message is almost always linked to this SCP configuration or a DNS resolution issue.

Excellent! This is the smoking gun.

The error message: "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."

This definitively means that your SSL certificate on the Exchange 2013 server (EX2013) is the problem. Your Exchange 2019 server (ARGEX2) is reaching the EX2013 server on port 443 (HTTPS), but it's refusing the connection because it doesn't trust the certificate being presented by EX2013.

Here's the troubleshooting and solution plan for the SSL certificate:

1. Inspect the SSL Certificate on EX2013 Thoroughly:

• On EX2013, open IIS Manager.

• Expand Sites -> Default Web Site.

• In the right-hand "Actions" pane, click on Bindings....

• Select the https binding (Port 443) and click Edit....

• Note the "SSL certificate" that is selected. Click View... next to it.

  Now, carefully examine the certificate details:

  • General Tab:

    • Valid From / To: Is the certificate currently within its valid date range? (i.e., not expired, and not yet valid if it's a future-dated cert).
    • Issued To: This should typically be your primary domain or mail.argofield.co.uk.

  • Details Tab:

    • Scroll down to Subject Alternative Name (SAN) or DNS Name. This is critical.
      • Does autodiscover.argofield.co.uk appear in this list?
      • Does mail.argofield.co.uk appear?
      • Does the internal FQDN of your EX2013 server (e.g., ex2013.argofield.local) appear?
      • Does the NetBIOS name of your EX2013 server (e.g., EX2013) appear? (While less critical for HTTPS directly, it's good practice for internal certificates).

  • Certification Path Tab:

    • Is the entire chain complete? You should see your server certificate, followed by any intermediate CAs, leading up to a trusted Root CA at the top.
    • Are there any red crosses or warnings in the certification path? If so, it indicates a problem with the chain (e.g., a missing intermediate certificate on EX2013 or ARGEX2 doesn't trust the root).

2. Common Certificate Issues and Solutions:

Based on your error, here are the most common reasons and their fixes:

• A. Missing Subject Alternative Name (SAN):

  • Problem: The FQDN autodiscover.argofield.co.uk (or whatever FQDN you use in your AutoDiscoverServiceInternalUri for EX2013) is not included in the SAN list of the certificate on EX2013. When ARGEX2 connects to autodiscover.argofield.co.uk, the certificate it receives doesn't cover that name, so it throws a trust error.
  • Solution: You need to get a new SSL certificate for your EX2013 server that includes all necessary FQDNs in its SAN list. At a minimum, this should include:
    • mail.argofield.co.uk (if you're using this for OWA/ECP/EWS)
    • autodiscover.argofield.co.uk
    • ex2013.argofield.local (the internal FQDN of your Exchange 2013 server)
    • EX2013 (the NetBIOS name, optional but good for internal consistency)
  • Once you have the new certificate, import it onto EX2013, assign it to the IIS services (and SMTP, POP, IMAP if used), and bind it to the HTTPS binding in IIS.

• B. Expired Certificate:

  • Problem: The certificate on EX2013 has passed its "Valid To" date.
  • Solution: Renew or replace the certificate on EX2013.

• C. Incomplete/Untrusted Certificate Chain:

  • Problem: The intermediate Certificate Authority (CA) certificates are not installed on EX2013, or the Root CA is not trusted by ARGEX2 (unlikely for well-known public CAs, but possible for internal CAs or if a chain is broken).
  • Solution:
    1. Ensure all intermediate certificates are properly installed in the Intermediate Certification Authorities store on EX2013. Your CA provider usually gives you these.
    2. Verify the full chain. If ARGEX2 is not trusting the root, you might need to import the root CA certificate into ARGEX2's Trusted Root Certification Authorities store (if it's a private CA).
    3. The Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) can also help diagnose chain issues from an external perspective.

• D. Using a Self-Signed Certificate (Not Recommended for Production):

  • Problem: If you're using a self-signed certificate on EX2013, ARGEX2 won't inherently trust it.
  • Solution: Export the self-signed certificate from EX2013 (including the private key if necessary for full chain) and import it into the Trusted Root Certification Authorities store on ARGEX2. This is a workaround, not a best practice. A proper commercial or internal CA-issued certificate is always preferred.

After making any certificate changes on EX2013:

1. Restart IIS: iisreset on EX2013.
2. Restart Mailbox Replication Service: Restart Microsoft Exchange Mailbox Replication service on both EX2013 and ARGEX2.
3. Re-run the Test-MigrationServerAvailability from ARGEX2:

   Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress [email protected] -Credentials (Get-Credential)
   

This SSL/TLS secure channel error is highly specific to certificate trust. Resolving the certificate issue on EX2013 should clear this block.