Unable to check for failed actions. : DBManager.IManageDB.1 : Cannot open database "ADMT" requested by the login. The login failed.

To resolve this you will need to install the Microsoft SQL Server management Studio, download available here: http://www.microsoft.com/en-us/download/details.aspx?id=7593

Run the installer and select New SQL Server stand-alone installation or add feature to an existing installation.

Choose Add features to an existing instance of SQL Server 2008.

Select Management Tools - Basic (it's greyed out here as I've already got them installed).

Follow the rest of the installation through, when complete run the SQL Server Management Studio and connect to the SQLEXPRESS instance.

Select Security, Logins and choose New login.

Add the account that needs access to the ADMT MMC Console and select Windows Authentication.

You can see the user added, right click and select properties.

Select User Mapping, tick ADMT and give the db_owner and public role membership.

The user will also need to be local administrator on the ADMT machine. You should now be able to open the MMC console.

ADMT Supported Operating Systems for Computer Migration

ADMT 3.2 - supports the migration of computers that run Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

ADMT 3.1 - supports the migration of computers that run Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, and Windows Server 2008

ADMT 3.0 - supports the migration of computers that run Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server, and Windows Server 2003.

Computer Migration

From the ADMT machine, run ADMT and select Computer Migration Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Select computers from the domain or use an include file. This may be quite useful if you're doing an OU at a time as you can export objects of an OU via ADUC (right click -> export list).

Select the target OU.

Choose the objects you wish to translate.

Here you can choose to replace, add or remove the permissions. Add is the safest option and is what I would recommend in most cases.

After the wizard has completed, wait x minutes before restarting the computer. This can typically be set to 0 minutes.

You can exclude particular attributes of the computer here, if needed.

Select Do not migration source object if a conflict is detected in the target domain.

At this stage the computer object will be pre-staged in the target domain, you will be able to refresh the target OU and view the object.

As usual, run the pre-check, then run pre-check and agent operation. Once the Agent operation is complete, the wizard will wait to carry out the post-check. The post check uses a A record in the target domain to contact the machine and remove the ADMT tools. You should see an A record being created on machine reboot.

If you don't, the post-check will fail- this isn't a major issue. As long as you're aware of why it failed. If the A record has not been created you will need to investigate why.

You'll probably get a message in the logs stating:

Admt unable to retrieve the dns hostname adsi property cannot be found in the property cache hr=0x8000500d

Confirmed joined.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

Be aware this process can take some time, I've seen it take up to 40-45 minutes on some older laptops.

Translation Security Wizard - For Local Profiles

From the ADMT machine, run ADMT and select Security Translation Wizard.

Next.

If you have migrated the source domain user accounts, you can select Previously Migrated Objects- this will pull the list of the source and target SIDs from the ADMT database for mapping across the new permissions. This is probably the best method if you have migrated the users across, or if you don't need granular control over the process.

You can use a SID mapping file to link two accounts from the source and target domain. In the migration I recently went through, the accounts had already been created in the target domain, and there was no requirement for SID history. I decided that merging the user accounts wasn't necessary. As I hadn't migrated the users I was unable to use the previously migrated objects option, as ADMT has no history of the account SIDs in the ADMT database. A SID mapping file was used instead.

The SID Mapping file can be in the following formats:

OldSID,NewSID

or

OldSID,TARGET\USER

or

SOURCE\USER,TARGET\USER

For demonstration purposes I have migrated a bunch of users accounts so I can choose the previously migrated objects option.

Select the source and target domain, you can also select which specific domain controller to use.

Select computers from the domain or use an include file.

We will be translating profiles on a Windows XP SP3 test machine.

Choose the objects you wish to translate.

Files and folders - Select this option to translate security on files and folders on the targeted computer.
Local groups - Select this option to translate security on the local groups on the targeted computer.
Printers - Select this option to translate security on the local printers that are configured on the targeted computer.
Registry - Select this option to translate security on registry settings on the targeted computer.
Shares - Select this option to translate security on the shared resources on the targeted computer.
User profiles - Select this option to translate security on the local user profiles on the targeted computer.
User rights - Select this option to translate security on the user rights on the targeted computer.

Here you can choose to replace, add or remove the permissions. Add is the safest option and is what I would recommend in most cases.

Select Finish.

Run the pre-check and make sure it passes, then choose run pre-check and agent operation.

If you click on Agent Detail and View Log you will be able to see what actions have been carried out. We have already migrated the user Ronnie Coleman so we see:

