How to Deploy Office 2016 Using SCCM: Step-by-Step Guide (2026)

Manually installing Office 2016 on 500 computers is a nightmare. Here is how to automate it in 30 minutes using SCCM.

I've lost count of how many times I've walked into an environment where someone is still USB-hopping around the office, installing Office 2016 one machine at a time. It's 2026, and if you're managing more than a handful of endpoints, that approach doesn't just waste time—it introduces inconsistency, security gaps, and a whole lot of frustration.

That's where ConfigMgr (formerly SCCM) comes in. It's been the gold standard for enterprise software deployment for years, and when it comes to deploying Office 2016 at scale, nothing beats it. This guide walks you through the entire process—from prerequisites to troubleshooting the errors that'll make you want to throw your laptop out the window.

We're focusing on Click-to-Run (C2R) deployment here, which is the modern method for Office 2016. If you're still clinging to MSI-based deployment, it's time to move on.

---

Prerequisites for Deploying Office 2016 with SCCM

Before we dive into the actual deployment, let's make sure you've got the foundation right. I've seen too many deployments fail because someone skipped this step.

What You Need Before You Start

First things first—you need a working SCCM (ConfigMgr) infrastructure. At minimum, that means:

• A functional SCCM site with at least one Distribution Point (DP). If you're running SCCM 2012 R2 SP1 or later, you're good. Earlier versions? Upgrade first.
• Administrative access to both the SCCM console and the content source share where you'll store installation files.
• The Office 2016 volume licensed media—either an ISO or extracted files. If you're deploying Office 365 ProPlus (C2R), you'll need access to that source instead.
• The Office Deployment Tool (ODT) , which you can grab from the official Microsoft download page.
• A basic understanding of XML configuration files. Don't worry—I'll provide working examples you can copy-paste.

One thing I've learned the hard way: test your SCCM infrastructure before starting. Run a simple application deployment first. If that fails, Office 2016 will too, and you'll waste hours chasing the wrong problem.

---

Step 1: Download and Prepare Office 2016 Installation Files Using the Office Deployment Tool

This is where most people trip up. The ODT is powerful, but it's also finicky. Get the XML wrong, and you'll stare at a command prompt doing nothing for 20 minutes.

Creating the Download.xml Configuration File

The Download.xml file tells the ODT what to download—which version, architecture, and languages. Think of it as your shopping list.

Here's a working example for Office 2016 Pro Plus (Volume edition) with English and French:

<Configuration>
  <Add SourcePath="C:\Office2016" OfficeClientEdition="32">
    <Product ID="ProPlusVolume">
      <Language ID="en-us" />
      <Language ID="fr-fr" />
    </Product>
  </Add>
</Configuration>

A few notes from experience:

• Product ID "ProPlusVolume" is for volume-licensed Office 2016 Pro Plus. If you're deploying Office 365 ProPlus, use "O365ProPlusRetail" instead.
• OfficeClientEdition="32" is still the safe bet for most organizations. Go 64-bit only if you have specific needs (like large Excel datasets or AutoCAD plugins).
• The download is roughly 1.25 GB and happens silently. You won't see a progress bar—just a blinking cursor. That's normal.

To execute the download, open a command prompt in the folder containing setup.exe and run:

setup.exe /download Download.xml

Go grab a coffee. Or two. Depending on your internet speed, this could take a while.

Creating the Configure.xml File for Silent Installation

Here's the critical distinction: Download.xml is for downloading. Configure.xml is for installing. They serve different purposes, and mixing them up will cause headaches.

The most important rule—and I cannot stress this enough—do NOT include the SourcePath attribute in your Configure.xml file. SCCM handles the source path dynamically through its client cache. If you hardcode a path, the installation will fail on every machine that doesn't have that exact folder structure.

Here's a working Configure.xml for silent installation:

<Configuration>
  <Add OfficeClientEdition="32">
    <Product ID="ProPlusVolume">
      <Language ID="en-us" />
      <Language ID="fr-fr" />
    </Product>
  </Add>
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

Notice what's missing? No SourcePath. The Display Level="None" and AcceptEULA="TRUE" ensure the installation runs completely silently—no pop-ups, no user interaction required.

I once spent three hours debugging a deployment only to realize I'd left a stray SourcePath in the Configure.xml. Don't be that person.

---

Step 2: Create the Office 2016 Application in the SCCM Console

Now we're getting to the good stuff. This is where SCCM's application model shines compared to the old package model.

Manually Specifying the Application Information

Navigate to Software Library > Application Management > Applications in the SCCM console. Right-click and select Create Application.

