Jul 22 2019 06:01 AM - edited Dec 18 2020 02:50 AM
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.
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:
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>
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:
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.
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).
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.