RUM processing with clashing user profiles

Hi everyone,

We are doing pilot testing of an AD migration. It's a fairly straightforward consolidation from source domain to target domain, with a 2-way trust between them.

Users in the source domain also have an active account in the target domain. This was done as part of a previous Office 365 consolidation project, so that all users are in the target O365 tenant, synchronised from the target on-premises AD. Our AD migration is therefore doing a minimal "merge" migration of users, copying SIDHistory but excluding most other attributes.

Most users only log on with their source account to the their Win10 PC which is in the source domain. These users can be migrated with no problems and their user profiles are updated as expected.

The issue occurs when the user has two profile on their PC - one for the account in the source domain and one for the account in the target domain. The default behaviour of RUM when updating the PC is to keep the user profile for the target account and the source user profile seems to be lost. (I have more testing to do here!) In our case, we want to keep the SOURCE account user profile.

Any ideas on how best to proceed with this? We could script something to delete any existing user profile for the target user, prior to processing with RUM. Has anyone come up with a neater solution?

Many thanks!

John

  • As far as I know, what you are seeing is expected behavior.  When you re-ACL a Win10 machine, you must immediately cut the user over to their target account.  Unlike pre Win10, there is no "sharing" of the profile.  I don't believe you have a choice but to delete the existing target domain profiles.  We'll see what others have to say.

  • There two ways you can address this, before or after.

    Before. Changing your migration process. Add this step before you resource process the workstation. 

    1. Run a resource processing task to "Revert to the Original local group, user rights and object permissions.
    2. Handling Rights and Resources, deselect all and select local profiles.

    This will remove the pointer to the target users profile, allowing the Resource Processing target to create a new pointer to the source users profile

    Or you can fix it after you fix. There is a resource kit utility, ChangeProfile.exe that you place on a network share along with a vmover.ini file. This can be run with the help of the support desk or as part of a logon script. This will point the target account's profile to the source accounts profile. In short, fixing the issue. 

    ChangeProfile.exe documentation -> support.quest.com/.../4

  • Many thanks Jeff.

    I've decided to go with the "before" option, rather than fixing after the event. It works well with test accounts. Next stop pilot users. :-)

    I had assumed that the "revert to the original" processing option only rolled back changes that had been applied by the tool. Good to know that it can be applied in this way too.

    John