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.


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.


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.

Skype for Business Online Hybrid Coexistence – User Moves with Move-CSUser

While onsite with a customer who was having John Weber and myself setup a Skype for Business Hybrid coexistence with their previously configured Office 365 tenant, we ran into a conundrum with setting up a PS Session from one of their existing edge servers.

Due to their security measures, (i.e. various internal firewalls and proxies) we were unable to establish a PS Session from their network to SfB Online. This is because the WinRM protocol 5985 was most likely blocked.

We discovered this when trying to establish a PS Session to run the following command from one of the edge servers:

Since we were not able to run the command from their network environment, we were however, able to run the command from a hotspot connection and change this value thus establishing coexistence.

The customer wanted to be able to manage their coexistence (aka perform the user moves) from one of their edge servers, and they were concerned with how they would perform their user moves using the Move-CSUser cmdlet from their edge server considering that WinRM was not able to establish a PS Session.

With this customer, making the change requests to open this port could take weeks to get approved.

In our troubleshooting, to make matters worse, we could not telnet over port 443 from the server to the URL we were trying to pass credentials to as part of their O365 tenant when performing the steps to perform the move with the Move-CsUser cmdlet.

We ended up being able to run the Move-CsUser cmdlet regardless of all of the above, and so this caused us to contemplate how the command is perform the moves to SfB Online, so we could provide the documentation to the customer.

The only conclusion we could think of, because we could not find an answer after a few hours of research to present to the customer, was that it must have been passing the credentials to their DirSync server, and since they had already synced users to O365, the DirSync server must have been passing the credentials, and the other changes needed to effectively show the user as “In the cloud.”

It seems that for now, the way the cmdlet Move-CsUser operates is that of Microsoft “Voodoo” magic until I or someone else gets a chance to analyze network traffic being passed during a passing of the Move-CsUser cmdlet when moving users from on-premise’s to Skype for Business Online.

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:


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


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:

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

Can’t Verify Domain in Office 365

If you have been creating trial tenants over and over again like I have been with Office 365 and their E3 license, it is likely you may run into the same issue I have.

Microsoft does not really give you any hints in regards to troubleshooting your domain verifications.

I am currently going after the MCSA for O365, and the way I have been able to learn the ropes of O365 for the 70-346 and 347, has been purely from signing up for their E3 trial.

No need to spend any money at all, and you can get Sharepoint, Exchange, SfB, etc. Additionally, you get 25 user licenses to play around with.

“What if my trial ends?” you say?

The good news is that you can extend the trial an additional 30 days! (totaling 60 days.) I have a single domain name I used to work with O365 and a lab environment at home that I setup an Exchange hybrid in, manage Sharepoint Online, etc.

Worst case scenario: You use your total of 60 days, and MS asks for money. Just buy another 99 cent throw away domain from or and start another trial. Once MS trashes your original domain which expired, (30 days after your original 30 day, or extended 60 day trial ends) you can use that same domain name again as an O365 tenant and start again.

Rinse. Repeat. Profit.