Deploying Custom Registry Settings for Office 2010

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 “HKLM\Software\Microsoft\Office\Word\Addins”), or maybe you want to tweak the status bar in more detail than OCT or Group Policy allows (In “HKCU\Software\Microsoft\Office\14.0\Word\StatusBar” ). 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:

• During the Office installation
• After the Office installation
• When the user who installed Office first launches an Office application
• When a different user first launches an Office application
• When settings are changed by the user at some other point in time

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.

Step 1 – Propagating the Settings

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

   HKLM\SOFTWARE\Microsoft\Office\14.0\User Settings

Windows 64bit, Office 2010 32bit

   HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings

Windows 32bit, Office 2007 32bit

   HKLM\SOFTWARE\Microsoft\Office\12.0\User Settings

Windows 64bit, Office 2007 32bit

   HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\User 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 HKCU\Software\Microsoft\Office\14.0\Word\StatusBar, so the key I need to make is as follows:

HKLM\Software\Microsoft\Office\14.0\User Settings\FTSettings\Create\Software\Microsoft\Office\14.0\Word\StatusBar

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.

Step 2 – Deploying the Settings

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.

If you want to see the functionality in action, take a look at this video - https://www.youtube.com/embed/cloO05XDzVo

 

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.

This post was contributed by Richard Smith on behalf of our guest blogger - Yoni Kirsh (ykirsh@ftpl.com.au) a Microsoft Virtual Technology Solutions Professional (V-TSP) working with the Office Team

Comments

• Anonymous
  January 01, 2003
  If you are planning to customize your Office 2010 deployment significantly, then at some point, you will

• Anonymous
  June 03, 2011
  Nice! Thank you! Is this Hive progagation feature published in official Microsoft documentation?

• Anonymous
  June 16, 2011
  Very helpfull article. Am I correct that the registry example used shows FTSettings instead of FTpropagation? This might be confusing. HKLMSoftwareMicrosoftOffice14.0User SettingsFTSettingsCreateSoftwareMicrosoftOffice14.0WordStatusBar

• Anonymous
  June 26, 2011
  Will this work with Outlook settings or making changes to current user settings?

• Anonymous
  June 27, 2013
  This is not working for me when I try to perform this using the OCT. I try to propagate the following values: HKLMSOFTWAREWow6432NodeMicrosoftOffice14.0User SettingsFTPropagationCreateSoftwareMicrosoftOffice14.0PowerPointOptions GridVisible=0x00000001 But the only Key/value that gets propagated is the  FTPropagationCount =1 value Although all the subkeys under FTPropagation are all specified to be created separately as empty keys, nothing under FTPropagation key gets created. Any thoughts?

• Anonymous
  July 15, 2013
  Increase the Count value to 2.

• Anonymous
  September 06, 2013
  Hi there, thanks for the clarification! :) Everything works fine except my Outlook keys. I set several values [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftOffice14.0User SettingsmyDeploymentCreateSoftwareMicrosoftOffice14.0CommonMailSettings] "ComposeFontComplex" and others. When I start Excel or PowerPoint or Word as a new user, all values are prograged correctly. But when I start Outlook afterwards, the MailSettings keys are gone. However "Template" and "NewTheme" are left untouched... Count is set to 1. I've seen "Order" keys here and there. Can I use this to prevent the deletion?

• Anonymous
  May 17, 2014
  Is there a way to use the registry to change the default language for office 2010 in Windows 7?

• Anonymous
  June 06, 2014
  Jason, thanks for sharing [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftOffice14.0User SettingsmyDeploymentCreateSoftwareMicrosoftOffice14.0CommonMailSettings] font settings will be deleted.
  Unfortunately this is also the case when manually entering these entries in the registry and then start Outlook (1st time).
  After closing Outlook values are deleted.
  Guess this has to do with 1st time run of Outlook somehow.

• Anonymous
  July 30, 2014
  Hello. Does this automation procedure also work with Office 2013?

• Anonymous
  September 05, 2014
  I have been trying to use your example to add a custom addin that we use for Microsoft word, but the HKCUSoftwareMicrosoftOfficeWordAddins just does not seem to want to populate. Does this process not work for settings that reside outside of the "Office14.0" folder? Thank you.

• Anonymous
  November 26, 2014
  Hi. Since updating to SP2, this no longer seems to work. It did previously. Any ideas? Thanks

• Anonymous
  December 31, 2014
  Hi,I have installed outlook addin for all user and there is correct value in registry for addin,but addin is not showing in outlook addin list i.e active/inactive or disabled addins. Any idea?

• Anonymous
  January 20, 2016
  It seems to me it works only with standard Office app such as Excel, Word, Outlook, etc, but not with extended Office app that install separately, such as Project. Is that true? How can we work around this if anyone knows?