Archive for the ‘Quest Migration Manager’ Category

QMM Transmission Agent (NTA) and Robocopy

November 25, 2013 3 comments

Quest Migration Manager (QMM) has its own logic to transfer (migrate) from data a source mailbox to a target mailbox  MSA –> NTA –> MTA.  Latest version of QMM for Exchange supports multiple agents on Quest Agent Host.  You  can have up to 10 MSAs and 10 MTAs but Transmission Agent (NTA) is still limited to 1 per Agent Host.  This is still a huge limitation when transferring  large amount of data.  Quest’s NTA still performs a single threaded, sequential operation.  Even if you have enough “available” bandwidth, these types of applications cannot be able to use all available bandwidth. 

In QMM for Exchange, NTA is responsible for referring the exacted PRV files from Source to Target agent servers.  If NTA is the bottleneck, you can use any other mechanism to copy PRV  files from Transmission OUT folder to Transmission IN Folder.  Keep in mind that you need to copy all extracted files at the same time (or in the correct order).   I have decided replace NTA with a Robocopy option for the initial data copy.  With Robocopy, you can specify the thread up to 128. 

Using the following method, I have reduced the file copy time from weeks to hours!

  1. Stop Transmission Agent (NTA)
  2. Stop Mail Target Agent (MTA)
  3. Start Mail Source Agent (MSA) and generate all PRV files from source mailboxes.
  4. After the initial creation of all PRV files (you can verify this by reviewing the MSA log file), Stop MSA
  5. Perform a Robocopy operation to copy all files from OUT folder to IN folder.  Here is an example:

Robocopy “\\SourceAgentHost01\C$\Windows\SysWOW64\Aelita Exchange Migration Wizard\Mail Transmission Agent\OUT\TargetAgetnHost01\2” “\\TargetAgentnHost01\c$\Windows\SysWOW64\Aelita Exchange Migration Wizard\Mail Transmission Agent\IN\SourceAgentHost01\2” /MT:128

In the above example, MSA and NTA was running on SourceAgentHost01 and MTA was on TargetAgentnHost01

  1. Start MTA agent and complete mail data import process. 
  2. After the initial data copy, you can start the MSA, NTA and MTA agents. The delta change or update will go thought the normal Quest process (MSA –> NTA –> MTA). 

Microsoft Robocopy


Quest CPUU / EMWProf and Windows Credential Manager

I ran into an issue on my current project with Quest Client Profile Update Utility (CPUU).  The CPUU / EMWProf was prompting for user or password or it was failing with MAPI_E_FAILONEPROVIDER error.  The error message or result wasn’t consistent. 



The CPUU log shows the utility wasn’t getting the correct source and target user name and password from the INI file.  The utility was trying to open target mailbox using source admin account etc.  I even have specified the target domain domain in the Domaincfg section. 

I was using the latest version of the CPUU utility (5.2).   Clearing the credentials on local machine did not help in my situation.  My solution was to disable the Windows Credential Manger using a GPO (Network access:  Do not allow storage of passwords and credentials – Enabled).  You can GPO details in the following screenshot:




The following is the error message details from CPUU log file:


MAPI error.

Error code: 0x8004011d


Extended error description:

   Component:         Microsoft Exchange Information Store

   Error description: Microsoft Exchange is not available.  Either there are network problems or the Exchange server is down for maintenance.

   Context:           1318

   Low level:         2147746069

MAPI error.

Error code: 0x8004010f

Description: MAPI_E_NOT_FOUND

Mailbox Migration – MAPI_E_FAILONEPROVIDER / Invalid Data

Mailbox migrations can be challenging and interesting Smile  I ran into an issue this morning with one mailbox using Quest Migration Manager.  Quest Mail Target Agent (MTA) was failing with our “favorite” MAPI_E_FAILONEPROVIDER error. 

1/29/2013 5:16:19 PM    CSession::Logon               Error      -2147221219       You do not have permission to log on. – MAPI_E_FAILONEPROVIDER (Microsoft Exchange Server Information Store)  Low level error: 0x0 File: ‘aeWrapHelpers.h’ Line: ‘279’

1/29/2013 5:16:19 PM    MailKernel::Connect      Informational    2079       Synchronization status: Object XXXXXXXXXXXXXXXXXXXXXX synchronization was not started due to connection errors.

When I open the properties of this mailbox in Exchange 2010 side, I was getting the following error message:


I found some detailed error message by going through the properties of this mailbox.   In my case it was due the value of Delivery Restriction property in Exchange 2010.


The 30 GB Sending message size!!! (don’t ask me why Winking smile) was configured in the source mailbox.  


QMM tries to populate this value during the Quest directory sync.  It was failing due to the size limitation in the target Exchange 2010 environment. 

Quest Migration Manager EMWProf – MAPI_E_USER_CANCEL 0X80040113

This error message was little misleading! 

[Error] Cannot open default message store.

MAPI error.

Error code: 0x80040113



Function Address: 004e7801

Function Address: 00456a5e

Function Address: 0046bcb3

Function Address: 0046a6dc

Function Address: 0042b42c

Function Address: 0042b7e6

Function Address: 0047981b

Function Address: 005e5fdf

Function Address: 7c817077


According to all Quest documents, this error is due name resolution issues.  In my case, it was “technically” true.  However, the actual issues wasn’t related to a “pure” NetBIOS or FQND name resolution.  I had the same computer object (same name) in the target domain.  So the workstation or EMWProf wasn’t getting the correct source Exchange information.  It was resolving to an object in the target domain instead of the source Exchange server.  I deleted the duplicate computer name in target domain and everything started working!

