I was recently asked if I knew of any way to migrate user settings from a locally installed version of Office 2003, to an App-V delivered version of Office 2010. This quite a recurrent scenario. Well, really there are 2 different scenarios. I’ll explain each briefly below.
You work in the IT department for large organisation which has an SOE based on Windows XP and Office 2003. This is still a fairly common (although thankfully dying) situation. Your organisation is looking to upgrade to Office 2010, however there are some considerations. How do you know you’ve identified all critical Office files and checked their compatibility? Are you aware of every Office add-in being used in field?
In order to proceed, you decide to leverage your investment in Software Assurance and MDOP, using App-V to deploy Office 2010 along side Office 2003. This will allow your users to get to know Office 2010 and identify any potential compatibility issues, without taking away their existing productivity suite. If something doesn’t work, you can instruct your users to simply keep editing that particular spreadsheet in Excel 2003 until the issue is resolved. This approach will also support your less savvy users adjust to the change, by allowing them access to Office 2003 ‘just in case’.
OK, say you now work in the IT department for a different large organisation. Unfortunately, like in the first scenario, this company still has an SOE based on Windows XP and Office 2003. However this time you have the board on your side and they are keen as mustard to upgrade the whole fleet to Windows 7 and Office 2010. Your organisation has a large number of sites, with varied desktop requirements, so you will need to deploy a light-weight, flexible SOE.
You once again decide to leverage your investment in Software Assurance and MDOP. This time you can create a base image without any Microsoft Office products installed as this will save you a few gigs in your WIM. You sequence Office 2010 using App-V with the intention of streaming the applications only to those PC’s that require them.
Things are looking good… your department stands to realise significant savings from reduced software licenses, you have a flexible and efficient SOE ready to go…. the board will be pleased…. maybe it’s time to ask for a raise.
So… do either of these scenarios sound familiar? (what’s that? your company didn’t spring for Software Assurance and now you’re stuck doing it the hard way? bugger…) Anyway if you’ve gone down this path you’ve likely been faced with the challenge of migration settings from Office 2003. Take App-V out of the equation and this is a fairly straight forward concept, Office 2010 applications will migrate settings from previous versions the first time they launch… simple. With App-V however it’s a very different story. Sequence Office 2010 either by following the guidance on TechNet, or by using the new Package Accelerator (cool) and you’ll find that none of your user settings get migrated
Firstly, during the sequencing process, we launch various Office applications a number of times. As such, when the applications launch for the first time on the user’s computer under App-V, they don’t exhibit their normal ‘first run’ behaviour, as it was performed already during sequencing.
Secondly, even if the Office applications tried to perform their ‘first run’ actions, they wouldn’t be able to see the registry keys containing Office 2003 user settings, as these would be overridden by the Office 2010 information in the virtual registry.
In this post I will explain the steps required to deploy Office 2010 using App-V, in a manner that allows each user’s Office 2003 settings to be migrated across. To avoid re-inventing the wheel, I’m going to assume you are already familiar with the Microsoft Office Customization Tool (OCT), which we’ll use as part of the solution. If you haven’t used OCT before, I’d suggest take a look at this TechNet article, which has plenty of technical details and videos. I’m also going to assume that you are familiar with sequencing App-V packages, specifically Office 2010. Microsoft provide some fairly explicit guidance on this TechNet article.
OK, let’s make this happen!!
This solution is essentially a big '’Jedi Mind Trick’ (These aren’t the registry keys you’re looking for). We need to trick Office 2010 into behaving the way we want. We need to trick it into thinking that Office 2003 was previously installed so it will attempt to migrate settings at ‘first run’. We also need to trick it into thinking that it has never launched before, even though it has, during the sequencing process.
When the Office 2010 installer runs, it checks for previous versions of Office (which it will likely remove during the install) and sets a number of registry keys, which hold information about the language and version of the previous install. The keys and values are stored under:
HKLMSOFTWAREMicrosoftOffice14.0CommonMigration
Previous versions of Office won’t be present on the sequencing computer, so the Office installer is not going to place these keys. We can however, use OCT to place the keys for us. Whilst it’s not necessarily a requirement, I always like to use OCT to create a passive install for sequencing with App-V, as I can be assured of consistent results and I have the maximum flexibility.
Open up the “Add registry entries” section in OCT. You’ll notice there is a convenient Import utility, which will allow us to… you guessed it… import settings from a .reg file. In this case, we are upgrading from Office 2003, if you are using a different version, you would need to adjust your .reg file accordingly. You can download mine from here if you like, otherwise, the keys you need to add are as follows:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigration]
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationAccess]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationExcel]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationInfoPath]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationOffice]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationOutlook]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationPowerpoint]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationPublisher]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409[HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonMigrationWord]
"UpgradeVersion"=dword:0000000b
"Lang"=dword:00000409
Import all of this into OCT, it should look like this.
That’s it. When Office installs during sequencing, it will place these keys and values into the virtual registry. Remember if you need to apply custom settings through the HKCU hive in the registry, here is a good place to insert them, rather than tweaking the registry manually during sequencing. Check out my recent post on HKCU Propagation for more info.
When any Office application runs for the first time, it will check for these keys and if found, it will run the migration actions. You can see this pretty clearly from a Procmon dump of Word running for the first time.
You may need to click on this image to enlarge it
As you can see, WINWORD.exe checks for the migration keys in HKLM, finds them, and then gets to work, as represented by entries inside the blue box. Inside the grey box, you can see Word reading registry values out of the Office 2003 (11.0) keys in HKCU, and migrating them into the Office 2010 (14.0) keys.
When it is done, we can see Word creates another key under HKCU, which it check each time it runs, so as not to repeat the migration steps.
The key it creates is:
HKCUSoftwareMicrosoftOffice14.0CommonMigration<OfficeApplication>
Remember this one, we’ll need it in a second.
Now that we have configured our OCT package to support migration of user settings, we need to make a few changes to the virtual application. We should start off by sequencing Office 2010 either by following the guidance on TechNet, or by using the Package Accelerator. Remember to use the MSP file that you created earlier with OCT.
Once this is completed, we need to open the Virtual Registry tab in the sequencer to make some changes. Drill down into the following key:
USER –> %SFT_SID% –> Software –> Microsoft –> Office –> 14.0 –> Common –> Migration
We need to delete this key and its subkeys from the virtual registry. As we discovered earlier, These are the keys that Office applications look for when they run for the first time, to see if the settings have already been migrated. If you don’t delete these keys, Office will presume the migration already took place last time the application ran, and bypass the steps that we require.
NOTE: Make sure you are deleting the keys from the USER part of the virtual registry, it is all too easy to get turned around in there
Next drill down into the following key:
USER –> %SFT_SID% –> Software –> Microsoft –> Office
create a new key here called 11.0. Right-click this key and ensure it is set to Merge with Local Key. This will ensure that registry information in this part of the physical registry is merged with information in the virtual registry and presented to the application. This step is imperative as without it, App-V will essentially block Office applications from viewing these parts of the physical registry, which will in turn stop the user settings from being migrated.
But hang on!! the Office key right above this one has clearly been set to merge… so why do we need to create the 11.0 key? surely App-V will merge the entire Office key and all its subkeys, which would in this case include the 11.0 key? Well it doesn’t, and I don’t know why not. If you set a key to merge, then it merges the key and all subkeys. That is of course unless the key that you set to merge has subkeys under it in the virtual registry that are set to override, in which case, App-V will only merge the key you set, and not any subkeys….. go figure!
If you want to see the functionality in action, take a look at the video below.
Well that’s it really! you should now have an Office 2010 App-V package that, when deployed to a computer, will migrate user settings from an existing installation of Office 2003. If you are upgrading to Windows 7 in this process, there isn’t much more to consider. Simply ensure that your USMT migration includes Office settings (the default MigApp.xml will do the trick). This way, USMT will migrate the Office11.0 keys from Windows XP to Windows 7, ready for the App-V version of Office to find when it runs for the first time.
I hope this information is of some use to you, and helps you in some way.