Choose "Manually specify the application information" —don't let SCCM auto-detect anything. It rarely gets it right for Office deployments.

Fill in the basics:

• Name: Office 2016 Pro Plus
• Publisher: Microsoft
• Software version: 16.0

The Application Catalog settings are optional, but I recommend filling them out if users will be installing from Software Center. A clear description saves helpdesk tickets.

Configuring the Deployment Type (Script Installer)

This is where the magic happens. Select Script Installer as the deployment type—not Windows Installer, not App-V. Script Installer gives us the flexibility to use ODT's command-line interface.

Content Location: Point this to the network share containing your ODT files—setup.exe, Configure.xml, and the downloaded Office folder. Make sure the SCCM computer account has read access to this share.

Installation Program:

setup.exe /configure Configure.xml

Uninstall Program:

setup.exe /configure Uninstall.xml

You'll need to create a simple Uninstall.xml. Here's one that works:

<Configuration>
  <Display Level="None" AcceptEULA="TRUE" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <Remove>
    <Product ID="ProPlusVolume">
      <Language ID="en-us" />
      <Language ID="fr-fr" />
    </Product>
  </Remove>
</Configuration>

Detection Method: This is where I see people make mistakes. Use Windows Installer detection with the following product code:

{90160000-008F-0000-1000-0000000FF1CE}

This is the product code for Office 2016 Pro Plus. If you're deploying a different SKU, you'll need a different code. Microsoft publishes a full list, but I've found this one works for 95% of volume-licensed deployments.

Installation Behavior: Set this to "Install for system" . If you set it to "Install for user," the installation runs in the user context and can fail when users don't have local admin rights—which they shouldn't.

---

Step 3: Distribute Content and Deploy the Application

You've built the application. Now let's get it to your endpoints.

Distributing Content to Distribution Points

Right-click your application and select Distribute Content. Choose your Distribution Point or DP Group. If you have remote offices, make sure you select DPs that are geographically close to your target machines—nobody wants to pull 1.25 GB across a slow WAN link.

Monitor the distribution status in the Monitoring > Distribution Status > Content Status node. Wait until the status shows "Success" before proceeding. I've seen deployments fail because someone distributed content and immediately deployed before the DPs had the files.

Creating a Deployment to a Device Collection

Right-click the application and select Deploy. Here's where you make some key decisions:

Target Collection: Select the device collection containing your target machines. If you're testing, use a pilot collection first. I always recommend a phased approach—start with IT staff, then a pilot group, then broad rollout.

Purpose:

• Required = automatic, mandatory install. The machine will install Office whether the user likes it or not.
• Available = users can install from Software Center when they're ready.

For Office 2016, I typically use "Required" with a deadline. Users get a notification and can schedule the install, but it will happen eventually.

Schedule: Set this to "As soon as possible" for immediate deployment. If you're doing a phased rollout, use a specific date/time.

User Experience: Check "Software installation" and "System restart (if needed)." Office 2016 rarely requires a restart, but it's better to be safe.

---

Troubleshooting Common Office 2016 SCCM Deployment Errors

Let's be honest—deployments rarely go perfectly the first time. Here are the errors I see most frequently and how to fix them.

Error 30068: The Installation Failed

This is the generic C2R error that makes everyone panic. It's like Windows telling you "Something went wrong"—not helpful.

Common causes:

• Corrupted source files
• Network issues during download
• Insufficient disk space on the client

Solutions:

1. Re-download the Office source files using ODT. I've seen downloads that appear successful but have corrupted files. Delete the Office folder and run setup.exe /download Download.xml again.

2. Check the SCCM client cache at C:\Windows\ccmcache. Look for corrupted or incomplete files. You can clear the cache using the Configuration Manager control panel applet.

3. Verify your Distribution Point has the latest content. Right-click the application and select "Update Content" to force a refresh.

Microsoft has official documentation on error 30068, but honestly, re-downloading fixes it 80% of the time.

Error 0x80070005: Access Denied

This one's straightforward—permissions. But tracking down which permissions can be maddening.

Solutions:

1. Verify the target machine's computer account has "Read" access to the SCCM content source share. This is the share where you stored the ODT files, not the Distribution Point.

2. Check the Network Access Account configuration in SCCM. Go to Administration > Site Configuration > Sites, select your site, and check the Client Computer Communication settings. The Network Access Account needs permissions on the content source share.

3. Ensure "Install for system" is selected in the deployment type. If it's set to "Install for user," the installation runs under the user's credentials, which may not have access to network shares.

How to Check Office 2016 Deployment Log Files

