[Windows 7 Toolkit V2.3 Activator 2012 Download
Abdul Soumphonphakdy
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.
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:
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:
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.
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.
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.
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 -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:
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.
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.