V1.1

Mike BranniganMike Brannigan

Enterprise Strategy and Senior ConsultantEnterprise Strategy and Senior Consultant

Domain MigrationDomain Migration

Agenda

Domain Migration

Tips and Tricks

Not covering design (Domain, Forest, OU, Site..)

Domain Migration

Domain Migration

Benefits

–Start with a pristine environment – no baggage or “history”

–Perceived as less risky (not big bang)

–Used to consolidate domains

Disadvantages

–Far more effort than upgrade

–Have to manage parallel infrastructures for duration

–Exchange is more complex

Domain Migration

Typically used

–After forest root is created through in place upgrade

–To consolidate resource and account domains

–For merger, acquisition or to divest businesses

SIDHistory is the enabler

SIDHistory

What is it?

How does it work?

What are the downsides?

Domain Migration Tools

Tools

–ADMT v2

–ClonePrincipal

–ADC

–3rd Party

ADMT v2

Free

Migrates user, group, computer, & password

Drive via wizard, cmd line or script

Perform trial migrations

Translate SIDs on workstations and servers

Can translate Roaming Profiles

Lots of guidance

Primary tool used by MCS

Not as automated as some 3rd party tools

ClonePrincipal

Free

Scriptable

Clones users and groups

Can copy SIDHistory

Can’t clone computer accounts (use Netdom)

Can’t migrate password

Free

Populates the AD from Exchange 5.5 directory

Uses Connection Agreements to flow changes (uni- or bi-directional)

–New user

–Delete user

–Change attribute

Requires Exchange knowledge

Needs schema extension

Active Directory Connector (ADC)

3rd Party

Quest Migration Suite for Active Directory

BindView bv-Admin for Windows Migration

NetIQ Domain Migration Administrator

Pointdev IDEAL Migration

Sys-Manage CopyRight

Domain Migration Tools

What tool to use?

–Start with ADMT v2 and look for reasons why not to use it. E.g.

– Huge number of domains

– 3rd party tools may have better consolidation features

– Want to migrate >1 domain at a time

– As above

– Want to perform more manipulation of user objects during migration

– E.g. rename / change naming convention

ADMT v2 Overview

Analyzes the migration impact both before and after the actual migration process

Tests migration scenarios before you perform the migration

Supports migration within a forest and between forests

Provides wizards to support the most common migration tasks

ADMT key components

ADMT “Server”–Usually DC in target domain

–Stores everything in Protar.mdb

– Migrated users and computers

– SIDHistory

– Used for security translation

– Protar.mdb not editable

Password Export Server–BDC in NT 4.0 domain

–Uses encrypted channel to send password hashes to ADMT Server

ADMT key components

Agent

– Installed automatically on computers to be migrated by ADMT

–Performs security translation, profile translation and changes domain membership

Can use a SID mapping file for more complex situations

ADMT v2 Migration Scenarios

Migrating user, group, and computer accounts between domains

Performing security translation on local groups, user profiles, and file and print resources

Populating the SIDHistory attribute with migrated security principals

Translating security on computers

Resolving the related file, directory, and share security issues

ADMT v2 Security

Delegated users can migrate computers

Launching agents requires local admin rights (e.g. Profile translation)

Running ADMT requires local admin rights

SID History migration has special requirements–Source domain:

– User must have administrator rights

–Target domain:

– Windows Server 2003: Domain administrator rights OR “Migrate SID History” extended right on domain

ADMT Security Requirements

Migration Object

Credentials Necessary In Source Domain

Credentials Necessary in Target Domain

User/Group with SID history

Local administrator or domain administrator

Delegated permission on the user OU or the group OU, extended permission to migrate SID history, and local administrator on the computer on which ADMT is installed.

Computer Domain administrator or administrator in the source domain and on each computer

Delegated permission on the computer OU and local administrator on the computer on which ADMT is installed.

Profile Local administrator or domain administrator

Delegated permission on the user OU and local administrator on the computer on which ADMT is installed.

