There are limitations to consider when using ADMU. It is recommended to test account migration on a test domain user before migrating a real user account.

### Known Limitations

The following is a _general_ list of known limitations, other undocumented issues may exist. Please test the ADMU on an account which accurately represents your organizations user base before migrating users.

## Antivirus and Windows Registry

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, steps may need to be taken before the ADMU can be run again. Please see the [reverting conversion](https://github.com/TheJumpCloud/jumpcloud-ADMU/wiki/Convert-Profile#reverting-conversion) steps and take action as necessary.

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:

1. Open Start Menu and type `lusrmgr.msc`
2. Identify the newly created local user
3. Delete the local user using the graphical prompt
4. 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.

## Start Menu Layouts

Windows start menu layouts can not be migrated.

## Default Apps

Prior to version 2.6.2, Windows default apps and associations would be lost post-migration. Later versions of the tool should retain default application and protocol preferences.

Prior to version 2.6.2 those applications would need to be reconfigured in the `settings` application.

![default_app](images/default_app.png)

## Microsoft Apps

After converting an account, outlooks .ost offline cache file must be recreated and re-authenticated. Office activation and association should still be present but require a 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 error](images/outlook_error.png)

![365_login](images/365_login.png)

Outlook should open and being syncing with the configured outlook mail server.

## Syncing Apps (Box, OneDrive, Google Drive, etc.)

Note: The Update Home Path parameter has been removed from the 2.0.0 and greater GUI version of the tool. If there is a need to update a user's home path, please run the [CLI version of the ADMU](<[ADMU-Powershell-Script.md](https://github.com/TheJumpCloud/jumpcloud-ADMU/wiki/ADMU-Powershell-Script)>).

File syncing apps which copy user data from the local system to a cloud storage service often times rely on a hard-coded file-path. If a sync app is configured to sync the `C:\Users\ianjohnson\SyncedFiles` directory, ADMU migration used to (prior to v1.6.4) break sync with the remote server.

If for example, the aforementioned domain user `DOMAIN\ianjohnson` were converted to `COMPUTERNAME\ian.johnson` (note the difference being the '.' between 'ian' and 'johnson') and the user's home path was updated to `C:\Users\ian.johnson\SyncedFiles`, the `C:\Users\ianjohnson\SyncedFiles` directory would no longer exist after migration. To solve for this issue, the default behavior of the ADMU beginning on v1.6.4 and above is to no longer update the home path to the JumpCloud username.

Note the "Update Home Path" option is unchecked by default.

### Expected Conversion Behavior

The follow table displays the difference between either marking the "Update Home Path" parameter checked or leaving it unchecked (default behavior).

| Domain Username   | JumpCloud Username | User Path Before ADMU | Update Home Path             | User Path After ADMU |
| ----------------- | ------------------ | --------------------- | ---------------------------- | -------------------- |
| Domain\ianjohnson | ian.johnson        | C:\Users\ianjohnson   | Unchecked (Default Behavior) | C:\Users\ianjohnson  |
| Domain\ianjohnson | ian.johnson        | C:\Users\ianjohnson   | Checked                      | C:\Users\ian.johnson |

If the "Update Home Path" parameter was checked on `ian.johnson`'s account and a sync app was set to sync files on that account. The sync app would _most likely_ be unable to find it's original sync directory. As such, the ADMU's default migration behavior is to _point_ the migrated user's home path to the previous domain user's home path - this ensures that applications configured with hard-coded file paths are able to find those locations after migration. Unless there's a specific need to update a user's home path to the same name as the JumpCloud username, we do not recommend checking the "Update Home Path" parameter during migrations.

![onedrive](images/one_drive.png)

At least with One Drive, re-authentication is required after ADMU migration. Successful re-authorization should re-enable sync services as long as migration was completed **without** checking the "Update Home Path" parameter.

## UWP App Printing

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.

![photos_error](images/uwp_print_error.png)

## Trusted Platform Module - Keyset does not exist

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.

![tpm keyset issue](images/tpm_keyset.png)

## Entra ID (Azure AD) UWP App Conversion

Due to a limitation in how the PowerShell function: `Get-AppxPackages` works, it's recommended that EntraID (Azure AD) accounts be 'bound' to EntraID (Azure AD) before converting the EntraID (Azure AD) user to a local user. `Get-AppxPackages` can identify a standard local and domain account by it's SID but not not an EntraID (Azure AD) account by SID. If converting an EntraID (Azure AD) account while 'unbound' from the EntraID (Azure AD) domain, the converted account will register UWP apps assigned to all users. In this edge case, a converted user could be missing several Windows Store Apps upon login, these can be downloaded from the store again.

## Windows Hello Biometrics

The migration of Windows Hello Biometrics such as fingerprints is not transferable to the newly created profile for the migrated user due to security safeguards. Biometrics data are often stored in hardware like TPM or BIOS, further inhibiting the ability to migrate it from one profile to another. Therefore, it is advisable that if a user or device is using Windows Hello biometrics, make sure to remove the user’s biometrics in Windows settings prior to using the ADMU migration tool.