VMware Horizon Community
pbastiaans
Enthusiast
Enthusiast
Jump to solution

Office 2013 C2R to Office 2016 MSI UEM migration

Has anyone successfully been able to migrate settings using 'Application Migration' in UEM?

If 'yes', please share.

Some of the challenges I am experiencing is that certain keys, for example Access/Excel/Word MRU keys are not migrating. They show up after next log on without the moved keys.

I have tried the rename, which works except that the 2013 version keeps MRU in an OrgID.:

<key action="rename" source="HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Access" destination="HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access" />

Now I am at trying to move the values out of OrgID into the new default location:

<key action="create" source="HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\File MRU"

<key action="move_value" source="HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\User MRU\OrgID_*\File MRU" destination="HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\File MRU" />

I am thinking a log off/log on script? Maybe?

Thanks!

1 Solution

Accepted Solutions
pbastiaans
Enthusiast
Enthusiast
Jump to solution

After a lot of trial and error, application migration worked (intermittently). For users with issues, a log off/log on with the overwrite command resolved.

It appears that the root of the issues I faced were conditions, having no conditions allowed this to work smoothly.

The Application Migration instructions included with the UEM install were helpful at configuring the XML's required for migration. A little more content on best practice and requirements (i.e., do not disable current app config files) would be icing on the cake.

Thanks all for reading and posting...drive fast, take chances!

View solution in original post

4 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi pbastiaans,

Application Migration has not received a lot of attention over the last few releases of the product, but it has definitely been used successfully to migrate settings from one version of Microsoft Office to another.

However, that might have been limited to scenarios where customers "just" upgraded Office, without switching between "delivery mechanisms".

Application Migration unfortunately does not support wildcards, so your OrgID_* key is not going to work 😞  Do you need to account for many different sub keys?

I am thinking a log off/log on script? Maybe?

I'm not sure what you're asking here? Application Migration runs at logon.

pbastiaans
Enthusiast
Enthusiast
Jump to solution

Thank you.

I understand, no wild cards in the xml.

"I am thinking a log off/log on script? Maybe?"

I was putting feelers out to see if someone else had 'skinned this cat' in a different manner, possibly a Powershell script at log off/on.

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Do you have many different OrgID_* sub keys that you need to move over?

I guess you could use the UEM agent's COM interface to programmatically extract a user's profile archive, tweak the .REG file a bit, and then zip it up again? (You can't use standard zip/unzip tools, as UEM will only import its "own" flavour.)

I can provide some more info on using the COM interface to unzip and zip; the "tweak the .REG file a bit" is left as an exercise for the reader, though 🙂

0 Kudos
pbastiaans
Enthusiast
Enthusiast
Jump to solution

After a lot of trial and error, application migration worked (intermittently). For users with issues, a log off/log on with the overwrite command resolved.

It appears that the root of the issues I faced were conditions, having no conditions allowed this to work smoothly.

The Application Migration instructions included with the UEM install were helpful at configuring the XML's required for migration. A little more content on best practice and requirements (i.e., do not disable current app config files) would be icing on the cake.

Thanks all for reading and posting...drive fast, take chances!