The galactic story is going backwards, one prequel at a time…

There are some AD migration scenario’s (I’d rather call them “consolidation”) were, for various reasons, the user accounts already exist in the destination domain. This is typically the case when organizations use to operate a “mail forest”, dedicated to Exchange and used another forest for user to log and then decide they want to merge them, preferably keep the one used for mail because it contains rich address book information but also because Exchange is difficult to move from one domain to another. The “mail forest” only contains disabled user account linked to the user forest.

The ADMT does not provide a way to “reconcile” account and populate SID history of the existing users in destination domain using the original SID of the source domain. Fortunately, the force is with you if you use a scripting COM object part of the Windows 2000 Reskit: DSUtils.ClonePrincipal. This component allows you to script, using WSH or PoSh, the reconciliation of both users in the destination domain, consequently preserving permission set with the SID of the source domain.

In order to be able to use DSUtils.ClonePrincipal, the same requirements as the ones applicable to ADMT with Sid history usage are applicable: Trusts, Forest functional level, Registry modification (NT4)… Here is a short example of how to use it, where “Anakin” is the name of the user in the source domain and “darthvador” is the matching user in the destination domaine. Note that the actual domain names are specified in the line starting with “objClonePr.Connect” and must not be supplied in the line starting with “objClonePr.AddSidHistory”, which contains only SAM Account names of the users.

Set objClonePr = CreateObject("DSUtils.ClonePrincipal")

objClonePr.Connect “SourceDomainPDCDNSName”, “SourceDomainDNSName”, “DestinationDomainPDCDNSName”,”DestinationDomainDNSName”

objClonePr.AddSidHistory “anakin”, “darthvador”

Note: This also works for groups and computers (do not forget the $ at the end of the computer name in this case). Of course, it will not migrate the group membership, only the SID.

Now, practically, how would look a typical domain migration/consolidation end-to-end with the following constraints:

- Users exist in source and destination domain and must be reconciled

- Computers exist in source domain only and must be migrated

- Groups exists in source domain only and must be migrated

- Profiles and Permissions must be translate on all systems

You would have to plan the following steps:

1. Prepare a CSV text file containing the user-mapping between the source and the destination domain. It would look like:

lightside\anakin,darkside\darthvador

lightside\palpatine,darkside\darthsidious

2. Using ADMT, migrate the groups preserving SID History

3. Migrate/reconcile users using the script snippet above and the file made at step 1

4. Manually or using a script (I’ll provide an example in a later post), reconcile the group membership

5. Using ADMT, migrate the computer and perform security and profile translation. ATTENTION: you will need to run ADMT multiple times in order to get the permission and profiles correctly translated:

Run #1: Just to change the domain affiliation of the computer. The Migrated computer will reboot

Run #2: Chose Security Translation and all options as default. The Migrated computer will not reboot

Run #3: Chose Security Translation BUT specify a SID-mapping file, which is actually the file made at step 1

6. Optionally migrate logon scripts, GPO’s… as necessary

In a later post, I will publish and comment scripts to help getting the whole job done.

More info: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbf_upg_ojiy.mspx?mfr=true

And Cut!

Finally the new version of ADMT is out, together with the following tools and document, and downloadable from MS.com:

• Active Directory Migration Tool version 3.1: http://www.microsoft.com/downloads/details.aspx?FamilyID=ae279d01-7dca-413c-a9d2-b42dfb746059&DisplayLang=en
• Password Export Services (PES): x86 http://www.microsoft.com/downloads/details.aspx?FamilyID=f0d03c3c-4757-40fd-8306-68079ba9c773&DisplayLang=en and x64 http://www.microsoft.com/downloads/details.aspx?FamilyID=5b4e5c61-1c00-4da7-9c0d-130200aed21a&DisplayLang=en
• Migrating and Restructuring Active Directory Domains Using ADMT v3.1: http://www.microsoft.com/downloads/details.aspx?familyid=6D710919-1BA5-41CA-B2F3-C11BCB4857AF&displaylang=en (I am afraid it contains some typos so be watchful…)

Sadly, it is not supported to deploy this version of ADTM on Read-only DC’s and on CORE version of Server 2008 or on any version prior Windows Server 2008. Apparently NT4 is not supported as source domain anymore and the migration agent is not supported on NT4 computers anymore…

Hopefully, it now uses SQL2005 as backend (remote or local) and comes with extended command-line capabilities for set-up and post set-up configuration

