Best practices from the field: Build dynamic, lean, and universal packages for Microsoft 365 Apps
We’re making some changes to the update channels for Microsoft 365 Apps, including adding a new update channel (Monthly Enterprise Channel) and changing the names of the existing update channels. To learn more, read this article.
This article was written by Microsoft experts in the field who work with enterprise customers to deploy Office.
As an admin, you might have to deploy Microsoft 365 Apps (previously named Office 365 Business or Office 365 ProPlus) in your organization. But such a deployment is more than just Office: After the initial migration to Microsoft 365 Apps, you might have to provide ways for your users to automatically install additional language packs, proofing tools, products like Visio and Project, or other components. We often refer to these scenarios as 2nd installs, while the initial upgrade to Microsoft 365 Apps from a legacy Office is called 1st install.
This article shows you how to build dynamic, lean, and universal packages for Microsoft 365 Apps. This method can greatly reduce long-term maintenance costs and effort in managed environments.
When you plan your upgrade to Microsoft 365 Apps, the actual upgrade from a legacy version to the always-current Microsoft 365 Apps is front and center (1st install scenario). But looking beyond the initial deployment, there are other scenarios you’ll need to cover as an admin (2nd install). Sometimes, after you upgrade your users, they might need any of the following components:
- Additional language packs
- Proofing tools
Historically, each of these scenarios was addressed by creating a dedicated installation package for automatic, controlled installation for users. Usually, an admin would combine the necessary source files (of ~2.5 gigabytes) and a copy of the Office Deployment Tool (ODT) together with a configuration file into a package for each of these components.
But, especially in larger organizations, you often don't have a single configuration set of Microsoft 365 Apps. You might have a mix of update channels (often SAC and SAC-T). And maybe you're currently transitioning from 32-bit to 64-bit, and maybe you'll have to support both architectures for quite some time.
So in the end, you wouldn't have 1 package per component but 4, covering each possible permutation of SAC/SAC-T and x86/x64. The end result would be:
- A large number of packages. The 4 listed components would result in 16 or more packages.
- High-bandwidth consumption, as a client might get the full 2.5-GB package pushed down before installation.
- High maintenance costs to keep embedded source files current.
- High user impact, if you haven’t kept the source files current and installing a component will perform a downgrade just to perform an update to the current version soon after.
- Low satisfaction for users who have to pick the matching package from many options presented in the software portal.
While the initial upgrade to Microsoft 365 Apps is a one-time activity, the scenarios described previously will be applicable over a longer period. Users might need additional components days, weeks, or even years after the initial deployment.
So, how do you build packages that are less costly to maintain over a long time frame and avoid the downsides?
The solution: Dynamic, lean, and universal packages
You can resolve these issues by implementing self-adjusting, small, and universal packages. Let's cover the basic concepts before we dive into sample scenarios.
Build dynamic packages where you don’t hard-code anything. Use features of the Office Deployment Tool (ODT) to enable the packages to self-adjust to the requirements:
- Use Version=MatchInstalled to prevent unexpected updates and stay in control of the version installed on a client. No hard coding of a build number, which gets outdated quickly, is required.
- Use Language=MatchInstalled to instruct e.g. Visio or Project to install with the same set of languages as Office is already using. No need to list them or build a script that injects the required languages.
Build lean packages by removing the source files from the packages. This has multiple benefits:
- Package size is much smaller, from 2.5 GB down to less than 10 megabytes for the ODT and its configuration file.
- Instead of pushing a 2.5-GB install package to clients, you let clients pull what they need on demand from Office Content Delivery Network (CDN), which saves bandwidth.
- When you add Project to an existing Microsoft 365 Apps installation, you need to download less than 50 megabytes, as Office shared components are already installed.
- Visio installs are typically 100-200 megabytes, based on the number of languages, as the templates/stencils are a substantial part of the download.
- Installing proofing tools is typically 30-50 megabytes, versus a full language pack, which is 200-300 megabytes.
- A second install scenario is often less frequent, which lowers the internet traffic burden, ultimately reducing the impact.
- You don’t have to update the source files every time Microsoft releases new features or security and quality fixes.
Build universal packages by not hard coding things like the architecture or update channel. ODT will dynamically match the existing install, so your packages work across all update channels and architectures. Instead of having 4 packages to install Visio, for example, you'll have a single, universal package that will work across all permutations of update channels and architectures.
- Leaving out OfficeClientEdition makes your package universal for mixed x86/x64 environments.
- Leaving out Channel makes your package universal across update channels.
How to build and benefit from building dynamic, lean, and universal packages
The idea is to not hard code everything in the configuration file, but to instead utilize the cleverness of the Office Deployment Tool as much as possible.
Let’s have a look at a "classic" package that was built to add Project to an existing install of Microsoft 365 Apps. We have the source files (of ~2.5 gigabytes) and a configuration file, which explicitly states what we want to achieve:
<Configuration> <Add OfficeClientEdition="64" Channel="Broad"> <Product ID="ProjectProRetail"> <Language ID="en-us" /> </Product> </Add> <Display Level="None" /> </Configuration>
When we apply the concepts of dynamic, lean, and universal packages, the result would look like this:
<Configuration> <Add Version="MatchInstalled"> <Product ID="ProjectProRetail"> <Language ID="MatchInstalled" TargetProduct="O365ProPlusRetail" /> </Product> </Add> <Display Level="None" /> </Configuration>
So what have we changed, and what are the benefits?
- We removed the OfficeClientEdition-attribute, as the ODT will automatically match the installed version.
- Benefit: The configuration file now works for both x86 and x64 scenarios.
- We removed the channel for the same reason. ODT will automatically match the already-assigned update channel.
- Benefit I: The package works for all update channels (Monthly, Semi-Annual, SAC-T, and others).
- Benefit II: It also works for update channels you don’t offer as central IT. Some users are running Monthly Channel, some are on Insider builds? Don’t worry, it just works.
- We added Version=MatchInstalled, which ensures that ODT will install the same version that's already installed.
- Benefit: You're in control of versions deployed, with no unexpected updates.
- We added Language ID="MatchInstalled" and TargetProduct to match the currently installed languages, replacing a hard-coded list of languages to install.
- Benefit I: The user will have the same languages for Project as were already installed for Office.
- Benefit II: No need to re-request language pack installs.
- Benefit III: Also works for rarely used languages that you as the central IT admin don’t offer, which makes users happy.
- We removed the source files. The ODT will fetch the correct set of source files from the Office CDN just in time.
- Benefit I: The package never gets outdated. No maintenance of source files is needed.
- Benefit II: The download is about 50 megabytes instead of about 2.5 GB.
Another example: Add language packs and proofing tools the dynamic, lean, and universal way
Let’s have a brief look at other scenarios as well, like adding language packs and proofing tools. The classic configuration file to install the German Language Pack might look like this:
<Configuration> <Add OfficeClientEdition="64" Channel="Broad"> <Product ID="LanguagePack"> <Language ID="de-de" /> </Product> </Add> <Display Level="None" /> </Configuration>
If you’re running SAC as well as SAC-T and have an x86/x64 mixed environment, you'd need three additional files to cover the remaining configuration permutations. Or, you just go the dynamic, lean, and universal way:
<Configuration> <Add Version="MatchInstalled"> <Product ID="LanguagePack"> <Language ID="de-de" /> </Product> </Add> <Display Level="None" /> </Configuration>
This single configuration file will work across x86/x64 and all update channels (Insider Fast, Monthly Targeted, Monthly, SAC-T, SAC, and others). So, if you want to offer five additional languages in your environment, just build five of these "config file + ODT" packages. For proofing tools, you just change the ProductID to "ProofingTools".
There are some prerequisites you must meet to make this concept work in your environment:
- Use Office Deployment Tool 16.0.11615.33602 or later to enable Version=MatchInstalled to work.
- The ODT must be able to locate the matching source files on the Office CDN.
- Make sure that the context you're using for running the install can traverse the proxy. For details, see Office 365 ProPlus Deployment and Proxy Server Guidance.
- Make sure that the account (user or system) that's used to install the apps can connect to the internet.