How to Deploy Microsoft Office Using SCCM

Microsoft Configuration Manager (SCCM) has a built-in wizard that handles most of the heavy lifting when deploying Microsoft 365 Apps to your organization’s devices. The process involves creating a configuration XML that defines what gets installed, packaging it as an application in the SCCM console, and distributing it to your target collections. Here’s how to work through each stage.

Build Your Configuration XML

Every Office deployment starts with a configuration XML file that tells the Office Deployment Tool exactly what to install, in what language, and how to behave during installation. You can write this file by hand or use Microsoft’s cloud-based Office Customization Tool, which gives you a visual interface and outputs the XML for you.

At minimum, your XML needs two things: a Product element with an ID attribute (such as O365ProPlusRetail) and a Language element with an ID attribute (such as en-us). Beyond those, you’ll want to configure several other settings:

  • Architecture: Set OfficeClientEdition to “64” or “32” in the Add element. Most organizations now deploy 64-bit.
  • Update channel: Determines how quickly your users receive new features (more on this below).
  • ExcludeApp: Lets you skip specific apps. If you don’t want Access or Publisher installed, add an ExcludeApp element for each with the app’s ID.
  • Display: Controls whether users see the installation UI. Setting Level="None" and AcceptEULA="TRUE" runs a silent install.
  • RemoveMSI: Automatically uninstalls older MSI-based versions of Office during the upgrade (covered in detail below).

A basic configuration XML for a silent 64-bit install on Current Channel looks something like this:

<Configuration>
  <Add OfficeClientEdition="64" Channel="Current">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Publisher" />
    </Product>
  </Add>
  <Display Level="None" AcceptEULA="TRUE" />
  <Updates Enabled="TRUE" />
  <RemoveMSI />
</Configuration>

Choose the Right Update Channel

The update channel you select in your XML controls how often users get new Office features. Pick this carefully, because changing channels later means redownloading the full Office installation on every device.

Current Channel ships new features as soon as they’re ready, typically at least once a month with no fixed schedule. It’s the best fit for users who want the latest capabilities right away. Each release is supported only until the next one ships, usually about a month.

Monthly Enterprise Channel delivers feature updates on a predictable schedule: the second Tuesday of every month. This gives IT teams a few extra weeks of lead time compared to Current Channel, since features that appeared in Current Channel arrive here on the next Patch Tuesday. Each release is supported for two months.

Semi-Annual Enterprise Channel receives feature updates only twice a year, in January and July, though it still gets monthly security patches. Microsoft recommends this channel primarily for non-interactive devices, automated task systems, or environments with strict regulatory requirements. Each release is supported for eight months (reduced from fourteen months starting July 2025). Beginning July 2026, this channel will shift to receiving feature and security updates monthly, aligning it more closely with Monthly Enterprise Channel.

For most general-purpose deployments, Monthly Enterprise Channel strikes the best balance between staying current and having a predictable patching schedule.

Remove Legacy Office Versions

If your devices still have Office 2007, 2010, 2013, or 2016 installed via the older Windows Installer (MSI) method, you need to remove those before or during the Microsoft 365 Apps install. The simplest approach is adding <RemoveMSI /> to your configuration XML. This strips out all MSI-based Office products, including Visio, Project, SharePoint Designer, InfoPath, Lync 2013 and later, and standalone apps like Access Runtime.

If you need to keep a specific product (for example, a standalone Visio Pro installation), use the IgnoreProduct element inside RemoveMSI:

<RemoveMSI>
  <IgnoreProduct ID="VisPro" />
</RemoveMSI>

To carry forward whatever language packs were installed on the old version, add <Language ID="MatchPreviousMSI" /> alongside your primary language ID. This saves you from manually tracking which languages each machine needs.

One thing to plan for: uninstalling MSI-based Office requires a reboot to fully complete, but the installer does not force one automatically. You’ll want to handle this through your SCCM deployment settings or a maintenance window.

Create the Application in SCCM

SCCM includes a dedicated wizard for Office deployments that bundles the download, packaging, and distribution steps together.

  1. In the Configuration Manager console, go to Software Library > Overview > Office 365 Client Management.
  2. Select Office 365 Installer in the upper-right pane. This launches the Office 365 Client Installation Wizard.
  3. On the Application Settings page, give the application a name and description, then enter the download location as a UNC path (for example, \\server\share). This is where SCCM will store the Office source files.
  4. On the Office Settings page, select Go to the Office Customization Tool. This opens the browser-based tool where you configure your XML settings: products, languages, excluded apps, update channel, and everything discussed above. When you’re done, click Submit to send the configuration back to the wizard.
  5. On the Deployment page, select Yes if you want to deploy immediately, then click Next.
  6. On the General page, choose the device collection you want to target.
  7. Walk through the remaining wizard pages. These are the same screens you’d see for any SCCM application deployment: scheduling, user experience settings, distribution points, and alerts. Configure them based on your organization’s standard practices.
  8. Complete the wizard.

SCCM downloads the Office source files to the share you specified, creates the application with the correct detection method, and distributes the content to your distribution points. If you chose to deploy during the wizard, it also creates the deployment targeting your selected collection.

Set Up the Content Source

The UNC path you provide during the wizard becomes the central content source for the deployment. Make sure the share has enough space for the Office installation files, which can range from roughly 2 to 4 GB depending on how many languages and products you include. The SCCM computer account needs read/write access to this share so it can download the source files from Microsoft’s CDN.

If you’re deploying to remote offices with slow WAN links, consider pre-staging content on local distribution points or enabling BranchCache. The Office source files are large enough that pulling them across a constrained connection for hundreds of machines will cause problems.

Configure Deployment Settings

When you set up the deployment (either through the wizard or by creating one manually afterward), a few settings deserve attention.

Set the deployment purpose to Required for a forced rollout or Available if you want users to install from Software Center on their own schedule. For a phased rollout, start with an Available deployment to a pilot collection, verify everything works, then switch to Required for broader groups.

Under the User Experience tab, you can allow installations to run outside maintenance windows and suppress restarts if needed. Since the MSI removal step expects a reboot, scheduling the deployment inside a maintenance window gives the cleanest experience: install, reboot, and the user comes back to a working Office installation.

Monitor the Deployment

After the deployment starts reaching clients, you can track progress in the Configuration Manager console under Monitoring > Deployments. This shows you success, failure, and in-progress counts across your target collection.

When something fails, client-side logs are your primary diagnostic tool. The key files to check are all located in %windir%\CCM\Logs on the target device:

  • AppEnforce.log: Records the install and uninstall actions SCCM takes for the application. This is the first place to look when a deployment fails, because it shows the exact command line that ran and the exit code it returned.
  • AlternateHandler.log: Captures details when the client calls the Office Click-to-Run COM interface to download and install updates. Useful for diagnosing problems with the Office installer itself rather than the SCCM wrapper.

Office also writes its own setup logs. Look in %temp% and %windir%\temp on the client machine for files with names starting with “SetupExe” or in the %localappdata%\Temp folder. These logs capture errors from the Office Deployment Tool that SCCM’s logs won’t show, such as XML configuration problems or CDN download failures.

Common failure causes include insufficient disk space, network issues reaching a distribution point, and conflicts with running Office applications that block the installer. If you see exit code 17002 or 17004, those typically point to a problem with the source files or an in-use Office process preventing the upgrade.

Post navigation