Microsoft 365 Packages

-->

Modern workplace training. Learn how to get more work done, from anywhere on any device with Microsoft 365 and Windows 10. Discover how industry professionals leverage Microsoft 365 to communicate, collaborate, and improve productivity across the team and organization. If you currently use Microsoft Dynamics 365 Commerce functionality for the retail point of sale, you will also have to synchronize self-service installers. What is an all-in-one deployable package? An all-in-one deployable is a software deployable package that contains all the models and binaries that you currently have in an environment.

Note

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. For 1st install scenarios, have a look at the install options as well as the best way to right-size your deployment.

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.

The challenge

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
• Visio
• Project

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 Semi-Annual Enterprise Channel and Semi-Annual Enterprise Channel (Preview). 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 Semi-Annual Enterprise Channel/Semi-Annual Enterprise Channel (Preview) 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:

When we apply the concepts of dynamic, lean, and universal packages, the result would look like this:

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 (Current Channel, Monthly Enterprise Channel, Semi-Annual Enterprise Channel, and others).
  • Benefit II: It also works for update channels you don’t offer as central IT. Some users are running Current 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 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:

If you’re running Semi-Annual Enterprise Channel as well as Semi-Annual Enterprise Channel (Preview) 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:

This single configuration file will work across x86/x64 and all update channels, such as Current Channel, Monthly Enterprise Channel, Semi-Annual Enterprise Channel, 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'.

Build your own configuration

The above concept is universally applicable to all Click-To-Run-based installations and products, as long as the ODT is used. You can change the specified Product ID to your scenario. Please check out the list of supported Product IDs for more information.

Prerequisites/Notes

Here are some prerequisites you must meet to make this concept work in your environment and some notes:

• 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.
• The tailored configuration files shown above are good for installing the products (with the /configure switch), but do not work with the /download switch. This is expected, as the ODT is missing some details to perform a download (like architecture). For the above concept, there is no need to download the files beforehand.

Follow the steps in this article to choose how to deploy Office, how to manage updates to Office, and whether to deploy the Office files from a local source on your network or from the cloud.

Before you begin

If you haven't already, complete the assessment of your environment and infrastructure. This assessment will help you make key decisions as part of planning your deployment.

Step 1 - Choose how to deploy

Note

Best practice: If you use Configuration Manager already, make sure you are on the current branch and use it to deploy Office from distributions points on your network. If you don't have Configuration Manager, use the Office Deployment Tool and deploy Office from the cloud. If your network capacity doesn't allow for that, deploy Office with the ODT from a local source. We recommend self-install for situations in which you require less administrative control and you have the network capacity to have your users install directly from the Office portal.

To deploy Office, you first choose what deployment tool to use and whether to install the Office files directly from the cloud or from a local source on your network.

We recommend the current branch of Configuration Manager for organizations that already use it to distribute and manage software. Configuration Manager scales for large environments; enables extensive control over installation, updates, and settings; and has built-in features for deploying and managing Office.

If you do deploy with Configuration Manager, we recommend deploying from a local source, using your Configuration Manager distribution points. If you use a previous version of Configuration Manager, we recommend upgrading to the current branch before using it to deploy Office.

For organizations that don't have Configuration Manager but still want to manage their deployment, we recommend using the Office Deployment Tool (ODT). You can use the ODT as a standalone tool or you can use it to download installation files that can be deployed using third-party software deployment tools. In either case, the ODT provides control over installation, updates, and settings. For more details, see Overview of the Office Deployment Tool.

If you use the ODT and have the network capacity, we recommend deploying Office from the cloud. Doing so will minimize your administrative overhead. If you don't have the network capacity to install Office on client devices from the cloud, you can use the ODT to download the Office files to a local source on your network and install from there.

You can also manage your deployment from the Office portal and have your users install Office on their client devices directly from the portal. This method requires the least amount of administrative setup, but gives you less control over the deployment. You can, however, still define how frequently your users receive feature updates. For more details, see Manage Office installation options in the Microsoft 365 admin center. This option requires that your users have local administrative rights on their client devices.

Choose how you want to deploy:

• Deploy from a local source with Configuration Manager: Manage your deployment with Configuration Manager, and download and deploy Office from distribution points on your network.

• Deploy from the cloud with the Office Deployment Tool: Manage your deployment with the ODT, and install Office on client devices directly from the Office CDN.

