Insights into OfficeClientEdition and how to make it work for you

Since the early days of Microsoft 365 Apps, the Office Deployment Tool (ODT) supported a switch called “OfficeClientEdition”. It is used to specify if you would like to install Office in 32- or 64-bit, sometimes also known as x86 vs. x64.

<Configuration>
	<Add OfficeClientEdition="64">
		<Product ID="O365ProPlusRetail">
			<Language ID="en-us"/> 
		</Product>
	</Add>
</Configuration>

In this blog post I will give you an insight view on how OfficeClientEdition works and how it can be leveraged when implementing the "dynamic, lean & universal packaging" concept which greatly reduces effort and maintenance costs.

Scenario: Initial installation

When you deploy Microsoft 365 Apps to for the first time to a device, maybe during an upgrade from an older version of Office or during a bare metal deployment, most admins have OfficeClientEdition set in the configuration.xml in order to specify which architecture (x86 or x64) of Office gets installed.

But what happens if you don’t specify OfficeClientEdition at all? Then the Office Deployment Tool will automatically determine which architecture fits your device:

If the device is running Windows x86 or has less than 4 GB RAM, Office will be installed as x86 as well.
In all other cases, x64 will be deployed.

So in case the IT landscape you manage is a mix of e.g. Windows x86 and x64, you could go with the following configuration.xml to cover both scenarios. No need to have two e.g. SCCM applications.

<Configuration>
	<Add>
		<Product ID="O365ProPlusRetail">
			<Language ID="MatchOS"/> 
		</Product>
	</Add>
</Configuration>

Scenario: Adding Visio, Project, Language Packs, Proofing Tools or other components

Let’s assume that Microsoft 365 Apps is already deployed to a device and you are looking for ways to automate the deployment of additional products. This could be e.g. Visio and Project, just adding Language Packs/Proofing Tools or other components like Access Runtime.

As we can’t mix x86/x64 on the same device, these additional installs must match the architecture already deployed. So, when having both Office x86 and x64 in your estate, you need e.g. SCCM applications covering both architectures. Does this mean you have to duplicate all packages?

Luckily not, as OfficeClientEdition can also be automatically determined by the Office Deployment Tool during run time. Here is an example of a configuration.xml which adds Visio to an existing installation:

<Configuration>
	<Add Version="MatchInstalled">
		<Product ID="VisioProRetail">
			<Language ID="MatchInstalled" TargetProduct="O365ProPlusRetail" /> 
		</Product>
	</Add>
</Configuration>

This configuration.xml will do the following for you in a dynamic, lean and universal way:

As OfficeClientEdition is not specified, the ODT will automatically match the new install to the already installed product. So this is a x86/x64 universal configuration.xml.
UpdateChannel is not specified as well. It will also automatically match the Channel used by the already installed product as described here.
The to-be installed version will match the installed one. Even if a newer version is available e.g. on the OfficeCDN, it will not do an implicit update (See dedicated blog post about Version="MatchInstalled").
Visio will be deployed with the very same languages as Microsoft 365 Apps is already installed with. For more details please check out this blog post.

So, we have a pretty universal configuration.xml which has no hard-coded architecture, languages, update channel or version. You can build this e.g. SCCM application once and use it for both architectures, no need for doing double work here.

Benefits

In the past configuration files were pretty static, each covering one specific scenario/configuration. By using new features like Version=MatchInstalled and Language=MatchInstalled together with the dynamic OfficeClientEdition and update channel, you can build universal configuration.xml which you can use in multiple scenarios.

This will not only save you time during the initial creation and on-going maintenance of the packages, but also ensure that users are not confused by e.g. seeing multiple very similar packages in the Software Center (when using Configuration Manager).

Prerequisites/Notes

The ODT must be able to locate the matching source files
If you use a Configuration Manager application with source files included or use SourcePath to point ODT to a local folder/network share, …
- use the AllowCdnFallback-switch to allow ODT to fetch missing language packs dynamically. Only include the most commonly used languages in the SCCM app/source path (recommended for initial deployment).
- Include all source files (x86 and x64) for all languages you might encounter. This will increase the overall size compared to the method above.
When using the OfficeCDN as a source (no sourcepath, no source files in ODT's folder), you don’t have to care about source files. ODT will be able to locate the right set automatically. Recommended for adding products/Language Pack/etc. later on (aka "2nd install").
If ODT can't locate all required files, it will fail. (E.g. when including the en-us source files only into a SCCM application which should install Visio onto a device which has also de-de installed and AllowCdnFallback is not set to true.)

The Author

This blog post is brought to you by manoth_msft, a Microsoft 365 Apps Ranger and senior deployment expert at Microsoft. Feel free to share your questions and feedback in the comments below.

Forum Discussion