How to Manage the Full Lifecycle of Microsoft 365 Apps with Configuration Manager

You should be running a currently supported version of Microsoft Endpoint Configuration Manager with, at minimum:

• A primary site
• A management point
• A distribution point (DP)
• A software update point (SUP)

On top of that, make sure:

• Clients are enrolled and reporting into ConfigMgr
• You have already deployed some packages or applications successfully

If your lab or production environment doesn’t meet this baseline, it’s worth fixing that first. In my experience, trying to troubleshoot Office deployments on top of a half‑configured ConfigMgr setup is just unnecessary pain.

Once those boxes are checked, you’re ready to start building and deploying Microsoft 365 Apps.

From the Configuration Manager console, your starting point is the Software Library workspace.

High‑level workflow:

1. Go to Software Library → Office 365 Client Management.
2. Select Office 365 Installer.
3. Launch the wizard to create a new Microsoft 365 Apps application.

This wizard doesn’t just build an app definition inside ConfigMgr—it actually connects out to the Office configuration web tool to generate the XML configuration file for you. That XML tells the Office Deployment Tool exactly what to install.

Key configuration decisions you’ll make in the designer:

• Architecture: e.g. 64‑bit (recommended for most modern environments)
• Product: Microsoft 365 Apps for enterprise (formerly Office 365 ProPlus)
• Additional products: Optional add‑ons such as Visio or Project
• Update channel: For example, Monthly Enterprise Channel, Current Channel, or Semi‑Annual Enterprise Channel
• Version: The wizard usually autofills the latest available build for that channel
• Apps to include/exclude: Word, Excel, PowerPoint, Outlook, OneDrive, Teams, etc.
• Bing search integration: You can turn off the Microsoft Search in Bing background service if it’s not desired
• Languages: Primary language plus optional additional languages (full, partial, or proofing only)
• Installation behavior: Whether to force close running Office apps (many admins choose not to be disruptive here)
• Previous MSI versions: Automatically uninstall older MSI‑based Office products
• Licensing and activation: Typically user‑based activation with EULA automatically accepted

Once you walk through those options and click Finish in the web configuration tool, it generates the configuration.xml file. The ConfigMgr wizard then:

• Downloads the latest Office Deployment Tool (setup.exe)
• Uses your generated XML with a /download switch
• Pulls down all the required Office files to the content source folder you specified

When the wizard completes, you’ll see a new Application under Application Management → Applications for Microsoft 365 Apps.

Here’s where a lot of admins quietly get bitten.

The initial Office 365 Installer workflow creates a static package:

• The XML usually contains a specific build number (version attribute)
• The downloaded Office files match that exact build

That means:

• Even if months go by and new builds are released, your app will still install the old build
• You can easily end up deploying outdated, vulnerable Office versions

From a best practices perspective, if you stick with this static model, you should periodically refresh the source files.

A typical refresh flow for a static package:

1. Go to the source folder for the application (where ConfigMgr downloaded Office).
2. Optionally back up the directory in case you ever need that specific build.
3. Delete the Office subfolder that contains the binaries.
4. Open configuration.xml.
5. Remove the version="xxxx" attribute from the `<Add>` element if it’s still there.
6. Open a PowerShell window in that folder.
7. Run:
`.\\setup.exe /download .\configuration.xml`

The Office Deployment Tool will download a fresh set of binaries based on:

• The update channel defined in the XML, and
• The latest available build for that channel

After the download completes, you can go back to the ConfigMgr console and update content on all distribution points.

This does work, but to be honest, it’s a little bit of ongoing overhead—especially if you have multiple channels or languages to maintain.

A dynamic install for Microsoft 365 Apps in ConfigMgr is a lightweight approach where:

• ConfigMgr does not host the Office binaries
• The package only contains:
• `setup.exe` (Office Deployment Tool)
• `configuration.xml` (your settings)
• At install time, the client device uses the Office Deployment Tool to connect directly to the Office Content Delivery Network (CDN) and download the latest bits

This approach has some very real pros and cons.

Pros of dynamic installs

• No need to manually refresh Office content on DPs
• Always installs the latest build for the selected channel
• Smaller footprint on your distribution points
• Simpler management when you support multiple languages or channels

Cons of dynamic installs