It’s therefore time to revise my backup/restore process a bit compared to by original post from April 08 (http://www.marc-antho-etc.net/blog/post/2008/04/BackupRestore-of-the-ADMT-Database.aspx)

Thanks to SQL2005 you can now backup to a remote folder, example:

“%PROGRAMFILES%\Microsoft SQL Server\90\Tools\Binn\osql.exe" -E -S %computername%\MS_ADMT -Q"BACKUP DATABASE ADMT TO DI

SK = '\\SERVER\SHARE\admt.bak'"

Note that that the path contains 90 instead of 80 since the SQL version is incremented.

Now for another stuff, just a little bit tricky. It is possible to use ADMT against a remote SQL server. But the problem is: you have to create the database first and then install and configure ADMT while, to get your hands on the tool to create the database, you have to install ADMT first… Catch my drift?

Here is how to do it seamlessly:

1. Log on you DC, preferably with a domain admin or with a user administrator on both DC and SQL Server
2. Start the ADMT Setup
3. On the Welcome screen, click Next
4. On the EULA, select “I agree” then click Next
5. On the customer Experience Improvement Program, chose whatever you want the click Next
6. On the Database Selection, select “Use and existing SQL Server” and enter the name of the remote SQL then click Next
7. The next screen will show an error messaging complaining about the fact that the setup could not connect to the remote SQL or find the ADMT database. Keep the wizard open and do not click on Finish
8. Open a command-line and navigate to %WINDIR%\ADMT\AdmtDb\ 
9. Execute the command “admtdb create /s:MYSQLSERVER\MYINSTANCE” (the instance is optional and depends on your SQL configuration. The command should return “The ADMT database was created successfully”. If not, check permissions, connectivity, name resolution etc.
10. Return to the Wizard and click Back
11. On the Database Selection, select “Use and existing SQL Server” and enter the name of the remote SQL like you previously stated in the command-line then click Next
12. The next screen should now show a successful message, click Finish

Now let’s say that you changed your mind and wish to use the local SQL Express that ADMT installed during the setup (yes it actually installed one instanced then disabled it). Here is how to do:

1. Open a command-line and navigate to %windir%\ADMT\AdmtDb\
2. Execute the command “sc config MSSQL$MS_ADMT start= auto”, this will set the SQL instance’s startup mode to “Automatic”
3. Execute the command “sc start MSSQL$MS_ADMT”. It should return a text containing “STATE              : 4  RUNNING”. This will start the SQL instance
4. Execute the command “admtdb create /s:%computername%\MS_ADMT” to create the ADMT database locally. It should return “The ADMT database was created successfully”
5. Set the path to %windir%\ADMT\
6. Execute the command “admt config setdatabase /s:%computername%\MS_ADMT” to configure ADMT to use the local database. Note: The document from MS over ADMT v3.1 contains typos regarding the parameters of this command.
7. Start the ADMT console to check if everything OK

And cut!

Attention: none of the procedure describe in this post are supported by Microsoft, test and use at your own risks!

When migrating or restructuring domains, it often happens that, the first steps are to migrate user accounts and groups and then, gradually migrate computers while translating security. When using standard method of translation, the AMT Tools uses its internal database to store mapping between the user from the security principal (user, group or computer) from the source domain and the one from the destination domain, in order to achieve a SID mapping between both.While in most case, the migration can happen in one day, larger organizations may need weeks to achieve migration. It may therefore be an interesting option to backup the ADMT database, just in case of disaster… 

With versions of ADMT earlier than v3, backup was a matter of making sure not one was busy with an ADMT console open and coping the protar.mdb file (a jet-like database). From version 3, ADMT uses MSDE as database engine.

There are therefore basically two methods to back up the database:

You can use an “offline” method by stopping the service MSSQL$MS_ADMT, then copying the files ADMT.mdf et ADMT_log.LDF located under %windir%\ADMT\MSSQL$MS_ADMT\Data\ to a safe place and finally starting the service MSSQL$MS_ADMT again.You can also use an “online” method (well known by DBA’s).

To backup, execute this command: "%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\osql.exe" -E -S %computername%\MS_ADMT -Q"BACKUP DATABASE ADMT TO DISK = 'C:\admt.bak'"

And to restore, execute this one:

"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\osql.exe" -E -S %computername%\MS_ADMT -Q"RESTORE DATABASE ADMT FROM DISK = 'C:\admt.bak'"

Since MSDE is based on SQL2000, it will not support UNC path, only local file system!

And cut!