(2006-12-27) Migrating Stuff With ADMTv3

ADMTv3 has been out for a while and is the free Microsoft Migration Tool available for use (besides other small tools that can help you during your migration like NETDOM, SUBINACL, ROBOCOPY, etc.). It can be downloaded here

Besides the tool you can also view and download documents with loads of info about migrations and how to use ADMT. The following information is available:

• ADMT v3 Migration Guide
• How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003
• Windows 2000 Server Domain Migration Cookbook

 

ADMTv3 is a migration tool that can help you with:

• Migrating user and group objects (with or without sIDHistory) from one domain to another
• Migrating computer objects and the actual computers from one domain to another
• Translate stuff (from source domain –> target domain):
  • Security on file based data ACLs
  • Security on printers ACLs
  • Security on shares ACLs
  • Security on registry ACLs
  • Security on profiles ACLs (and registry information)
  • Service Accounts used by services
    • REMARK: make sure you identify the custom service accounts FIRST on each server to be migrated. This also prevents the option "change password at next logon" being set as the user account is migrated. All accounts NOT identified as service accounts will have the option set. If needed you can revert this afterwards with ADMOD/ADModify
  • It CANNOT help you with:
    • Translate security on services ACLs. For that you can use SUBINACL
    • Translate information within IIS and COM+. For that you need to use a third party tool
    • Translate information within SQL. For that you need to use a third party tool
    • ….other apps…. –> For that you might need to use a third party tool

 

Interesting enhancements within ADMTv3 when compared to ADMTv2:

• When migrating between AD forests, it is aware of possible schema differences between the AD forests
  • It allows to define attributes for exclusion during migration
  • Schema differences (attributes that are not migrated) are shown within the migration logs
• SQL or (W)MSDE database support
  • Enables and supports the use of multiple consoles
• The possibility to select source and target DCs for migrating objects
• It supports INPUT files for objects to be migrated
• It allows the rename of objects during migration (through the use of an input file)
• Performing pre-migration tests to ensure availability of computers to be migrated
• Additional options when migrating passwords like:
  • "Do not update passwords for existing users"
  • Migration of changed passwords from source domain
• The "Password Export Server (PES)" can be configured to run with a service account. This enhancement removes the dependency on the "pre-Windows 2000 compatible access" group that PREVIOUS should contain the well-known security principals "Everyone" and "Anonymous Logon" (in W2K only "Everyone" as that by default already contained "Anonymous Logon") (in W2K3 you can revert to the same behavior but that IS NOT recommended!)

 

NOT that of an enhancement:

• It can only be installed on Windows Server 2003

 

When migrating from one domain (source) to another domain (target) the following are high-level steps to consider:

• Make sure the target AD has been configured (sites, subnets, replication, OUs, GPOs, delegations, DNS, WINS, DHCP, etc.)
• Setup name resolution (WINS or DNS) between source and target domain/forest
  • REMARK: When either endpoint of a trust is NT4, you must use NetBIOS name resolution which is made possible by WINS or LMHOSTS. When either endpoint of a trust is W2K or higher, you can either use NetBIOS name resolution, which is made possible by WINS or LMHOSTS, or use DNS name resolution (I prefer the last!)
• Setup trusts between source and target domain
  • REMARK: When either endpoint of a trust is NOT W2K3, you must use an external trust. When either endpoint of a trust is W2K3 or higher, you can either use an external trust or a forest trust. For the latter, which one you use depends on the environment and your requirements.
    Be aware that sIDFiltering is by default enabled on the outgoing part of an external trust (which therefore impacts the use of sIDHistory AND/OR the use of external domain group membership within the same target forest)
    sIDFiltering is by default NOT enabled on the outgoing part of a forest trust (which therefore does NOT impact the use of sIDHistory AND/OR the use of external domain group membership within the same target forest). Some documents might mention sIDFiltering is enabled by default on the outgoing part of a forest trust. This is not true!
    When sIDFiltering is enabled on the outgoing part of a trust and sIDHistory is used AND/OR domain external domain group membership within the same target forest, you need to disable it using the following command:
    • Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<domainadminAcct> /passwordD:<domainadminpwd>
      (to ENABLE sIDFiltering again specify Yes)

 

SOURCE DOMAIN —————–(trust)—————–> TARGET DOMAIN
                              ^                                             ^
                               |                                              |
                               |                                              |
                               |                &nbsp
;                             |
                    outgoing part                           incoming part
(sIDFiltering is ALWAYS configured on the outgoing part of a trust – not saying if it is configured or not! Just saying WHERE)

Also see:

• When to create an external trust
• When to create a forest trust

• Setup migration accounts to be use with the migration tooling
  • REMARK: this really depends if you have a one-way or two way trust, what you want to migrate and if the source and or target domain are AD… see the migration guide for this!
• Install and configure migration tooling and if needed for password migration, also designate a source DC as the Password Export Server (PES) and install the required software
• Identify service accounts across servers in the source environment
• Migrate groups, user accounts with passwords and group memberships (with sidhistory)
  • REMARK: When resource access is provided by a sID, sIDHistory can help you. However if resource access is provided in another way (e.g. <domain><user or group>, or something else), you MUST add the target ACEs first before the users switch over to their new account. When not taken care of, resource access might be lost. Examples of applications where this can occur is SQL server.
  • REMARK: To use sIDHistory your target domain MUST be in at least "Windows 2000 Native" mode or domain functional level. Well, this is the supported configuration! There exists migration tooling that is able to migrate sIDHistory without the AD domain being in at least "Windows 2000 Native" mode or domain functional level, or in other words, still being in "Windows 2000 Mixed" mode or domain functional level. Remember, the latter is NOT supported by Microsoft! I also do not know that the impact is of this and what requirements might exist emposed by the migration tool.
• Migrate clients from the source domain to the target domain, translate security on the client, and translate profiles (at this moment users start logging on with their new AD account on the migrated clients that have been migrated previously to the w2k3 domain)
• Migrate mailboxes if needed
  • REMARK: This is another story and it depends if you are migrating from Exchange 5.5 or Exchange 2000/2003
• Migrate servers to the new domain or migrate data to new servers
• Translate security (Re-ACL) and other stuff of the data/resources from source security principals to target security principals (replace the security descriptors from the old domain with the security descriptors from the new domain) (see list above)
  • REMARK: Although you might have not yet translated security it might look like the ACLs already show security principals from the target domain. This DOES NOT mean security has been translated. This occurs when using sIDHistory as the target system recognizes the sID (because it is stored in the sIDHistory field) and shows the target security principal instead of the source security principal. If you would cleanup sIDHistory suddendly the source security principal is shown and if you additionally remove the trust an "unknown sID" is shown
• Cleanup temporary configurations
• Cleanup sidhistory (recommended!).
  • REMARK: sIDHistory is a temporary configuration and is used to access resources while those resources still have security descriptors from the source domain. As soon as all data (file, folders, mailboxes, etc.) have been re-ACL-ed sIDHistory can be cleaned. sIDHistory should only be used temporary for migration purposes! To clean sIDHistory you can use ADFIND and ADMOD. The command line looks like:
    • For the complete target domain:
      • adfind -default -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
    • For just some OU within the target domain:
      • adfind -b "<DN of some OU>" -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
• Remove trusts
• Decommission old domain(s)

 

For more information about ADMTv3 and possible steps needed for migration see the ADMT v3 Migration Guide.

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————