Replacing an Active Directory Forest NTP server

There should only be one time source in your forest and by default it would be on the first Domain Controller you bring up.  At some point you will need to replace that server with newer hardware.  Just make sure you remember to add the authoritative time source to the new server or another Domain Controller in your forest.  A best practice is to keep the NTP server on a PDC emulator (or if you have a multi domain forest the root domain on the PDC emulator) .

The following MS article (kb816042) explains the proces -> http://support.microsoft.com/kb/816042

To check which server is PDC role holder run netdom query fsmo.

Make sure that below parameters are set correctly on PDC Server.

  1. Change the server type to NTP
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type (default is NT5DS) should be changed to NTP
  2. Specify the time sources.eg time.windows.com,0x1
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer (default is time.windows.com,0x1) should be set to a time source you trust the default should be fine.
  3. Set AnnounceFlags to 5
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags (default is 10) should be changed to 5
  4. Enable NTPServer
    HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enabled (default is 0) should be changed to 1
  5. Restart the windows time service.
    net stop w32time && net start w32time
  6. Run w32tm /resync /rediscover command, which should complete successfully.

Once again please remember there should only be one server in the forest which is marked as a reliable time source.  Please make sure only one Domain Controller has there w32time type set to NTP.

Server 2012 – Add Additional Domain Controller to a 2008 R2 Domain

When you try and run DCPromo from the explorer shell on Windows Server 2012, you will receive the following message “The Active Directory Domain Services Installation Wizard is relocated in Server Manager. For more information, see http://go.microsoft.com/fwlink/?LinkId=220921.”

Dudewheresmydcpromo

No DCPromo, what now?! DCPromo is deprecated in Windows Server 2012, so adding an additional Domain Controller is slightly different than in earlier versions. The new process is still straight forward, and the wizard will even extend the schema (to version 56) for you- meaning it’s a one-stop process. Adding a Windows Server 2012 Domain Controller requires a Windows Server 2003 forest functional level or higher on your existing forest.

Promoting a Server 2012 to a Domain Controller

1. Open Server Manager, select Local Server on the left hand side then choose Manager -> Add roles and Features.

Server2012-DC1

2. Next.

Server2012-DC2

3. Next.

Server2012-DC3

4. Select the server you wish to promote.

Server2012-DC4

5. Tick Active Directory Domain Services.

Server2012-DC5

6. Click Add Features.

Server2012-DC6

7. Next.

Server2012-DC7

8. Next.

Server2012-DC8

9. Install.

Server2012-DC9

10. In Progress.

Server2012-DC10

11. Close.

Server2012-DC11

12. You’ll now notice you have a notification, prompting you to promote this server to a domain controller.

Server2012-DC12

13. We are adding a domain controller to an existing domain, specify the domain and domain administrator credentials.

Server2012-DC13

14. It will make the additional DC a DNS and GC by default, we do not want to make this a Read Only Domain Controller. You have the option to add the DC to a particular Site. Enter your DSRM password (as usual, keep this safe!).

Server2012-DC14

15. You can typically ignore the warning about DNS delegation, a more detailed explanation can be found here: http://technet.microsoft.com/en-us/library/cc754463(WS.10).aspx

Server2012-DC15

16. You can install from Media, which is useful if you are promoting a DC in a branch office with a poor connection- it will significantly reduce the initial Active Directory replication. You can specify a particular DC for the initial replication.

Server2012-DC16

17. Default locations.

Server2012-DC17

18. This screen tells us it will prepare the Forest, Schema and domain for us (Server 2012 uses Schema Version 56).

Server2012-DC18

19. Review screen and option to view the Powershell script.

Server2012-DC19

20. Click Install.

Server2012-DC20

21. The install will tick over and when it has finished the server will be restarted.

Server2012-DC21

Server2012-DC22

The server will now reboot and the promotion is complete.

Windows Server 2008 ADMT 3.1 PES Password Issue

When installing the Password Export Server on a Server 2008 Domain Controller in the destination forest, the following error was encountered entering the password for the .pes file security key that was generated in the source forest:

The supplied password does not match this encryption key’s password. ADMT’s Password Migration Filter DLL will not install without a valid encryption key.

The error that was being generated “the password does not match this encryption key” is bogus, as the password did match. This error was actually being generated by a permission problem to the SAM database caused by UAC (user account control).

To get around this run a command prompt as administrator and launch pwdmig.msi from there. Ensure the command prompt is running as administrator!

ADMT Series – 11. Computer Migration Wizard

This post will cover the process of migrating computers from the source domain to the target domain. After you migrate a batch of local user profiles, migrate the corresponding batch of user workstations.

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, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 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 – 10. Security Translation Wizard – Local Profiles

This post will cover the Security Translation Wizard from the context of migrating local user account profiles into the target domain. This step is crucial if you want your users to maintain the same local profile. The Translation Wizard needs to be run before migrating the computers. If you decide to skip this step, the users will receive a new profile when they logon to the target domain for the first time:

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:

1
OldSID,NewSID

or

1
OldSID,TARGET\USER

or

1
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 – 9. Merging Users with a Different sAMAccountName

Is the last post we looked at a vanilla user account migration, assuming a clean target domain.

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:

1
2
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:

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

From the target domain:

1
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.

1
2
3
4
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:

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

Run after:

1
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 – 8. User Account Migration Wizard

In this post we’ll run through the User Account Migration Wizard to migrate users from the source to target domain. This guide will cover migrating users that do not exist in the target domain, if they do, please wait for the next article which will cover merging user accounts with an include file and/or migrating only the siDHistory attribute (with no other attributes).

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 – 7. Group Account Migration Wizard

Universal, global and domain local groups can be migrated with the ADMT tool. Each group type has different rules for membership, and each group type serves a different purpose. This affects the order that the groups are migrated from the source to the target domains.

 

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 – 6. Service Account Migration Wizard

The Service Account Migration Wizard will identify, migrate and update services that run in the context of a domain user account. ADMT does not migrate services running under the Local System account as they are migrated automatically when the computer is migrated. The Local Service and Network Service accounts are not migrated, because they are well-known accounts that always exist in domains.

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 – 5. Machine Preparation

This post will look at preparing your workstations and servers to work with ADMT and to make sure you give ADMT the correct permissions and connectivity.

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.