Quest Migration Manager (QMM) for MS Exchange - CAS FQDN Issue and Resolution

Applies to: 

• Exchange 2007 To Exchange 2019
• Quest Migration Manager for Exchange 8.14 and 8.15

With QMM for Exchange, we can migrate Exchange 2003 to 2019 mailboxes from one AD forest to another (NativeMove) OR a tool can provision empty mailboxes at the target and then migrate mailbox data from a source mailbox to a corresponding target mailbox.

This article is not meant to explore how to set up the quest migration tool for exchange migration. It focuses mainly on CAS FQDN specific errors we face when doing NativeMove Migrations or pre-provisioned mailbox synchronization jobs.

Environment:
Source and Target Active Directory - Windows Server 2012 R2
Source Exchange Org - Exchange 2010 SP3 (mail.extreme.net)
Target Exchange Org - Exchange 2010 SP3 (mail.contoso.com)
Quest Migration Manager for Active Directory and Exchange - version 8.15

Issue statement:
Exchange server-internal hostnames and FQDN are not part of the Exchange SAN certificate issued by a public CA (Eg:mail.contoso.com). The QMM tool base / initial configuration doesn’t understand Exchange CAS FQDN. It only understands and looks for Exchange server "internal" Hostnames or FQDN which is not present in an SSL certificate used to connect exchange web services. In that case, both a native move or mailbox synchronization job (Preprovisioned mailboxes) will keep failing. Additional configuration is required to let QMM understand CAS FQDN. These are extra configuration steps we need to take and also need to work on a SQL database level to resolve specific issues.

NativeMove is a migration mode where the source to target mailbox data is migrated in a temp mailbox in the target until you switch the mailbox. This behaviour is by design to avoid mailflow issues. You have the option for auto or manual mailbox switching during the NativeMove batch.
 
After switching is completed, target MEU is converted into a mailbox and the source mailbox is converted into MEU pointing to the target mailbox email address to maintain mailflow.

The snapshot below shows a NativeMove failure:








Further, If we check logs under the Agent Manager pane:

2020-07-22          13:30:40.4176     Px9A4   Tx1D      A1           C16         M10       Error System.Management.Automation.RemoteException: The call to 

'https://exch2k10.extreme.net/EWS/mrsproxy.svc' failed. Error details: Could not establish trust relationship for the SSL/TLS secure channel with 

authority 'exch2k10.extreme.net'. --> The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. --> The 

remote certificate is invalid according to the validation procedure.

2020-07-22          13:30:40.4176     Px9A4   Tx1D      A1           C16         M10       Info        Native Move Job has been finished(State - 'Failed').

 

Further log checking shows:

2020-07-22          13:29:59.1297     Px9A4   Tx1D      A1           C16         M10       Trace     Execute PowerShell: New-MoveRequest -Identity d0488d2a-d19b-4bcd-ba74-

2ac27736a75b -TargetDatabase e27e6aff-1c4c-444f-9197-8197ceaa6108 -RemoteGlobalCatalog DC1.Extreme.net -RemoteCredential [EXTREME\Administrator] -

TargetDeliveryDomain contoso.com -BatchName QMMEX(2BB01037-E212-4872-8363-D15DB47FF6A3), TargetDB(e27e6aff-1c4c-444f-9197-8197ceaa6108) -BadItemLimit 4 -

SuspendWhenReadyToComplete -Remote:$true -RemoteHostName Exch2K10.Extreme.net

The installed Exchange SAN Certificate doesn't have an " Exch2k10.extreme.net" entry since its internal hostname of the exchange server. As a result, TLS channel cannot be established.

To resolve the above issue:
Exch2k10.extreme.net is the source CAS internal server hostname / FQDN
We need to tell QMM mailbox collection to use CAS FQDN instead of the internal server FQDN at the source. Our CAS FQDN at the source is mail.extreme.net
To modify the collection properties, we need to use the Quest PowerShell Module on QMM server:
 
Open Quest PowerShell and run the following commands:

Add-MMExExchangeRemoteHost –OrganizationName <Source Exchange organization name> -FQDN <CAS FQDN> -Version <Exchange version)
In our Case:
Add-MMExExchangeRemoteHost –OrganizationName labexchange -FQDN mail.extreme.net -Version Ex2010SP3

The above cmdlet actually registers CAS FQDN in the QMM SQL database.

Now modify the collection properties to use the above CAS FQDN
Execute Get-MMExCollection
SourceRemoteHostName and TargetRemoteHostNamevalues are empty. These are nothing but CAS server entries at both source and target.
Execute the following cmdlet:

Set-MMExCollection –Name NMCollection1 –Type NativeMove –SourceRemoteHostName mail.extreme.net

Now restart NativeMove Agent for collection

Now retry move operation
Still, it has failed.
Upon checking the Agent Manager logs for collection, the error message was:

Further, if you try to modify / add collection members, you will get the following error.
In fact, you cannot add a new synchronization job, you will still get the same error as shown below

The issue occurs because the CAS FQDN we added has a missing DN value of CAS server in the SQL database. 

We need to install the SQL management studio on the QMM server, load the Quest database and add the CAS server DN value.


1)   From SQL management studio, Connect to QMM SQL instance, it will load the QMM SQL database (MMExProject)
2)   Expand Tables.
3)   Locate the corresponding entry for the CAS Array or Load Balancer in the dbo_EXCH_SERVER table
4)   In the above table locate CAS FQDN entry mail_extreme_net. Its DN value is missing (NULL)
5)   Right-click and edit the table, Copy the DN value for a CAS server in the source Exchange Organization and paste it in the DN field of that CAS FQDN (Array / load balancer). From Adsiedit configuration container we can grab CAS server DN


6)   Save the change and retry the move operation

Now we can see that operation is successful and QMM completed initial sync and is ready to switch mailbox.

You have the option for an auto or manual mailbox switch during the NativeMove batch. I have selected the "manual switch" option

At the same time, checking from EMC, "Move Request" completed initial synchronization successfully and ready to switch

Click Switch

Switch process completed successfully

Mailbox synchronization job FAILURE: 
Mailbox synchronization is the process where QMM provisions empty mailboxes at target exchange organization with target address points to source mailbox to avoid mailflow issues
Once the mailbox initial sync is completed, it awaits for mailbox switch.
Once you switch the mailbox, it does sync incremental data since the last sync and clears the targetaddress attribute from the target mailbox and stamps the target address attribute on the source mailbox pointing to the target mailbox

Synchronization job failed as shown below
 
Further looking in collection Agent manager logs:
Quest tool failed to fetch source organization autodiscover end point (@extreme.net) and hence mailbox sync job failed. To resolve this issue, we need to modify QMM organization settings with source exchange CAS FQDN autodiscover end points with Quest cmdlets

From Quest EMS run Get-MMExOrganizationProperties
We can see that AutodiscoverUrl has not set for source and target exchange organizations in QMM database, we can set it with below command

Set-MMExOrganizationProperties –ForestName extreme.net –AutodiscoverUrl https://mail.extreme.net/autodiscover/autodiscover.svc

Now we can try the synchronization job again:
Mailbox synced successfully

Now switch the mailbox

Mailbox switch also completed successfully

Reference:
https://support.quest.com/migration-manager-for-exchange/kb/213504/configuring-project-exchange-organization-autodiscover-settings
https://support.quest.com/technical-documents/migration-manager-for-exchange/8.15/user-guide/21#TOPIC-1171069

If you like this article, please like/endorse the article by clicking the Thumbs-up button below

Thank You
Mahesh