Migrate Account Domains before Resource domains–Preparation

– Build new infrastructure

– Setup Trusts

– Setup ADMT

–Test

–Migrate

– Groups

– Users

– Service Accounts

– Resources

Domain Migration Roadmap using ADMT

Create target infrastructure

–Forest & Domain structure

–OU structure

–GPOs, incl login scripts

–Domain must be in Windows 2000 Native mode for SIDHistory

–Ensure name resolution works between old and new infrastructures

Migration Preparation - Build New Infrastructure

Preparation – Trusts

Minimum: source domain trusts target domain

If migrating some resources before users, you need 2-way trust

Recommended: 2-way trust

–Simplifies troubleshooting

–Gives you more migration options

Preparation – Setup ADMT

Install ADMT from the Win2K3 CD using Migration accountI386\ADMT\admigration.msi

Recommendation: installed on a DC in target domain–Runs faster (less network latency)

–Always targets the local DC

Ensure the Pre-Windows 2000 Compatible Access group contains

–Everyone

–Anonymous Logon

–Note: if this is not the case, you need to restart the Server service on all DCs in the target domain after replication

Preparation – Setup ADMT

Create an Encryption Key

–On target DC

ADMT KEY <source domain NetBIOS name> <path to save key> <password>

Password Export Server (PES)

–Requires 128-bit encryption (NT 4.0 SP6a)

– Install i386\ADMT\PWDMIG\pwdmig.exe on the nominated BDC in source domain

– Will ask for path to encryption key

– Don’t locate the key on a share

Preparation – ADMT Setup

Enable auditing of Account Management in the Target domain

Enable User and Group Management in the source domain

Create the following registry entry on the PESHKLM\System\CurrentControlSet\Control\LSA

AllowPasswordExport : DWORD : 0x1

Restart the PES

Create a domain local group called <domain>$$$ in source–This is used by ADMT to cause auditing to occur (drops the

migrated account into this group, then removes it)

Create the following registry entry on the PDCHKLM\System\CurrentControlSet\Control\LSA

TcpipCientSupport : DWORD : 0x1

– ADMT will configure these automatically on 1st run

Test

Create a test user in the source domain

–Make this user representative (homedir, group membership, roaming profile etc)

Create a test workstation in the source domain for each OS

–Make this representative (e.g. apps & local/roaming profiles)

Test

Refine your migration plan during tests

–Which group of users will be migrated 1st?

–Will you migrate user profiles?

–Will their workstation be migrated? If so, at the same time?

Migration – Global Groups

Migrate Global Groups before users

Group needs to be there before users can be made members

Groups are what give the migrated user access to shared data in old domain (via SIDHistory)

Group membership may (likely) change during the migration project

–ADMT allows re-migration to fix this

Lesson: migration of GG consumes lots of network & resources on DC executing ADMT

ADMT does not migrate Local Groups–Move members to global groups

–Permission resources with computer local groups

Migration – Users

Think about creating Migration Groups to make batch migrations easier

Change drive mappings to Dfs if possible

–You’re then free to migrate shares at your leisure

If not migrating workstations, update the DefaultDomain on NT/Win2K/XP

HKLM\Software\Microsoft\Windows NT\ CurrentVersion\Winlogon

Migration – Users

Any changes made to users in target domain need to be made manually in source domain to maintain rollback ability

–Lesson 1: Avoid changes to both source and target, make them in 1 domain only

–Lesson 2: Set user expectations up front

–Lesson 3: Communicate with all users about their domain name (not just migrated users)

–Lesson 4: Provide at least some minimal training

Get user representation in the planning

Run a pilot to get feedback and refine communications plan

Migration – Users

If you don’t migrate profiles, you need to think about

–Printer access/mappings

–Persistent drive mappings

–Desktop items

–Application settings which aren’t part of Default User

–Start Menu

Migration – Computers

Wizard deploys an Agent on computers to be migrated (hence need for Admin)

