Set the new domain as the default “Log on to” after ADMT migration

I recently worked with a client that was migrating from one domain to another using Microsoft’s Active Directory Migration Tool or ADMT v3.2.

One of the customers concerns, like many others was: “What will the impact be on the end users post-migration?”

If you are like most IT administrators, if you can help it, you probably want to minimize the amount of help desk tickets you receive on a daily basis. Migrations from one domain to another has “help desk ticket hell” written all over it.

Issue

One of the concerns associated with using ADMT as the primary migration tool of choice was how it handles the presentation to the user when they show up to their computer Monday morning after a weekend of migrations.

Unfortunately ADMT does not get super complex with its offerings but perhaps this is intended by Microsoft. After all, it is free.

That said, I encountered the following scenario:

ADMT v3.2 by design leaves the previously logged on username and their associated domain intact after migrating from a source domain to a target domain. Windows by default caches the previously logged on username, and ADMT v3.2 does not make any changes to this.

My customer had expressed a business need to help mitigate tickets to the help desk, as well as provide the most transparent experience to the end user, to have this cached domain and username changed or removed.

Basically, the customer did not want to have users show up Monday morning at their workstation that was recently migrated to the new domain, attempt to login on the machine using their previous domain credentials because Windows decided to keep the cached value of the last logged-on user.

This customer had reasons to keep the old account active in the source domain, and since everything was on the same network and subnet internally, you could imagine the headaches that could come if Bob from HR logs in using his old credentials on his now migrated workstation.

Solution

Due to the nature of ADMT and Group Policy, it was determined that the best solution to resolving this issues to meet this need was to perform the following to remove the cached last logged on username and domain:

  • In the source domain create an OU by the name of “Pre-Migration Computers”
  • Create a new GPO that enables the policy “Do not display last user name in logon screen.”
  • Prior to migration, place the computer objects that are to be migrated in the “Pre-Migration Computers” OU to allow the group policy to apply to the computer objects ahead of time.
  • In the target domain, create an OU by the name of “Post-Migration Computers”
  • Create a new GPO that enables the policy “Do not display last user name in logon screen.”
  • Prior to migration, place the computer objects that are to be migrated in the “Pre-Migration Computers” OU to allow the group policy to apply to the computer objects ahead of time.
  • At the time of the migration, migrate the computer objects from the “Pre-Migration Computers” OU in the source domain to the “Post-Migration Computers” OU in the target domain.
  • Once it has been determined by the customer that the end user has had enough time, or has been verified to have logged into their workstation post-migration with their new credentials, the computer object can be moved freely to any desired OU regardless of whether the GPO created as a part of this process is applied to it, or not.

ADMT Breaks Default File Associations Registry

On my most recent project with a customer, I decided to take on a task of filling in for a fellow engineer who became unavailable on a project he was working on.

Since I was on the bench, I figured why not take on a few hours of ad-hoc work to fill in some time.

With this particular work, I was tasked with resolving a couple of issues, specifically one that intrigued me when using ADMT v3.2.  (Active Directory Migration Tool)

Not too long ago, Microsoft updated ADMT v3.2 claiming support for all currently supported operating systems including Windows 8.

However, I don’t think it is fully supported, nor works as well as Microsoft would probably like to say it does.

With this customer, they had conveyed that they had run into the following issue:

Scenario:

Use ADMT 3.2 to migrate Windows 8* machines to a new domain and forest.

Results:

The migrations finish successful without any problems but when the user logs on to their migrated workstation, all of the default file extension associations are lost. Even after choosing a program to open the file in question, the prompt turns up again if the user chooses to open the file again after closing it. This happens for just about every major default or manually set file extension association such as .jpg, .pdf, .xls, etc.

Why Microsoft? Why?

Turns out that I am not the only one that has been running into this issue however….

In this Microsoft Forum Post several other people have mentioned this issue as far back as 2013!

Until recently, the issue has been closed.

Their support moderator says that “For File Associate issue, is should not related to ADMT.”

By the way, you read that quote correctly. I don’t think this moderator understands the issue, let alone knows how to type out proper English.

Another user does a very good job of describing exactly what is going on, and in more detail to their individual experience:

“The ADMT migration runs perfectly, without issues, but upon completion when a user logs into their PC all their file associations are broken – reg keys under HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts all seem intact, but until I go in and delete the UserChoices reg key I cannot set these file associations again!

Looking at a PC before and after migration, there doesn’t seem to be any changes (other than the new user is added to the permissions obviously)!

Interestingly, after deleting user choices, I am still not prompted to set “default program” when I double click an affected file type…I have to right click and “Open With” before I see the checkbox to set the default!

Very strange behavior and must be something to do with the security translation of the registry as part of ADMT if you ask me?”

All in all, I was getting nowhere with what I could find, as this forum was the only thing that actually had some relevant pointers for me that applied to what I was experiencing with my customer.

The Fix: 

I was able to fix the issue after trying many different approaches.

One of the strategies was to implement a GPO that set the default file associations on the computer objects post-migration.

The policy I implemented sets the default file associations using the GPO under: “Computer ConfigurationAdministrative TemplatesWindows ComponentsFile ExplorerSet a default Associations Configuration File”

Using the default dism.exe file, as the policy suggests, seems to hold no results even after verifying that the policy was successfully applied to the computer object.

Regardless of this implementation, various file types i.e. .jpg, .bmp, all prompt with an inquiry asking which program you would like to use to open the file, effectively resulting in a non-resolution.

Obviously this is an unacceptable after-effect of the migrations that where promised to be as seamless as possible to the end users.

What did work however, was creating a GPO to run a startup script to run regedit.exe and import a .reg key which sets all the default file extension associations back to the default!

My steps were as follows:

  • Create or obtain .reg keys which contain the settings for file extension associations that will result in the desired effect.
    • Example .reg keys that can be downloaded can be found at:
      • http://www.sevenforums.com/tutorials/19449-default-file-type-associations-restore.html

Placement of Registry Keys (.reg files)

  • Create a GPO in the domain to run regedit.exe with the “/s” parameter specified when pointing to a .reg file set to change the registry keys back to the default settings defined by Microsoft for Windows 8 and Windows 8.1.

Startup Properties of the GPO

  • Apply the GPO to a designated migration OU container
  • Migrate workstations to the target migration OU which has the GPO applied to it.
  • Allow the GPO to apply to the migrated workstation.
  • Once the GPO has been applied, the workstation can be moved to any desired OU, without effecting the results of the applied GPO on the designated migration OU that the file extension GPO was applied to.

Additional Notes:

In my testing, I tried to recreate the registry keys manually (by hand) on the test machine post migration to that of the default key values, regardless of my deleting and creating of new keys, they held no results, even after a reboot of the local machine.

My registry keys included in the GPO I made touch each store on the local machine registry that handles file associations. It deletes the old entries and creates completely new ones that mimic the default associations.

Personally, I am  leaning towards jumbled security permissions post migration, because I couldn’t change the values of the keys manually. I would see an error saying I couldn’t change it. Not specifically a permissions error. I had to delete it all together and create a new key.

The reason why I am not inclined to think the default program definition is a player in this issues, is a result of my experience manually specifying the default program when opening a .jpg for example. I could specify the default program, but it never stuck, meaning every time I opened the .jpg it would prompt again to choose the program I want to use to open it.

Very peculiar behavior. I am inclined to agree with one of the contributors in the forum link I shared with you when he says: “Microsoft needs to understand customer impact so it can prioritize work.”