Limitations of User Account Conversion
There are limitations to consider when using ADMU. It is strongly recommended to test account migration on a representative test user before migrating production accounts.
Important: The following is a general list of known limitations. Other undocumented issues may exist. Always test ADMU on an account that accurately represents your organization's user base before migrating production users.
The ADMU modifies several registry keys during migration. Some AntiVirus products have flagged these registry key modifications as malicious, and halted the ADMU process during migration. We have been able to reproduce this behavior with BitDefender and SentinelOne. Other antivirus products may interfere with ADMU migration.
During migration the ADMU copies the user registry of the domain user to the new local profile. It's during this step where some AntiVirus products have flagged the ADMU and killed the process. Please test the ADMU with the AntiVirus solution deployed in your production environment before migrating accounts.
If the migration process is killed before completion, accounts may be left in a half-migrated state. If this occurs, you can use the automated reversion features available in ADMU v2.11.0+. See Reverting Migration for detailed instructions.
If migration is halted before completion, it's likely the case that the new local user was created, but, not migrated. If the domain profile can still be logged into using domain credentials, simply remove the newly created local user and it's corresponding home path before running ADMU on that account again.
Ex. If migration was halted due to AntiVirus closing the process, an empty local profile would exist on the system. To remove this empty profile:
- Open Start Menu and type
lusrmgr.msc - Identify the newly created local user
- Delete the local user using the graphical prompt
- Delete the user's home directory ex.
C:\Users\localUsername
After removing the new local user, the ADMU can be run again with the same parameter set.
You may need to whitelist the JumpCloud ADMU exe or PowerShell Module before you are able to successful migrate.
Windows Start Menu layouts cannot be migrated. Users will need to reconfigure their Start Menu layout after migration.
As of ADMU v2.6.2+, Windows default apps and protocol associations are preserved during migration. Some windows settings may still need to be reconfigured by the user after migration. Windows uses a hash-based protection mechanism to prevent programmatic changes to certain types of applications like web browsers and PDF readers. This means that while ADMU attempts to preserve default app settings, some associations may not carry over perfectly.
If you experience issues with default apps after migration, they can be reconfigured in Windows Settings:
After converting an account, Outlook's .ost offline cache file must be recreated and re-authenticated. Office activation and association should remain intact but require re-authentication.
If presented with an error: stating "you must connect to exchange before you can use your .ost file", sign into Office using the account's credentials.
Outlook should open and being syncing with the configured outlook mail server.
Note: The
UpdateHomePathparameter is available in the CLI executable and PowerShell module, but not in the GUI. If you need to update a user's home path, use the CLI executable or PowerShell module with the-UpdateHomePathparameter.
File syncing apps that copy user data from the local system to cloud storage often rely on hard-coded file paths. If a sync app is configured to sync the C:\Users\ianjohnson\SyncedFiles directory, updating the home path during migration can break sync with the remote server.
If the domain user DOMAIN\ianjohnson is converted to COMPUTERNAME\ian.johnson (note the '.' between 'ian' and 'johnson') and the user's home path is updated to C:\Users\ian.johnson\SyncedFiles, the original C:\Users\ianjohnson\SyncedFiles directory would no longer exist after migration. To solve this issue, the default behavior of ADMU is to NOT update the home path, preserving the original directory structure and preventing sync app disruption.
The following table displays the difference between using the UpdateHomePath parameter or leaving it at its default (do not update):
| Domain Username | JumpCloud Username | User Path Before ADMU | UpdateHomePath Parameter | User Path After ADMU |
|---|---|---|---|---|
| Domain\ianjohnson | ian.johnson | C:\Users\ianjohnson |
$false (Default) |
C:\Users\ianjohnson |
| Domain\ianjohnson | ian.johnson | C:\Users\ianjohnson | $true |
C:\Users\ian.johnson |
If the UpdateHomePath parameter is set to $true on ian.johnson's account and a sync app is configured to sync files, the sync app will most likely be unable to find its original sync directory. ADMU's default behavior preserves the original home path, ensuring that applications configured with hard-coded file paths continue to function after migration. Unless there's a specific requirement to update a user's home path to match the JumpCloud username, we do not recommend using -UpdateHomePath $true during migrations.
OneDrive requires re-authentication after ADMU migration. Successful re-authorization should re-enable sync services as long as migration was completed without the UpdateHomePath parameter (or with -UpdateHomePath $false).
The conversion process may break the windows universal platform app (UWP Apps) print dialogue box. Clicking the print icon from the windows photos app will display the print dialog box before promptly closing the app. We are investigating the issue further before implementing a fix. Printing from a non-Windows UWP app is recommended.
If after migration and subsequent login to an Office 365 app a Keyset error (like the screenshot below) is displayed, credentials may be cached and in need of replacement. If the user's account is listed under Settings > Email & Accounts but is unmodifiable, the account should be removed from Settings > Access work or School by clicking the "disconnect button" on the migrated user's account. Afterwords, signing into Office 365 apps should prompt for re-entry of the user's credentials. Successful authentication should resolve the issue.
Due to a limitation in how the PowerShell function Get-AppxPackages works, it's recommended that Entra ID accounts remain bound to Entra ID during conversion. Get-AppxPackages can identify standard local and domain accounts by SID, but not Entra ID accounts by SID.
If converting an Entra ID account while unbound from the Entra ID domain, the converted account will register UWP apps assigned to all users. In this scenario, a converted user may be missing several Windows Store apps upon login. These can be re-downloaded from the Microsoft Store.
Windows Hello biometric data (fingerprints, facial recognition) cannot be migrated to the new local profile due to security safeguards. Biometric data is stored in hardware (TPM or BIOS) and tied to specific user profiles, preventing migration.
Recommendation: If a user or device uses Windows Hello biometrics, remove the user's biometric data in Windows Settings before running ADMU. Users will need to re-enroll their biometrics after migration.
- Reverting Migrations: Revert ADMU Migration
- Troubleshooting: Troubleshooting Errors
- Migration Parameters: Start-Migration Documentation