Workspace Virtualization: Office 2010, MUI, Standalone Applications, Concurrency, with Full KMS Support for Enterprises
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:
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
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. :)