2012-05-19 17:00:36 Translating user profile, source account='Ronnie.Coleman', target account='Ronnie.Coleman'

After the profiles have been translated you will want to migrate the computers straight away.

What happens to the profile?

To show you what's happened I've logged into XP1. You can see that the target user has been granted full permission over the local profile. As we chose the Add option, the source domain user also maintains access.

The migrated user in the target domain has been added to the profile list in the registry, and the profile is pointing to the source user's profile. You can view this under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList.

Target SID / User

Source SID / User

The next part of the series will run through migrating the computer objects and computer domain affiliation to the target domain.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

There may be a situation where the users have already been created in the target domain with a different sAMAccountName. For example, the user Branch Warren might have the sAMAccountName of bwarren in the source domain but branch.warren in the target.

Source

Target

To get around this you can use an include file to map these different sAMAccountNames together when migrating. The include file is in the following format, and if we use the example above would look like this:

Sourcename,TargetSAM,TargetUPN
bwarren,branch.warren,branch.warren@target.local

Creating the Include File

To generate this list you can use CSVDE to pull out the required information from the two forests. The final include file will require a bit of manual preparation to get into the correct format.

From the source domain:

csvde -d "OU=source,DC=source,DC=local" -f sourceinclude.csv -l "sAMAccountName"

From the target domain:

csvde -d "OU=target,DC=target,DC=local" -f targetinclude.csv -l "sAMAccountName, userPrincipalName"

Create the include CSV file in the same format as the example above, I've created three users which I need to migrate and merge with an include file.

Sourcename,TargetSAM,TargetUPN
jjackson,Johnnie.Jackson,Johnnie.Jackson@target.local
jcutler,jay.cutler,jay.cutler@target.local
bwarren,branch.warren,branch.warren@target.local

Once you have this in place, the migration process is very similar to the method outlined in the last blog post. When you are asked to select users, choose Read objects from an include file, specify the Include file you created above.

Clear all check boxes.

When you get to the conflict management screen, choose Migrate and merge conflicting, leave both tick boxes empty.

Click finish, and view log. Here you can see the account being merged, passwords being migrated and sIDHistory completed.

If you open up one of the users, you can see the attributes have been carried across from the source domain user.

Migrating Only the siDHistory

When you migrate users, all attributes are carried across unless otherwise specified. There may be a scenario where the user objects in the target domain need to be kept untouched but siDHistory brought across. You can achieve this with the object property exclusion options. Run through the user migration and tick Exclude specific object properties from migration, select object type User and move all attributes into the excluded properties box.

Run through and finish the rest of the wizard. You can confirm that only the siDHistory has been brought across by running ldifde and comparing the two files.

Run before:

ldifde -f user_before.ldf -d "CN=lee.priest,OU=target,DC=target,DC=local

Run after:

ldifde -f user_after.ldf -d "CN=lee.priest,OU=target,DC=target,DC=local

Winmerge is a pretty handy tool to compare two files, here they are side-by-side:

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

I have created 9 test users in the source domain, which are members of the global security group we migrated in the last series post.

Migrating Users

From the ADMT machine, run ADMT and select User Account Security Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Select users from the domain or use an include file (the include file will be explained in the next ADMT Series post).

I've chosen 9 test user accounts.

Select the target OU.

Select Migrate Passwords, and choose the source DC (the DC which the Password Export Service is install on). If you receive the error: Unable to establish a session with the password export server. The Password Export Services is not running on the source server. Go to the source DC and start the Password Export Server Service.

Tick Migrate Users SIDs to target domain if you require siDHistory.

Enter source domain credentials to add SID history.

You can exclude particular attributes of the user here. By default it will pull across all attributes, such as home address, telephone numbers, descriptions etc... If you want to exclude any of these from being migrated across, tick Exclude specific object properties from migration and select User in the object type box. Move any user properties you want to exclude into the excluded properties box.

Conflict management, if you are unsure if a group with the same name exists in the target domain leave the default setting in place.

Click Finish

If you click view log you can see that the user object and password has been migrated. As we previously migrated the global group, the user has also been added to that.

You can now see the users in the target domain.

Group membership updated.

SID history carried across.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

Universal groups
Universal groups can contain members from any domain in the forest, and they can replicate group membership to the global catalog. Therefore, you can use them for administrative groups. When you restructure domains, migrate universal groups first