When things go wrong, logs are your best friend. Here are the key ones:

• AppEnforce.log (client-side): Located at C:\Windows\CCM\Logs. This tells you if the detection method succeeded or failed. Look for lines containing "App enforcement" and "Detection state."

• execmgr.log (task sequence): Also in C:\Windows\CCM\Logs. Use this if you're deploying via task sequence.

• ODT log: Located in %temp%. The exact filename varies, but look for files starting with "Office" or "ODT."

To enable verbose logging for ODT, add this to your Configure.xml:

<Logging Level="Standard" Path="%temp%" />

Change "Standard" to "Verbose" for maximum detail. Warning: verbose logs can get huge, so only use it for troubleshooting.

---

Best Practices for a Smooth Office 2016 SCCM Deployment

After deploying Office 2016 to thousands of machines across dozens of organizations, here's what I've learned works best.

Handling Existing Office Versions

If your users have Office 2013 (or older) installed, you need to handle the upgrade gracefully. The RemoveMSI element in Configure.xml automates this:

<Configuration>
  <Add OfficeClientEdition="32">
    <Product ID="ProPlusVolume">
      <Language ID="en-us" />
    </Product>
  </Add>
  <Display Level="None" AcceptEULA="TRUE" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <RemoveMSI />
</Configuration>

The RemoveMSI element automatically uninstalls any previous MSI-based Office versions. But here's the catch—it only works for MSI versions. If users have Click-to-Run versions of Office 365, you'll need a different approach.

Warning: Test this on a pilot collection first. I've seen RemoveMSI fail when users have custom Office installations or non-standard configurations. Always, always test.

Managing Updates for Deployed Office 2016

Once Office 2016 is deployed, you need to keep it updated. SCCM can handle this through the Software Updates feature.

1. Enable the "Office 2016" product category in your Software Update Point configuration. Go to Administration > Site Configuration > Sites, select your site, and configure the SUP component.

2. Create an Automatic Deployment Rule (ADR) for Office updates. This automates the monthly update cycle. Microsoft publishes Office updates on the second Tuesday of each month (Patch Tuesday).

3. Monitor compliance using the built-in reports. The "Compliance 5 - Specific software update" report is particularly useful.

Microsoft has detailed documentation on configuring SUP for Office updates, but the key takeaway is: don't rely on Office's built-in auto-update. Let SCCM manage it.

---

Frequently Asked Questions

Can I deploy Office 2016 using SCCM without a task sequence?

Absolutely. Deploying as an Application (as shown in this guide) is the simplest method. Task sequences are useful for more complex scenarios—like OS deployment or chaining multiple applications together—but for a straightforward Office install, an Application deployment is all you need.

What is the difference between deploying Office 2016 with SCCM and the Office Deployment Tool (ODT) alone?

ODT is a command-line tool for local or scripted installations. It's great for small-scale deployments or one-off installs. SCCM, on the other hand, provides enterprise-scale management—reporting, scheduling, compliance monitoring, and phased rollouts. Under the hood, SCCM uses ODT for C2R deployments, but it adds the management layer that makes large-scale deployments practical.

How do I silently install Office 2016 via SCCM?

The key is the Configure.xml file. Set Display Level="None" and AcceptEULA="TRUE". Also, ensure the SCCM deployment type is set to "Install for system" and the deployment purpose is "Required." This combination gives you a completely silent, hands-off installation.

Why is my Office 2016 SCCM deployment failing with error 30068?

Common causes include corrupted source files, network issues, or insufficient disk space on the client. Start by re-downloading the Office source files using ODT. If that doesn't work, check the SCCM client cache for corrupted files and verify your Distribution Point has the latest content version.

---

Conclusion

Deploying Office 2016 with SCCM doesn't have to be complicated. The key steps are straightforward:

1. Prepare your ODT files—Download.xml for downloading, Configure.xml for installing
2. Create the SCCM application with a Script Installer deployment type
3. Configure the deployment type with the correct detection method and installation behavior
4. Distribute content and deploy to your target collection

The most important advice I can give: test on a pilot group before broad rollout. I've seen too many organizations push Office to thousands of machines only to discover a configuration error that breaks half of them. Start small, validate, then scale.

Mastering this process saves significant time and reduces manual errors. In my experience, automating Office deployment with SCCM cuts deployment time by 90% compared to manual installation—and that's not counting the time saved on troubleshooting inconsistent configurations.

Have you encountered a specific error during your deployment? Share your experience in the comments below, or download our free Office 2016 deployment checklist to ensure you don't miss a step.