Microsoft Office is an application that is generally easy to install into a layer, and, if it will be used by itself, there are no complexities other than activation. If your organization's requirements are more complicated, then there will be more things to keep in mind. If you use Office Add-ons, these should be included in the office layer, but can sometimes be installed in different layers with Office checked as a prerequisite layer during layer creation. When using add-ons in separate layers, it is recommended to include all previously included add-ons also as prerequisites to ensure that they will work together properly if they will ever be deployed together. Note that some Office add-ons, like for Excel, are installed directly in the user profile, so can't be layered. User profile installations must be done in the end-user VM while logged in as the user.
KMS should be considered a requirement for VDI deployments of Office 2010 and higher. Volume licensing should also be considered a requirement for Office 2007 and earlier. It is possible to use a different licensing structure than volume licensing; however, it will be more difficult to manage as each license must be activated separately on each desktop.
The easiest way to manage the actual configuration of Office itself is through the extensive list of GPO's provided by Microsoft Office. Every setting for Office can be changed through the Microsoft GPO's.
This recipe covers all versions of Office between Office 2010 and Office 365.
Back to top
While it is possible to use a layering strategy based on installing the main Office application first and using that as a prerequisite for say Project and Visio etc., we recommend that you create separate layers for each full set of Office apps you will distribute. So, if you use Office 2010 Std, Project 2010, and Visio 2010 and some users have Project, some Visio and some both then you would create 4 layers:
In this case you will have one more layer than if you created the layers separately with prerequisites, but updates will be much easier to perform and you won’t have to worry about always including the correct prerequisites to keep all the layers intact.
If your licensing permits it would be better to provide all users all three applications and have just one layer, but that often is not possible.
Citrix recommends that the all Office applications be included as part of the layered image.
If you’re licensing for Visio and Project allows all your users access then you can create a single layer with all of Office and add it to your image.
Running Visio and Project as elastic layers will cause issues with broker sessions or a reconfigure when the applications are run because of the way Office Apps update the windows store.
If you need a smaller set of users to have access to Visio and Project then you must create a second layer for Office, Visio and Project, as described above, and include that on a separate Layered image.
An alternative to that is to use Visio and Project as published apps on XenApp.
Back to top
When the first Office application is run for the first time on a desktop it creates a CMID for the application on that desktop that uniquely identifies the application instance for licensing. Therefore, when packaging Office for an image installation as we do with App Layering, the best option is to rearm the office deployment before finalizing. This will reset any licensing information to allow an image deployment. The command used to rearm Office 2010 is:
C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe
Office 2013 and 2016 slightly changes the folder that contains ospprearm.exe:\
C:\Program Files\Common Files\Microsoft Office\Office15\ospprearm.exe
Note: For Office 32 bit on 64 Bit Windows look in the Program Files (x86) folders.
If you are using MAK keys and not KMS, then activation must be run on each desktop after the layer has been deployed. You can activate on the desktop using the ospp.vbs script or using the Volume Activation Management Tool (VAMT 2.0/3.0).
Note Microsoft has changed activation with Office 2013 allowing not only KMS and MAK activation for Windows 7 but also AD Activation. When using the AD Activation keep in mind that it will tie the account to the machine it is activated on. When a Non-Persistent desktop is refreshed Office will no longer have that binding, but Microsoft may still have the machine information recorded.
Later in this document we discuss automating licensing using ospp.vbs scripting. We encourage you to read and understand the power of this approach if you have a complicated set of office requirements.
Citrix recommends including the OS Type and OS bit level in the name, for Example Microsoft Office Pro 2010 Win7x32. For versions, remember that when choosing a layer you can see the version name but not the version description. Use naming that will allow you to differentiate versions appropriately. For example “1.0 12-12-2012”.
Back to top
All of the Office products share a licensing file and the method of activation. For KMS licensing, Activation can be automated or activation can be performed on first use. For MAK based licensing an automated activation approach works best.
This recipe provides an automated approach to the installation of both KMS and MAK keys when deploying desktops. This solution can be used if you are only deploying office itself or if you are also integrating Visio and/or Project and even if you are integrating different versions of Visio and Project.
The solution has several separate components including:
If you need to support different versions of Office you will have to perform this whole process more than once. It is far easier to support a single version of Office itself because it will greatly reduce the number of permutations you have to deal with.
In 4.x a layered image is created and then deployed using a provisioning system. For Citrix MCS and Horizon View Linked clones the Master Image/Parent VM’s should have Office Applications activated before they are snapshotted for deployment. The included Citrix activation scripts will activate Office when the Master Image/Parent VM is first booted.
For PVS each machine will have office activated every boot if using our scripting.
Our scripting will also rebuild the Office WMI before activating office to ensure that activation works properly.
Office Activation scripts have been included in conjunction with the Citrix optimizer for a long time. However they are often updated. When you upgrade App Layering versions it is recommended to also upgrade the scripts that come with our gold tools self extracting zip.
To do this add a version to your OS layer. Download the tools from the Citrix downloads web site, from the Tools section, called "citrix_app_layering_os_machine_tools_{version}.exe". Or if you are automatically receiving App Layering software updates from Citrix through the ELM, the OS MAchine Tools package is in your configured Network File Share, in the Unidesk\Upgrade Disks\{version} folder, with the same name as above. Put that file in your packaging machine. Right-click on the .EXE, get Properties, and select to Unblock the file if offered.
Then execute the installer. It will unpack the scripts into the C:\Windows\setup\scripts folder. These files include new versions of the optimizer, kmssetup.cmd and the three office specific scripts we care about: OfficeActivate.cmd, NoReReg.cmd and Office2013Windows81_PREP.cmd. Running the installer will overwite the scripts already present in the OS layer, but it will not remove or overwrite any configurations you have already specified. The settings you have specified are stored in files that are not part of the scripts package. So you don't have to worry about preserving anything. It can't hurt to make a copy of the Scripts folder before you start, but there should be no danger.
Updating the scripts in the OS layer allows you to use them for all the Office layers you might want to use. For Office the utility provides the ability to activate office during or after the build using KMS by just selecting the appropriate checkbox when creating the layer. MAK is also supported but not recommended.
Do any other OS layer updates desired and finalize the OS layer. If you choose to run the Optimizer in the OS Layer, please do not select any Office options yt. Office options should always be done only in the Office layer itself.
This step runs through the process to create the application layer for Office
C:\windows\setup\scripts\Office2013Windows81_PREP.cmd
C:\windows\setup\scripts\Office2013Windows81_PREP.cmd
When creating the Office layer, use an ISO or Network Install Point. If you use a .EXE package for Office it will first unpack into the layer making the layer much larger.
If you will choose not to activate using a script and the version of the Office product you want to deploy is different from the version your installer installs by default, you can change the version using the ospp.vbs script (Office Software Protection Platform).
For example, to change the Visio Premium version installed by the Visio installer to Visio 2010 Pro use the KMS key for that version and run the following cmd at an administrative cmd prompt:
"c:\program files\Microsoft Office\office14\ospp.vbs" /inpkey:7MCW8-VRQVK-G677T-PDJCMQ8TCP
This will change the version of Visio to Visio Professional so that the first time it is set and activated it will work. If the first application fails, our testing shows that further activation can fail as well.
The Citrix Office Activation script (OfficeActivate.cmd) has all of these commands built in for all Office Products using Office 2010, Office 2013 and Office 2016. Use the appropriate command for your situation.
These scripts are available in the Gold Image Tools Version 5.x and later.
If you are using these tools, just run the App Layering Optimization Builder utility and choose which Office applications are installed in the layer. The script will handle entering the product key and activating all the Office applications included in the layer.
Use GPO’s to configure user settings. User settings are not captured in an Application Layer.
The newest versions of the Citrix Optimizer tool will automatically run the Office preparation script. If after running the Optimizer tool you see the message “Microsoft Office preparation script ran successfully.” then you can safely skip this section as the script has been automatically run for you.
If you are installing Office 2013, 2016 or 365 on Windows 8.1 or Windows 10. After installing your Office applications and before finalizing, the script Office2013Windows81_PREP.cmd script must be run. This will make copies of two files:
C:\windows\system32\spp\store\2.0\data.dat
C:\windows\system32\spp\store\2.0\tokens.dat
and store them for use later on the desktop or session host. Then when the activation script is run they will be copied up to their original location but in the UEP of the desktops so that they match what the office layer saw when it was installed. That script is now run automatically by the App Layering optimizations tool when you select an applicable version of Office.
The store copy is performed via startup script. The scripts will wait for the Software Protection Platform to stop before copying the store. This can take a while - even 2-3 minutes or more.
Therefore, if you log right on to the desktop or XenApp host right when it boots up, the scripts may not yet have run. If this becomes an issue there is a setting in XenDesktop (7.7 and later) that delays registration for a defined period after boot to allow scripts to run.
The setting that allows this is for Delivery Groups and is called “SettlementPeriodBeforeUse”. To use it run:
Set-BrokerDesktopGroup -Name “Win10 Ent” -SettlementPeriodBeforeUse 00:03:00
This will set the wait period to 3 minutes before registration. If there are no idle VDA’s the broker will not wait.
Otherwise, you can delay the start of the VDA Service in Windows by setting the service to "Automatic (delayed start)".
Office 365 can be installed with a standalone downloader or using the Office Deployment Toolkit. For Citrix App Layering Deployments, we require that the Office Deployment Toolkit is used. The toolkit is a small executable that downloads the latest version of Office 365 with updates to an Admin Installation Point. Then the toolkit is used again to install from the installation point into the layer.
An example configuration.xml file might look like this:
Note: MS Teams has specific recommendation for installation in VDI, Follow https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/multimedia/opt-ms-teams.html
You need to exclude teams installation when deploying through office deployment toolkit
Some important settings included within the xml file:
See the summary section for the exact steps to use for Office 365. Of note; Office 365 does not need to be rearmed. Most other of the standard steps apply.
When you run the optimize.hta to create the flag files used to tell the officeactivation scripts what to do you will see the following:
Check the box to process Office 365 and click Save Settings A-K
This creates 2 flag files, one in the kmsdir folder and one in scripts. The kmsdir file tells our startup script to run officeactivate.cmd. The one in the scripts folder tells it to do the o365 stuff which is really just replacing the store.
After completing the installation and defining the proper key you should rearm the installation. In Office 2010 this was not always necessary but we have noticed it is necessary in Office 2013 or later whether you run an Office application or not.
To rearm find the appropriate folder and run the rearm command from an Administrative cmd prompt.
"C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe" or
"C:\Program Files\Microsoft Office\Office15\ospprearm.exe"
Or if using 32 bit office on 64 bit windows look in the Program Files (x86) directories.
After installing Office and any Updates you will have to run the NGEN process because Office is a heavy user of DOTNET.
To run NGEN open an Administrative cmd prompt and change to the .Net Framework folders:
C:\windows\Microsoft.Net\Framework\v4.0.30319
And then run 'ngen eqi 3'
If this is a 64 bit OS then also go to:
C:\windows\Microsoft.Net\Framework64\v4.0.30319
And then run 'ngen eqi 3'
After running NGEN reboot the Install/packaging Machine then finalize the layer.
The way the optimizer works is that when you create the Office layer you run the Optimizer utility, select Activate MS Office via KMS and check all the Office Apps that are included in your layer.
When you save using Save Settings A-J, this will create two or more flag files. One will be OfficeActivate.txt which tells the kmssetup.cmd to run OfficeActivate.cmd. This will be placed in the kmsdir folder. There will also be a flag file for each office application selected. This tells the OfficeActivate.cmd script to include that office application when inserting the KMS key and activating office. These files will be created in the C:\Windows\Setup\Scripts folder.
Note: the utility now supports MAK keys (though their use is not recommended unless you have an unlimited number of activations). To use MAK activation check the Activate office via MAK and enter the keys. The keys will be stored in the flag file for Office, Project and/or Visio and used by the activation script when activating office.
We always recommend updating the Office Layer in a new version of the Office layer.
To update Office 365, you can create a whole new Office Layer based on the current distribution or add a version to your existing Office layer and update that. If you are creating a new Office layer you just follow the instructions defined earlier in the recipe after deleting the source files that were originally downloaded by the ODK setup. This will give you the smallest possible layer.
To install updates in a new version of the layer, add a version to the office layer change the configuration.xml to allow updates then rerun the setup /download configuration.xml. This will add new updates to the source share similar to the following:
Then change the xml back to disable updates and run setup /configure configuration.xml which will install the updates into the layer.
Upgrading from one version to the next
When going from one version of Office to another (IE 2013 to 2016) it is highly recommended that a new Layer is created rather than upgrading an existing layer inside of a version. Not only does this allow for the cleanest install path, but it also keeps the layer footprint small.
Activation on non-persistent desktops is more challenging than persistent desktops because activation must either be performed during setup or on every machine boot, otherwise it will happen every time an office application is run for the first time. This may not be an issue as KMS does not care how many times you reactivate a version of Office. If you use MAK activation this step will be critical. To activate during the build process, use the App Layering optimizer to create appropriate activation script files as discussed in the section entitled “Add Flag Files”.
If the KMS host for Office is not defined in DNS then on your Installation Machine run this line first with the proper host
cscript ospp.vbs /sethst:MyHost.MyDomain.com
If you plan on deploying more than one office version to the same desktops and you receive this message “Please wait while Windows Configures Microsoft Office” you should consider setting these registry options in the default profile. The “NoReReg” tells windows to not re-register the office programs and their associations. This is very important in a non-persistent environment because the users will see this warning every time they open an Office application after logon. But it also pertains to persistent desktops when using multiple version of Office. Unfortunately no matter what you do if you have two different versions of Office installed even with the norereg it will run the “Please Wait …” once. But it won’t keep running it every time on a persistent desktop.
The Optimizer also provides the ability to define and set NoReReg settings in the default profile.
If you need to define these settings run the Optimzer executable when creating your Application Layer and select the appropriate Office Applications that you want to disable registration for.
This KB supplies some information on this approach. http://support.microsoft.com/kb/2528748
On a persistent desktop this is often just a temporary annoyance as once the ReReg is run it stays that way but if you are using two different versions this may be useful on a persistent desktop as well.
Back to top
The following sections define some interesting GPO settings for Office Applications. In order to use GPO User Settings for an OU based GPO you must first set the loopback policy for the GPO.
The loopback policy allows user settings to be processed only when logging into a computer in a particular OU. Using this we can define user settings that only apply to the virtual desktops.
These are interesting GPO settings for Office in a VDI environment. Most of these help with disabling graphics and making ensuring large files for updates and mailboxes aren’t stored on desktops. However, we recommend you explore additional options through Microsoft's website to fully optimize for your own environment.