Migrating User Settings from Office 2003 to Office 2010 with App-V
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...
Elevated Digital and Colocation Infrastructure.
Fast and flexible connectivity and network services.
We're experts in video conferencing and modern workplace solutions.
At Fastrack Technology, our vision is to fundamentally change the way our customers perceive and consume datacentre, network and collaboration services.
Got any questions or concerns, or simply want to provide feedback to the team? Contact us today!
If you are planning to customise your Office 2010 deployment significantly, then at some point, you will more than likely need to make changes to the registry. Perhaps you wrote a custom add-in that you need to define (In “HKLMSoftwareMicrosoftOfficeWordAddins”), or maybe you want to tweak the status bar in more detail than OCT or Group Policy allows (In “HKCUSoftwareMicrosoftOffice14.0WordStatusBar”). Whatever the case, you are probably going to find yourself wondering what is the best way to effect these changes.
In this post, I would like to describe a robust and efficient way to control Office 2010 registry settings, using a combination of the Microsoft Office Customization Tool (OCT) and a little known feature in Office 2010 (and Office 2007 for that matter) best described as HKLM –> HKCU Propagation.
Let’s try to understand a little more about why changing these settings can be difficult.
Firstly, registry settings for Office are applied by default, at various stages during the deployment process. These stages include:
Naturally, this array adds complexity and often leads to confusion. How do you know when in the process to set your custom values? Set them too early and they may get overwritten… Set them too late and you might have your applications start before the settings are applied.
Secondly, registry settings for Office span across the HKEY_CURRENT_USER (HKCU) space, the HKEY_LOCAL_MACHINE (HKLM) space, and the HKEY_CLASSES_ROOT (HKCR) space. Global settings tend to live in HKLM, however the majority of settings that you will look to customise will be located in HKCU. This makes it difficult to apply settings to each user’s HKCU, as well as users who you don’t even know about yet.
Applying settings for the user who installs Office is relatively straight forward, you could use a VBScript, PowerShell, or even a simple batch file to add or remove registry values. You could also use the OCT to add new values, however for reasons we’ll get to later, you will struggle to change or remove keys or values using this method.
It gets tricky when you want your changes to effect not only the HKCU of the user who installs Office, but all users, including those who have already logged into a given computer, and those who haven’t. You might consider mounting the Default User’s NTUSER.dat hive and making the changes there, however not only is that generally unsupported, it won’t help for users who have already logged onto the computer, as they already have a profile. Also, some settings will be overwritten when the user first launches an Office application.
OK… enough doom and gloom, let’s talk about a solution.
The functionality we are relying on here is executed each time an Office application is launched and is controlled entirely through the registry. Let’s take a look at how to use it. In this example, we are going to apply some settings related to the word status bar, to every Office user on the computer.
First, open Regedit. Navigate to one of the following keys, as appropriate.
Windows 32bit, Office 2010 32bit
HKLMSOFTWAREMicrosoftOffice14.0User Settings
Windows 64bit, Office 2010 32bit
HKLMSOFTWAREWow6432NodeMicrosoftOffice14.0User Settings
Windows 32bit, Office 2007 32bit
HKLMSOFTWAREMicrosoftOffice12.0User Settings
Windows 64bit, Office 2007 32bit
HKLMSOFTWAREWow6432NodeMicrosoftOffice12.0User Settings
Create a new key here, call it whatever you like, I’ve named mine “FTPropagation”. Next add a DWORD value called “Count”, set it to “0x00000001”
Under your key (the one I called “FTPropagation”) add a key called either “Create” or “Delete”, depending on if you want to add or remove information from HKCU, in this case, I’m going to use “Create”.
Under the create key, you will need to add keys that correspond to the locations in HKCU you wish to change. In my case, I want to add values to HKCUSoftwareMicrosoftOffice14.0WordStatusBar, so the key I need to make is as follows:
HKLMSoftwareMicrosoftOffice14.0User SettingsFTSettingsCreateSoftwareMicrosoftOffice14.0WordStatusBar
This is explained below.
Group Name = Whatever you like
Action = Either Create or Delete
HKCU Key Location = Whatever key you would like to change inside the HKCU of every user.
Next we can add any values that we wish to propagate, I’ll add a bunch that define how I want the status bar to look for my users.
That’s it! done… open Microsoft Word and take a look inside HKCU, you’ll notice that all the settings you defined have magically appeared. Now log on as a different user and Open Word, you’ll notice the settings propagate each time a user launches an Office application.
NOTE: If you want to change some of these settings at a later date, simply make the changes in HKLM, then change the value of the “Count” key to something different (perhaps 0x00000002), your changes will propagate next time someone opens an Office application.
Whilst you have Regedit open, you can export your configuration, by right-clicking the key I describe above as “Group Name” in HKLM and selecting export. This will come in handy later, as you will see.
So now that we have an reliable method for adding, changing or removing registry settings for every user, let’s take a quick look at how to deploy these settings along with your Office Installation. For the purpose of brevity, I’m going to assume you are familiar with the Microsoft Office Customization Tool (OCT). If you aren’t, you will find plenty of information on TechNet.
OK, so let’s open OCT by navigating to our Office 2010 installation directory and running “Setup.exe /admin”. Don’t forget you need to use Volume Licensing media to gain access to OCT.
We can apply our changes using the “Add registry entries” section. You’ll notice there is a convenient Import utility, which will allow us to… you guessed it… import settings from the .reg file we created earlier.
And we’re done! make sure you have your “Count” value in there, as well as the keys and values you wish to propagate out to all your users. Just save your.msp file and you are ready to go.
But hang on a second, why don’t we just use the “Add registry entries” and “Remove registry entries” sections in OCT and forget all this HKLM –> HKCU propagation rubbish? well…. I’ll tell you why… it’s because of a fairly major limitation in the OCT’s behaviour. Essentially the OCT will add entries just fine, however it will not modify or remove HKCU entries that Office creates at first log on. This is presumably due to the fact that the Office HKCU default entries are only created when a user launches an Office application for the first time. It appears that the OCT custom registry entries are applied before Office creates its default entries, so the custom entries are simply overwritten.
Well there you have it! a fairly easy, definitely robust mechanism for adding custom Office registry bits and pieces to all users on a computer. I hope this is of some use to you and saves you time as you prepare for your deployment.
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...
I recently posted an entry on USMT Migration using LiteTouch, which would help you quickly enable a fairly comprehensive migration in as little as a...
Today is a very exciting day as Microsoft announce the next generation of Office 365 and the Office suite, and everything that comes along with it....