This article covers the Quest Migration Manager (QMM) for MS Exchange configuration issue with regards to CAS FQDN. Quest support docs are available to resolve some issues but don't cover the base issue. The Article should be useful to engineers working on Quest MS-Exchange migration projects.
- 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.
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
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 Job failure:
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 "
" entry since its internal hostname of the exchange server. As a result, TLS channel cannot be established.
To resolve the above issue:
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
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
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.
From SQL management studio, Connect to QMM SQL instance, it will load the QMM SQL database (MMExProject)
Locate the corresponding entry for the CAS Array or Load Balancer in the
In the above table locate CAS FQDN entry
Its DN value is missing (NULL)
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
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
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
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
If you like this article, please like/endorse the article by clicking the Thumbs-up button below