Global groups
Global groups can include only members from the domain to which they belong. Create global groups to organize users. Global groups should be migrated second.

Domain local groups
Domain local groups can contain users from any domain. They are used to assign permissions to resources. When you restructure domains, you must migrate domain local groups when you migrate the resources to which they provide access, or you must change the group type to universal group. This minimizes the disruption in user access to resources. Migrate Domain Local groups last.

In this example we will migrate a global security group and a domain local security group which is the member of the global group.

Migrating Global Groups

From the ADMT machine, run ADMT and select Group Account Security Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Select groups from the domain or use an include file.

Select the global groups you wish to migrate.

Select the target OU.

When migrating groups, only tick Fix membership of group and migrate group SIDs to target domain. If you choose Copy Group Members, this will migrate the AD users within the group, you do not want to do that at this stage

Fix membership of group. Select this option to add migrated user accounts to target domain groups if the user accounts were members of those groups in the source domain.

Migrate group SIDs to target domain - Select this option to add the security identifiers (SIDs) of the migrated group accounts in the source domain to the SID history of the new group accounts in the target domain. This option uses a secure connection to the source domain controller.

Enter source domain credentials to add SID history.

You can exclude particular attributes of the group here.

Conflict management, if you are unsure if a group with the same name exists in the target domain leave the default setting in place.

Click Finish

The Global security group should now be migrated to the target domain (with no members).

Migrating Local Groups

Follow the same process as above, but select the local groups you wish to migrate. You'll notice that when you open the Local group in ADUC the Global group you migrated earlier will have been added.

What about the users?

The User accounts will be added to the relevant groups when you perform the user account migration (next part of the series).

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

When you run the Migrate Service Account Wizard, you are asked to select the computers you wish to scan for service account flagging. You can either search for computers on the domain, or provide an include file (text file with new computer objects separated by a line break). The wizard will then deploy the ADMT agent to the selected computers and scan for services running in the context of a domain user account. After the scan is complete, you will be presented with a list of services and service accounts.

The Service Account Migration Wizard doesn't migrate any service accounts, nor does it make any changes to the services running under the computers you choose. It's simply to flag the service accounts in the ADMT database.

To migrate the service account and update the service with the migrated user (in the target domain), you need to run the User Migration Wizard and select the Service Accounts highlighted in the process above. This doesn't need to be done straight away and can be part of the User Migration Process. For this demo I will carry out the complete process so you can see what happens to the services.

This step isn't mandatory, and you would typically only run this against your servers (see the security concerns at the bottom of this post). You may find if you have a small number of servers you would want to do this manually with a re-jig of your service accounts. Or perhaps the target domain has a different policy for service accounts, be that a naming scheme or how they are used.

Identifying Service Accounts

On XP1.source.local I've changed two of the services to run under domain user accounts.

From the ADMT machine, run ADMT and select Service Account Migration Wizard.

Select the source and target domain, you can also select which specific domain controller to use.

Choose Yes, update the information.

Select computers from the domain or use an include file.

Select the computers you wish to identify service accounts on.

Run the pre-check, it should Pass fairly quickly- if it fails it's normally a permissions issue, so check your permissions on the source machine.

Once the pre-run has been checked and passed, run the pre-check and agent operation.

Once it's successful you can view the agent detail and log, here we can see it listing the services and service users.

The Accounts Marked as Service Accounts are shown.

Finish. The accounts chosen are now marked in the ADMT database as Service Accounts.

You can view the flagged Service Accounts under the Services Table in the ADMT Database.

Migrating the Service Accounts and Updating the Service

This doesn't have to be done straight away, it can also be part of the main user migration progress.

Run the User Account Migration Wizard in ADMT

Choose the source and target domain.

Select the service account users from the domain or include file.

Select an OU for the service user accounts to be migrated to.

Choose Generate complex passwords, you will be unable to migrate the password as the account as been flagged as a service account.

Keep the default settings.

Provide administrative credentials.

Make sure only Update user rights is ticked.

You can exclude particular attributes of the user object here.

Conflict management, if you are unsure if a user with the same name exists in the target domain leave the default setting in place.

As the user account has been flagged as a service account you will get the option to migrate all service accounts and to update SCM (service control manager).

Select Finish.

View the migration progress, once finished you can view the log. Check for any errors. Select Close.

You can see that the service account user has been migrated into the target domain.

The service has been updated with the migrated service account.

Before:

After (we only migrated the ServiceAccount user):

