Windows Server










Pre-requisites for ADMT:


1.      DNS Name resolution should work both ways for both the Domains from one another.

2.      After creating Trust, ADMT should work


By Default: SId Filtering is enabled.

To Disable:→ netdom Quartime command


Check PING

{ IP


{ FqDN Domain



Domain Migration Cookbook



Chapter 1: Security




ADMT v3.1

ADMT v 3.1




ADMT 3.1 is now available for download. Like all previous versions of ADMT, it’s free to install and use.

The big change in this version of the Active Directory Migration Tool is support for migration using Windows Server 2008 domain controllers.

Also included with this are new versions of the Password Export Service (for 32-bit and 64-bit DCs), and an updated migration guide, which we highly recommend for anyone planning to do a migration.

As always, if you’re planning on doing a migration project, we recommend testing carefully before doing anything with production computers and users.




Action Plan to be followed on Staging Environments:

Always use the PDC on both the domain, the Source and the Destination for ADMT.


On both the DC (do the following):


First of all, set the DNS Name resolution to work properly from source domain to destination domain and vice-versa.


For DNS Name Resolution to work:

+ make them point to themselves as primary DNS server in ncpa.cpl

+ net stop dns & net stop netlogon & net start dns & net start netlogon

+ ipconfig /flushdns

+ ipconfig /registerdns

+ created a secondary zone for the two domain on each other’s DNS servers successfully.


Now test ping the FqDN Domain name from source to destination and vice-versa; If successful then proceed:


Now create a two-way trust between the two Domains.


In my case:

+ tried to create a two way trust using GUI:

Error: "The operation cannot be performed on the specified domain."


+ ran dcdiag /v and netdiag >> came clean on both Domain controllers

+ checked services:

> stopped windows firewall


/ still getting the same error while creating trust


Checked that the guids and FqDN’s were pingable both ways.


+ found SOX080815700040


>> Both the dc's had same sid >> confirmed using psgetsid.exe

>> demoted one domain


+ ran newSID

>> re-promoted it back

>> Trust was created successfully


Now, create the following registry key on the PDC:


The RestrictAnonymous value on the target domain controller should be set to 0 during the migration.

The following registry key value is set on the target domain controllers:

>> HKLM > SYSTEM > Current Control Set > Control > LSA > Restrict Anonymous = 0


LmCompatibilityLevel should be similar on both the Domain Controllers:

>> LM Compatibility: following Kb Article ID: 889030


>> created the user "migadmin" in source domain >> This will be the user account that will be used to migrate using ADMT. The tool will use it to read Active Directory objects.


\\ added migadmin to Domain Admins in the source domain


\\ added the "source-domain\migadmin" to the Built-in Administrators group in the Target Domain




Will proceed with ADMT now: in the following steps

>> On the Target Domain PDC log in using the "source domain \ migadmin"


Install ADMT V3 on the PDC Role holder DCs in both the domains

After this try and Migrate the User by running the ADMT tool on the Destination Domain.


Simple User Migration Checklist


- Name Resolution :: done

- Trust :: done

- Ports and Permissions :: done

- LmCompatibilityLevel should be similar - 889030 :: done

- Restrict anonymous set to 0 :: done



Password Migration

(KB Article ID : 832221 )


Destination PDC

- Enable Auditing "Account Management" enable both success and failure

Default Domain Controller Policy >> Computer Config > windows settings > security > local policies > Audit policy

- Create .pes File on Target Domain PDC - Admt Key "sourceNetBiosName" location(c:\) password.

ADMT KEY /opt:create /sd:Bhaskar /kf:c:\key\ /pwd:*

- Domain Functional Level should be 2000 native or above

- Everyone should be member of pre-windows 2000 compatible group

- Everyone should include Anonymous users (Let Everyone Permission apply to anonymous users) should be enabled.

- Enable Default domain controller Policy > Computer Configuration > Windows Settings > security > local policy > security options >>

Network Access: Let Everyone Permission apply to anonyous users


- Copy .pes file to source domain PDC.


Source PDC

- Enable Auditing "Account Management" success and failure

- Created Dword "TcpipClientSupport" under HKLM\system\CCS\Control\Lsa and set it to 1

- Install Password Migration Dll

// found in the ADMT installation folder


- Set DWORD "AllowPasswordExport" Key Under HKLM\System\CCS\Control\Lsa to 1

- Everyone should be member of pre-windows 2000 compatible group

- Everyone should include Anonymous users (Let Everyone Permission apply to anonymous users) should be enabled.

- Domain Functional Level should be 2000 native or above

- Enable Default domain controller Policy > Computer Configuration > Windows Settings > security > local policy > security options >>

Network Access: Let Everyone Permission apply to anonymous users


Computer Migration


-          All machines to be migrated should on CRT ALT DEL Screen

-          All admin shares should be present (Admin$,IPC$)

-          Migration account should be Member of “Local administrators” group.

-          Disable any antivirus and Firewall if there is one

-          Do not try to translate registry during computer migration.





What is domain migration?


The Domain migration is moving (Migrating) or copying (Upgrade) the computers and users from an existing domain (Source Domain) to an existing domain or a new domain (Target Domain).

Migration of domain moves the domain objects to a new or existing domain. It is consolidation of one or more domains into one. Upgrading of domain retains the domain structure, users and groups.

A source domain is the point of origin of migration where as a target domain is the end of origin of migration. We move or copy source domain’s Security Principle Name (SPN) to the Target domain we move or copy the SPN from an existing domain to a new or existing domain. We can also merge two or more domain into one to reduce the load of administration the domains, it is helpful in case of NT 4.0 as this kind of environment only support 40000 Object’s database.


We can either clone or consolidate the domain migration.


     Cloning is the process of making copies of security principals from one domain, and creating them in another domain without loosing the functionality.

     Consolidation is mergers one or more domain on to a new or existing domain.


We can either do Inter forest or Intra forest migration.

Difference between inert forest and intra forest is as below:-


Inter Forest

Intra forest


The user account is a copy operation, we consolidate the users as to avoid the chances of loosing the accessibility to the source domain

The user account is a cut operation, as users cannot have same GUID in a forest


The computer account is a cut operation

The computer account is a cut operation


The user groups is a copy process, to retain the membership until we do not complete other migration process and to retain the accessibility to source or parent domain

The user group is a copy process, to retain the membership until we do not complete other migration process and to retain the accessibility to source or parent domain





Objects that can be migrated or merged:-





     Trust relation



     SID and SID history



Requirement for Migration:-


     In case of inter forest migration the target domain must be in native mode

     In case of intra forest the source and the target domain must be in native mode

     The target domain must be a 2000 environment, the source domain can be Win NT 4.0

     Two way trusts is required between source and target domain if we wish to migrate the passwords also

     The user who is migrating must be the member of local administrator group in source domain and member of domain administrator in target domain


Tools used:-


We can either clone or consolidate a domain in to a new or existing domain. Microsoft provides us with ADMT v 2.0 and v 3.0, a tool which is based on GUI helps us migrate the domain. This tool has user, computer, trust, and group migration and merger wizard.


     ADMT v 2.0—This tools helps in migrating the Windows NT 4.0, 2000 and 2003 servers

     ADMT v 3.0---This tool helps in migrating the Windows 2000 and 2003 servers only.

We can do domain migration within the forest (Intra forest) or outside the forest (Inter forest)



Probing Questions to the customer:-


1.    What is the reason for migration?

       Is it a merger of the companies or the customer is upgrading his environment


1.    Are the domain controllers being upgraded and the domain mode has changed?

The DC might be upgrade from NT 4.0 or the domain’s native mode is changer to 2000 or 2003


1.    What kind of migration is it, inter forest or intra forest?

If its intra forest then it would be merger or two or more domains. And in case of inter forest the objects will be move on to new forest


1.    What all do we need to migrate, users, computers, trust etc?

Keep in mind for the password retention and group membership of the users


1.    Do we have a two way trust between the source and the target?

2.    Is customer the member of domain admin group on target domain and member of local administrator group on source domain?

3.    Does the customer wishes to retain the passwords for the users?

4.    Does the customer wishes to move the SID history?



ADMT extra’s



Please look at the below information step by step on how to migrate users and computers


ADMT requires the following permissions to run properly:

• Administrator rights in the source domain.

• Administrator rights on each computer that you migrate.


Before you migrate a Windows 2000-based domain to a Windows Server 2003-based domain, you must make some domain and security configurations. Computer migration and security translation do not require any special domain configuration. However, each computer you want to migrate must have the administrative shares, C$ and ADMIN$.

The account you use to run ADMT must have enough permission to complete the required tasks. The account must have permission to create computer accounts in the target domain and organizational unit, and must be a member of the local Administrators group on each computer to be migrated. User and group migration

You must configure the source domain to trust the target domain. Optionally, the target may be configured to trust the source domain. While this may ease configuration, it is not required to finish the ADMT migration.

Requirements for optional migration tasks You can complete the following tasks automatically by running the User Migration Wizard in Test mode and selecting the migrate sIDHistory option. The user account you use to run ADMT must be an Administrator in both the source and the target domains for the automatic configuration to succeed.

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.


1.     Create a new local group in the source domain that is named %source domain%$$$. There must be no members in this group.


2. Turn on auditing for the success and failure of Audit account management on both domains in the Default Domain Controllers policy.


3. Configure the source domain to allow RPC access to the SAM by configuring the following registry entry on the PDC Emulator in the source domain with a DWORD value of 1:


HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport You must restart the PDC Emulator after you make this change.


Note For Windows 2000 domains, the account you use to run ADMT must have domain administrator permissions in both the source and target domains. For Windows Server 2003 target domains, the 'Migrate sIDHistory' may be delegated. For more information, see Windows Server 2003 Help & Support.

You can turn on interforest password migration by installing a DLL that runs in the context of LSA. By running in this protected context, passwords are shielded from being viewed in cleartext, even by the operating system. The installation of the

DLL is protected by a secret key that is created by ADMT, and must be installed by an administrator.


To install the password migration DLL:


1.Log on as an administrator or equivalent to the computer on which ADMT is installed in the source domain.


2. At a command prompt, run the ADMT KEY /option: create /source domain:


"DOMAIN"/keyfile:"C:\passmig.pes"command to create the password exportkey file (.pes). In this example, source domain is the NetBIOS name of the source domain and path is the file path where the key will be created. The path must be local, but can point to removable media such as a floppy disk drive, ZIP drive, or writable CD media. If you type the optional password at the end of the command, ADMT protects the .pes file with the password. If you type the asterisk (*), ADMT prompts for a password, and the system will not echo it as it is typed.


3. Install the Password Migration DLL on the Password Export Server by running the Pwmig.exe tool. Pwmig.exe is located in the I386\ADMT folder on the Windows Server 2003 installation media, or the folder to which you downloaded ADMT from the Internet.


4. When you are prompted to do so, specify the path to the .pes file that you created in step 2. This must be a local file path.


5. After the installation completes, you must restart the server.


6. If you are ready to migrate passwords, modify the following registry key to have a DWORD value of 1. For maximum security, do not complete this step until you are ready to migrate.




Please look at the below articles on how to migrate users and computers by using










No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3193

Leave a comment


Author Bio          ★★★★★

Author Name:         ebhakt
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011