• Clients must be able to reach the Office CDN during installation
• Install speed depends on the user’s network connection (could be blazing fast, could be painful)
• Less control if you prefer to stage content internally for bandwidth reasons

In many environments, the dynamic method is a great default, especially if you already allow cloud content and have decent internet connectivity from endpoints.

The nice thing is you don’t need to rebuild your application from scratch. You can simply convert the existing static package to behave dynamically.

High‑level steps:

1. Locate the content source folder used by your Microsoft 365 Apps application.
- In the console, edit the deployment type → Content tab to confirm the path.
2. Open that folder in File Explorer. You’ll typically see:
- An `Office` folder (the static binaries)
- `configuration.xml` (your install configuration)
- `setup.exe` (Office Deployment Tool)
3. Delete the `Office` folder.
- This ensures ConfigMgr is no longer distributing static binaries.
4. Open configuration.xml in Notepad.
5. On the `<Add>` element, remove the version attribute.
- Without a version, Office will install the latest build on the defined channel.
6. Save and close the XML.

That’s it. The application now functions as a dynamic installer.

Next steps:

• Distribute content (the small setup + XML) to your distribution points.
• Deploy the app to the appropriate device or user collections.

From here on, the client:

• Downloads `setup.exe` and `configuration.xml` from your DP
• Runs the Office Deployment Tool
• Pulls the current build from the Office CDN at install time

For organizations where internet access from clients is normal, this is often the sweet spot between control and maintainability.

First, your Software Update Point (SUP) needs to know it should sync Microsoft 365 Apps updates.

Steps in the console:

1. Go to Administration → Site Configuration → Sites.
2. Right‑click your site → Configure Site Components → Software Update Point.
3. On the Classifications tab:
- Ensure Updates is checked.
4. On the Products tab:
- Filter for `365`.
- Enable Microsoft 365 Apps / Office 2019 / Office LTSC (wording may vary slightly by version).
5. Click Apply and close the dialog.

Then trigger a sync for Office updates:

1. Go to Software Library → Office 365 Client Management → Office 365 Updates.
2. Click Synchronize Software Updates in the ribbon.
3. Confirm the prompt.

This starts a software update synchronization that will bring in the Office update metadata.

Next, the ConfigMgr client settings need to be aware that they should manage Microsoft 365 Apps updates.

You can either modify an existing client settings policy or create a new custom one. The transcript used a new custom policy, which is often cleaner:

1. Go to Administration → Client Settings.
2. Create a new custom client device settings policy.
3. Enable at least these categories:
- Hardware Inventory
- Software Updates

Then configure them:

Hardware Inventory

• Make sure Hardware inventory is Enabled.
• Set the inventory schedule to an interval that fits your environment.
• Click Set Classes… and search for `Office`.
• Enable Office 365 Configurations.
• This class includes important fields like update channel, version, CDN URL, etc.
• (Optional) Enable additional Office‑related classes for migration/compatibility scenarios (e.g., if you’re moving from Office 2016 MSI).

Software Updates

• Ensure Enable software updates on clients is Yes.
• Set the scan schedule and reevaluation schedule as appropriate.
• Scroll down to the Microsoft 365 Apps‑specific settings:
• Enable management of the Office 365 Client Agent: set to Yes.
• This enables Office COM management so Office takes update instructions from ConfigMgr.
• Enable update notifications from Microsoft 365 Apps: choose whether to show native in‑app notifications or rely only on Software Center.
• If you set this to No, users will only see Software Center notifications.

Deploy this client settings policy to the relevant collections (for example, All Desktops and Server Clients or a more targeted set). Clients will need time to:

• Pull the new policy
• Run a hardware inventory cycle
• Report data back to ConfigMgr

Once that’s in place, you’ll have the data and client behavior you need to manage Office updates effectively.

Dynamic collections let you slice your environment based on Office properties—version, channel, presence of Microsoft 365 Apps, and so on.

Typical helpful collections include:

• All devices with Microsoft 365 Apps installed
• Devices on a specific update channel (e.g., Monthly Enterprise Channel)
• Devices on a specific build or older than a certain build

In the transcript, a collection named something like:

> Devices with Microsoft 365

was created using a query rule. The actual WQL query isn’t reproduced here, but the idea is:

• Query against the Office 365 Configurations hardware inventory class
• Filter for devices where Microsoft 365 Apps is present (and possibly by channel or other attributes)

The collection is set to update membership on a schedule (e.g., every 1 day), so it stays current automatically.

You can then:

• Use this collection as the target for software update deployments
• Build additional collections off of it for canalized rollouts (test, pilot, production) or channel migrations

Office update naming can be surprisingly confusing until you’ve seen the pattern a few times. But understanding it is critical to avoid deploying conflicting updates.

Key points:

• Microsoft 365 Apps updates are cumulative.
• If you miss two months and install the latest update, you still get all prior fixes and features.
• Production channels include:
• Current Channel
• Monthly Enterprise Channel
• Semi‑Annual Enterprise Channel (with preview and extended support options)
• Some channels (Monthly Enterprise, Semi‑Annual) can have both a production version and an extended support version live at the same time.

The release type in the update title is particularly important:

• Feature Update
• A new build that introduces features (e.g., each Monthly Enterprise release)
• Quality Update
• A cumulative update that primarily delivers fixes (used for months between major Semi‑Annual feature updates)
• Extended Quality Update
• For the extended support build, one version behind the current release

The trap to avoid: deploying both the current feature/quality update and the extended quality update to the same device. They’re both “current” (not superseded), but they’re not meant to be installed together. Doing so tends to cause update failures and messy compliance numbers.

Rule of thumb:

• If you want latest production build for a channel → deploy the most recent Feature Update or Quality Update.
• If you intentionally stay one version behind → deploy the Extended Quality Update only for that channel/build.

You can deploy updates manually just like Windows updates.

From Software Library → Office 365 Client Management → Office 365 Updates:

1. Use Add Criteria to filter updates. For example:
- `Required >= 1` to only show updates needed by at least one device
2. Review the results:
- Check Superseded status (ignore superseded updates)
- Look at the Title to identify release type (Feature, Quality, Extended Quality)
3. Choose the single appropriate update (for example, the monthly Feature Update for Monthly Enterprise Channel).
4. Right‑click → Deploy.
5. Walk through the standard Software Update Deployment Wizard:
- Name the deployment
- Select target collection (e.g., your “Devices with Microsoft 365 Apps” collection)
- Configure schedule, user experience, alerts, deployment package options, etc.

This works for one‑off deployments or initial testing, but doing this manually every month (or multiple times per month for Current Channel) gets old very quickly. That’s where Automatic Deployment Rules (ADRs) come in.

Automatic Deployment Rules let you define search criteria, deployment settings, and a schedule, then let ConfigMgr handle the ongoing maintenance.

To create an ADR for Microsoft 365 Apps:

1. Go to Software Library → Software Updates → Automatic Deployment Rules.
2. Right‑click → Create Automatic Deployment Rule.
3. Give the rule a meaningful name (e.g., `M365 Apps – Monthly Enterprise Channel – Prod`).
4. Select the target collection.
- Often a dedicated “M365 Apps – Prod” collection, possibly after a smaller “M365 Apps – Pilot” rule.
5. Choose to add updates to an existing software update group or create a new one.
- For M365 Apps, many admins simply use a single ongoing group since older updates expire out.
6. Enable the deployment after the rule runs (so it’s active automatically).

Now define your search criteria—the key part:

Typical example for Monthly Enterprise Channel Feature Updates:

• Product = Microsoft 365 Apps / Office 2019 / Office LTSC
• Required ≥ 1
• Superseded = No
• Title contains `Monthly Enterprise Channel Feature Update`

Use the Preview button to verify that the query:

• Returns exactly the single expected update (the latest Monthly Enterprise Channel Feature Update)

For other channels, you might do something like:

• Title contains `Semi-Annual Enterprise Channel`
• Title does not contain `Preview`
• Title does not contain `Extended`

Because Feature and Quality updates supersede one another, that logic typically leaves you with just the latest cumulative update.

On subsequent wizard pages:

• Evaluation schedule: Often “run after every SUP sync.”
• Deployment schedule: Set delays/maintenance windows to match your patching policy.
• User experience: Configure restart behavior and notifications.
• Deployment package:
• You can use a traditional deployment package or
• Choose No deployment package and let clients download directly from the CDN (similar to the dynamic install approach).