Security Concerns

The Service Migration Wizard never migrates passwords into the target domain, instead they are given clear-text passwords which enables ADMT to configure and update the services after the services account migration. An encrypted version of the password is stored in the password.txt file within the ADMT installation directory.

It is recommend that you only migrate service accounts on servers that trusted administrators manage. The reason for this is that an administrator of a workstation or server can install a service and configure it to use any domain account. A malicious user could configure a service to use a privileged domain user account with an incorrect password, after the service account is migrated a new password would be generated and the service account updated with the migrated user and correct password allowing the service to run.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

Local Administrators Group

The ADMT Migration Account that you use to migrate workstations and member servers must have local administrator rights in the the source domain. If you don't the ADMT agent cannot be deployed which will result in errors such as:

ERR2:7006 Failed to install agent on \\xp1.source.local, rc=5 Access is denied.

ERR2:7674 Unable to determine the local path for ADMIN share on the machine 'xp1.source.local'. rc=-2147024891

We'll look at two ways to achieve this with group policy.

Method 1. Restricted Groups

Create a Domain Local Security Group in the Source Domain, add the ADMT Service Account (ADMTUser in my case) to the group. You may decide to simply add the domain admins group from the target domain, as this includes the ADMTUser account. Also the Domain Admins group will get automatically added when the computers are migrated. The end result is the same though.

Create a new GPO and link it to the OU with the computer objects in.

Give it a name.

Dig down to Restricted Groups under the Computer Configuration.

Add the ADMT Admin Local Security group you created earlier.

Under This group is a member of: select add, type Administrators.

This is how it should look in the end.

Now if you run a gpupdate /force on a computer object within the OU you've applied the GPO to you should see the ADMT Admin group added.

Method 2. Net Localgroup

Another way to add the group or user to the local administrators is to use the Net local group command. This will run under the user context, so the users must already be local administrators on the machines for this to work.

Create a batch file with the following and deploy it to an OU containing users. It's a bit of a dirty method but it works.

Format: net localgroup administrators "targetdomain\user-or-group" /add
Example specific: net localgroup administrators "target\ADMT Admin" /add

Windows Firewall

Firewalls, such as Windows Firewall in Windows XP Service Pack 2 (SP 2 or above), can prevent the Active Directory Migration Tool (ADMT) computer account migration from completing. Microsoft recommend for any migration tasks that use agent deployment and where Windows Firewall is in use, enable the File and Printer Sharing exception.

Personally I recommend disabling the firewall completely for the migration via group policy.

Create a new group policy object (as above), again linking it to the OU containing computer objects.

Dig down to the domain profile under the computer configuration, set Windows Firewall: Protect all network connections to disabled.

This covers the basic preparation required for ADMT run.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

Migrating Password Prerequisites

Before you can migrate passwords, you will need to install the password export server onto a domain controller in the source domain.

Download the tool here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10370

Before you go ahead and install PES onto a DC in the source domain you need to create an encryption key from the machine running ADMT in the target domain. In our case this is ADMT.target.local. From the command prompt run:

admt key /option:create /sourcedomain:source.local /keyfile:"c:\PES Key\PES.pes" /keypassword:*

Now head over to a DC in the source domain (AD01.source.local) and download and run the PES installer. When prompted choose the .key file you created on the ADMT machine.

Provide the password you used when creating the key.

ADMT provides the option to run the PES service under the Local System account or by using the credentials of an authenticated user in the target domain. It’s recommend that you run the PES service as an authenticated user in the target domain.

The installation is now complete, you will need to restart the domain controller.

For Password migration to work, you will need to manually start the Password Export Server service. You should only start this service when you are running through the User account migration, when you have finished, stop this service.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

To improve the security of this external trust, security identifier (SID) filtering is enabled. However, if users have been migrated to the trusted domain and their SID histories have been preserved, you may choose to turn off this feature.

What is SID History

SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain you will have the option to migrate the users SID to the target domain. This becomes the sIDHistory attribute under the new user object.

Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.

SID history can be used for roaming user profile access, certification authority access, software installation access and resource access.

To visualise this I've created a user called Ronnie Coleman in the source domain and run dsquery to display the user's SID.

dsquery * -filter "&(objectcategory=user)(samaccountname=ronnie.coleman)" -attr objectsid

Here is Ronnie Coleman's SID in the Source Domain:

