Migrating Users from Windows 2003 to Windows 2008 using ADMT 3.1

[patris1]

http://remoteitservices.com/content/migrating-users-windows-2003-windows-2008-using-admt-31-0

Hi guys,
I’m going to talk today about the ADMT 3.1 and the complete process of migrating users accounts
and passwords supported with snapshots.

Active Directory Migration tool “ADMT 3.1” is the latest version that can be run on Windows 2008.
This task will demonstrate with snap shots the process of setting up the ADMT, configuring user’s migrations, setting password export server on the source domain, migrating users’ passwordsand SID history.
First step: installing ADMT 3.1 on Windows 2008 Domain Controller



installing ADMT
ADMT installation file can be downloaded from http://www.microsoft.com/downloads/d...displaylang=en
During installation the installation Wizard will ask about the database to be used by ADMT, the wizard can use existing SQL 2005 instance or it can install a new instance of SQL 2005 express, in our case we choose to install a new SQL 2005 instance.

Then, the wizard will prompt us if we need to import data from any previous ADMT database, since this is a new installation we choose not o import any data.

Importing previous ADMT data
Then the installation Wizard completes successfully.


Second Step: Installing Password Export Server

In order to be able to export the user’s passwords, we needto install the password export server.
The password export server will need a password encryption file to secure password migration, to create this password encryption file we use the ADMT utility in the command line to generate the file as follows:
1-We navigate to the location of the installation of the ADMT, in our case it is C:\Windows\ADMT
2-We issue the following command C:\Windows\ADMT>admt key /opt:create /sd:”Source_Domain” /kf:c:\Domain.pes /PWD *
3-The utility will then ask you to provide the password and validate it.

After creating the encryption file we move it the source domain controller where we are going to install and use the password export server as in the following steps:
1-Start the installation wizard

2- Accept the license agreement


Accept License agreement
3- Choose the password encryption key file that we created in the previous steps 4- Insert the password that we used to
encrypt the password encryption file

Password Prompt
5- Start installing the Password Export Server

6- Choose the service account that the PES server will run under , this account should be administrator on the
destinationdomain, we chose the administrator in the source domain and made it a member of the administrators group in
the Windows 2008 domain


Up to this stage the installation is finished, the wizard will require the source server to be restarted, after restarting the

server, the PES server has to be started manually.

Third: running the ADMT Migration wizard

To start the migration wizard, we go to the ADMT console on the destination domain controller, “Windows 2008 DC” and
start the user’s migration Wizard.


Start ADMT Users Migration
Choose next to the welcome screen


Start Migration
Choose the source Domain and domain controller, and the destination domain and domain controller. In our case the
source domain is “radmins.com” and the source domain controller is “RDC01radmins.com”,the destination domain
is“nwtraders.com“
and the destination domain controller is “dc01.nwtraders.com”.

Then we choose to select the users from the domain directly and not from a file:



Selecting Users to Be migrated
After selecting the user accounts to be migrated, we choose to migrate the passwords of the users as well and choose the
password export server on that we installed on the source domain controller.


Password Migration

Then we choose the target OU to which we will migrate the users to:

Then we choose the state of the migrated users, we can select that the users will be enabled, disabled, or the same state of
the source domain, also we can select to migrate the source SID of the users, this will allow users to access the resources
that they used to access in the source domain.

Migrated users state and SID migration
When choosing to migrate the users SIDs, the wizard will prompt to enable auditing and creating a group necessary for
migration of users SIDs, by selecting “yes” the wizard will enable these settings on the source domain controller
automatically ad we can proceed.

Enabling Auditing
The wizard then will prompt for a user account with proper privilege to add SID history.

Administrative Account
The wizard then will prompt for options like migrating users roaming profiles, update user’s rights, migrating associated groups, and fix users group memberships.

Migration Options
Then the wizard gives us an option to exclude some users from migrations:


Users Exclusion
Then we can choose how to handle conflicts when they occur


Dealing with users conflict
And finally the migration wizard will start migrating users.

Start Migration Process

---

موضوعات مشابه:

• update LDAP windows server 2003 to windows srever 2008 fro replication
• How to extend a data volume in Windows Server 2000, 2003, 2008 and Windows XP
• Migrating DHCP from Windows 2000 Server/Windows Server 2003 to Windows Server 2008
• کرک Termianl Services برای Windows 2003 & Windows Server 2008

---

[patris1]

http://blogs.dirteam.com/blogs/jorge/archive/2008/07/15/migration-support-in-admtv3-1-for-windows-server-2008.aspx

Migration Support in ADMTv3.1 for Windows Server 2008

