Archive

Archive for the ‘ADMT 3.2’ Category

ADMT – “ ERR3:7194 Could not open input file C:\Program Files\OnePointDomainAgent ” Issue

Issue

Active Directory Migration Tool (ADMT) Security Translation Process failed with the following error message in the ADMT log file:

ERR3:7194 Could not open input file C:\Program Files\OnePointDomainAgent\AccountsXXXXX.txt

Cause

This is most likely due to a corrupted ADMT agent (OnePointdomainAgent)  installation. 

Resolution

Uninstall and reinstall the ADMT agent (OnePointdomainAgent).  If you can’t uninstall from the console or control panel, you need to perform a manual removal process. 

You can use SC command to delete the agent if needed – SC Delete "OnePointdomainAgent"

Also, make sure the HKLM\Software\Microsoft\ADMT registry key  and c:\windows\ADMT Directory are  not present after the agent removal.

Categories: ADMT, ADMT 3.2, Microsoft, Migration

Computer Migration – Things to Consider (Updated)

September 6, 2011 2 comments

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:

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 athttp://www.sivarajan.com/cm.html

ADMT User Migration and Leaf Object Error Message

Issue:

ADMT displays the following error message when try to migrate a user account:

ERR2:7422 Failed to move source object ‘CN=XXXX’. hr=0x8007208c The operation cannot be performed because child objects exist. This operation can only be performed on a leaf object.

Cause/Resolution:

Some application may add configuration details to a user object.  Exchange ActiveSync is an example. If you have ActiveSync, make sure the ExchangeActiveSync child object has the proper value.  Or if the application is not using this configuration, you can remove the attribute value.  You can use ADSI Edit to verify this value (ADSIEdit –> Default Naming Context –> Properties of the User). 

If the issue is only happening on a few user accounts, you can dump the user account properties using DSQUERY command and compare them with a “good” user account value. 

 

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 Filehttp://portal.sivarajan.com/2011/06/admt-include-file.html

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

>User Account Migration and Merging – Part I (ADMT)

>

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 Active Directory Migration Tool (ADMT).  In Part II of this document I will explain the account migration and merging procedure using Quest Migration Manager (QMM). 

Scenario:

I have a 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 (include file) for the migration.  This file contains a mapping between source and target user account.  I am using a TXT file. You can use CSV or any other format.  Here is an example of my include file:

image

Migration Procedure:

1.  Open Active Directory Migration Tool console. 

2.  Right click on the Active Directory Migration Tool node and select User Account Migration Wizard. 

image

3.  On the Welcome window, select the correct source and target domains and domain controllers.  Click Next

image

4.  Select Read object from an include file option on the User Selection Option window.  Click Next

image

5.  In the Input File Selection window, click Browse and select the previously created include file.  Click Next

image

6.  On the Organization Unit Selection window, select the correct destination OU.  Click Next

image

6.  Select appropriate option on the Password Options window.  Click Next

image

7.  Select appropriate option on the Password Options window. Make sure to select Migrate user SIDs to target domain option.  Click Next.

image

8.  On the User Account window, enter the proper credentials.  Click Next

image

9.  Select appropriate options on the User Options window.  Click Next. 

image

10. Select appropriate options on the Object Properties Exclusion window. Click Next.

image

11.  Select the following options on the Conflict Management window.  Click Next

    • Migrate and merge conflicting objects
    • Uncheck Before merging remove user rights for existing target account – I have some pre-assigned groups and don’t want to remove those. 
    • select Move merged objects to the specified target Organizational Unit – I am moving user objects from a pre-created OU to Migrated OU after the migration. 

image

12.  Click Finish to complete the user migration process. 

image

13.  You will see the migration status on the Migration Process window. 

image

Your target account should be merged and have the same SID in the sIDHistory attribute. 

Sid and sIDHisotry Info:

When a User object migrated from one domain to another, a new SID must be generated for the user account and stored in the ObjectSID property. Before the new value is written to the property, the previous value (ObjectSID from source domain) is copied to another property of a User object, sIDHistory in the Target domain. So you can use the sIDHistory value to search the Source domain using the ObjectSID attributes to identify the corresponding user in the Source domain. In other words, the sIDHistory value will be equal to the source ObjectSID.  You can SID and sIDHistory using the following procedure:

http://portal.sivarajan.com/2011/03/verify-sidhistory-and-identify-source.html

image

Other Related Articles:

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

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

>ADMT SID Mapping File Generation Using DSQUERY Command

>

As you know SID Mapping file can be used perform Security Translation using Active Directory Migration Tool (ADMT).  You can create a  SID Mapping file from the ADMT database as described in the http://support.microsoft.com/default.aspx?scid=kb;EN-US;835991 article.   

But my plan is to use my favorite DSQQUERY command to create this file.  When you migrate an object from one domain to another, a new SID will be generated for the account and stored in the ObjectSID property. Before the new value is written to the property, the previous value (ObjectSID from the source domain) is copied to another user attribute, sIDHistory in the Target domain. So you can use the sIDHistory value to search the Source domain using the ObjectSID attributes to identify the corresponding user in the Source domain. In other words, the sIDHistory value in the target domain should be equal to the ObjectSID value in the source domain.  You can read more information on my following blogs:

http://portal.sivarajan.com/2010/12/powershell-script-search-active.html

http://portal.sivarajan.com/2011/01/generate-sidhistory-report-using.html

The ADMT Mapping file should contain source and target account information.  It can be sAMAccountName or objectSID.  Since sIDHistory and ObjectSID are available in the migrated target objects, my plan is to get these information using the following DSQUERY command:

dsquery * -filter "(&(objectCategory=Person)(objectClass=User)(sIDHistory=*))" -attr sIDHistory ObjectSID

You can redirect the output to a txt or CSV file.  ADMT uses a comma separated value file.  So update the output file in the correct format.  You can use  sAMAccountName instead of ObjetSID.  If you are using sAMAccountName make sure to use it in domain\sAMAccountName format.  The SID Mapping file should look like this:

image

OR

image

As I mentioned, you can get the sIDHistory and ObejctSID information from the target domain.  But if you want to use the source sAMAccountName you need to run the query in the source domain. 

Other Related 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/

 

Technorati Tags: ,

>ADMT–Could Not Verify Audting and TcpipClinetSupport on Domains

>

Issue:

ADMT displays the following error message when try to migrate a user account with SID History: 

Could not verify auditing and TcpipClinetSupport on domains.  Will not be able to migrate Sid’s.  Access is denied. 

image

Resolution:

If Auditing is enabled and TcpipClinetSupport Registry key is valid, verify the ADMT service account permission.  Make sure the logged in account has proper permission in source and target domains. I have explained these permission details in my following blog:

http://portal.sivarajan.com/2010/04/admt-service-account-permission-and.html

1. Create an account in the Target Domain
2. Add this account to the Domain Admins group in the Target Domain
3. In Source Domain, add this account (target account) to the built-in administrator group (not Domain Admin)

Other Related 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/

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

>Verify sIDHistory and Identify the Source User Account

>

Here is a simple procedure which you can use to verify the sIDHistory and identify the corresponding source object.  

Step #1 – Get the sIDHistory of the migrated Object

You can use QSQuery command to generate the sIDHistory.  Here is an example. On the target domain, run the following command to get the sIDHistory value: 

dsquery * -Filter "(samaccountname=santhosh)" -Attr  sIDHistory

Step #2 – Compare this sIDHistory value against the source account. 

When a User object migrated from one domain to another, a new SID must be generated for the user account and stored in the ObjectSID property.  Before the new value is written to the property, the previous value (ObjectSID from source domain) is copied to another property of a User object, sIDHistory in the Target domain. So you can use the sIDHistory value to search the Source domain using the ObjectSID attributes to identify the corresponding user in the Source domain.  In other words, the sIDHistory value will be  equal to the source ObjectSID. 

So in the source Domain, you can perform a custom LDAP search using sIDHistroy  to identify the corresponding source object.  Here is an example:

[image[3].png]

The output of this LDAP query will be the corresponding object in the source domain. 

image_thumb29

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

>Active Directory Migration Tool (ADMT) and Supported Migration Objects

>

I started seeing many questions about ADMT version and supported migration objects. The latest version is 3.2. But the previous versions of this product are still available for download. So review your requirements from the following table and use the correct version of ADMT.

Active Directory Migration Tool (ADMT) Version 3.0

Downloadhttp://www.microsoft.com/downloads/en/details.aspx?familyid=6F86937B-533A-466D-A8E8-AFF85AD3D212&displaylang=en

Supported Operating Systems: Windows Server 2003.

Target domain: Windows 2000 Server or Windows Server 2003

Source domain: Windows 2000 Server, Windows Server 2003, or Windows NT Server 4.0

Supported computer migration objects – Windows 2000 Professional, Windows XP, Windows NT 4 with SP4 or higher, Windows 2000 Server, and Windows Server 2003.

Active Directory Migration Tool (ADMT) Version 3.1

Download - http://www.microsoft.com/downloads/en/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059&displaylang=en

Supported Operating Systems : Windows Server 2008

Target domain: Windows 2000 Server or Windows Server 2003 or Windows Server 2008 or Windows Server 2008 R2

Source domain: Windows 2000 Server, Windows Server 2003, or Windows Server 2008

Supported computer migration objects – Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, and Windows Server 2008

Windows 2008 R2 Domain – There are some known issues with using ADMT 3.1 in a Windows 2008 R2 environment.  You can read more info on http://support.microsoft.com/kb/976659

Active Directory Migration Tool (ADMT) Version 3.2

Download - http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=20C0DB45-DB16-4D10-99F2-539B7277CCDB

Supported Operating Systems: Windows Server 2008 R2

Target domain: Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2

Source domain: Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2

Supported computer migration objects – Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

Other Related 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/

Follow

Get every new post delivered to your Inbox.