Active Directory Migration Utility

In this tutorial module, we’ll cover how to leverage JumpCloud’s Active Directory Migration Utility or better known as the ADMU to migrate your Active Directory bound workstations and users to local workgroups and local users without having to migrate any profile information or data.
The following steps are outlined on JumpCloud’s Public GitHub Wiki with the links provided.
The ADMU is run on a Windows system which is bound to a domain controller. During this demo migration, the JumpCloud Agent will be automatically installed using your Connect Key and the system added within your JumpCloud Organization. Afterwards, the AD profile is converted to a Local Account. Finally, the system will leave the Active Directory Domain and reboot. After reboot the local profile will display on the login window.
There are several prerequisites in order to ensure the ADMU will execute appropriately. Please refer to the ADMU Guidelines within JumpCloud’s GitHub for more details:
github.com/The...
The ADMU can run as a graphical user interface or as a powershell command line interface. In this module, we will cover the graphical user interface.
In our example, I have a Windows 10 21H1 VM running with a single user, Bob Fay, who is an Active Directory User on this AD bound Windows machine. We will run the ADMU GUI tool to detach both his system and convert his profile to local.
In order to migrate Bob’s account we need to sign into a local administrator and completely sign out of Bob’s account. [sign out of bob & sign into admin] One logged in the Machine as a local Administrator, I will run the ADMU tool as an Admin and bring up the ADMU GUI Window.
Once the ADMU is on screen, we will want to configure a few fields before executing.
First Copy your Connect Key from your Admin Portal for Adding Systems into the Connect Key field in the ADMU.
Next ensure that the following are checked:
Install JC Agent
Convert Profile (This is the default behavior)
Leave Domain
Force Reboot (is entirely optional, in our case I will check this)
Once the appropriate checkboxes have been added, you should see a list of User Accounts listed at the top where both AD bound and local accounts are shown.
In my example, we see both the local Super Admin Account as well as Bob Fay’s Active Directory account.
I’ll go ahead and select Bob Fay’s AD Account from the list.
In our example, I’m going to ensure that his JumpCloud username is bobfay and the temporary password will be TestPass123! - a password that meets the complexity requirements of the domain controller and local group policy on the system.
Once everything appears to be configured correctly, click on the Migrate Profile button in the bottom right. This will begin migration of Bob Fay’s domain Account with our configured settings.
Once the machine reboots, we can log in as Bob Fay using the password we’ve set previously. The ADMU finalizes account setup during first login. We can also see that his desktop still has the folders and files from the domain profile.
NOTE:
Some components will not be migrated using this utility such as:
Windows start menu layout
Windows default apps. These will need to be reconfigured in the settings application.
Applications that are installed and ran from the appdata directory may not migrate fully. An example would be: Onedrive & Microsoft Teams. This may result in the need to resync, reinstall or update shortcuts for the new profile.
If leveraging Outlook, after converting the account, outlooks .ost offline cache file must be recreated and the account re-logged into. However the office activation and association should still be present but require a reauth.
Once the System has come back online, you can then bind the employee’s JumpCloud User Account to the newly added System to take over the pre-existing profile. Ensure that the JumpCloud Username matches what the username you set within the ADMU migration.
Giving this about 60 seconds, we should now be able to login with Bob’s JumpCloud password of PearlStreet303! This System and Account is now entirely managed by JumpCloud without any Active Directory bindings.
That’s it!
This concludes the module over JumpCloud’s Active Directory Migration Utility. For more information, check out JumpCloud’s related knowledge base articles and GitHub for more details.
Thanks again!