The problem is, if you want to change these settings, you will have to do it on all your servers ONE BY ONE.

A better way to solve this problem for all of your servers at once is by setting up a Group Policy:

• On the domain controller, open “Gpedit.msc”
• Go to: Computer configuration / “Windows settings / Security settings / Event log
• Set “Retain Security log” (or whatever log you want to set) to the desired number of days
• Set “Retention method for security log” to “Overwrite events by days”.

Of course, you will apply this policy to the Organizational Unit your servers are in.

Therefore, you have to install the TS Client Access Licenses (CAL) to a new machine, typically one of the DCs of your new domain.

Beforehand, make sure you have:

• a connection to the Internet
• your Windows Server CD
• your activation codes for the Terminal server licenses.

Here are the necessary steps:

• On the designated machine, install “Terminal Server Licensing” (very easy: Control Panel / Add or remove programs / Windows components);
• Choose (typically) “Your Domain or Workgroup”;
• Leave the default license database location to “C:\WINDOWS\System32\LServer”;
• (Make sure you have your Windows Server 2003 CD inserted) Finish;
• Once the component is installed, go to “Administrative Tools / Services” and restart the “Terminal Server Licensing” service;
• Again, go to “Administrative Tools” and run ” Terminal Server Licensing”: you will see your server as “Not Activated”;
• Right-click on the server name and choose “Activate Server” from the menu. Then press “Next” and choose “Automatic connection”;
• Insert your company data, then go ahead until you can “Start Terminal Server Client Licensing Wizard now”;
• Insert your activation codes.

It is not over: on Terminal Servers, you have to point to the new license server in order to make them work:

• On the TS, go to Administrative Tools / Terminal services configuration;
• Server settings / License Server discovery mode / Use these license servers;
• Specify the name of the license server.

These ensure that you can REALLY disable Autoplay.

In an Active Directory environment, you can use a group policy to enforce autorun settings:

• Start / Run “gpedit.msc” to open Group Policy Editor
• “Computer Configuration”
• “Administrative Templates”
• “System”
• “Turn off Autoplay”
• Select “All drives”.

To be even safer, you should also prevent the creation of “autorun.inf” files by not giving  anyone “Create” rights to the root of mapped network drives. Users should only be able to write inside subdirectories, not to the root directory.

Be careful as administrators too… and don’t forget to choose a good antivirus software.

This profile information should be deleted from the Terminal Server after the user logs off (this is not the default).

The most effective way to delete the cached profiles is to put all of the Terminal Servers in an Active Directory container and apply a specific policy to them that deletes all cached profile information on logging off.
In this case, the policy setting is: “Computer Configuration / Administrative Templates / System / User Profiles / Delete Cached Copies of Roaming Profiles”.

Here comes the nasty part: in some circumstances, something (a sharing violation error, it seems) prevents some “index.dat” files from being deleted at logoff, hence the user’s directory is not removed.
The next time the user logs on, a new directory is created on the TS, typically named C:Documents And Settingsusername.domain. This one too does not get deleted at logoff, so the next logon will create an additional directory, named C:Documents And Settingsusername.000. And so on, username.001, username.002, ad libitum.

Guess what? This issue happened to me after the installation of a Single Sign-On software (that I will not mention).

So what do we do?

I went looking on the Internet, found LOTS of documentation about it, installed many hotfixes and updates and so on… but nothing seemed to work.

At last, after A LOT of struggling, that was the solution:

• Download the UPHClean utility installer (Microsoft User Profile Hive Cleanup Service) from here. You will learn the long story of this bug…
• Run the setup (which installs a service)
• After that, open RegEdit and modify the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesUPHCleanParametersSHARING_VIOLATION_REMAP and set it to 1.
• Reboot
• Hope for the best. It worked for me.

Alas, we found that this causes the user to lose his settings and bookmarks.
Particularly important are proxy server settings (see related article on how to configure proxy settings for all users on a TS). Settings in the user’s  roaming profile are right, but they do not work once the user is logged on the TS. Settings in the “all.js” file are also ignored.

So, here is the solution:

• Open the user profile folder (typically, networkshareprofilepath$username.domainnameApplication DataMozillaFirefoxProfilesrandomname.default
• Rename the file “places.sqlite” to “places.sqlite.bak”
• Rename all “.json” files in the “bookmarksbackup” subfolder to ”.json.bak”
• Restart FireFox. Data are now migrated from Firefox 2.x to 3.x format.

This should be performed for every migrated user… of course, not a desirable situation.

The best way to work is to migrate all TS users first, and then upgrade Firefox on the new machine (when all users are all logged off, of course).

As an alternative, upgrade Firefox both on the old and new Terminal Servers (in order to convert users data from the old format), and then migrate users.

1 – Syncing PCs with the Domain Controllers

Luckily, we can synchronize all PCs in the domain with the domain controllers. In order to do that, we have to define a policy on the Domain Controller.

• Open your domain default policy (I assume that you already know how to use Policy Editor, and that you already have some policy in place) and navigate to:
  - Computer Configuration / Administrative Templates / System / Windows Time Service / Time Providers
• Set both “Enable Windows NTP Client” and “Enable Windows NTP Server” options to “Enable”
• Open “Configure Windows NTP Client”: set to “Enable”, and set it this way:
  • NtpServer: the name of your domain (i.e. “domainname.net”)
  • Type: NT5DS
  • CrossSiteSyncFlags: 2
  • ResolvePeerBackoffMinutes: 15
  • ResolvePeerBackoffMaxTimes: 7
  • SpecialPollInterval: 3600
  • EventLogFlags: 0

Save and close.

On PCs, in order to check if the time provider works, just open a command prompt and type:

net time

You will get an aswer like:

Current time on \DOMAINCONTROLLER is ...

This means that the PC is correctly syncing its time with the domain controller.

2 – Syncing the Domain Controllers with an external timeserver

We also have to make sure that the domain controllers themselves are in sync with a time server: in brief, we will configure EVERY Domain Controller in order to get in sync with “pool.ntp.org” (or another time server of our choice).

These are the necessary commands we have to type in a command prompt on every domain controller (I will not comment them as they are pretty straightforward):

w32tm /config /syncfromflags:MANUAL /manualpeerlist:pool.ntp.org,0x8
w32tm /config /update
w32tm /resync
net stop w32time && net start w32time
net time /querysntp

That’s it. Not difficult, but not very well documented too…

When migrating users to a new domain, you will have to tell them about the “change”.

On Microsoft’s ADMT Migration guide, it is advised to create an “end-user communication plan”…

“… to ensure that they understand their responsibilities, the impact of the migration, and who to contact for help and support.
… If your organization maintains an intranet, publish the account migration schedule and the information contained in the user mail or on an easily accessible Web page.”

Well, try that: they will never understand what a domain is, why it is there, and what the hell you are doing to their computers. Instead:

• they will think that you are doing something that messes up their computer
• they will “feel” that their computer is slower
• every small problem that they will have in the future will be ascribed to the migration.

A fixed public schedule makes little sense too. You will never be able to follow the schedule, for one reason or another.
You too have other things to do, often unpredictably.

Be flexible, and perform the computers migrations when you can. Sometimes a big batch, sometimes a single PC.
Don’t ask users when they are ready; don’t fix a date, they will be busy right then. Just avoid known busy days (at the end of the month, typically), and avoid calling late in the afternoon.

In my experience, it is better to tell the users that you are doing a “small maintenance operation“.
Call them and tell them you need their PC for a few minutes for a routine task.
If they tell you they’re really busy (very rare), don’t insist, and try later.

If they ask you what you are doing (very rare too), tell them… They won’t understand.

But, in general, they don’t want to hear about technicalities. Users just want their printer to work.

You can do everything remotely, if you use some remote control software:

• just call the user, he/she will be glad to take a tour to the coffee machine
• connect to his/her/their computer (yes, you can do more computers at once) and change the “Administrators” group
• launch the computer migration in ADMT, and wait until the computer reboots
• reconnect, logon to the new domain (remember? you forced the account password after its migration)
• test quickly if everything works (just network shares is enough, if you tested your first users well)
• call the user again and tell him to change his password. Done!

By the way: user accounts can be migrated long in advance, if their groups don’t change. So, you can prepare a batch of users, migrate them, and then call them when you want to migrate their computers.

You can also show up in their office (even for some other reason) and perform the migration for the whole office: connect to the DC via Remote Desktop, run ADMT, and wait for the office computers to reboot.

You can migrate a whole office (say, 6-7 people) in 15-20 minutes. Don’t underestimate the power of the coffee machine.

Even better, if you have to perform some intervention on a PC for other reasons (software installation, upgrades, other problems, whatever) just migrate the PC without telling the user. Just tell him you had to reset his password, and make him enter a new one. He will never notice the difference (that is, the new domain name in the logon screen: just two people out of 165 noticed that).

Remember: the more publicity you give to the migration, the more it will perceived as a problem.

Just make sure you solved all the problems on your first test users:

• Of course, begin the migration with a test user you created. Copy your account: you can freely mess with shares, rights, scripts, and so on, until you get it straight (be careful anyway!)
• Migrate your IT colleagues first: they usually understand what is going on, they will usually be patient and provide you with a lot of feedback and help. They will often have to fix things on their side.
• After the whole IT department has migrated successfully, migrate some (non-IT) friend colleagues telling them that they are guinea pigs and you want feedback from them.
• If you choose your first users well, 90% of the problems rise (and can be solved) very early, and the rest of the migration will be fairly straightforward.

If there is some group who uses some peculiar software you don’t know well, follow the same pattern: migrate only one user (choose with intelligence), and only migrate the rest of the group after he confirms that everything is running smoothly.

I repeat: make sure you solved all the problems on your first test users.

In order to migrate a PC, we will have to perform the following steps:

• Add the “TARGETadmin” user to the the local “Administrators” group of the PC:
  right click on My Computer / Manage / Users and local groups / Groups / Double click on Administrators / Add / Select the target domain and type “admin” / OK
• Check that the “Remote Registry” service is running on the PC
• Deactivate hybernation, sleep and such things (we don’t want to have the PC turned off in the middle of the migration process)
• Disable firewall and antivirus on the PC (remember to enable them again after the migration!)
• From the target DC, we must check that the following share: “computer.source.netADMIN$” is reachable (“computer” is the name of the workstation we are about to migrate, of course). If it does not work, check the previous steps again. In extreme cases, it will only work if we enable “File and printer sharing” in the network connection properties of the PC.
  It is not a good thing, though. If you do it, disable it again after the migration.

Now, the actual migration process takes place on the target domain DC:

• Run ADMT / Action / Computer migration wizard
• Domain selection / Select the source domain and the target domain and the relative DCs
• Computer Selection / Select computers from domain / Add / select the computers to be migrated
• Organizational Unit selection / Select the OU of destination
• Translate objects / Select ALL
• Security translation options / Add
• If , God forbid, we get the following error message: “The Active Directory Migration Tool cannot look up the SID for domain”, it means that the trust relationship has become corrupted, and we need to destroy it and create it again from scratch.
• Computer options / select “1 minute before restart after wizard completion” (it is crucial that the computers performs an immediate reboot after the migration process!)
• Object property exclusion / (nothing)
• Conflict management / Do not migrate source object if a conflict is detected in the target.

After the process completes, we will close the wizard window. The process is shown in a “Migration progress” window. When the migration has completed and we close this window, a new window will open automatically, the “ADMT Agent Dialog”:

Call the (human) user to ensure that he stops working and closes all open applications, and warn him that the computer will reboot shortly and his password will be reset to a default value (see above the “Account Migration” paragraph).
Of course, make sure you reach an agreement with him before you start… I will write another post about user interaction.

• Select “Run pre-check” (default) / Start (we expect to see “Passed” after the check: if it does not work, check again the above mentioned pre-requirements).
• If the pre-check passes, select “Run pre-check and agent operation” and then “Start” to “translate” the PC ACLs, etc.
• This operation will last a while, typically 10-15 minutes.
• The selected computer will be restarted automatically after the preset lapse of time (1 minute after completion, in our case. A message window will warn the user, counting down the time to reboot.

After the reboot, we will SELECT THE NEW DOMAIN from the dropdown of the password dialog, and LOGON TO THE NEW DOMAIN (old user name, default forced password).
I repeat. IMPORTANT: reboot the machine, and log on immediately to the new domain. Do not log on the source domain again, or you will encounter problems.

Once logged on, we have to check that everything is working properly:

• the user has access to all his network shares
• printers are working correctly
• internal Web applications are working correctly (there could be authentication problems: check the web applications authentication method. Check DNS configuration also: sometimes “ipconfig /flushdns” or a reboot is enough)
• other applications work correctly: email, single sign-on procedures, proxy access to the Internet, etc.

After the check, tell the user to change his password immediately.

1. Service accounts
2. Global groups
3. Users accounts (keeping SID history)

1. Migrating service accounts

We already identified them in the previous step, now we need to migrate them.
Sometimes, some problems arise:

• “normal” accounts are used as service accounts
• services are run under the default administrator account (bad!)
• the password of the service accounts is unknown (it might have been forgotten and not documented anywhere).

Therefore, we can’t always “isolate” service accounts to migrate them. We should FIRST fix the inconsistencies we find, and THEN migrate the accounts.

The process would be the following:

• Run ADMT (as we have already seen before, as “admin” on the target)
• Action / User Account Migration Wizard
• Domain selection / Select source and target domains and relative DCs
• User Selection / Select users from domain / Add / Select the accounts from the source domain
• Organizational Unit selection / Select the target OU
• Generate complex passwords: they are saved in the file “C:WINDOWSADMTLogspasswords.txt”. We will force them later on.
• Enable target accounts / Migrate user SIDs to target domains
• Insert the credentials of the source domain administrator (“admin”, in our case)
• Select ONLY “Update user rights”
• Exclude specific objects: skip it
• Do not migrate source object if a conflict is detected in the target
• Select the accounts to be migrated (they could appear more than once, if several services are run by the same account)
• Migrate all service accounts and update SCM for items marked include

Check that:

• The log does not contain errors
• The service accounts have been created in the target OU
• The applications based on these accounts are still working correctly

IMPORTANT: we will face some problems migrating users (both service accounts and “regular” accounts):

• If we are migrating to a child domain (like “target.root.net”), looking at the properties of the migrated user (AD Users and computers / right click on the user / Properties / Account tab) we can see that the “domain” field is “@root.net” and NOT “@target.root.net“. This is very strange, but easy to solve: just open the dropdown list and select the right domain. (This can also be done on multiple users, selecting them all and then changing the property.)
• The “Change password at next logon” option is active (this option can be changed for all users too)

Therefore, immediately after the migration, we have to remember to change the “domain” field of the migrated users, and reset their passwords to a default. We will tell the users, and ask them to change it immediately after their first logon.

2. Migrating global groups

We must migrate global groups BEFORE migrating the users! (Warning: do not migrate the groups in peak hours because a lot of network traffic is generated).

• Run ADMT / Action / Group Account Migration Wizard
• Domain selection / Select source and target domains / DCs (they should be already saved since the first migration)
• Select groups from domain / Add / Add the group(s) to migrate. (You should have “Security groups” separated from “Application groups” for better management: but this is another topic…)
• Select the target OU (having separate Security/Application OUs is better)
• Select ONLY “Migrate Group SIDs to target domain”
• User Account (provide source domain admin credentials – now it’s becoming repetitive)
• Object exclusion (leave to defaults)
• Do not migrate source object if a conflict is detected in the target
• Check the log for errors, and that the migrated groups are in the right OUs.

We will migrate all groups.

3. Migrating user accounts (maintaining SID history)

Here we will completely ignore the instructions of the ADMT manual, and use a much simpler way. Migrate a batch of user accounts, or a single test account first. This will work almost exactly like the migration of the service accounts.

The ideal way is to do the next steps for one user, and then one PC: after all issues are solved, we can repeat the process to migrate all the other users in batches, at will. (If something goes wrong, we can easily roll back: more about rollback in a future post).

The migration of user accounts will happen in three phases:

- Phase one: account migration

• ADMT / Action / User Account Migration Wizard
• Select source / target domains and DCs (you should already be familiar with that)
• Select users from domain / Add / Select (type) the source domain user account to migrate
• Select the OU of the target domain where the users will be migrated
• Do not update passwords for existing users / Generate complex passwords (you will later reset them to a default)
• Enable target accounts / 90 days until source accounts expire (to be safe) / Migrate user SIDs to target domain
• Provide source domain admin credentials
• Select “Translate roaming profiles” and “Fix users’ group memberships” / uncheck “Update user rights” and “Migrate associated user groups”
• Uncheck “Exclude specific object properties from migration”
• Do not migrate source object if a conflict is detected in the target
• Check the log for errors, and that the users have been created in the right OU
• Check if the users have retained their groups
• Force the password of the migrated users to some default (something like “password” will be OK)
• If your target is a child domain, change the domain of the migrated users from “@root.net” to “@target.root.net” (see above).

- Phase two: policy migration

Now, we have to migrate the policies (GPOs) from the source to the target domain, in order to apply them to the users (and to the PCs we will migrate later).

Of course, this step will only be performed once: when the policies are in place we will not need to touch them. We have to insure that they work before migrating all the users, so we need to test them thoroughly with the first migrated test user.

• Open the console “gpmc.msc” on source domain (source.net)
• Add the target domain to the console: right click on “Group policy management” / Add forest / write the domain’s name (target.root.net). Obviously, a trust relationship must be in place between the two.
• Simply duplicate GPOs from one part to another. It is much like copy and paste.

Very easy.
Of course, we will have to make some modifications to policies:

• Copy the logon/logoff scripts from the source domain to the “domaincontrollerNETLOGON” directory of the target
• Modify the policies in order to specify the new position of the scripts
• Change the scripts in order to account for the new environment (drive mappings, etc.)

- Phase three: Computer migration

This will be discussed in the next post…

• Creating the trust relationships between the two domains/forests
• Creating the necessary “migration accounts”
• Setting up source and target domain for SID history migration
• Creating the OU structure in the target domain
• Installing ADMT in the target domain
• Identifying the “service accounts”

IMPORTANT: in the next examples, we will call “admin” the domain administrator accounts used, “source.net” the source domain, and “target.net” the target domain.
If we have a root domain, it will be called “root.net“, and the child will then be “target.root.net“.

1. Creating the trust relationship between the two domains/forests

It is better to create a “two-way” trust between the source and the target (it is simpler, faster, more practical for our purpose). This is how:

• Log on the source domain DC as a domain administrator.
• First of all, create a “DNS forwarder” to reach the target domain (or nothing will work):
  Start / Administrative Tools / DNS / Server / Forwarders / Add x.x.x.x (the IP address of a DC of the target domain)
  (Note: we already created a DNS forwarder the other way around, from the target domain to the source, in order to connect to the Internet (via the default proxy server in the source domain).
• Restart the “DNS” and “Net logon” services to make the change effective (Start / Administrative Tools / Services)
• Use “nslookup” to check that the names are resolved (command prompt / nslookup target.net). Do it also from the target towards the source domain. It is very important: if it fails, nothing will work.
• Create the trust relationship with the target domain:
  AD domains and trusts / Right click on the domain / Properties / Trusts
  New trust / target.net / Two-way / Both this domain and the specified domain
  We need “Enterprise Admin” credentials of the target domain: (if we have a root domain we will use something like “ROOTenterpriseadmin” – password)
  Go on until the end; we will get a warning about SID filtering being enabled.
• Disable SID filtering (via command line) for both sides of the trust:

  netdom trust source.net /domain:target.net /quarantine:no /usero:admin /passwordo:xxx
  netdom trust target.net /domain:source.net /quarantine:no /usero:admin /passwordo:xxx

NOTE: sometimes the trust relationship ceases to work… it actually happened to me twice.
Remove the trust, reboot, recreate it again and reboot again until everything works.

2. Creating the necessary “migration accounts”

As a security policy, we should never use the Windows default “administrator” account. So:

• Create alternate administrator accounts in both domains (we should already have them, let’s say “admin”)
• In the target domain, add the “Domain Admins” group of the source domain to the built-in local “Administrators” group, this way:
  - AD users and computers / Builtin / Administrators / Members / Add / Locations / select the source domain / Write “Domain Admins” / “Check names” for security / OK
  - Exactly in the same way, in the source domain, add the “Domain Admins” group in the target domain to the group builtin local “Administrators” group.
  Note: In the ADMT manual a very different way is explained, involving OUs and delegation, too complex for our purposes…

3. Setting up the source and target domains for SID history migration

This could be configured manually, but ADMT configures it automatically the first time it is run. So why bother? :-)

4. Creating the OU structure in the target domain

• Create the necessary OUs in the target domain
• Create administration groups, and assign the necessary users to these groups
• Where needed, delegate the OU administration to these groups

These are very “free” steps, depending on the company organization. I will not go into this topic (we have to know what we are doing).

5. Installing ADMT in the target domain (“SQL Server Desktop Edition” will be installed automatically)

• Download and run “admtsetup.exe” (ADMT 3.0). Install it on a DC of the target domain.
  We will always run ADMT as “admin” on the DC of the target domain.
• Configuring components (a SQL server “MS_ADMT” database instance will be created)
• Database selection (choose “Use SQL Server Desktop / Express”)
• ADMT Database import (leave “No”, as per default)
• Summary / Finish (and reboot, just to be safe)

If we wish, we could set up a PES (Password Export Server) to migrate passwords. But it is complicated, and the work is not worth the hassle.
In the migration process, a random password will be automatically generated: we will just reset the passwords of the migrated users, and we will force them to change their password right after the migration (a small effort from their side).

Now, we will perform a test migration to prepare the environment:

• Log on as “admin” in the target domain (otherwise it will not work)
• Run Administrative Tools / ADMT
• Actions / Group account migration wizard
• Domain selection / Select the source and target domain and the relative DCs
• Group selection / Select groups from domain / Add / Select group/ (type an existing group name)
• Organizational Unit selection / Select the OU of the target where the migrated group will go
• Group Options / Select ONLY “Migrate Group SIDs to target domain”, uncheck everything else
• Choose YES to the prompt “Auditing is currently not enabled on the source domain, enable auditing?”
• Choose YES to the prompt “Auditing is currently not enabled on the target domain, enable auditing?”
• Choose YES to the prompt “The local group SOURCE$$$ does not exist on the source, create it?”
• Provide admin credentials of the source domain
• “Exclude specific object properties”: leave it as it is
• Conflict management / “Do not migrate source object if a conflict is detected in the target”
• Wait some time in the “Migration progress” window

If you get this warning: “ADMT could not migrate some properties for this object type (group) due to schema mismatches”, it is because some attributes are not compulsory, they are present in the source but not in the target (to check that, see the schema with the Schema Snap-In). Typically these could be Exchange attributes.

If everything has worked:

• In the source domain, a “local group” is created (i.e. “SOURCE$$$”, under “Users”). NEVER ADD USERS HERE.
• In the source domain, the entry DWORD “TcpipClientSupport=1” is created in the registry under “HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsa“.
  If it is not created, create it! (In my case, it was not created) and reboot.
• Account management auditing is enabled both in the source and the target. Check:
  - AD Users and computes / right click on the domain / View / Advanced features
  - Right click on “Domain controllers” / Properties / Group policy / Default domain controller policy / Edit
  - Computer configuration / Windows settings / Security settings / Local policies / Audit policy
  - “Audit account management” should have both “Success” and “Failure” selected (default is only “Success”)
  (this worked).

For some reasons, at this point the trust stopped working… I removed and recreated it, repeating the “SID filtering” part too.

6. Identifying the “service accounts”

These are accounts used to execute applications, for example ASPNET or SQLSERVER.

• Run ADMT in the target domain, after logging in as source domain admin (otherwise for some reasons we have no access rights to the servers)
• Action / Service Account Migration Wizard
• Domain selection / Select source domain and target domains, and relative DCs
• Yes, update information / Select computers from domain / Add
• Choose your application servers (include all servers you have)
• Agent actions / Run pre-check and agent operation / Start (it will run an agent on the machines to find the service accounts)
• Once the “Agent actions” window is closed, we will have the list of the service accounts
• “Skip / Include” selects the accounts to be included from the migration
• Summary / Finish

NOTE: this operation only identifies the service accounts, does not migrate them.

On to next time!