If we use ADMT to migrate Ronnie Coleman to the target domain and migrate his SID from the source domain you will see both the new SID, and the sIDHistory from the source domain.

The actual process of migrating the sIDHistory will be shown in the Migrating Users part of the series, this post is simply to explain what SID History is and why you would use it in your migration.

In Action

On DC1.source.local (source domain) I have shared a folder called Ronnie Coleman, on which only Ronnie.Coleman@target.local can access. I've then migrated Ronnie.Coleman@target.local to the target.local (target) domain and migrated the SID (as above).

Ronnie.Coleman@target.local has logged onto the AD1.target.local (target domain) and attempted to access the file share with SID Filtering still enabled, as you can see- access is denied:

After SID filtering has been disabled (and Ronnie has logged off and back on) he is granted access, despite his user account not being directly in the NTFS permissions. SID History has allowed Ronnie.Coleman@target.local access to the resource.

How to Disable SID Filtering

If you choose to utilise SID history you will need to disable SID filtering. Run Netdom as a domain or enterprise administrator from the target domain.

External trust: Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd

In our test bed, source.local (source) is trusting target.local making it the trusting domain.

If you are using a Forest trust, the command is slightly different:

Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes /usero:domainadministratorAcct /passwordo:domainadminpwd

Security Concerns

Disabling SID filtering requires a level of trust between the two forests, and ultimately those who are responsible for Active Directory. With SID Filtering disabled, a rogue domain administrator could clone a SID from the other domain and add it to their SID History, granting them unauthorized rights.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

ADMT requires a preconfigured instance of SQL Server for its underlying data store, so we'll go ahead and install SQL 2008 SP1 Express on ADMT.target.local.

Installing SQL Express 2008 SP1

SQL Express download here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25052

1. Choose New Stand-alone installation.

2. Select Database Engine Service.

3. Accept the default named instance.

4. Set an account for the SQL service to run under (use your ADMT Service Account).

5. Set a SQL administrator, choose the user account you plan to run ADMT under- be aware that this user account will need to have local administrative rights in the source domain (this will be discussed further in the series).

Installing ADMT

For this series I will be using ADMT 3.2, which is the supported version for Server 2008 R2. Use ADMT 3.1 for installation on a Server 2008 non-R2 server, or ADMT 3.0 for Server 2003. If you need to migration a Server 2000 Domain, you will need to use ADMT version 3.1 or earlier. The requirements are explained in the links below:

ADMT 3.0: http://www.microsoft.com/download/en/details.aspx?id=17488
ADMT 3.1: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17918
ADMT 3.2: http://www.microsoft.com/download/en/details.aspx?id=8377

Run the ADMT setup file, and enter the named instance we created earlier.

Here is the ADMT MMC, ready to go.

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

After recently using ADMT for an Active Directory migration I thought I'd write a series to document its use and to share any useful tips I found along the way. This first post will explain how to prepare the Active Directory for the migration process.

If you've found this blog post you're probably already aware of what ADMT is and what it can be used for, and I'd suggest (as always) to read the documentation provided by Microsoft. The user guide for ADMT can be found here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=19188

Series Test bed

In this Series I'm going to be using 3 servers and an XP client.

Server 1 AD1 - Target Domain Server 2008 R2 Domain controller in the target.local domain
Server 2 ADMT - Target Domain Server 2008 R2 Member Server running ADMT in the target.local domain
Server 3 DC1 - Source Domain Server 2003 Domain controller in the source.local domain
Client 1 XP - Source Domain Windows XP client in the source.local domain

The goal of this series will be to migrate from the 2003 source.local Domain to the 2008 R2 target.local domain.

Preparing Active Directory

In this post we'll look at preparing Active Directory for the migration process. There are two main things to prepare, DNS and a domain trust.

Before the domain trust can be created both domains will need to be able to resolve each other via DNS. To achieve this you can use stub zones, secondary zones or forwarders. I'll show you how to setup forwarders below on Server 2003 and 2008 R2. When using forwarders you need to manually populate the IP(s) of the name servers you'll be using for resolution, if for whatever reason these change you will have to manually go back and change the forwarder. This probably isn't an issue for most scenarios.

Setting up a Server 2008 R2 DNS Forwarder

1. Open the DNS MMC console, expand the server tree and select Conditional Forwarders. Right click and select new conditional Forwarder.

2. Enter the other DNS domain name (the source domain in this case), then click below where it says "Click here to add" and enter the IP address of on the DNS servers in the other domain. Press enter. If you have multiple DNS servers in your Active Directory it's a good idea to store the conditional forwarder in AD, and replicate it accordingly.

