Video Screencast Help

Workspace Virtualization: Office 2010, MUI, Standalone Applications, Concurrency, with Full KMS Support for Enterprises

Created: 15 Apr 2011 | 11 comments
Language Translations
EddieNYC's picture
+9 9 Votes
Login to vote

Some folks on here on Connect have seen a lot of the threads on getting SWV working with Office 2010 to virtualize it, and have seen that I've been pretty active.  In this article, I'm going to basically discuss end-to-end how to get Office 2010 working in an Enterprise environment, where you would have KMS activation, Multilingual User Interface support (MUI), other Office 2010 standalone applications, and potentially other Office versions that you may need for backward compatibility/legacy support.

First thing's first, I will first discuss are the major challenges:

1. While the new Skylark (SP7) release, Office 2010 is supported (finally) out of the box.  This works if you only work with Office 2010, as when you capture it, the Office Software Protection Platform Services (OSPPSvc) is captured and will work with KMS.  However, the challenge is if you use any other Microsoft applications that use OSPPSvc that are captured in other layers (ie: Visio 2010, Project 2010, etc.), because each layer has their own OSPPSvc instance, it causes token key conflicts and every time you open each application it will go through a new configuration to pull a new token from your KMS each time, which is a lengthy process.  After you reboot, depending on which order the layers get activated, you will have this issue again.

2. If you capture Office 2010, your 20 day grace period for KMS activation will be lost by the time you deploy.  Thus if your user is not connected to your network (physically, wirelessly, VPN), they will get an error on the first run saying the software is not licensed, and the application will forcefully quit.  Yes, you can use Office 2010's rearm command, but this is not a clean way of doing this.  If you have a lot of mobile users, sales force, etc. this will be a huge pain.

3. If you capture Office 2010 English as your main layer, and want to create another layer for each MUI for each language your enterprise supports, the Help functionality doesn't show in the MUI language.  Also sometimes when you set the language settings (setlang.exe in the Office14 folder), sometimes it doesn't set it properly, or writes the registry in weird locations, and thus these reg keys don't "stick" depending on what order you activate the layers.

For the documentation below here are the assumptions:

1. You're capturing on a clean VMWare instance, all my examples are based off Windows 7 Enterprise 32 bit English

2. You plan to have these separate layers: Office 2010 Pro English (with any appropriate admin file if you have it), Office 2010 MUI (one for each language), Visio Pro 2010, Project Pro 2010

3. You're a corporate environment with KMS activation (although if you use standard MAK should be the same as MAK uses OSPPSvc as well)

First Step: Capturing Office 2010

1. Go to your VMWare, install SWV SP7 (Skylark).  Begin capture by capturing a command line window (capture c:\windows\system32\cmd.exe)

