Office 365 Pro Plus – Lean Installations Explained

Challenges in traditionally managed environments

Today I am going to talk about Office 365 Pro Plus lean installations often referred to as second install. After the initial migration to ProPlus, you might have to provide ways for your users to acquire automated installs of additional features or other components. In traditional managed environments that would require a dedicated installation package in order to allow an automated and controlled way to install:

  • Additional Language Packs
  • Proofing Tools
  • Visio
  • Project

Usually, for each of the above components, an admin would combine the necessary source files (~2.5 gigabyte), a copy of the Office Deployment Tool (ODT) together with a configuration file, into a package. Especially in larger organizations, you often do not run a single installation of Office 365 ProPlus. You might have a mix of update channels (often SAC and SAC-T) and maybe you are currently transitioning from 32 bit to 64 bit, and for quite some time you will have to support both architectures. At the end, we would not have one package per component, but rather four, covering each possible permutation of SAC/SAC-T and x86/x64. The result would be:

  • High number of packages, the four 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 install.
  • 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 user satisfaction when having to pick the matching package out of a bunch of options.

While the initial upgrade to Office 365 ProPlus is a one-time activity, the above scenarios will be applicable over a longer period as users might need additional components days, weeks or even years after the initial deployment. So, how do we build packages which are less costly to maintain over a long-time frame and avoid the above downsides?

Solution with Dynamic, Lean and Universal packages

In a new world, we can solve the issues by implementing self-adjusting, small and universal package.


Build dynamic packages where you don’t hard-code anything. Leverage features of the Office Deployment Tool (ODT) to allow 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) required.
  • Use Language=MatchInstalled to instruct e.g. Visio or Project to install with the very same languages which are already installed for Office. No need to list them or build a script which 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, we allow clients to pull what it needs on demand from Office CDN which saves bandwidth:
    • When adding Project to an existing Office 365 ProPlus install, we need to download less than 50 megabytes as Office shared components are already installed.
    • Visio installs are typically between 100-200 megabytes, based and the number of languages as the templates/stencils are a substantial part of the download.
    • Installing Proofing Tools is typically between 30-50 megabytes versus a full Language Pack is somewhere between 200 to 300 megabyte.
  • A 2nd install scenario is often less frequent, which lowers the burden on the internet traffic ultimately reducing the impact.
  • You don’t have to update the source files every time when Microsoft releases new features, 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 e.g. four packages to install Visio, you will have a single, universal package which 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, even ones you don’t support

So what have we changed and what are the benefits of doing so?

  • Removed OfficeClientEdition-attribute, as the ODT will automatically match the installed version.
    • Benefit: Configuration file now work for both x86 and x64 scenarios.
  • Remove Channel, same reason, ODT will automatically match the already assigned update channel.
    • Benefit I: Package works for all update channels (Monthly, Semi-Annual, SAC-T, you name it)
    • Benefit II: It will also work for update channels you don’t offer as central IT. Some users are running Monthly, some are on Insider builds? Don’t worry, it just works!
  • Added Version=MatchInstalled which will ensure that ODT will install the exact same version which is already installed.
    • Benefit: You are in control of versions deployed, no unexpected updates.
  • Added Language ID=”MatchInstalled”  and TargetProduct  designed to match the currently installed language(s), replacing a hard-coded list of languages to install.
    • Benefit I: User will have the same languages in Project as already installed for Office.
    • Benefit II: No need to re-request Language Pack installs.
    • Benefit III: Will also work for rarely used languages which you as central IT admin don’t offer, leading to happier users.
  • Removed the source files, the ODT will fetch the correct set of source files from the Office CDN just-in-time.
    • Benefit I: Package never gets old. No maintenance of source files needed.
    • Benefit II: Download is ~50 megabyte instead of pushing 2.5 GB around.

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:


If you’re running SAC as well as SAC-T and have a x86/x64 mixed environment, you would need three additional files to cover the remaining permutations of configurations. Or you just go the dynamic, lean and universal way:


This single configuration file will work across x86/x64 and all update channels (Insider Fast, Monthly Targeted, Monthly, SAC-T, SAC, and so on). So if you want to offer 5 additional languages in your environment, just build 5 of these “config file + ODT” packages and you’re good to go.

Important Requirements for this to work

There are some prerequisites you must meet to make this concept work in your environment:

  • Use Office Deployment Tool 16.0.11615.33602 or newer to enable Version=MatchInstalled to work.
  • The ODT must be able to locate the matching source files on the Office CDN.
  • Ensure that the context your using for running the install can traverse the proxy.
  • Make sure, that the account (user or SYSTEM) used to install the apps is able to connect to the internet.

I hope this will help you in saving quite some storage and in the end have a much faster Office 365 Pro Plus management framework.

Cheers,
Ken

You must be logged in to post a comment.