In this post I explain what you can do with ADMTv3 and what you cannot do. Additionally I also define common migration steps and provide links to other information sources. ADMTv3.1 has been released a few days ago and it now supports Windows Server 2008 based servers. If you need to use ADMT on W2K3 use ADMTv3 and look at this post.
Like ADMTv3 could only be installed on a W2K3 server, ADMTv3.1 can only be installed on a W2K8 server. Additionally the "Password Export Server" is available as a separate download for both 32 bit and 64 bit computers. Microsoft also updated the migration guide.

System Requirements

• Supported Operating Systems: Windows Server 2008
• ADMT can be installed on any computer capable of running the Windows Server 2008 operating system, unless they are Read-Only domain controllers or in a Server Core configuration.
• Target domain: The target domain must be running either Windows 2000 Server or Windows Server 2003 or Windows Server 2008
• Source domain: The source domain must be running Windows 2000 Server, Windows Server 2003, or Windows Server 2008
• The ADMT agent, installed by ADMT on computers in the source domains, can operate on computers running Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008

The following is available:

• ADMT v3.1 (only supports W2K8 servers, but supports all AD versions)
• Password Export Server version 3.1 (x86) (supports W2K, W2K3 and W2K8 servers)
• Password Export Server version 3.1 (x64) (supports W2K, W2K3 and W2K8 servers)
• Guide for Migrating and Restructuring Active Directory Domains Using ADMT v3.1

Cheers,
Jorge

[patris1]

http://www.biztechmagazine.com/article.asp?item_id=697

Managing Active Directory Migration

Undertaking an Active Directory migration is a big task, regardless of an organization’s size and structure. Here are four suggestions for a successful migration:
Carefully Consider a Multidomain Forest

There are few benefits or technical reasons for configuring a multidomain forest. In fact, the potential problems far outweigh any benefits. The biggest issue, though not the only concern, is the complexity that is added to Domain Name System in this type of forest structure.
Keep the Trust

The trust needed for migration from one forest to another must remain in place until the old forest is shut down, and the names of the old and new forest must be different for the trust to work.

It’s important to determine if users need access to resources in the old forest before migrating their accounts. If they do, the trust will need to be created to allow Security Identifiers (SIDS, a unique value of variable length used by Microsoft to identify a security principal or group) to transverse the trust. Ensuring unduplicated user IDs, computers or groups between forests will also save time and headaches.
Turn to Time-Savers

Create a Group Policy Object to turn off Windows Firewall during migrations, because leaving it on can lead to troubleshooting difficulties. Create the GPO in the Organizational Unit where the workstations reside in both forests. It can be removed once migrations are complete.
Consider investing in a third-party remote-control tool outside of Remote Desktop Protocol. RDP will sometimes fail during migrations because of the state of the machine, making it difficult to fix issues. We also utilized a freeware tool called PsExec, which proved invaluable to our success.
Be Aware of These Issues

If you migrate over slow wide-area network links, start the Active Directory Migration Tool pre-check several hours before the scheduled migration times for workstations. This will allow the ADMT agent to be pushed in advance and not delay migration efforts.

• Develop a migration schedule;
• Write scripts to run on the machines being migrated in advance of the scheduled migration to ensure the machine can be pinged;
• Ensure the ADMIN$ share is enabled and a common administrator user ID and password is present on each machine; and
• Clean up old user profiles and delete temp and history files from the machines being migrated.

After the machines have migrated, depending on network structures and speeds, you may experience problems with group policies and Kerberos. If so, check to ensure firewall ports are open (if present) and that virtual private network tunnels aren’t blocking large Internet Control Message Protocol (ICMP) traffic. Look at these Windows registry keys for group policies issues:
کد:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System] 
"GroupPolicyMinTransferRate"=dword:00000000

and
کد:

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System] 
"GroupPolicyMinTransferRate"=dword:00000000

There are many issues to consider before migrating between Active Directory forests. Those listed above are only a few of the tips and tricks we picked up along the way to speed efforts or solve problems we encountered. Our migration won my group national recognition and is the foundation of future projects for years to come

[patris1]

http://clintboessen.blogspot.com/2009/10/windows-server-2008-admt-31-pes.html

Windows Server 2008 ADMT 3.1 PES Password Issue


When installing the Password Export Server on a Server 2008 Domain Controller in the destination forest, the following error was encountered entering the password for the .pes file security key that was generated in the source forest:

The supplied password does not match this encryption key's password. ADMT's Password Migration Filter DLL will not install without a valid encryption key.





The error that was being generated "the password does not match this encryption key" is bogus, as the password did match. This error was actually being generated by a permission problem to the SAM database caused by UAC (user account control).

To get around this run a command prompt as administrator and launch pwdmig.msi from there. Ensure the command prompt is running as administrator!

[patris1]

http://www.sivarajan.com/admt.html

Active Directory Migration Using ADMT 3.1