• Deploy from a local source with the Office Deployment Tool: Manage your deployment with the ODT, and download and deploy Office from a local source on your network.

• Self-install from the cloud: Manage your deployment from the Office portal and have your users install Office on their client devices directly from the portal.

Many organizations will use a combination of these options for different users. For example, an organization might use Configuration Manager to deploy Office to most of their users, but enable self-install for a small group of workers who are not frequently connected to the internal network.

Step 2 - Choose how to manage updates

Note

Best practice: We recommend updating your client devices automatically. You can define the frequency of the feature updates, but the updates occur without any administrative overhead.

To manage updates to Office, you choose whether to have your client devices automatically updated, what tool to use, and whether to install the updates to Office directly from the cloud or from a local source on your network.

We recommend updating your client devices automatically from the Office CDN. You can still control the frequency of the feature updates, as those settings are defined as part of the initial deployment, but the updates themselves occur without any additional tools or administrative overhead. In addition, the updates are automatically deployed over a number of days to conserve your network bandwidth.

If you choose to manage the updates directly, you can do so with Configuration Manager by downloading the updates and deploying them from distribution points. If you use a previous version of Configuration Manager, we recommend you upgrade to the current branch.

If you don't have Configuration Manager, you can use the ODT to download updates to a local source on your network and deploy them from there. This option requires the most administrative overhead, as you will need to manage update packages for different update channels, architectures, and platforms. We suggest this option only when your network capacity is too limited to update from the cloud.

Choose how to manage updates:

• Update automatically: Client devices are automatically updated directly from the Office CDN based on the update channel you define as part of the initial deployment.

• Manage updates with Configuration Manager: Office updates are downloaded and deployed to client devices by Configuration Manager.

• Manage updates with the Office Deployment Tool: Office updates are downloaded to a local source by the ODT and then installed on client devices.

As with the initial deployment, organizations can use a combination of these options for different users.

Step 3 - Choose your update channels

With Microsoft 365 Apps, you can control how frequently your users receive feature updates to their Office applications. To do so, you choose an update channel for your users:

• Current Channel: Provides users with the newest features of Office as soon as they're ready, but on no set schedule.

• Monthly Enterprise Channel: Provides users with the newest features of Office only once a month and on a predictable schedule (the second Tuesday of the month)

• Semi-Annual Enterprise Channel: Provides users with new features of Office every six months, in January and July.

We recommend Current Channel, because it provides your users with the newest Office features as soon as they are ready. If you need additional predictability of when these new Office features are released each month, we recommend Monthly Enterprise Channel. In those cases where you have select devices that require extensive testing before receiving new features, we recommend Semi-Annual Enterprise Channel.

All the update channels will receive updates for security and non-security issues when needed. These updates usually occur on the second Tuesday of the month.

For more information, see Overview of update channels for Microsoft 365 Apps.

To preview or test new updates to Office before deploying them to your entire organization, you can deploy two update channels. For example, if you're using Semi-Annual Enterprise Channel:

• Deploy Semi-Annual Enterprise Channel (Preview) to a targeted group of representative users who can pilot new features of Office. The users should include people from business groups across the organization and their client devices should include the architectures in your organization (32-bit and 64-bit), any significant differences in hardware and device drivers, as well as any critical line-of-business applications, add-ins, and macros. This group receives feature updates four months ahead of the rest of your organization. We recommend using the same group of users you defined in the assessment phase.

• Deploy Semi-Annual Enterprise Channel to the remaining users in your organization. They receive feature updates every six months, four months after the users with Semi-Annual Enterprise Channel (Preview).

You could take a similar approach with Current Channel (Preview) and Current Channel. In that scenario, users with Current Channel usually receive feature updates just a few weeks after the users with Current Channel (Preview).

Step 4 - Define your source files

Note

Best practice: Build separate Office installation packages for the different architectures and update channels you require. In each installation package, include all the required languages and applications, including the core Office applications and, if needed, Visio and Project. For additional languages, you can make them available for user installation or deploy them separately after the initial deployment.

When deploying Office, you create an installation package of the source files used to install Office. The source files are different for 32-bit and 64-bit versions of Office and are different for each of the update channels. Because of this, you will likely need to create multiple installation packages to support the different architectures and update requirements in your organization. For example, to deploy to two update channels and both architectures, you create four packages:

