The Deployment Guys

Helping to deploy your world automagically...

Deploying Custom Registry Settings for Office 2010

Deploying Custom Registry Settings for Office 2010

  • Comments 9
  • Likes

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”

image

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.

image

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.

image

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.

image

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.

imageimage

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.

Office Registry Keys Video on YouTubeIf you want to see the functionality in action, take a look at this video - http://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

  • Nice! Thank you!

    Is this Hive progagation feature published in official Microsoft documentation?

  • Very helpfull article.

    Am I correct that the registry example used shows FTSettings instead of FTpropagation? This might be confusing.

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

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

  • Will this work with Outlook settings or making changes to current user settings?

  • This is not working for me when I try to perform this using the OCT. I try to propagate the following values:

    HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings\FTPropagation\Create\Software\Microsoft\Office\14.0\PowerPoint\Options

    GridVisible=0x00000001

    But the only Key/value that gets propagated is the  FTPropagation\Count =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?

  • Increase the Count value to 2.

  • Hi there,

    thanks for the clarification! :)

    Everything works fine except my Outlook keys.

    I set several values [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings\myDeployment\Create\Software\Microsoft\Office\14.0\Common\MailSettings]

    "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?

  • Is there a way to use the registry to change the default language for office 2010 in Windows 7?

  • Jason, thanks for sharing [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings\myDeployment\Create\Software\Microsoft\Office\14.0\Common\MailSettings] 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment