Archive

Archive for the ‘Quest Migration Manager’ Category

QMM Transmission Agent (NTA) and Robocopy

November 25, 2013 2 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 Robocopyhttp://technet.microsoft.com/en-us/library/cc733145.aspx

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. 

 

clip_image002

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:

 

clip_image002[5]

 

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

 

MAPI error.

Error code: 0x8004011d

Description: MAPI_E_FAILONEPROVIDER

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: 0×0 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:

clip_image002

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.

clip_image002[4]

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

clip_image002[7]

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: 0×80040113

Description: MAPI_E_USER_CANCEL

Stack:

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

Resolution

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:

http://portal.sivarajan.com/2011/05/user-account-migration-and-merging-part.html

Scenario:

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:

http://portal.sivarajan.com/2010/12/user-migration-and-input-file-format.html

Here is an example of this input file:

image

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

image

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.

image

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.

image

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. 

sIDHistory

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.

image_thumb29

Verify sIDHistory and Identify the Source User Accounthttp://portal.sivarajan.com/2011/03/verify-sidhistory-and-identify-source.html

siDHistory Report – with Multi Value Supporthttp://portal.sivarajan.com/2011/04/sidhistory-report-with-multi-value.html

Generate sidHistory Report using DSQUERY commandhttp://portal.sivarajan.com/2011/01/generate-sidhistory-report-using.html

[image7.png]

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. 

image

Other Related Blogs & Articles:

Active Directory Migration Using ADMT – http://www.sivarajan.com/admt.html

Computer Migration – Things to Consider – http://www.sivarajan.com/cm.html

User Account Migration and Merging Using ADMT – http://www.sivarajan.com/

ADMT Include File – http://portal.sivarajan.com/2011/06/admt-include-file.html

User Migration and Input File Format – http://portal.sivarajan.com/2010/12/user-migration-and-input-file-format.html

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

image

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:

image

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

image

everything started working after the registry modification. 

Other Related Blogs/Articles:

Active Directory Migration Using ADMThttp://www.sivarajan.com/admt.html

Computer Migration – Things to Considerhttp://www.sivarajan.com/cm.html

User Account Migration and Merging Using ADMThttp://www.sivarajan.com/

>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:

image

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. 

image

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:

image

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.

image

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

>User Migration and Input File Format

>

I ran into an user migration issue with Quest Migration Manager (QMM) when merging accounts using an input file.  Instead of merging the user account, the QMM was creating a duplicate account in the target domain. 

The input file was in the following format:

SourceSamAccountName<TAB>TargetSamAccountName<TAB>TargetName

The issues was due to the file Encoding type.  We were using  UTF-8 encoding type.  Based on my testing, the Encoding type must be ANSI.  I believe it is because of the TAB character in UTF-8 encoding. 

So if you are planning to use an input file for the migration using Quest Migration Manager (QMM), make sure the Encoding type is ANSI.

image

>Outlook has encountered a Problem – Mailbox Migration

>

In my recent Active Directory and Exchange migration project using Quest Migration Manger (QMM), I encountered an issue during the mailbox migration.  I added a couple of mailboxes to the mailbox synchronization collection, after a few hours users started complaining that they can’t login to their mailboxes using Outlook.  There were getting the following error message:

Microsoft Office Outlook has encountered a problem and needs to close.  We are sorry for the inconvenience.  

clip_image002[4]

These mailboxes were not migrated.  They were only in the mailbox synchronization collection.  I opened these mailboxes using MFCMAPI tool (http://portal.sivarajan.com/2010/05/mailbox-and-outlook-troubleshooting.html) and  noticed that, these mailboxes have duplicate “Calendar” folder as displayed in the following screenshot:

Outlook_QMM

Since outlook was pointing to calendar (outlook today) users were not able to open the outlook.
On some other mailboxes I have seen duplicate “Sync Issues” folder.

Outlook_QMM_2

Cause:
According to Quest support professionals, they have seen duplicate calendar issue before but this is the first time they were seeing duplicate folder issue on different folders.  It may be due to other 3rd party applications such as backup and antivirus software logging into the mailbox while the data is being synchronized. You can see the details on the Quest Solution article SOL42312. 

I implemented the workaround as described in the SOL43372 article but that didn’t help me with the issue.
I was using 8.4 version of the QMM.  According to Quest, this issue will be fixed in 8.6 and they told me they can provide a hotfix for 8.5 version of the product. Unfortunately, they don’t have a fix for 8.4.  Since I had completed 70% of the migrations, I decided not to upgrade it to 8.5 or 8.6 version.

I also noticed that, this issue is happening only from one mailbox server and it is happening whenever I leave the mailboxes in the collection overnight.  It could be because of backup or antivirus scanning on the server in the night.

Workaround:
Since the issue is happening in the night, I decided to schedule the agent synchronization from 7 AM to 7 PM.  This configuration will avoid any third party software (backup, antivirus etc) logging into the mailbox while the data is being synchronized.  After that, I was able to successfully migrate mailboxes from this server. 

Other Related Articles and Blogs:

Active Directory Migration Using ADMThttp://www.sivarajan.com/admt.html

Computer Migration – Things to Considerhttp://www.sivarajan.com/cm.html

User Account Migration and Merging Using ADMThttp://www.sivarajan.com/

>Computer Migration – Things to Consider

>

Here are a few points which you can consider while doing computer migration.  These points are applicable to all migrations irrespective of the migration tool (ADMT, NetIQ, Quest etc). 

Here is a high level flow chart that describes the computer migration process:

San-Article

Admin$ Access (PreMig1 Script) – Ensure that you can access Admin$ or C$ on the workstation using your migration service account.  You can use the following script to test the Admin$ permission:

http://portal.sivarajan.com/2010/01/check-admin-share-using-poweshell.html

Ping (part of PreMig1 Script)– Make sure you can ping the workstation from the migration console/server.  But keep in mind that, if ICMP is disabled on your network, you won’t be able to ping the workstation.  Also, I have seen in many cases that Ping is resolving to an incorrect IP address,  which can be due to a bad WINS server or bad name resolution.

Read more at: http://www.sivarajan.com/cm.html

Other Related Blogs/Articles:

User Account Migration and Merging Using ADMThttp://www.sivarajan.com/

Active Directory Migration Using ADMThttp://www.sivarajan.com/admt.html

Computer Migration – Things to Considerhttp://www.sivarajan.com/cm.html

Follow

Get every new post delivered to your Inbox.