Before the forwarder:

After the forwarder:

Setting up a Server 2003 DNS Forwarder

1. Open the DNS MMC console, right click on the server and select properties.

2. Select the 2nd tab along titled 'Forwarders', new, enter the other DNS Domain (the target domain in this case) and click OK. With the Domain selected enter the IP address of one of the DNS servers in the other Domain and select Add.

Setting up the Domain Trust

The trust will be created completely on AD1 in the Target.local domain.

1. Open the Active Directory Domains and Trusts, right click on the domain and click properties.

2. Head over to the Trusts tab and select new trust.

3. Enter the DNS domain name of the other Domain.

4. Choose External or Forest trust, to setup a forest trust both domains will need to be at a 2003 Forest Functional level or higher. As we're dealing with two single domains an external trust is fine.

5. We'll use a two-way trust.

6. To setup both sides of the trust from the target domain you will need domain administrator credentials for the source/other domain.

7. Domain-wide authentication.

8. Confirm both the incoming and outgoing trusts.

I will cover SIDHistory in the next blog post, so we can ignore this for now.

Here we can see the trust in place.

Suffix Search List

Now that we have the forwarders in place in the source and target domains, clients from either domain should be able to resolve FQDNs from the other. However you will want to add the source/target domains suffix to the suffix search list, allowing simple, single-label names resolution.

On the Server 2008 R2 server, open Group Policy Management in Server manager, right click on the level you want to apply the policy to and select Create a GPO in this domain, and link it here... We'll call our GPO Trust - Suffix.

Dig down to Policies -> Administrative templates -> Network -> DNS Client. Set the Primary DNS Suffix to the current domain, so in the Target.local domain we'd put this was Target.local. Then enable the DNS Suffix Search List policy, add the current domain first, then add the other domain- seperated with a comma.