This document outlines the group, user and computer migration procedure the Active Directory Migration Tool (ADMT) version 3.1.
Here is a graphical representation of the high level steps involved in an Active Directory migration using ADMT version 3.1:

The following sections will explain the procedure of migrating the Groups, Users and Computers:
Group Migration
1. Logon on to the <ADMT Server> using <ADMT service> account.
2. Open ADMT Console.
3. In the ADMT snap-in, click Action, and then click Group Account Migration Wizard.
4. Select the appropriate options in the Group Account Migration Wizard

a. Domain Selection - > Select Source and Target Domain
b. Group Selection -> Select groups
c. Organizational Unit Selection -> Select target OU
d. Group Options-> Click Migrate Group SIDs to target domain
e. User Options-> Select appropriate options
f. Object Property Exclusion-> Select appropriate options
g. Conflict Management -> Select appropriate options

5. Complete the Group Account Migration Wizard.
6. When the wizard has finished running, click View Log, and review the migration log for any errors.
User Migration
1. In the ADMT snap-in, click Action, and then click User Account Migration Wizard.
2. Select the appropriate options in the User Account Migration Wizard

a. Domain Selection - > Select Source and Target Domain
b. User Selection -> Select User accounts (use an input file if you want to migrate a group of people)
c. Organizational Unit Selection -> Select target OU
d. Password Options -> Migrate Password
e. Account Transition Options -> Select appropriate options
f. User Account -> Enter Type the user name, password, and domain of a user account that has administrative credentials in the source domain.
g. User Options-> Select appropriate options
h. Object Property Exclusion-> Select appropriate options
i. Conflict Management -> Select appropriate options

3. Complete the User Account Migration Wizard.
4. When the wizard has finished running, click View Log, and review the migration log for any errors.

Security Translation
1. In the ADMT snap-in, click Action, and then click Security Translation Wizard.
2. Select the appropriate options in the Security Translation Wizard

a. Domain Selection - > Select Source and Target Domain
b. Computer Selection -> Select computer accounts
c. Translate Object -> Select necessary items
d. Security Translation Options -> Select Add or Replace option. If you select Add option, you need to use Replace option later to clear the old profile
e. ADMT Agent Dialog -> Select Run pre-check and agent operation, and then click Start.

3. Complete the Security Translation Wizard.
4. Review the results that are displayed on the screen for any errors. After the wizard completes, click View Migration Log to see the list of computers, completion status, and the path to the log file for each computer
Workstation Migration
1. In the ADMT snap-in, click Action, and then click Computer Account Migration Wizard.
2. Select the appropriate options in the Group Account Migration Wizard

a. Domain Selection - > Select Source and Target Domain
a. Computer Selection -> Select computer accounts (use an input file if you want to migrate a group of people)
b. Organizational Unit Selection -> Select target OU
c. Translate Object -> Select necessary items
d. Security Translation Options -> uncheck all options
e. Object Property Exclusion-> Select appropriate options
f. Conflict Management -> Select appropriate options
g. ADMT Agent Dialog -> Select Run pre-check and agent operation, and then click Start

3. Complete the Computer Account Migration Wizard.
4. Review the results that are displayed on the screen for any errors. After the wizard completes, click View Migration Log to see the list of computers, completion status, and the path to the log file for each computer

[patris1]

http://blogs.dirteam.com/blogs/jorge/archive/2009/11/09/migrating-your-local-users-local-groups-and-memberships-from-the-sam-into-ad.aspx

Migrating your local users, local groups and memberships from the SAM into AD

You may have a Windows Server somewhere that's not joined to a joined that contains lots of local user accounts, local groups and of course memberships of local accounts in those local groups. On that server you have permissioned all NTFS permissions with those local groups. Another scenario is a member server with exact same information. Now you have decided you want to "migrate" all of that into AD. How would that be possible easily without loss of information?

REMARK: Before you do this, as a fallback plan, make sure to have a FULL backup of the server you want to perform this operation on!

The starting point would be something similar to the pictures below.
All Users


All Groups


All Group Memberships


In these pictures you see local users and local groups and those users are member of those local groups. The way to keep that all is to promote the server to a DC in a NEW AD domain. Because of that the information is kept and "migrated" into AD (into the 'Users' container). If you promoted the server into an existing AD domain, the information in the SAM would be lost.
In this example I'm promoting a member server in an AD domain into a new AD domain in the same AD forest. After promotion of the member server into a new AD domain in the existing AD forest, the end result is shown below.

Migrated Users and Groups


Migrated Group Memberships


Migrated User Properties


By doing it this way, you migrate the info into AD and when that has occurred you can use ADMT to migrate the objects into some other AD domain. The fun part is that in the second migration into another AD domain, you will not have issues regarding the membership rules when migration between AD domains in the same AD forest!

More specific information about the upgrade process can be found here.

Cheers,
Jorge