• Semi-Annual Enterprise Channel for 32-bit
• Semi-Annual Enterprise Channel for 64-bit
• Semi-Annual Enterprise Channel (Preview) for 32-bit
• Semi-Annual Enterprise Channel (Preview) for 64-bit

You can also create separate packages based on different languages, Office applications, or installation settings, but we don't recommend it. Instead, we recommend including all the Office applications and all the languages your organization requires in each of your installation packages. Later, when you deploy the packages to different groups of client devices, you can specify which language and Office applications are actually installed.

To package the languages, we recommend identifying required languages in each region. You can deploy these languages directly as part of the first installation of Office. You can also install the language that matches the operating system of the client device. For more details, see Install the same languages as the operating system.

After you've deployed Office with the required languages, you can install additional language accessory packs at any time by choosing one of the following:

• Have your users download and install the language accessory packs that they need from the Office 365 portal (requires local administrator permissions).
• Use Configuration Manager or the Office Deployment Tool to deploy the appropriate language accessory packs to your users.

For more details, see Overview of deploying languages for Microsoft 365 Apps.

For details on which architecture to choose, see Choose the 32-bit or 64-bit version of Office.

If you have the subscription versions of the Project and Visio desktop apps, continue to use those. If you have the 2013 versions of Project and Visio, you can either upgrade to the subscription versions or keep using the 2013 versions side-by-side with Microsoft 365 Apps. If you have the 2016 MSI version of Project or Visio, you should use the Office Deployment Tool to install volume licensed editions of Visio 2016 and Project 2016.

Step 5 - Define your deployment groups

Note

Best practice: Define deployment groups to deploy the appropriate architectures, update channels, languages, and applications to your client devices. If multiple deployment groups share the same architecture and update channel, use the same installation package to install Office.

When deploying Office, you can install different versions of Office for different groups of users. In addition to the architecture and update channel, you can include or exclude specific applications, choose languages, and define the installation experience. Each group of users is a separate deployment group. If you use Configuration Manager, you define the settings for these deployment groups as part of the deployment wizard. If you use the ODT, you define the settings in a configuration file.

Note that you can use the same installation package to deploy different configurations of Office to different groups. For example, you can create an installation package that includes the following:

• 32-bit version of Microsoft 365 Apps
• English, Japanese, and German
• Semi-Annual Enterprise Channel

This single installation package can then be used to deploy to multiple deployment groups:

• Group 1 receives the Office apps in English
• Group 2 receives the Office apps in all three languages
• Group 3 receives the Office apps in English, but without Publisher

By re-using installation packages for different deployment groups, you can save administrative costs and conserve network bandwidth.

Step 6 - Plan your upgrade from existing versions of Office

Note

Best practice: Before installing Microsoft 365 Apps, remove any existing versions of Office.

Microsoft Office Options

Before installing Microsoft 365 Apps, we recommend removing any existing versions of Office. Microsoft supports installing Microsoft 365 Apps alongside the most recent previous version of the Office suite, but we don't recommend it. If you need to have two versions of Office on the same computer, we recommend that you keep only the necessary earlier applications and that you plan to transition to using only Microsoft 365 Apps when possible. To verify the supported versions to be installed alongside Microsoft 365 Apps, refer to Supported scenarios for installing different versions of Office, Project, and Visio on the same computer.

Can I Get Microsoft 365 For Free

To help you remove prior versions of Office that use Windows Installer (MSI) as the installation technology, you can use the Office Deployment Tool and specify the RemoveMSI element to automate the removal with your Microsoft 365 Apps deployment package. For details see Remove existing MSI versions of Office when upgrading to Microsoft 365 Apps.

Step 7 - Plan for shared computers (optional)

Note

Best practice: For shared computer scenarios, such as VDI, enable shared computer activation when deploying Microsoft 365 Apps.

If your organization has a virtual desktop infrastructure (VDI) implementation, or you have users that share workstations (for example, shift workers), you need to enable shared computer activation for those devices when you deploy Microsoft 365 Apps.

With shared computer activation enabled, any user that has been assigned a Microsoft 365 Apps license can log on to the computer and use the Office apps, such as Word or Excel. For more details, see Overview of shared computer activation for Microsoft 365 Apps.

Review exit criteria

Before beginning your deployment, make sure you've completed the planning exit criteria:

Next step

Microsoft Office Deals

Depending on your deployment plan, go to one of the following articles: