Frequently Asked Questions (FAQ)


Supported Windows Versions

Registration and Licensing

Technical questions




ACS Builder

Technical Support


Supported Windows Versions

Which Windows Versions are supported?

Profile Migrator can migrate user profiles and data from Windows XP up to Windows 10 / Server 2016 build 1607. This means all Operating System versions in between (Vista, Windows 7, Windows 8, Windows 8.1 as well as their server pendants are supported as well.
However the new V6 user profiles (generated by Windows versions with build of 1703 and higher) are not supported.

Registration and Licensing

How is Profile Migrator licensed?

Profile Migrator can be used free of carge. You can get your license file for free by contacting us via our online registration form.
When you download Profile Migrator it is running in evaluation mode, meaning migration is limited to three simultaneous users per migration. When installing the free full license there are no limitations for the migration. You can get the license file by contacting us via our web registration form.


Technical questions


Which permissions are required to run Profile Migrator?

  • On the machine running Profile Migrator: Local admin rights (in order to load and unload registry hives).
  • On the source profile folders (those profiles that are to be migrated): Read access.
  • On the target profile folder (where new profiles are created): full access. Additionally the privilege “Take ownership of files or other objects” (SeTakeOwnershipPrivilege) is required, which by default is granted to local administrators.

A workaround to requiring the SeTakeOwnershipPrivilege exists. Setting the owner is not required if you enable the group policy setting “Do not check for user ownership of Roaming Profile Folders” (Computer Configuration -> Administrative Templates -> System -> User Profiles) on all computers where roaming profiles are used. The option “Do not set profile owner” can then be activated in Profile Migrator.

Recommendation: Set the profile owner on all profiles you create to avoid problems on computers that do not have the ownership check disabled via group policy.


On VMware Workstation 6.5.x Profile migrator reacts slowly to input

Profile Migrator uses WPF, a technology VMware Workstation 6 does not fully support. As a workaround please disable 3D graphics acceleration in the virtual machine settings:

  • Shut down the virtual machine.
  • Press CTRL+D to open the virtual machine settings dialog.
  • Click on “Hardware” and then “Display”.
  • Uncheck the box “Accelerate 3D graphics”

Alternatively upgrade to VMware Workstation 7.


What Windows languages are supported by Profile Migrator?

Profile Migrator fully supports all Windows languages. Profile Migrator can be run on all existing language versions of Windows and can migrate profiles of all languages.

Profile Migrator is not able to establish a network connection. What can I do?

Profile Migrator requires an SSL (https) connection to be able to successfully connect to our servers. Please check your Internet Explorer proxy settings and your firewall. Be sure that an SSL connection to our server “” is permitted.


How is the owner of a profile determined?

Profile Migrator needs to determine the user account for each profile is associated with in order to be able to set the correct permissions on newly created user profiles. It determines the profile owner by checking file system and registry permissions and by permforming additional checks as described below:

  1. Check the direct permissions on the file NTUSER.DAT in the profile. “Direct” means that group permissions are ignored. If this yields exactly one user account with read and write access, that account is considered the owner. The check fails if no such account is found. If multiple accounts are found, Profile Migrator tries to find the owner among those by performing the additional checks described below.
  2. Look for each account name in the path to the profile in one of the following formats: username/username.domain/username.v2/username.domain.v2. If an account name matches, it is considered the profile owner. If no match is found, continue with step three.
  3. Load the profile’s registry hive and remove all those accounts from the list above that do not have read and write acess to HKCU\Software. If exactly one user account remains, that account is considered the owner. If no account is found, the check fails. If multiple accounts are found, Profile Migrator tries to find the owner among those by performing the additional checks described below.
  4. Look for each account SID remaining after the previous checks in HKCU\Software\Microsoft\Protected Storage System Provider and remove those from the list not found as subkeys. If exactly one user account remains, that account is considered the owner. If no account or multiple accounts are found, the check fails.

If the check fails, the current profile cannot be migrated and Profile Migrator writes the following message to the log file: “ERROR,Migration,DOMAIN,USER,TID,CreateProfilePairWrapper: Could not determine the owner of profile ‘<path to profile>’, access rights are inconclusive.”


Some settings do not seem to be migrated

There are many possible reasons for this. There might be no ACS for the application in question, or the application’s ACS was not included in the migration. Alternatively, the application’s ACS might not have been created for the application version you are using – storage locations of user settings might have changed between versions.

But what if the setting in question has been migrated correctly but is still not active – the application uses something completely different? Please check if one of the following products or technologies is used in your organization to customize the user profile that overwrites migrated settings in the process:

  • Group Policies
  • Group Policy Preferences
  • Logon scripts
  • Active Setup
  • Software distribution products like Enteo NetInstall or Microsoft SCCM


Migrating a local profile to a roaming profile does not seem to work in client migrations

A local profile is created on the target machine when a local profile is migrated to a roaming profile during client migrations. Only when the user sucessfully logs on and off is the local profile converted to a roaming profile. As long as the user does not log on such profiles are displayed as local profiles in the user profile list.


Are excluded and included elements be considered if I disable recursion for a directory or registry key?

No, a disabled recursion takes precedence over exclusion and inclusion lists. Any excluded and included elements in a directory or registry key without recursion are not processed during the migration.


Where can I find any information on how long a migration took?

In Profile Migrator version 1.1 statistics for a running migration were added. The statistics include elapsed and remaing time for the entire migration as well as the shortest, longest and average migration time of a single user profile.


Outlook is unable to use the migrated OST file

After migrating the OST file of an Exchange server e-mail account Outlook sometimes diplays the error message “Outlook is using an old copy of your Offline Folder file (.ost). Exit Outlook, delete the .ost file, and restart Outlook. A new file will be automatically created the next time you initiate a send/receive.”.

The cause of this behavior is that the OST file is older than the information stored on the Exchange server. This happens when the user continues to work on the source computer after the OST file has been collected by the Collector script. Once the OST has been deleted Outlook can be started again. The OST file is re-downloaded from the Exchange server at that point.

In order to prevent this behavior keep the amount time between the collection of the data on the source system and the first start of Outlook on the target system as small as possible. Alternatively you can exclude OST files from the migration by not adding the ACS script ‘Office – Outlook local PST files’ to the list of applications whose setting are to be migrated.


Can I migrate roaming profiles into local profiles?

You can migrate your roaming profiles into local profiles with the Clients migration mode. Roaming profiles must be locally cached otherwise Profile Migrator is not able to collect such profiles. If roaming profiles are not cached (usually configured on terminal servers), a migration is not possible.

Migration fails with the error “No profiles found for migration”

There are different reasons why this error can occur. The following list can help you solve your problem:

  • Check the permissions of your user profiles. Most of the time this error occurs when the permissions of user profiles are misconfigured.
    Have a look at this Microsoft article on how to fix it.
  • Check if the user profile is corrupted. Is it currently usable by the user itself? Are you able to load the ntuser.dat into your local registry?
    Profile Migrator requires a fully functional user profile to migrate.

A good strategy is to analyze the entire verbose log file of Profile Migrator to detect the reason for this error.

Migration fails with the error “Could not determine the owner of profile…”

Profile Migrator uses the permissions on the user profile to determine the profile owner. During profile analysis just one user with read write access is expected.
If you have detected this error message in your log file the reason for this error could be caused by misconfigured permissions on the profile.

The following steps show you which locations we check for the determination.

Step 1

  • Check the permissions inside the file properties of the ntuser.dat.
  • We need exactly one user with read write access inside the permissions.
  • If no user is listed you found the reason!
  • Do you have more than one user with read write access? Proceed with step two.

Step 2

  • Load that ntuser.dat of that profile into your machines´ registry. Open the properties of the Software key.
  • We need exactly one user with read write access which matches a user with read write access found in step one.
  • Do you have more than one user with read write access in the registry permissions? Proceed with step three.
  • If you don’t have any user with read write access we can’t proceed with the determination.

Step 3

  • Finally check the following registry key: Software\Microsoft\Protected Storage System Provider
  • If there is no SID (subkey) of a single user with read write access found in step two, we can’t proceed. The determination fails.
  • Does it contain more than one SID of users found in the previous step? If so, it’s not clear enough, therefore the determination fails.



Which return values are returned by PMCommand?

PMCommand returns detailed return values to evaluate the performed operation and act accordingly in scripting scenarios.
Only the highest return value is returned.

  • 0 – The migration was performed successfully.
  • 1 – The help was printed.
  • 2 – At least one profile was skipped during the migration.
  • 3 – At least one profile was renamed during the migration.
  • 4 – At least one profile was overwritten during the migration.
  • 5 – No profiles were found to migrate.
  • 6 – No ACS files were found or selected to migrate.
  • 7 – There were more than 3 users selected to migrate simultaneously with an evaluation version.
  • 8 – There were more users selected to migrate simultaneously than allowed by the evaluation license used.
  • 9 – At least one user profile was removed from the source profile list, because the user already had another profile in the list.
  • 10 – More users were migrated than licenses are available.
  • 11 – Updating the Active Directory user object failed.
  • 12 – The specified parameters contained an error.
  • 13 – At least one source profile was not found.
  • 14 – At least one profile directory owner could not be determined.
  • 15 – The evaluation period has expired.
  • 16 – An error occurred.
  • 17 – The process was canceled by the user.
  • 18 – The script to be executed prior to the migration of each profile failed for at least one profile.
  • 19 – The script to be executed subsequent to the migration of each profile failed for at least one profile.
  • 20 – The script to be executed towards the end of the migration of each profile failed for at least one profile.
  • 21 – More than the allowed number of users were migrated simultaneously in a test mode migration.


ACS Builder

How can I use ACS Builder on Windows XP and Server 2003?

ACS Builder offers two modes of operation:

  • Running any application in monitoring mode. This requires at least Windows Vista / Server 2008 and the Windows Performance Toolkit (WPT).
  • Analyzing log files in CSV format generated by Sysinternal Process Monitor. This works on all operating systems supported by Profile Migrator, namely Windows XP SP2 and newer.


I opened a Process Monitor log file with ACS Builder, but the resulting ACSX file has no entries

This may happen because you are logged on with a different user account than when the Process Monitor log was created.

ACS Builder has extensive filtering capabilities. Out of the hundreds of thousands of entries in a typical Process Monitor log it filters those that are the result of accesses to the user profile by the selected application. In order for this filtering to work, ACS Builder needs the path to the user profile being accessed. Since no profile path is stored in the log file it uses the current user’s profile path. If, however, the current user was not the user who was logged on while the Process Monitor log was created, ACS Builder will not be able to find relevant entries.


Technical Support

What information do I need to send to get my support case answered quickly?

Support cases can be a hard nut to crack if information is missing. To avoid having to ask you for basic information before getting to work on your support case, we have created a support center that explains what information should be contained in an initial support request.