In today’s post I would like to provide some insights into the Channel-attribute used in the <Add>-section of the configuration files for the Office Deployment Tool (ODT) and how it can be used for implementing "dynamic, lean and universal" packages:
<Configuration>
<Add Channel="Broad" />
<Product ID="O365ProPlusRetail">
<Language ID="de-de" />
</Product>
</Add>
</Configuration>
In nearly every configuration file (aka config.xml) you will find this attribute, but have you known that this is actually an optional attribute and can be used to build leaner deployments which require less maintenance? I will walk you through the steps on how the Channel-attribute works during the initial installation of Office 365 Client Apps and how to leverage it for reducing your effort when building sub-sequent installs (Project, Visio, …).
When designing an Microsoft 365 Apps deployment, especially in larger organizations, the “Update Channel” to use is an important factor. It controls the balance between receiving new features quickly and providing phases of “no changes” for the IT. It’s important to understand the foundational concepts, ways to implement it as well as the change management view on this topic. But this post will just focus on the channel assignment done through the ODT.
Scenario: Initial installation
When you deploy the Microsoft 365 Apps for the first time to a device, the channel attribute works pretty straight forward:
- If you have specified the channel (usually Monthly or Semi-Annual), ODT will just install the latest/available or specified version of Office from this channel.
- If you haven’t specified the channel, the Office Deployment Tool (ODT) will use the following default value which is Current Channel.
Most IT admins are not aware of the optional nature of the channel assignment, but there is not too much we can optimize here. The meat and potatoes lies in the 2nd install scenario.
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 as the IT admin has to provide ways to install additional Language Packs, Visio, Project, and Proofing Tools. Most organizations run a mix of SAC and SAC-T , more often than not you also have a small population on Monthly Channel.
This poses two challenges when going with the common approach of specifying the Channel attribute:
- You end up with a high number of install packages. E.g. when you want to provide one additional language as well as Visio and Project to your users, you end up with three install packages multiplied by the number of update channels you support.
- Your users are confused. If you want to provide a self-service to your users, e.g. through SCCM Software Center, they will see all these install packages and must pick the one which is matching their currently installed update channel. Most users don’t have a clue which channel they are on.
But ODT to the rescue! A little known fact is, that ODT will default to the assigned channel of the existing installation, if the attribute is not set. We can leverage this behavior to remove the (perceived) need to build one configuration file per deployed update channel. This reduces the number of required configuration files (and install packages) significantly.
Here is an example of a configuration file which adds Visio to an existing installation and will work for any update channel:
<Configuration>
<Add Version="MatchInstalled">
<Product ID="VisioProRetail">
<Language ID="MatchInstalled" TargetProduct="O365ProPlusRetail" />
</Product>
</Add>
</Configuration>
Above XML will do the following for you:
- 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 (read more about it 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 (Read more about Version="MatchInstalled").
- Visio will be deployed with the very same languages as Microsoft 365 Apps are already installed with. For more details please check out this blog post.
So, we have a dynamic, lean and universal configuration file which has no hard-coded architecture, languages, update channel or version. You can build this e.g. SCCM application once and use it for all update channels.
Benefits
In the past configuration files were static, each covering one specific scenario/configuration. By using new features like Version=MatchInstalled, Language=MatchInstalled together with dynamic OfficeClientEdition and update channel, you can build universal configuration files which cover multiple scenarios.
This resolves the two issues described above:
- You only need one installation package (e.g. an SCCM app) per component. For most environments (running MC, SAC and SAC-T) this reduces the effort by 66%, because you don’t have to build each package three times.
- Your users will be happy, as they can easily identify what they need from the Software Center. They don’t have to worry about which update channels they are on. It just works.
Prerequisites
- The ODT must be able to locate the matching source files on the Office CDN. Including the source files in the SCCM app would require having the exactly matching version included. Same goes for network shares/local folders. We recommend using the Office CDN instead.
- I always recommend to also make sure that you use the latest ODT available. There is no specific min. version for the Channel-attribute, but it is a good practice to always update the ODT when you’re touching it anyways.
The Author
This blog post is brought to you by @Martin Nothnagel, a Microsoft 365 Apps Ranger and senior deployment expert at Microsoft. Feel free to share your questions and feedback in the comments below.