Once the ADR is created, you can right‑click it and Run Now to test it immediately. Then, on each SUP sync, it will automatically:

• Identify new Office updates that match
• Add them to the target software update group
• Activate the deployment for your collection

At that point, your main job shifts from “push updates” to monitoring compliance and occasionally tweaking the ADR logic when your channel or servicing strategy changes.

A few practical ways to see what’s going on in your environment:

1. Targeted Collections

Beyond the basic “Devices with Microsoft 365 Apps,” you can build collections such as:

• Devices on Current Channel vs Monthly Enterprise Channel vs Semi‑Annual
• Devices on a specific version or older than version 2008
• Devices not yet onboarded to a certain management model

These are useful both for reporting and for staged deployments (for example, moving a subset of devices from Semi‑Annual to Monthly Enterprise).

2. CMPivot for Real‑Time Queries

CMPivot lets you query live data from connected clients, which is incredibly handy when you don’t want to wait for the next scheduled inventory cycle.

Typical use case:

1. Right‑click a collection (e.g., “Devices with Microsoft 365 Apps”) → Start CMPivot.
2. Run a prebuilt query against Office‑related entities.
3. View results in real time and optionally:
- Export the data
- Create a new collection based on those results

You might query things like installed version, channel, update status, or language packs.

3. Office 365 Client Management Dashboards

Under Software Library → Office 365 Client Management, you have graphical dashboards (assuming hardware inventory data is present), including:

• Install counts
• Devices without Microsoft 365 Apps
• Breakdown of versions and update channels
• Languages in use across the fleet

There’s also an Upgrade Readiness dashboard which is particularly useful if you’re moving from older Office versions or planning a major servicing profile change. It surfaces details like add‑ins and macros that might block or complicate upgrades.

For day‑to‑day patching visibility, you’ll spend a lot of time in the Monitoring workspace.

Deployment Status

1. Go to Monitoring → Deployments.
2. Filter to show:
- Your Microsoft 365 Apps application deployment
- Your Office updates software update group deployments (including ADR‑created ones)
3. From here you can see:
- Compliance percentages (Success, In Progress, Failed, etc.)
- Whether the deployment is Required or Available
- Feature type and general status

Right‑click a deployment → View Status to drill into specific states and see which devices are in each bucket. Remember this is summarized data—if needed, you can force a summarization refresh from the top right.

Reporting

Configuration Manager ships with a large set of built‑in SSRS reports.

For Microsoft 365 Apps update compliance, a very common one is:

• Software Updates → Compliance 1 – Overall compliance for a specific software update

Typical workflow:

1. In Monitoring → Reporting, expand Reports.
2. Navigate to Software Updates.
3. Run the report that shows compliance for a specific update.
4. When prompted:
- Select the collection that received the deployment.
- Provide a filter such as the update title.

You can run the report in a browser, which is convenient for bookmarking or for admins who don’t have the full ConfigMgr console installed.

From the report you can usually:

• See compliance percentages at a glance
• Click into the update title to drill down to device‑level details
• See which devices require the update and when they last reported

This level of visibility is what turns Office lifecycle management from guesswork into a measurable, auditable process.

You don’t need anything overly fancy to be effective. A straightforward pattern might look like this:

1. Initial App Deployment
- Create the Microsoft 365 Apps application using the Office 365 Installer.
- Convert it to a dynamic install package (setup + XML, no static content).
- Deploy it to your target device or user collections.

2. Update Management Setup
- Enable Microsoft 365 Apps products on the Software Update Point.
- Configure client settings for Hardware Inventory, Software Updates, and Office COM management.
- Build a dynamic collection for “Devices with Microsoft 365 Apps.”

3. Automated Updating
- Create one or more Automatic Deployment Rules based on your channel strategy.
- Use carefully crafted search criteria so you only pick up the right Feature/Quality updates.
- Allow clients to download updates from the Office CDN if that fits your network design.

4. Monitoring and Tuning
- Use dashboards, CMPivot, and reports to track versions and compliance.
- Adjust ADRs or collections as your servicing plan evolves.
- Use targeted collections for pilot testing, channel migrations, or troubleshooting.

It’s not completely “set it and forget it,” but once these pieces are in place, the day‑to‑day work is much lighter and far more predictable.