2. Run your setup with your admin file (if you're preconfigured it, otherwise manually go through the setup dialog boxes).  So run: setup.exe /admin "adminfile.msp"

3. Run any additional things you want to capture to the main office layer (except the MUI).  In my case, I ran the setup for the proofing tools, some hotfixes, patches, and SP1.

4. End your capture.  Deactivate the layer.

5. Under MSSharedTools look for a file called "OSPPrun.exe".  Copy this file to a share somewhere, as you will need this file later for a different layer.  Delete this file from the layer.  Also go to: [MSSharedTools]\office14\officesoftwareprotectionplatform.  Copy these to a file share somewhere as well, as we will need these later.

6. Now we need to strip out all the OSPPSvc instances in this layer.

How to strip out OSPPSvc from a layer:

1. Edit the layer, and delete the following:
System/[AllUsersProfile]/Microsft/officeprotection platform
HKLM\system\currentcontrolset\services - delete any instance os OSPPSvc and CLR_optimization* (wildcard)
In the registry delete any instance of MUICache (usually this is in the user hives)
HKUSERS\s-1-5-20  (or any similiar short GUID)

In [MS Shared Tools] delete:
office14\office setup controller
- pidgenx.dll
- pkeyconfig*.*

All user profile\microsoft\officesoftwareprotectionplatform

In the program files\Office14 folder, delete:

In the Delete Entries tab, clear out all the delete entries, as we do not need them deleted.

Close the layer properties.  Now on the VMWare physical registry, we need to edit the read only layer directly to strip out the OSPPSvc services...

On the VMWare host, go to start, and type in Regedit.  Assuming the Read only layer is #1, go to the registry:

Now we need to search and delete anything that has osppsvc listed.


Now for these areas, this is basically the services the layer starts when you do any SWV Action (activate, deactivate, etc.).  You'll have to go through the subfolders which are numbers and delete any folder # that has osppsvc listed.  We are basically removing the services from being run/started/etc.

HKLM\system\currentcontrolset\services\fslx\parameters\fsl\1\services\Postactivate\<some #> (look for any osppsvc)
HKLM\system\currentcontrolset\services\fslx\parameters\fsl\1\services\Postdeactivate\<some #> (look for any osppsvc)
HKLM\system\currentcontrolset\services\fslx\parameters\fsl\1\services\Predeactivate\<some #> (look for any osppsvc)
HKLM\system\currentcontrolset\services\fslx\parameters\fsl\1\services (delete osppsvc)

Exit the registry.

Now activate the layer, deactivate the layer, and reset.  The reason that we are doing this is so that it will activate faster on the end users machine when you deploy as this generates the initial hashcache.  If you don't do this, the first time activating on an end user's machine takes longer.

Export the layer.  The Office 2010 Pro English layer is ready.

For your standalone applications (Visio 2010, Project 2010, Outlook standalone 2010, etc.), you would follow essentially the same procedure.  Capture via the command method, and strip out all the OSPPSvc instances.

Now lets create your MUI's!

Step 2: Capturing your MUI's.

1. On a clean VMWare instance, install SWV SP7 (Skylark).  Now what you want to do is install Office 2010 physically to the machine EXACTLY the way you did in the layer (but without stripping out the OSPPSvc components).  So follow the instructions exactly how you installed office 2010 to the layer but install it physically to the base, with the same patches, same admin file, proofing tools, etc.  It's key that this be 100% exact.  The reason we are doing this, is that we are going to fool SWV to create a new layer so that only the MUI components are installed to a new layer, but since you can't capture with an existing layer active (Office 2010), this is essentially the same thing.  On the VMWare you should make a snapshot once this is done and make note you have SP7 with Office 2010 physical installed to the base.  You will use this snapshot each time you create a new MUI layer, as we want to create one for each language.

2. Capture the command window, and install your MUI language.  In my case I put Chinese (both traditional and simplified) in one layer, Japanese in another layer, French in another layer (these were all captured separately, reverting to the snapshot we did in step 1).  Once it's done running in the setup, in the command window, navigate to c:\program files\microsoft office\Office14.  Run setlang.exe.  This will bring up your language settings window.  Configure these how your country standards require.  For example Quebec requires by law that all dialog boxes and settings be set in French.  So I set all 3 panels to French, including the help.  Save these settings as default, then close this window.  Now exit the command prompt and capture should be done.  Deactivate the layer, as now it's time to clean it up.

3. You will have to clean out the OSPPSvc from these MUI layers just as you did with the Office layer, as yes there's remnants, although not .  This is important!  :)

4. Now in autorun, you want to add the following:
C:\program files\microsoft office\office14\clview.exe  (this will get help to show in the MUI's native language if you set it that way)
C:\program files\microsoft office\office14\setlang.exe  (this will keep registry changes if the user changes the language MUI settings and stores it to the MUI layer)

5. After that remember to generate the hashcache by activating/deactivate/reset then export

Ok now that we are done with the working layers, we need to outsource the job of the OSPPSvc to a new layer.  The good news is that Microsoft's own streaming solution (formerly Softricity Softgrid), App-V has a similar problem where other standalone will compete if the OSPPSvc is in each virtual layer.  So what they did is ripped out all the OSPPSvc components into an installer so you can install it!  Wow, that makes our lives a lot easier!

Next Steps: Capturing App-V Licensing Components

Please download the App-V Licensing Component (x32) installer here:

Now you will have to build a msiexec string of all the token keys you would like this licensing solution to populate from your KMS.  Note this is not consuming a license, it actually creates a token key for the bins in advance so that if you do install the layer with the binaries for those programs, it will pick up the token.  The good news is that you can deploy this layer first to your users, and they will get valid tokens as they are on the network, before you even deploy your office layers.  This alleviates the need to use the rearm command.  Also since the OSPPSvc are in one layer and not scattered in multiple layers, the Office 2010 apps won't fight each other, as long as you remember to remove all the OSPPSvc instances from the layer.

Ok so for reference you need to generate your MSI chain for your valid apps.  These are documented on Microsoft's site here:

For example, here's mine:

msiexec /i OffVirt.msi ADDLOCAL=Click2runMapi,Click2runOWSSupp,Click2runWDS,OSpp,OSpp_Core PROPLUS=1 PROJECTPRO=1 PROJECTSTD=1 VISIOPREM=1 VISIOPRO=1 VISIOSTD=1 KMSSERVICENAME=PutYourKMSfullyQualifiedDomainNameHere KMSSERVICEPORT=1688

So put this in a text file and go to your CLEAN vanilla VMWare instance.  Install SWV SP7 (skylark), and via the command line capture method, capture using the msi string that we put in that text file.  Exit the capture and now it's time to edit the layer.

Remember when capturing office I said to copy those files to a share somewhere, now it's time to put them back!  So put the OSPPrun.exe back in the  MSSharedTools folder.  Also copy back the [MSSharedTools]\office14\officesoftwareprotectionplatform folder and it's contents to this layer.  Exit the layer properties.

Now in the SVSAdmin, right click the layer, and make sure you check mark the following options:
Set layer to hide other layers from this layer
Keep file changes

The reason we are hiding other layers from this layer is because we want the App-V licensing component to think it's by itself, and not interfere with the other layers.  However, all your office and 2010 related software will see the tokens properly and play nicely.  Your App-V licensing layer is simply to do nothing but ping your KMS so that it purely maintains the 180 day activated window, and not care about anything else.  Congrats, you have successfully outsourced OSPPSvc to it's own layer!

################## Value Add: Concurrency of Office 2010 with previous versions of Office

You might be in a hybrid environment that's in transition with Office 2010, so you still have to support Office 2010 and some previous versions of Office.  Now the main issue with other versions of office is that they will try to hijack each other and invoke Office repair.  This is bad because it will run the repair to the physical host and not to the base, and you'll be left with a machine that's royally messed up.  Not only that it's a time costly process and very annoying if you're going from one version to another.

With office 2003 and 2007, you don't need to worry about the OSPPSvc nonsense if you use MAK keys, so if you captured that method, we will assume you're using that with the KMS Office 2010 as described above.

Ok in this example lets pretend my Office 2003 layer GUID is 50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99.

Go to the machine you staged your capture with, and navigate to the physical registry (not the layer properties), ie: type regedit in start.

Go to HKLM\System\CurrentControlSet\services\FSLX\Parameters\FSL

Navigate to the ReadOnly # folder for your Office 2003 (or Office 2007 or whatever stand alone component)

Create a multistring value called "IsolationRules"

Cut and paste the following to notepad (the spaces are actual tabs, there are no spaces, this is important)

*\msaccess.exe    BASE    0x0002    \REGISTRY\*    *    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99
*\msaccess.exe    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99    0x0002    \REGISTRY\HKEY_CLASSES_ROOT\*    *    BASE
*\excel.exe    BASE    0x0002    \REGISTRY\*    *    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99
*\excel.exe    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99    0x0002    \REGISTRY\HKEY_CLASSES_ROOT\*    *    BASE
*\powerpnt.exe    BASE    0x0002    \REGISTRY\*    *    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99
*\powerpnt.exe    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99    0x0002    \REGISTRY\HKEY_CLASSES_ROOT\*    *    BASE
*\winword.exe    BASE    0x0002    \REGISTRY\*    *    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99
*\winword.exe    50cfaaa9-258a-4bd2-87d6-b1bb5d2a3f99    0x0002    \REGISTRY\HKEY_CLASSES_ROOT\*    *    BASE

Replace my layer GUID with yours.  Now put cut and paste the entire 8 lines into the IsolationRules key that we just created.  When you see it listed it looks like garbage with square boxes as tabs, but if you double click to open the key you will see that the tabs are still there.

Exit regedit, and since we directly edited the ReadOnly area of the layer we can now Export this layer and the isolation rules will move with that layer.

Import this layer to your target machine, and set the following priorities:
svscmd "Microsoft Office 2003 English" PRIORITY -T NORMAL -L 85
svscmd "Microsoft Office 2003 English" PRIORITY -T HKCR -L 64.5

This is the last step to ensure that they won't fight and that the Office repair won't go crazy on your machine.  You would do the same for all other non Office 2010 apps and Office suites (although obviously if you're using project, change the exe's above to winproj.exe or whatever respective application executable you are using for that layer)

Congrats!  You can now successfully run Office 2003, 2007, and 2010 suite/apps on the same machine!

Hope this helps you, as this is the culmination of a lot of research, trial and error, and much frustration consolidated into one how-to guide.  :)

Best Wishes,

Comments 11 CommentsJump to latest comment

prsegtek's picture

5. Under MSSharedTools look for a file called "OSPPrun.exe".  Copy this file to a share somewhere, as you will need this file later for a different layer.  Delete this file from the layer. 

I looking in the layer properties and I did not see the OSPPrun.exe file. I also activated the layer and searched the whole HDD and I did find the file either.

Login to vote
jwheatman's picture

1. I can't find the OSPPrun.exe file either. Can you help me out?

2. Are all changes made only to read-only layer?



Login to vote
EddieNYC's picture

C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\

Yes changes made to the read only layer (in properties) from the SVSadmin.exe

Just to confirm are you working with an enterprise source or retail?  The retail ones do not ship with OSPPrun.exe so make sure you download the actual Enterprise source with KMS activation from the Microsoft Volume Licensing site.

Also on a physical install this file actually disappears after install, so make sure you do this in a layer...

"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote
EddieNYC's picture

Here's how it appears on SVSadmin in the Read only properties with an enterprise KMS source captured before ripping out OSPPSVC stuff:


"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote
jwheatman's picture

I downloaded the ISO from the Microsoft Volume Licensing Center. I do not see a specific KMS version. The OSPPrun.exe doesn't exist in my layer's properties.


Login to vote
EddieNYC's picture

I think you will have to talk to your Microsoft rep about your licensing then, as if you are using a KMS server in-house, you should have a KMS activated source ISO installation which only works with KMS activation unless you manually use a MAK key.  I've confirmed this evening with a few other contacts with other companies who have also confirmed that this is only in the KMS enterprise installation source.

It looks liks prsegtek also was able to find it as well...

"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote
EddieNYC's picture

Update from

Taxus812 said:

We didn't see it either.  We are using Enterprise. 

We do have it running and both packages are streamed to boot. (we had to tweak the service type in the Microsoft Office 2010 Deployment kit for AppV to be type 2 instead of type 3 however for it to stream). 

We do not have the OSPPRUN.EXE either so we omited that step with no issues.

Our Microsoft Office 2010 Deployment kit for AppV package also works with Visio Pro and STD and project Pro and STD without issue.

Hmm this is good to know.  For clarification my level of Enterprise Agreement is a full Software Assurance license agreement level.  Not sure if this makes a difference.  But it's good to hear it's working for others who do not see the exe in their builds...

"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote
EddieNYC's picture

A few people pinged me about trust center sometimes takes awhile to open (30 seconds).  To fix this, simply disable the research options by adding these keys to the Office 2010 layer (keep note that it's both on the user template hive and local machine hive):







"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote
EddieNYC's picture

Noticed a bug that wasn't picked up because the test machine was always in English and not using the language bar.  After putting this on a machine that uses IME multilanguage inputs the layer drops Chinese (simplified, traditional), Korean, and Japanese to the added keyboards for some weird reason.  This is irritating to the end user if they don't need these languages and only use say French and English.  The source of these is coming from the proofing tools and proofing tools SP1 that get installed to the layer and leave junk all over the place and for some reason leave these 3 countries keyboards enabled.

Basically what we need to do is pull the keyboards from the preloaded keyboards and disable the preload of the IME's for those country codes.

For reference, you can pull the full list of country codes from your own registry which list every country code here:
HK Local Machine\System\CurrentControlSet\Control\Keyboard Layouts\

In the layer remove from country codes from HK Current user\keyboard layout\preload
804 - China Simplified
404 - China Traditional
411 - Japan
412 - Korea

This is not enough to stop the preloading.  You need to go to all the CTF\TIP for each language and disable them... (also in current user)
[HKEY_LOCAL_MACHINE\Software\Microsoft\CTF\TIP\{GUID}\LanguageProfile\0x00000404\{GUID}] (replace 40 with other country code)
- set value: Enable = 0

Also in Current user, you need to set all the preloads to 0 for any IME* library.

Don't worry, this only removes it from the Office 2010 layer, the keyboard will still remain on the OS level for that user.  Also if you're using MUI's in a separate layer, it'll take care of the keyboard localization nicely.  This is only for your main office 2010 layer so it will only show up in English as a standard.

Below is what you can paste into a reg file, then import into the layer (don't run in the layer, go to the properties, registry and import the file), as these are the changes I made to fix this.  (note while [-HKEY\etc] will delete a key, apparently Value = "-" does not.  It will actually set the value to a dash!  Might be a SWV bug, so that's why I just simply wiped the hive and populated back the English).

Windows Registry Editor Version 5.00













[-HKEY_USERS\USER_TEMPLATE\Keyboard Layout\Preload]
[HKEY_USERS\USER_TEMPLATE\Keyboard Layout\Preload]





















"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote
EddieNYC's picture

More tips for outlook users...  (I commented this on another Outlook 2010 thread and realized it would pertain here too)

Also one thing to mention, a good idea if you're migrating from layers and want to preserve your setup (assuming your PST, OST, and all other files are correctly excluded), you can back up and restore the hive from the registry...

[USERPROFILE]\Local Settings\application data\microsoft\outlook

Another tip, to prevent that annoying prompt the first time you run Outlook to ask if it's ok to keep checking if it's the default mail client, best to use this (edit directly in the layer reg properties)

"Check Default Client"=dword:00000000

Then once your layer is done here's how to bring back the user profile... (assuming you didn't blow it away yet).  With your current outlook/office layer activated on the user's machine

regedit /e "C:\Windows\backups\OutlookProfile.reg" "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles"

Then delete the old Outlook / Office layer...

Import your office 2010/outlook layer

Then inject the exported reg key back into the layer:

svscmd "layer name" exec -P "regedit /s C:\Windows\backups\OutlookProfile.reg"
svscmd "layer name" NEWRESET
svscmd "layer name" A

"Rather fail with honor than succeed by fraud." - Sophecles

Login to vote