Here is a quick walk through showing the keys that are used to control the CMW and custom MSP files to determine what settings will take effect and if they had been run for the current user or not.

For the purpose of this walkthrough I have created this maintenance MSP. To keep it simple I am going to apply the following two changes in this custom .msp.

disableLivePreview

Add reg key

I then saved my custom maintenance MSP.

We will want to discover the GUID for this MSP. To find the GUID of a maintenance MSP you can right click the msp and goto properties. We will be looking at the revision number.

*note* In vista you will not be able to find the GUID this way.

From Windows 7:

custom_msp_properties

From Windows XP:

XPProp

So the GUID for this Custom.msp is {F920DCF9-E152-416E-A665-0E8342E48E1C}.

*note* If you make any changes to this custom.msp and resave the guid will change.

Now I am going to install this custom.msp on a machine that already had Office 2007 on it. Now that it is installed let’s dig into what happens in the background to ensure that these settings apply to each user.

Here is a screenshot of where the workstation keeps track that the MSP file is installed and what it is supposed to do on the machine. 

After running it, it gets listed in:
HKLM\software\wow6432node\microsoft\office\12.0\user settings\{GUID} (For a 64bit machine)
or
HKLM\software\microsoft\office\12.0\user settings\{GUID} (For a 32bit machine)

This key basically tells Office that there is a MSP file that was installed and needs to be run for each user. The things to notice, #1 the count value and #2 the subkeys below the guid will list the actions that the patch will take when the settings apply to the individual users.

Count = 1
Capture 

We see here that it is going to set HKCU\Software\Microsoft\ODSupport, and we can see it will also set HKCU\software\microsoft\Office\12.0\Word\options\Vpref  fLivePreview_2902_1=0X00000000 (0).

The fLivePreview registry key is what controls “enable live preview”. In this case we are unchecking it.
Capture2

Now look at the same location but in HKCU. This is how Office determines if it has been run for the current user or not.  Notice that I am missing HKCU\software\microsoft\office\12.0\user settings\{F920DCF9-E152-416E-A665-0E8342E48E1C}.

HKCUhive

It is missing because I have not yet run Office after applying the MSP file.

This next screenshot is after I opened an office product. Now that I have run an office product I do have HKCU\software\microsoft\office\12.0\user settings\{F920DCF9-E152-416E-A665-0E8342E48E1C} with a count of 1. This key basically tells office that this MSP file has already been run for this user, and thus doesn’t need to be run again. This is how an msp knows to apply or not apply to each user. Even if you double clicked the MSP file a second time, it still wouldn’t reapply for the user below because that MSP has already been run once according to the HKCU\software\microsoft\office\12.0\user settings\{GUID}\Count=1 key. Reinstalling the MSP will not increase the HKLM count and as long as the HKLM and HKCU count match it will not re-apply. You could make a new MSP and apply it and then that one would apply because the new MSP would have a new GUID with its own count.

HKCUhive2

Notice my settings have taken effect:

livepreview

odsupport

If you wanted an MSP file to re-apply to test its settings or its functionality, you could simply delete the HKCU\software\microsoft\office\12.0\user settings\{GUID} key and rerun office. Since the HKCU count won’t match the HKLM count, it will re-apply. Or if you wanted to get it to re-apply to all the users on a machine you could just increase the HKLM count to “2”. When the users launch office the HKLM count won’t match the HKCU count value and the MSP will re-apply.

Both MSP files and Office 2000-2003 CMW files operate in this way. There is one major difference between MSP files and CMW files however.

If you rerun an msp the local HKLM count value will always be 1. It doesn’t increase the count, so it will never reapply for a user. This is not case with a CMW file. Each time you apply a CMW, the HKLM “count” key will increase and cause the CMW settings to re-apply for users even if it had applied for them previously. This can cause issues especially in roaming environments.

Take this scenario into consideration.

You have a network that has enabled roaming profiles. You have 5 terminal servers in your terminal server farm that people  connect to with their roaming profile. The terminal servers in the farm have load balancing is enabled. You have a CMW file that you have applied to all 5 terminal servers that is designed to autocreate users Outlook profile. On one of the terminal servers you have applied the CMW twice by accident or otherwise.

Let’s say that there is a user named Jim who connects to the terminal servers and hasn’t had any problems until last Friday. Last Friday when he hit the term server farm and opened outlook, outlook expectantly reconfigured on him. This is the first time this has happened to him. In this scenario you can see that what happened is that Jim was lucky enough to always be routed to the 4 terminal servers that did NOT have the CMW file run more than once. As a result when Jim closed his previous sessions his HKCU count for the CMW file was always 1. Then last Friday when he hit the term server farm he was routed to the 5th terminal server that had previously had the CMW file run twice. As a result that terminal server has an HKLM count of 2 for the CMW. When he opened Office an evaluation was done and the machine discovered that his HKCU count was 1. As a result it reapplied the CMW file thus overwriting his previous Outlook profile.

When using CMW files in a roaming environment it is important to make sure that the CMW file is not rerun on some machines unless it is rerun on all machines as you don’t want a mismatch of HLKM counts for a particular CMW.