>User Account Migration and Merging – Part II (Quest Migration Manager)


Part I – User Account Migration and Merging Using ADMT

Part II – User Account Migration and Merging Using QMM

Pre-creating user account in the target domain is a common scenario these days due to single-sign-on solution, HR management procedure etc. This will make the user migrate procedure more challenging. During the migration you need to make sure these accounts are properly “merged” with correct SID information.

In this example, I will explain a procedure to migrate and merge user accounts using Quest Migration Manager (QMM). You can read the  Part I (User Account Migration and Merging – Part I (ADMT)) of this document in the following link:


I have pre-created user accounts in the target domain. Their logon name (samAccoutnName) is different in the target domain. My goal to migrate an account from the source domain, merge it with the corresponding account in the target domain and maintain the source SID in the migrated object.

Migration Plan:

My plan is to use an input file which contains a mapping between source and target user accounts.  The file encoding type must be ANSI.  You can read about this requirement in my following blog:

Here is an example of this input file:


In the above example, my plan is to migrate User1 and merge it with a pre-created user account (12345) in the target domain.  The column headers are Source sAMAccountName, Target sAMAccountName  and Target Name

Migration Procedure:

1. Open Quest Migration Manager console.  Right click on the Migration node and select New Session option.

Note: Make sure the Account Name matching attributes is selected in the domain pair configuration (Domain Pair –> Properties –> Object Matching).


2. Click Next on the Welcome window. 

3. Specify the name in the Name box for this migration session. Click Next.

4. On the Select Object in Source Domain window, click on Import button and select the user input file and click Open.


5. Click Next on Select Objects in Source Domain window.

6. On the Select Target Container window:

a. Click Browse to select the appropriate target OU

b. Select Migrate objects without OUs as a flat list option and

c. Select Merge and leave the account where it was before the migration option.

d. Click Next.


7. On the Set Security Settings window, select appropriate options. Click Next.

8. On the Specify Object Processing Options window, select appropriate options. Click Next.

9. Click Next on the Specify Object Processing Options window.

10. On the Select Migration Agent window, select the correct DSA as the migration agent server. Click Next.

11. Click Next on the Migrate Active Directory Objects window.

12. Click Yes on the Migration Wizard Popup window. Migration process status will display on the status windows

14. Select View log button on the Completing the Migration Wizard windows to verify the log file.

15. Click Finish to complete the user migration process. 


You can verify the sIDHistory value using ADSI Editor or one of the following scripts.  The sIDHistory value should be equal to the ObjectSID in the source domain.


Verify sIDHistory and Identify the Source User Account

siDHistory Report – with Multi Value Support

Generate sidHistory Report using DSQUERY command


QMM Directory Synchronization

If you are planning to use Quest directory synchronization, you can enable the directory synchronization after the user migration. QMM will update the user information (user properties, group membership etc) based the QMM matching attribute value (adminDescription & adminDisplayName or ExtensionAttribute 14 and 15).  These values get populated during the user migration. 


Other Related Blogs & Articles:

Active Directory Migration Using ADMT –

Computer Migration – Things to Consider –

User Account Migration and Merging Using ADMT –

ADMT Include File –

User Migration and Input File Format –

>Computer Migration – Access is Denied


Computer Migration – Access is denied.  I was getting an Access is denied error message in the Quest Resource Updating Manager (RUM) console when I was performing computer migration (move) – domain membership change operation. 


In general, “Access is denied” error message during computer “move” means the remote registry service is not running on these computers.  But in this case, the service was running but when I opened the registry remotely, I was getting the following error message:


It turned out to be a permission issue on the registry key.  This computer (master image) was upgraded from Windows 2000.  By default, Windows 2000 does not have a built-in user account named Local Service.  Instead, the Remote Registry Service is logged on as Local System. In Windows XP, the Remote Registry Service is logged on as Local Service. 

I assigned Read permission to LOCAL SERVICE on the following registry key:



everything started working after the registry modification. 

Other Related Blogs/Articles:

Active Directory Migration Using ADMT

Computer Migration – Things to Consider

User Account Migration and Merging Using ADMT

>Merging Multiple User Accounts using Quest Migration Manager (QMM)


Here is a method which you can use to merge multiple user and group accounts into a single account in the target domain.   The main goal is to get the objectSID from all source accounts and add them to a single account (sidHistory) in the target domain. 

Here are the high level steps:

Step1 – Create an input file with source and target account samAccountName in the following format:


In this example, I am merging suser1 source account with tuser account in the target domain. 

Step 2 – Perform user migration using QMM. 

Step 3 – Clear the QMM matching attributes. As you can see on the following screenshot, QMM has populated the Object GUID and Domain Pair ID values in the matching attributes.  I am using adminDescription and adminDisplayName as the QMM matching attributes.  These values need to be cleared before you can perform the second user migration. 


If you don’t clear the QMM matching attribute value, you will see the following error message in the QMM log file and the migration will fail:


Step4 – Update the input file with 2nd source account and repeat Step 2 and 3. 

In this example I merged 3 accounts into a single account.  As you can see the in the following screenshot, the target account has  3 values in the sidHistory attribute.


If QMM directory synchronization is enabled, the user properties, group membership etc will get updated based on the recent AdminDisplayname and AdminDescription values.