ADMT Guide: Migrating and Restructuring Active Directory Domains

Updated: December 19, 2014

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

The latest version of ADMT 3.2 is available on Microsoft Connect (http://go.microsoft.com/fwlink/?LinkId=401534) and it supersedes all previous versions. It runs on all versions of Windows Server and can migrate objects to and from any Active Directory environment. All previous versions of ADMT have been removed from the Microsoft Download Center.

You can download a version of this guide in .doc format (http://go.microsoft.com/fwlink/?LinkId=191734).

As part of deploying Active Directory Domain Services (AD DS), you might choose to restructure your environment for the following reasons:

• To optimize the arrangement of elements within the logical Active Directory structure.
  
• To assist in completing a business merger, acquisition, or divestiture.
  

Restructuring involves the migration of resources between Active Directory domains in either the same forest or in different forests. After you deploy Active Directory or AD DS, you might decide to further reduce the complexity of your environment by either restructuring domains between forests or restructuring domains within a single forest.

You can use the Active Directory Migration Tool (ADMT) to perform object migrations and security translation as necessary so that users can maintain access to network resources during the migration process.

In this guide

• Best Practices for Active Directory Migration 
  
• Interforest Active Directory Domain Restructure 
  
• Intraforest Active Directory Domain Restructure 
  
• Appendix: Advanced Procedures 
  
• Troubleshooting ADMT 
  
• Additional Resources 
  

The following sections explain the main migration scenarios for using ADMT. After you determine the appropriate scenario for your environment, follow the steps later in this guide for that scenario.

Interforest Active Directory domain restructure

You might perform an interforest restructure for business changes, such as mergers or acquisitions or divestitures, in which your organizations have to combine or divide resources. As part of the restructuring process, when you migrate objects between forests both the source and target domain environments exist simultaneously. This makes it possible for you to roll back to the source environment during the migration, if necessary.

Splitting or cloning forests—for example, to accommodate divestiture of an organization—is not supported. For more information, see Restructuring Limitations (http://go.microsoft.com/fwlink/?LinkId=121736).

Intraforest Active Directory domain restructure

When you restructure domains in a forest, you can consolidate your domain structure and reduce administrative complexity and overhead. Unlike the process for restructuring domains between forests, when you restructure domains in a forest, the migrated accounts no longer exist in the source domain. Therefore, rollback of the migration can only occur when you carry out the migration process again in reverse order from the previous target domain to the previous source domain.

The following table lists the differences between an interforest domain restructure and an intraforest domain restructure.

 

Migration consideration	Interforest restructure	Intraforest restructure
Object preservation	Objects are cloned rather than migrated. The original object remains in the source location to maintain access to resources for users.	User and group objects are migrated and no longer exist in the source location. Computer and managed service account objects copied and the original accounts remain enabled in the source domain.
Security identifier (SID) history maintenance	Maintaining SID history is optional.	SID history is required for user, group, and computer accounts, but not managed service accounts.
Password retention	Password retention is optional.	Passwords are always retained.
Local profile migration	You must use tools such as ADMT to migrate local profiles.	Local profiles are migrated automatically because the user’s globally unique identifier (GUID) is preserved.
Closed sets	You do not have to migrate accounts in closed sets. For more information, see Background Information for Restructuring Active Directory Domains Within a Forest (http://go.microsoft.com/fwlink/?LinkId=122123).	You must migrate accounts in closed sets.

Terms and definitions

The following terms apply to the Active Directory domain restructure process.

Migration   The process of moving or copying an object from a source domain to a target domain, while preserving or modifying characteristics of the object to make it accessible in the new domain.

Domain restructure   A migration process that involves changing the domain structure of a forest. A domain restructure can involve either consolidating or adding domains, and it can take place between forests or in a forest.

Migration objects   Domain objects that are moved from the source domain to the target domain during the migration process. Migration objects can be user accounts, service accounts, groups, or computers.

Source domain   The domain from which objects are moved during a migration. When you restructure Active Directory domains between forests, the source domain is an Active Directory domain in a different forest from the target domain.

Target domain   The domain to which objects are moved during a migration.

Built-in accounts   Default security groups that have common sets of rights and permissions. You can use built-in accounts to grant permissions to any accounts or groups that you designate as members of these groups. Built-in account SIDs are identical in every domain. Therefore, built-in accounts cannot be migration objects.

Active Directory Migration Tool

You can use ADMT to migrate objects in Active Directory forests. This tool includes wizards that automate migration tasks, such as migrating users, groups, service accounts, computers, and trusts and performing security translation.

You can perform ADMT tasks by using the ADMT console, a command line, or a script. When you run ADMT at the command line, it is often more efficient to use an option file to specify command-line options. You can use the ADMT option file reference in the following example to assist you in creating option files. Examples of command-line syntax are provided for each task that you must perform to restructure the domains within the forest.

The following listing shows common options that apply to several migration tasks. Each type of migration task has a section that lists options that are specific to that task. The section name corresponds to the task name when you run ADMT at the command line. You can comment out items with a semicolon. In the following listing, the default values are commented out.

[Migration]
;IntraForest=No
;SourceDomain="source_domain_name" 
;SourceOu="source_ou_path" 

;TargetDomain="target_domain_name" 
;TargetOu="target_ou_path" 
;PasswordOption=Complex
;PasswordServer="" 
;PasswordFile="" 
;ConflictOptions=Ignore
;UserPropertiesToExclude="" 
;InetOrgPersonPropertiesToExclude="" 
;GroupPropertiesToExclude="" 
;ComputerPropertiesToExclude="" 

[User]
;DisableOption=EnableTarget
;SourceExpiration=None
;MigrateSIDs=Yes
;TranslateRoamingProfile=No
;UpdateUserRights=No
;MigrateGroups=No
;UpdatePreviouslyMigratedObjects=No
;FixGroupMembership=Yes
;MigrateServiceAccounts=No
;UpdateGroupRights=No

[Group]
;MigrateSIDs=Yes
;UpdatePreviouslyMigratedObjects=No
;FixGroupMembership=Yes
;UpdateGroupRights=No
;MigrateMembers=No
;DisableOption=EnableTarget
;SourceExpiration=None
;TranslateRoamingProfile=No
;MigrateServiceAccounts=No

[Security]
;TranslationOption=Add
;TranslateFilesAndFolders=No
;TranslateLocalGroups=No
;TranslatePrinters=No
;TranslateRegistry=No
;TranslateShares=No
;TranslateUserProfiles=No
;TranslateUserRights=No
;SidMappingFile="SidMappingFile.txt"

When you run ADMT at the command line, you do not have to include an option in your command if you want to accept the default value. In this guide, however, tables that list possible parameters and values are provided for reference. The tables list the command-line equivalent of each option that is shown in the corresponding ADMT console procedure, including those options for which you accept the default value.

You can copy the option file reference into Notepad and save it by using a .txt file name extension.

As an example, to migrate a small number of computers, you might type each computer name at the command line, using the /N option, and then list other migration options within an option file as follows:

ADMT COMPUTER /N "" "" /O:".txt"

Where and are the names of computers in the source domain that you are migrating in this batch.

Using an include file

When you migrate a large number of users, groups, or computers, it is more efficient to use an include file. An include file is a text file in which you list the user, group, and computer objects that you want to migrate, with each object on a separate line. You must use an include file if you want to rename objects during the migration.

You can list users, groups, and computers together in one file, or you can create a separate file for each object type. Then, specify the include file name with the /F option, as follows:

ADMT COMPUTER /F "" /IF:YES /SD:"” /TD:"" /TO:""

To specify the names of users, groups, or computers, use one of the following conventions:

• The Security Accounts Manager (SAM) account name. To specify a computer name in this format, you must append a dollar sign ($) to the computer name. For example, to specify a computer with the name Workstation01, use Workstation01$.
  
• The relative distinguished name (also known as RDN), for example, cn= Workstation01. If you specify the account as a relative distinguished name, you must specify the source organizational unit (OU). 
  
• The canonical name. You can specify the canonical name as DNS domain name/ou_path/object_name or ou_path/object_name, for example, Asia.trccorp.treyresearch.net/Computers/Workstation01 or Computers/Workstation01.
  

The following sections describe the fields of an include file and provide examples for each field:

SourceName field

The SourceName field specifies the name of the source object. You can specify either an account name or a relative distinguished name. If you only specify source names, it is optional to define a header on the first line in the file.

The following example illustrates a header line that specifies the SourceName field. The example also shows a source object name that is specified in several formats. The second line specifies an account name. The third line specifies a relative distinguished name.

SourceName

name

CN= name

TargetName field

You can use the TargetName field to specify a base name that is used to generate a target relative distinguished name, a target SAM account name, and a target user principal name (UPN). The TargetName field cannot be combined with other target name fields that are described later in this section.

Note
The target UPN is generated only for user objects, and only a UPN prefix is generated. A UPN suffix is appended using an algorithm that depends on whether a UPN suffix is defined for the target OU or the target forest. If the object is a computer, the target SAM account name includes a "$" suffix.

The following example of input generates the target relative distinguished name, target SAM account name, and target UPN as "CN=newname", "newname," and "newname" respectively.

SourceName,TargetName

oldname, newname

TargetRDN, TargetSAM, and TargetUPN fields

You can use the TargetRDN, TargetSAM, and TargetUPN fields to specify the different target names independently of each other. You can specify any combination of these fields in any order.

TargetRDN specifies the target relative distinguished name for the object.

TargetSAM specifies the target SAM account name for the object. For computers, the name must include a "$" suffix to be a valid SAM account name for a computer.

TargetUPN specifies the target UPN for the object. You can specify either just the UPN prefix or a complete UPN name (prefix@suffix). If the name that you specify contains a space or a comma, you must enclose the name in double quotation marks (" ").

SourceName,TargetRDN

oldname, CN=newname

SourceName,TargetRDN,TargetSAM

oldname, "CN=New RDN", newsamname

SourceName,TargetRDN,TargetSAM,TargetUPN

oldname, "CN=last\, first", newsamname, newupnname

Note
A comma within the CN value must be preceded with an escape ("\") character or the operation will fail, and ADMT will record an invalid syntax error in the log file.

SourceName,TargetSAM,TargetUPN,TargetRDN

oldname, newsamname, newupnname@targetdomain, "CN=New Name"

Renaming objects

Use the following format in an include file to rename computer, user, or group objects during migration:

• Use SourceName, TargetRDN, TargetSAM, and TargetUPN as column headings at the top of the include file. SourceName is the name of the source account, and it must be listed as the first column heading. The TargetRDN, TargetSAM, and TargetUPN column headings are optional, and you can list them in any order.
  
• You must specify the account name as user name, relative distinguished name, or canonical name. If you specify the account name as a relative distinguished name, you must also specify the source OU.
  

The following are examples of valid include files in which the rename option is used:

SourceName,TargetSAM

abc,def

This include file entry changes the TargetSAM account name for user "abc" to "def." The TargetRDN and the TargetUPN, which are not specified in this include file, do not change as a result of the migration.

SourceName,TargetRDN,TargetUPN

abc,CN=def,def@contoso.com

This include file entry changes the TargetRDN for user abc to CN=def and the TargetUPN to def@contoso.com. The TargetSAM for user abc does not change as a result of the migration.

Important
You must specify CN= before using an RDN value.

Using an exclude file

You can exclude objects from migration by using an exclude file. An exclude file is a text file that lists the SAMAccountName attribute of the objects that you want to exclude. For example, to exclude the following managed service accounts, create a text file:

MSA_USER5$
MSA_USER6$

Then, specify the name of the exclude file when you run the admt command. For example:

admt managedserviceaccount /ef:”exclude file name”

Optionally, you can exclude specific accounts by using the /en parameter:

admt managedserviceaccount /en:”managed service account 1” “managed service account 2”

Using scripts

The sample scripts that are provided in this guide refer to the symbolic constants that are defined in a file named AdmtConstants.vbs. The listing that follows shows the ADMT constants Microsoft Visual Basic® Scripting Edition (VBScript) file. The constants are also provided in the ADMT installation folder, in the TemplateScript.vbs file, in the %systemroot%\WINDOWS\ADMT directory.

To use the sample scripts in the guide, copy the ADMT constants VBScript file into Notepad and save it as AdmtConstants.vbs. Be sure to save it in the same folder where you plan to save the sample scripts that are provided in this guide.

Option Explicit

'----------------------------------------------------------------------------
' ADMT Scripting Constants
'----------------------------------------------------------------------------

' PasswordOption constants

Const admtComplexPassword                   = &H0001
Const admtCopyPassword                      = &H0002

' Note that the following constant cannot be specified alone.
' It must be specified along with admtComplexPassword or admtCopyPassword.
Const admtDoNotUpdatePasswordsForExisting   = &H0010

' ConflictOptions constants

Const admtIgnoreConflicting           = &H0000
Const admtMergeConflicting            = &H0001
Const admtRemoveExistingUserRights    = &H0010
Const admtRemoveExistingMembers       = &H0020
Const admtMoveMergedAccounts          = &H0040

' DisableOption constants

Const admtLeaveSource        = &H0000
Const admtDisableSource      = &H0001
Const admtTargetSameAsSource = &H0000
Const admtDisableTarget      = &H0010
Const admtEnableTarget       = &H0020

' SourceExpiration constant

Const admtNoExpiration = -1

' Translation Option

Const admtTranslateReplace = 0
Const admtTranslateAdd     = 1
Const admtTranslateRemove  = 2

' Report Type

Const admtReportMigratedAccounts  = 0
Const admtReportMigratedComputers = 1
Const admtReportExpiredComputers  = 2
Const admtReportAccountReferences = 3
Const admtReportNameConflicts     = 4

' Option constants

Const admtNone     = 0
Const admtData     = 1
Const admtFile     = 2
Const admtDomain   = 3
Const admtRecurse           = &H0100
Const admtFlattenHierarchy  = &H0000
Const admtMaintainHierarchy = &H0200

[Exchange] Configuring NLB for Windows 2008 CAS servers

original article here.

Installing Windows 2008 NLB on Node 1;

Network Load Balancing is available in both the Standard and Enterprise Editions of Windows 2008 (it is also available in other higher level variants of Windows 2008). Essentially NLB uses a node based distributed process which farms network traffic between a number of Hosts (or nodes) – each node constitutes a member of a NLB cluster (this should not be confused with Windows Failover Clustering Services – NLB clustering is designed mainly around the distribution of Network traffic and providing fault tolerance at the interface level).

In order to install and correctly configure NLB in your environment you will need the following:

• At least two servers (or if you do not have two servers one server with two NIC interfaces – however under this scenario you would be at the mercy of the other components within the architecture).
• If you are Load Balancing two separate servers (which this article is about) you will require x 3 free IP addresses on your network:
  • x 2 for the Public Addresses of your nodes
  • x 1 for the NLB Cluster Address
• A DNS entry that points to the NLB clustered address – this will be used for hosts to connect to the Clustered NLB IP Address

Therefore before proceeding – ensure that each node (machine) that is going to form part of the NLB cluster has a Unique IP address on your Network, then, create a DNS host entry which points at the NLB Cluster IP Address – below is a simple overview diagram of how the NLB cluster will function as a Exchange Client Access Server:

When you have ensured that the above criteria has been met, open a Windows 2008 Command Prompt and type in the following command:

serverManagerCMD -i NLB – then press <Enter> (see below);

You will need to perform this on all nodes (computers) that will form that NLB cluster.

When NLB has completed installing (on both Nodes) on the Primary Node (First Machine you installed NLB) – go to the following [ START -> Programs -> Administrative Tools -> Network Load Balancing Manager ] – see below:

The following Window will open:

From the top left pane – right click on the “Network Load Balancing Clusters” and from the context menu that appears choose “New Cluster”:

You will then be presented with the “New Cluster: Connect” option – in the section that is entitled “Host” type in the Host name of the Primary Node in the cluster then click on the “Connect” button and then Click “Next” when the “Interfaces available for configuring this cluster” populates which will display the following:

As this the first node interface in the cluster you should ensure that the Priority is set to “1” – you can then leave the rest of the configuration options as the default and click on the “Next” button which will display the following screen:

This screen allows for you to configure the IP addresses that will be shared by each node of the NLB cluster – so for example earlier we created a DNS entry which corresponds to the CAS server’s Clustered IP address – click on the “Add” button which will open the following screen:

Enter in the Cluster IP addresses (which corresponds to the DNS entry) in the section entitled “Add IPv4 address” (you should also include the Subnet Mask) – then click on the “OK” button – this will return you to the main Cluster IP address screen – click on the “Next” button to be taken to the “Cluster Parameters” screen:

Here you will see that the Cluster IP address and Subnet have been pre-populated – however in the “Full Internet Name” section you will need to provide the FQDN of the DNS entry that we did at the start of the article (under the pre-requisites section) – as I am using a single network card I have chosen to use “Multi-cast” for the cluster operation mode – if you have two NIC’s in your server you should choose the Unicast option.

IMPORTANT: If you choose to go the Multi-cast route above, you'll need to update your ARP tables on your routers, as the IP address you're using is Unicast, with a Multi-Cast ARP. More info on this issue can be found here: http://technet.microsoft.com/en-us/library/cc781160.aspx#BKMK_2

We you are happy with the setting above click on the “Next” button:

Here you will be presented with the “Port Rules” section of the configuration.

Essentially this screen provides a means for you to reduce the “Attack Surface” area of the clustered IP address by allowing you to specify specific port traffic which is allowed via the IP address.

As you can see there is a default rule defined which essentially allows all traffic – select it and then click on the “Remove” button.

Now for the purposes of my CAS server I will only require ports 80 (HTTP) and 443 (SSL) – however it is possible that other people would also require 110 (POP3) and 143 (IMAP) to be added.

To add a port rule click on the “Add” button and the following dialog box will appear:

In order to configure HTTP Un-tick the “All” button, and then choose the IP address of your cluster from the “Cluster IP Address” area – then ensure that the rest of the configuration option match that as above. When you are happy with your choices click on the “OK” button.

You will be taken back to the main “Port Rules” screen – repeat the process for the other ports – when you have configured the remaining ports click on the “Finish” button.

Installing Windows 2008 NLB on Node 2;

You will now be returned to the main screen of the NLB cluster manager – which will now be processing your configuration changes. When it has finished – right click the New entry under “Network Load Balancing Clusters” (which is your new cluster) and from the context menu that appears choose the “Add Host to cluster” option – see below

You will be presented with the familiar “Add host to cluster” dialog box – here type in the Host name of the second node and then click on the “Connect” button – then when the “Connection Status” changes to “Connected” click on the “Next” button:

You will then be presented with the “Host Parameters” dialog box – ensure that the priority assigned is set to “2” – then click on the “Next” button:

You will given the option to Edit the port rules again – confirm that they are as expected then click on the “Finish” button:

The cluster will then return you to the NLB manager screen - where it will be processing the changes made and converge the interfaces.

When it has completed voila! – Windows 2008 Server NLB for Exchange CAS.

Visio 2007 Add-ins

Some extremely helpful Visio add-ins to help with environment discovery, assessment, and planning:

http://blogs.technet.com/wcraddock/archive/2008/11/28/visio-2007-add-in-s.aspx

Quest acquires NetPro

CEO of NetPro: “Quest and NetPro share the common goal of helping customers solve complex problems for better Identity Management, as well as Active Directory, Exchange, SharePoint, and SQL Server management, compliance and security."

Quest pretty much owns the Exchange and Windows migration 3rd-party space. It will be interesting to see how they leverage NetPro's diverse (some are very similar) set of tools and experts to provide us the best solutions out there. Forgive me if you're a fan of NetIQ...


http://www.quest.com/newsroom/news-releases-show.aspx?contentid=8055

Disclaimer: Quest/NetPro is a partner of my employer (Avanade)

ADMT 3.1 Released + Improved Migration Guide

The FREELY available AD Migration tool from Microsoft, ADMT (Active Directory Migration Tool) v3.1 has now officially been released. It includes support for migrating from Windows 2008 DCs, 32-bit and 64-bit PES (Password Export Service), as well as several bug fixes (and other improvements) over v3.0.

Here it is.

Microsoft has also released an improved ADMT migration guide, titled Migrating and Restructuring Active Directory Domains Using ADMT v3.1. Get it here

2008 Printer Migration and Consolidation

Step-by-step, using the Print Migrator replacement - Printer Migration Wizard / Printbrn.
Here.

Other helpful links:
KB938923 - How to back up and then restore printers when you upgrade from Windows Server 2003 to Windows Server 2008
Windows 2008 Print Services (TechNet link)

Migrating login scripts...necessary?

I often see companies looking to carry over login scripts for users after being migrated, or look for an alternative to login scripts (in a large enterprise environment, managing hundreds of login scripts can become a nightmare, especially in a non decentralized administrative model). Often times GPOs can replace many login script functions, and now Microsoft has recently released their Group Policy Preferences tool. This tool essentially lets you manage O/S and application settings that were previously unmanageable via GPOs. Some examples include managing group membership, mapped drives (some very flexible settings around mapped drives), Start menu settings, printers, folder options/view, and countless others.

By combining GPOs and GPPs, in many cases we're now able to completely eliminate the need for a login script.

Q. What is the main difference between policy settings and preference settings?

A. The main difference between policy settings and preference settings is that preference settings are not enforced. This means the end user can change any preference setting that is applied through Group Policy, but policy settings prevent users from changing them.

A few things to note:
* To manage GPPs you need a Win2008 Server or Vista-SP1 machine on your network
* To utilize GPPs you need your clients to at least be at XP-SP2, Vista, 2003-SP1, or 2008, in addition to having the GPP Client-Side Extensions update installed (available via Windows Update)

For more information:
Group Policy Preferences Overview
Group Policy Preferences FAQ

Windows Server 2008 Step-by-Step Guides

Always looking for downloadable versions of 2008 pages from the 2008 TechNet on-line library? Here's a collection of over 25 Step-by-Step guides for Server 2008.

Migration suites/tools- the players

Microsoft - ADMT 3.0, ADMT 3.1(BETA) - Users, Groups, Profiles, Workstations, Servers. ADMT 3.1 now support Server 2008.

Microsoft - FSMT (File Servers, only currently supported up to Server 2003), Print Migrator (Print Queue/Server Migrations, currently supported up to Server 2003)

Quest Software - DMW and Quest Migration Manager for AD

NetIQ - Domain Migration Administrator

WinZero - Server and Domain Migrator 2007

PointDev - PointDev's IdealMigration is a great product to demo. It includes MMC snap-in functionality, and the free reporting features included in the Demo alone make it worth checking out. Ideal for NT/2000/2003 environments.

Free WebCast: Plan Your Windows Server 2008 Migration in Less Time with Fewer Resources

Essential viewing prior to any 2008 migration activities. Level 200.

Go here

Presented by: Baldwin Ng, Senior Product Manager, Microsoft Corporation

Microsoft Assessment and Planning Solution Accelerator (MAP)

Planning to upgrade to 2008? The MAP tool from Microsoft is absolutely essential in helping to plan, assess and inventory your current environment's readiness for 2008 (as well as other O/S and Office solutions - Vista, for example), all while not even needing to install an agent. Get this fantastic FREE product here

PStools - Free, essential tools for all admins

If you haven't heard of the PStools free suite of tools (formerly from SysInternals, now owned by Microsoft), here is a great primer on the suite, and the thinking behind their creation:

The Desktop Files: PStools Primer

Fixing ACLs on Permissioned Resources

ADMT can be used to an extent to re-ACL Servers and Workstations in preparation for migrating to a new domain, however often times mass re-ACL'ing of data (whether to replace or append ACE entries to an ACL) is required for large data moves. A great tool to effectively copy/move/sync source and target data (while retaining security permissions) is Robocopy. This is a freely available tool from Microsoft, and there is even a free GUI front-end for the command-line challenged (or if you just want to avoid fat-fingering a critical data copy/move operation).

In conjunction with Robocopy, you can use the SubInACL free tool to replace/append SIDs to the ACL of each file/folder. SubInACL can be fed a mapping file which maps source to target user names/SIDs. Usually you'll want to start off by appending ACE entries to the ACLs to allow for co-existence (especially if the data migration activities happen to be occuring in parallel with user/group migrations). Once user/group migration activities are complete, and the environment has stabilized, you can re-run SubInACL to remove the unneeded source SIDs.

Remember that when using SIDHistory to access resources, you can only reach back in to the source, and not forward from the source to target. Even when moving data in the above scenario, I would always make it standard practice to be bringing over users with their SIDHistory attribute populated with their source domain SID (attribute name in source: ObjectSID)

As always with SIDHistory, make sure you have it correctly enable on your trust. Different versions of NETDOM (unfortunately you can only do it from a command-line) have different switches to enable SIDHistory. Running a netdom /? will let you know whether you should be using the /EnableSIDHistory:Yes switch, or /Quarantine:No switch. Here are examples:

Netdom Syntax:

Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No

netdom trust trusted_domain /domain:trusting_domain /enablesidhistory:yes

Depending what security context you're running this command in, you may need to specify source and target domain credentials (syntax again can be found with netdom /?)

Robocopy (included as part of the 2003 Resource Kit - free to licensed Windows users)
Robocopy GUI
SubInACL

Solution Accelerator for Consolidating and Migrating File and Print Servers from Windows NT 4.0

"The Solution Accelerator for Consolidating and Migrating File and Print Servers is a set of documentation which provides guidance on consolidating and migrating file and print servers from Windows NT 4.0 to Microsoft Windows Server 2003 and Windows Storage Server 2003"

Get it here

ADMT User Migration command-line syntax (and examples)

Technet reference article

Credit to Brent Dorrington for the below examples:

Admt.exe can be used to migrate users from the command-line (if you're sick of the ADMT GUI, or just want to automate/batch/script your migrations):

Appropriate syntax:

ADMT USER /N "user_name1" "user_name2" /SD:"source_domain" /TD:"target_domain" /TO:"target_OU" /MSS:YES

Therefore, if you have a CSV file, with your username in the 1st column, you could run

for /f "tokens=1,2,3* delims=,/ " %%i in (mycsvfile) do ADMT USER /N "%%i" "%%i" /SD:"source_domain" /TD:"target_domain" /TO:"target_OU" /MSS:YES

Note: if you are running from command line, remove the 2nd % in above syntax. The above syntax is fine if you are running in a batch file.

If the 1st column isn't command-line, then just increment %i (i.e. 2nd column would be %%j and so on. You will need to increase the tokens if the username is in column 3 or greater.

Thanks Brent!

Microsoft File and Print Migration Tools (Free)

File Server Migration Toolkit

Print Migrator

Well-Known Security Identifiers (SIDs)

Similar to TCP ports, have you ever wondered what all the different Windows SIDs are reserved for? Down below is a quick list of common Well-Known SIDs, and at the bottom of this post you'll find a link to the MKB article with an almost complete list.

First off, here's how a SID breaks down:

Example: S-1-5-21-1674060341-653213906-1520766640-1984

The first character is always an S. It identifies it as a SID

The first number is the SID revision level.

The second number identifies the authority (5 is NT authority)

The third of set of numbers is the domain or local computer identifier
(in this case: 21-1674060341-653213906-1520766640)

The final number (after the last hyphen) is the RID (Registered ID). Any RID that is 1000 or higher is part of a SID generated by the domain's RID Master. RIDs less than 1000 are built-in or created by default and reserved (for example, 500 on the end is reserved for the Administrator account). In the above example, 1984 refers to a created user object's SID.

		SID: S-1-5-domain-501 Name: Guest Description: A user account for people who do not have individual accounts. This user account does not require a password. By default, the Guest account is disabled.
		SID: S-1-5-domain-512 Name: Domain Admins Description: A global group whose members are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. Domain Admins is the default owner of any object that is created by any member of the group.
		SID: S-1-5-domain-513 Name: Domain Users Description: A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group by default.
		SID: S-1-5-domain-514 Name: Domain Guests Description: A global group that, by default, has only one member, the domain's built-in Guest account.
		SID: S-1-5-domain-515 Name: Domain Computers Description: A global group that includes all clients and servers that have joined the domain.
		SID: S-1-5-domain-516 Name: Domain Controllers Description: A global group that includes all domain controllers in the domain. New domain controllers are added to this group by default.
		SID: S-1-5-root domain-518 Name: Schema Admins Description: A universal group in a native-mode domain; a global group in a mixed-mode domain. The group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.
		SID: S-1-5-root domain-519 Name: Enterprise Admins Description: A universal group in a native-mode domain; a global group in a mixed-mode domain. The group is authorized to make forest-wide changes in Active Directory, such as adding child domains. By default, the only member of the group is the Administrator account for the forest root domain.
		SID: S-1-5-32-544 Name: Administrators Description: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.
		SID: S-1-5-32-545 Name: Users Description: A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer.
		SID: S-1-5-32-546 Name: Guests Description: A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.

Well-known security identifiers in Windows operating systems

ADMT UPN Issue when Merging Objects (zero appended)

Have you run into a strange issue in ADMT where you see a random zero ("0") or one ("1") appended to a UPN after using ADMT to migrate and merge a source object with a target object?

This happens in ADMT where target accounts, after merged with a source account, are randomly getting a zero appended to their UPN. If you fix the UPNs (using ADSIEdit, ADExplorer, or ADModify) and re-migrate the same batch of users, it will happen again, but to a different, random set of users. A workaround is using ADModify to query for (userprincipalname=*0@domain.com) …then reset their upns to samaccountname@domain.com. It’s a pain to run ADModify after every batch of users however, not to mention keeping track of any accounts to exclude (i.e., Student10@domain.com might accidentally get changed to Student1@domain.com).

This question was raised to the ADMT PM for Microsoft, and his comments were:

It happens when:

• there is an existing account in the Target domain with same UPN
• an include file is used to specify SourceName and TargetName values and these values are different

To fix it the best practice is to specify SourceName, TargetRDN, TargetSAM and TargetUPN in Include file.

We will be updating existing documentation to cover this better shortly for ADMT v3.1.

Sample SIDMapping file for ADMT

I've noticed the lack of available documentation around SIDMapping files used by ADMT. While they mention them briefly in the ADMT help file, and even in the MKB, there aren't any actual examples. I was originally stuck on this for a bit since I was used to the format of the normal ADMT include files (sourceName,TargetName,etc header on the first line, THEN the values - comma-delimited - on the subsequent line). Something to note: your SIDMapping file can contain multiple source domain SIDs (in a scenario where you're merging multiple source accounts - I've included examples of this below) that map to a single target domain object. I've seen user objects in AD with their SIDHistory attribute populated with 15-20 values. Anyway, below is a sample SIDMapping file I've used in the past. Notice that you can specity either by SID or by domain\username (in the second case, the domains will need to be reachable in order to resolve the domain\username to its actual Security Identifier).

sample sidmapping.txt file (cut and paste into Word, Notepad, etc to see the ends of lines trailing off the page):


S-1-5-21-1674060341-653213906-1520766640-1984,S-1-5-21-219123761-1972038647-3338400271-28241
S-1-5-21-1674060341-653213906-1520766640-5114,S-1-5-21-219123761-1972038647-3338400271-28241
S-1-5-21-602162358-299502267-839522115-2502,S-1-5-21-219123761-1972038647-3338400271-28241
NTDomain\janedoe,NEWCorp\janedoe1
S-1-5-21-1674060341-653213906-1520766640-2202,S-1-5-21-219123761-1972038647-3338400271-22263
S-1-5-21-1674060341-653213906-1520766640-5100,S-1-5-21-219123761-1972038647-3338400271-22263
XYZCorp\johndoe,NEWCorp\johndoe
NTdomain\jdoe,NEWCorp\johndoe






For more information on Security Identifiers (SIDs):

How to use a SID mapping file with the ADMT tool to perform a resource domain migration to Windows Server 2003
Why Understanding SIDs is Important
How to Associate a User Name with a Security Identifier