In the Server 2003 domain you can either add the policy via ADUC or via GPMC (http://www.microsoft.com/download/en/details.aspx?id=21895). The settings are in the same place.

We can see the policy applied when we run an ipconfig /all. The clients will now append the primary suffix first, then try the additional suffixes found in the suffix search list.

ADMT Migration Account

The account you run ADMT under will need to have administrative rights in both the source and target domain. You may decide to create a user specifically for the ADMT Migration, or you may use an existing user e.g. the default administrator account. I will create a user called ADMTUser and assign this user the correct permissions. This is the account we will use for the entire migration.

It is recommended that you make the user account in the target domain and make it a member of the domain administrators group.

Target Domain:

In the source domain add the same user to the builtin administrators group (you will be unable to add it to the domain administrators group).

Source Domain:

ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine
ADMT Series – 3. SID History
ADMT Series – 4. Password Export Server
ADMT Series – 5. Machine Preparation
ADMT Series – 6. Service Account Migration Wizard
ADMT Series – 7. Group Account Migration Wizard
ADMT Series – 8. User Account Migration Wizard
ADMT Series – 9. Merging Users with a Different sAMAccountName
ADMT Series – 10. Security Translation Wizard - Local Profiles
ADMT Series – 11. Computer Migration Wizard

I'm having some Active directory issues, where do I start?

I see these questions asked a lot, and talking someone through some basic troubleshooting steps without having physical/remote access can be fairly time consuming. For that reason I've put together a script to collect basic information about the domain controller the script is run on and active directory itself- which is then written to a log file.

The log file is saved onto the current users desktop by default. If you want to save the log file to a share you'd use:

set logfile=\\server\share\ADHealth\ADHealth.txt

So, what does it do?

System Boot Time - systeminfo | find "System Boot Time:" - Displays boot time, not massively helpful or directly tied with Active Directory but still worth being aware of the last start-up time.

TCP/IP network configuration - IPCONFIG /all - Displays all current TCP/IP network configuration values. This is normally helpful to highlight any DNS server misconfiguration. For example setting them to external public resolvers.

DCDIAG /a - The meat and potatoes, there's a great article on what it actually does here: http://blogs.technet.com/b/askds/archive/2011/03/22/what-does-dcdiag-actually-do.aspx. This is currently set to test all domain controllers (/a), you can get more verbose with /v, but I quite like the initial log to be succinct.

Repadmin /replsummary - Will show you an overview of any failures, and for which DC(s). http://technet.microsoft.com/en-us/library/cc835092%28v=ws.10%29.aspx

Repadmin /showrepl - This will let you know if the last replication attempts where successful. http://technet.microsoft.com/en-us/library/cc742066%28v=ws.10%29.aspx

NETDOM Query FSMO - This will return the FSMO role holders, which can be used to confirm that the role holders are still online and functioning. A good article on FSMO roles and what happens if one of them fails can be found here: https://msmvps.com/blogs/acefekay/archive/2011/01/16/active-directory-fsmo-roles-explained.aspx

Nslookup -querytype=srv _gc._tcp.%domain% - Displays all Global Catalogs.

The batch file

You can copy and paste it into your own batch file or download it from here. If you're running it on a DC prior to Server 2008 you will need to install the Adminpak: Windows Server 2003 Service Pack 2 Administration Tools Pack (adminpak)

@Echo Off
ECHO Running AD Health Checks - Notepad will open after completion
ECHO You can share this log using http://pastie.org/pastes/new
ECHO This Command Prompt will close after you close Notepad
ECHO http://blog.thesysadmins.co.uk
set logfile=%userprofile%\Desktop\ADHealth.txt
echo You can share this log using http://pastie.org/pastes/new > %logfile%
echo. >> %logfile%
echo. >> %logfile%
REM Finds system boot time
echo System Boot Time ------------------------------------------------------------- >> %logfile%
systeminfo | find "System Boot Time:" >> %logfile%
systeminfo | find "System Up Time:" >> %logfile%
echo. >> %logfile%
echo. >> %logfile%
REM Displays all current TCP/IP network configuration values
echo IPCONFIG ------------------------------------------------------------- >> %logfile%
ipconfig /all >> %logfile%
echo. >> %logfile%
echo. >> %logfile%
REM Analyse the state of domain controllers in a forest and reports any problems to assist in troubleshooting
echo DCDIAG ------------------------------------------------------------- >> %logfile%
dcdiag /a >> %logfile%
echo. >> %logfile%
echo. >> %logfile%
REM The replsummary operation quickly summarizes the replication state and relative health
echo Replsummary ------------------------------------------------------------- >> %logfile%
repadmin /replsummary >> %logfile%
echo. >> %logfile%
echo. >> %logfile%
REM Displays the replication partners for each directory partition on the specified domain controller
echo Showrepl ------------------------------------------------------------- >> %logfile%
repadmin /showrepl >> %logfile%
echo. >> %logfile%
echo. >> %logfile%
REM Query FSMO roles
echo NETDOM Query FSMO ------------------------------------------------------------- >> %logfile%
netdom query fsmo >> %logfile%
REM Query Global Catalogs
echo List Global Catalogs ------------------------------------------------------------- >> %logfile%
for /f "tokens=2" %%a in ('systeminfo ^| findstr Domain:') do set domain=%%a
nslookup -querytype=srv _gc._tcp.%domain% >> %logfile%
notepad %logfile%

Run the batch file, when it has completed notepad will open with the freshly created log. If you need to share this log with someone I suggest using pastie.org, and pasting the (redacted) document.

You may just want to run this as a one off when troubleshooting, or you may want to add this to a scheduled task (If so I'd remove the notepad %logfile% line off the end). This can be useful for comparisons and to outline when the error(s) / issues began. If your Active directory currently running like a dream, why not take a baseline log...

This script should give you a starting point for diagnosing some of the more common Active Directory issues. I recommend getting familiar with the tools included in the script, learning how to read and make sense of the information and to be aware of other parameters available.

Apple iPhone syncing contacts with Microsoft Exchange server

The Issue

New contacts default to the "On my iPhone" contact group, which aren't synced with the Exchange account. This could cause contact loss when upgrading or switching iPhones, or will cause missing contacts on multiple devices e.g. iPads. I came across this earlier when someone mentioned their upgrade had missing contacts (turned out to be over 40). iOS version 5 seems to set Exchange as the default contact group, I believe this effects iOS 4 and below. You can change it in this location:

Settings -> Mail, Contacts and Calendars -> Contacts - Default Account

The Solution

There are a few paid apps that can move contacts across the groups, or another popular solution is to "share" the iPhone contact and email it to yourself, from there you can save it as a contact in the right group. After a bit more digging I stumbled across Orbicontact which was free and has the functionality needed.

OrbiConact - iTunes

The contacts should now appear in Outlook and/or the new iPhone.