Agent changes Domain Membership and initiates a restart

Old SIDs remain in place, which is how SIDHistory works

–Lesson 1: Ideally migrate out of working hours or set the restart time to a low number

Migration – Service Accounts

ADMT can identify all servers/workstations in the source domain which run services not using Local System

Windows Server 2003 Deployment Kit states you should migrate these first

– I migrate them

– Separately

– Often after users

– Not using ADMT because the service is generally deployed on new hardware

Migration – User Profiles

Local and Roaming can be translated (“owning” user changed)

–Windows NT 4.0, Win 2000 & Windows XP

Primary SID is used on migrated profile, not SIDHistory–Logging on with the old account will not pick up the translated

profile

New SID can be added rather than replacing old SID–Lets the old user access the profile (e.g. to copy favourites), but

won’t be used for the users active profile

Migration – User Profiles

ADMT does not move the Roaming Profile – it will remain in the original share

Lessons

– If you translate profiles and then roll back, the target domain roaming profile won’t be rolled back

– If local profiles: next time user logs on with old account, a new profile is created

– If roaming profiles: next time user logs on, profile error will occur (access is denied) and user will get new local profile

Perform administration in the source domain only during migration

–E.g. group membership & new starters

–Schedule an ADMT re-migration nightly (for example) and use “replace conflicting accounts”

–Maintain a list of migrated users in a CSV file, pointing ADMT at this

–Freeze passwords for duration – “replace conflicting accounts” also migrates password

Migration – Parallel Environments

Rollback Plan

Windows NT 4.0 account objects–Enable the user accounts in the source domain (if you disabled

the accounts during the migration process)

–Get the users to log off from the Active Directory target domain and log on to the source domain

Windows NT 4.0 resource objects–Change the domain membership for the resource object to the

source domain

–Restart the server or workstation

–Log on to the source domain and verify that you can access the resource

–Don’t forget to change service accounts!

Rollback Plan

Post Migration

When everything is migrated

–Remove all bar PDC and 1 BDC from old domain

–Re-ACL migrated servers

– This is called Translating Security – ADMT

– Replaces SIDs from old domain with Group/User SIDs from new domain

–Power them off for a period to ensure everything is OK, then

–Tear down trusts with existing domain

Post Migration

Disable the migration account in new Domain

Delete Migration Groups

Remove SIDHistory from each user / group?

– Ideally, as this will have a minor performance improvement, and reduces chance of token-bloat

–Reality, never seen a customer do it, and have not knowledge of problems

Tips and Tricks

Cleanup the source domain before migration

–Unused groups

–Group Membership (esp. Domain Admin)

–Retired users

–Old computer accounts

Migrate shares to Dfs if possible

– Use deep mappings if clients are XP

Different password policies between source and destination won’t stop password migration

Tips and Tricks

Really long path/filenames

–>260 characters and ADMT will fail

Clone an OU?

–Not via the Wizard

–Command line or script, e.g.ADMT USER /SD:<source_domain> /SO:<source_ou> /TD:<target_domain>

/TO:<target_ou> /D:RECURSE+MAINTAIN

Recurse = clone sub OUs too

Maintain = maintain OU structure in destination

Tips and Tricks

Update Previously Migrated setting

–Replaces destination account – any changes since original migration are lost

Terminal Server profiles are not migrated

–Do it manually, or abandon

ADMT cannot migrate EFS files

–Decrypt

Don’t open / edit Protar.mdb, you’ll break it!

Make sure name resolution works – this is the root of lots of potential issues

3rd party tools

Resources

Whitepaper: Why Upgrade From Windows NT 4.0 to Windows Server 2003

–http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/nt4/nt4townet.mspx

Microsoft Solution for Management - Solution Accelerator for Windows Server 2003 Deployment

–http://www.microsoft.com/downloads/details.aspx?FamilyID=f4d07ff8-ae7d-4717-9f8b-f8ce16d580dd&displaylang=en

mikebran@microsoft.com

©2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.