Use Group Policy to enable Office 365 clients to receive updates via ConfigMgr

Office365_GPOThis week something completely different, compared to the last couple of weeks. This week I want to take a quick look at enabling Office 365 clients to receive updates via ConfigMgr. More specifically, use Group Policy for configuring Office 365 clients to receive updates via ConfigMgr. There is a lot of information available about configuring the Office 365 clients via the initial installation and configuration (configuration.xml), but what about the existing Office 365 clients?

In this post I will provide the required information about using Group Policy to enable the existing Office 365 clients to receive update via ConfigMgr. I will show the Group Policy settings, related to updating the Office 365 clients, and I’ll show how those settings relate to the initial installation and configuration settings. Of course, once I know the registry keys, used by the Group Policy, I can also use Configuration Baselines to do something similar. However, that’s not part of the scope of this post, but I will mention a few Group Policy settings that are ideal candidates for that.


Let’s start with a few important prerequisites for managing Office 365 client updates with ConfigMgr, mainly related to versions of products. Before enabling the Office 365 client to receive updates via ConfigMgr, make sure the following version requirements are in place:

  • System Center Configuration Manager current branch 1602 or later;
  • Windows Server Update Services (WSUS) 4.0 or later;
  • Office 365 client with version 16.0.6741.2014 or later;
    • This functionality is now available for First Release for Deferred Channel and Current Channel. Deferred Channel is expected in June 2016.

Group Policy settings

Before looking at the available Group Policy settings, make sure to download and install the Office 2016 Administrative Template files from the Microsoft Download Center. Once installed, the Office 365 client update settings can be found at Computer Configuration\Policies\Administrative Templates\Microsoft Office 2016 (Machine)\Updates.

Overview of Group Policy settings

Below is an overview of the Group Policy settings, that can be used to configure the Office 365 client update settings, including how those settings translate to the settings in the installation and configuration files (configuration.xml) and the available values.

Setting Value XML example
Enable Automatic Updates Not Configured | Enabled | Disabled Enabled=”TRUE”
Hide option to enable or disable updates Not Configured | Enabled | Disabled N/A
Hide Update Notifications Not Configured | Enabled | Disabled N/A
Office 365 Client Management Not Configured | Enabled | Disabled OfficeMgmtCOM=”TRUE”
Update Channel

Not Configured | Enabled | Disabled

Channel identifier:
[Specify one of the following Current | Business | Validation | FirstReleaseCurrent]

Update Deadline

Not Configured | Enabled | Disabled

[Specify UTC deadline format MM/DD/YYYY HH:MM]

Deadline=”08/05/2016 20:30”
Update Path

Not Configured | Enabled | Disabled

Location for updates:
[Specify location on the network, local on the device, or on Internet]

Target Version

Not Configured | Enabled | Disabled

Update version:
[Specify version number]


Note: The Group Policy settings are written in the registry in the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate.

Configure Office 365 client to use ConfigMgr for updates

The most important Group Policy setting, for enabling the Office 365 client to receive updates via ConfigMgr, is shown in blue italic. That setting, Office 365 Client Management, will make sure that the Office COM object takes commands from ConfigMgr to download and install Office 365 client updates.

Configure end-user experience

There are also a few Group Policy settings that can configure a little bit of the end-user experience. Enabling the Hide option to enable or disable updates setting, makes sure that the end-user can’t disable the update behavior of the Office 365 client and the combination of enabling the Enable Automatic Updates setting and disabling the Hide Update Notifications setting, makes sure that the end-user receives notifications about pending updates for the Office 365 client. That combination is definitely recommended.

Configure update channel

There is also a Group Policy setting that can configure the update channel of the Office 365 client. Enabling the Update Channel setting, enables the channel identifier. That identifier can be used to configure the update channel, by specifying Current, Business, Validation or FirstReleaseCurrent. With configuring the update channel keep in mind that the following information is applicable to the updates delivered to the channels.

Channel GPO/XML Feature updates Security updates Non-security updates
Current Channel Current Monthly Monthly Monthly
First Release for Deferred Channel Validation Every four months Monthly Monthly
Deferred Channel Business Every four months Monthly Every four months

Note: The FirstReleaseCurrent value, is referring to the First Release for Current Channel, which is the Office Insider Program.

Other Group Policy settings

The remaining Group Policy settings, the Update Deadline, the Update Path and the Target Version, are only relevant when ConfigMgr is not used for deploying Office 365 client updates.

More information

For more information about configuring the Microsoft Office 365 client and specifically the update configuration, please refer to:

Auto Deployment of FEP Definition Updates with ConfigMgr 2007

This week Microsoft released Forefront Endpoint Protection (FEP) 2010 Update Rollup 1 (including some extra tools). The tools update included some extra policies and also a Definition Update Automation Tool. Together with this, there was also an article published about Definition Update Automation with Configuration Manager.

Personally I don’t like the idea of creating a new Task with the Windows Task Scheduler, while we’ve got Status Filter Rules within ConfigMgr. With these rules we can make a “connection” between the scheduled synchronization of the Software Update Point (SUP) and the start of the Definition Update Automation Tool. Otherwise the tool might run while there hasn’t been a new synchronization of the SUP. To prevent this, I will show in this post how to create the Status Filter Rule.

The prerequisites for this post are the same as mentioned in Definition Update Automation with Configuration Manager.

Open the file and copy SoftwareUpdateAutomation.exe to <Installationdirectory>\AdminUI\bin

In the ConfigMgr Console browse to Site Database > Site Management > <Sitename> > Site Settings > Status Filter Rules and select New Status Filter Rule in the Actions pane.


On the General page, fill in a Name, select as Source ConfigMgr Server, select as Component SMS_WSUS_SYNC_MANAGER, fill in as Message ID 6702 and click Next.

This makes sure that every time the SMS_WSUS_SYNC_MANAGER is DONE this action (which we configure in the next step) will start.


On the Actions page, select Run a Program, fill in as commandline “<Installationdirectory>\AdminUI\bin\SoftwareUpdateAutomation.exe”
/AssignmentName <DeploymentName> /PackageName <PackageName> and click Next.


On the Summary page and click Next.


On the Summary page and click Finish.


Download Microsoft Forefront Endpoint Protection (FEP) 2010 Update Rollup 1 Tools:

Update 18-07: There are some issues discovered with the new tool, take a look here for more information and solutions:

Update 01-11: A new version of the Definition Update Automation Tool has been released. This version refreshes the Distribution Point by default and has a new option to disable that behavior (/DisableRefreshDP):

ConfigMgr 2007, Updating a Windows 7 Image with the latest Software Updates – A less conventional, but very effective way

Inspired by a previous post about the option to Schedule Updates for an already existing Operating System Image in ConfigMgr vNext, I created a little batch-file to do something similar without the GUI of ConfigMgr vNext. Of course, I do know that the ‘best practice’ for ConfigMgr 2007 is to just run another Build and Capture Task Sequence, but in some cases this can come in handy. One thing is for sure, this updates a Windows 7 Image within fifteen minutes.

Background Story

Now lets start with a little background story, to explain why in some situations there might be the need for this batch-file. Every month there are new Software Updates released by Microsoft. During the Software Updates Deployment the, for the organization needed, updates get selected and downloaded to the Software Update Package. In other words, the, for the organization needed, updates are already downloaded and available. To update the existing image with the newest updates, the ‘best practice’ is to deploy the newest updates and run another Build and Capture Task Sequence. Sometimes, especially at smaller companies, this is considered as a lot of extra work/ effort and because of that, it is often forgotten. Even though an up-to-date Windows 7 Image deploys a lot faster then a Windows 7 Image that still has to install a lot of Software Updates. So to help out the people that are just to busy (you can actually fill in anything you want, I just like to think that they are to busy), I created this batch-file that will do everything.PckgSrcLctn

Input Locations

Well… after this all being said, lets take a look at the two most important inputs that we need for this batch-file:

  1. The current setup of the batch-file assumes that there is a  Software Updates Package for all Windows 7 (x86 and x64) updates. The Package source of this package is used as input for this batch-file. This location can be found in the Properties of the Software Updates Package (see the first picture) in the ConfigMgr Console. By doing this, it is not needed to re-download the Software Updates, it’s only needed to gather the Software Updates together from all the subdirectories.
  2. Another important input for the batch-file is the location of the Windows 7 Image, which has to be updated. For this the Image path can be used, which can be found in the Properties of the Operating System Image (see the second picture) in the ConfigMgr Console. Don’t forget that it is still needed to update the Distribution Point(s) after the batch-file has run!


As we know now a little background story and we know where the most important parts of the input comes from, lets take a look at the batch-file that will make it happen.

REM =========================================
REM ARGUMENT -1- TempPartition = %1
REM ARGUMENT -2- UpdatesPackageSource = %2
REM ARGUMENT -3- Architecture = %3
REM ARGUMENT -4- WimFileAndLocation = %4
REM ===================================================

REM ===================================================
REM Make (temporary) directories for updates and mounting
REM ===================================================

MD %1\TEMP\Mount
MD %1\TEMP\Updates

REM ======================================================
REM Copy new updates of %3 -architecture and of > %5 -date to temporary directory
REM ======================================================

FOR /R %2 %%P IN (* DO (
XCOPY "%%P" %1\TEMP\Updates /H /C /Y /D:%5

REM ======================================================
REM Mount image, add updates, commit and unmount
REM ======================================================

DISM /Mount-Wim /WimFile:%4 /Index:1 /MountDir:%1\TEMP\Mount /LogPath:%1\DISM.Log
DISM /Image:%1\TEMP\Mount /Add-Package /PackagePath:%1\TEMP\Updates /LogPath:%1\DISM.log
DISM /Unmount-Wim /MountDir:%1\TEMP\Mount /Commit /LogPath:%1\DISM.log

REM ======================================================
REM Remove (temporary) directories again
REM ======================================================

RD %1\TEMP /S /Q

The biggest part will explain itself, with or without the comments, but it also shows here that I am using five variables. This is to make it easier adjustable for different Windows 7 Images, Package source location, architectures and dates. These variables are used in the following way:

  1. %1 – Presents the volume that can be used to store the temporary folders.
  2. %2 – Presents the full location of the Software Updates Package source.
  3. %3 – Presents the architecture of the Operating System.
  4. %4 – Presents the full location of the Operating System Image, including the name of it.
  5. %5 – Presents the date of the oldest Software Updates that have to be added (Format: MM-DD-YYYY).

Now lets end this post with how to run this batch-file:
[NameOfBatchFile].BAT [DriveLetter:] [SoftwareUpdatesPackageSourceLocation] [Architecture] [WIMLocation\WIMName] [DateLatestNeededUpdates]

Installing Software Updates via a Task Sequence in ConfigMgr 2007

I noticed that when your Site is running in Native Mode you can run into problems with installing Software Updates via a Task Sequence. The first time that your are installing your computer with your Task Sequence there are no problems, but every time after that the Task Sequence will finish successful but doesn’t install any Software Updates. It looks like that it will use existing scan results of the client from the previous scan. So when there are already scan results of your client it will not rescan during your Task Sequence.

To work around this I use the following scripts (that I run before the step Install Software Updates in the Task Sequence):

  1. Initiate Software Updates Scan:
    actionNameToRun = “Software Updates Assignments Evaluation Cycle”

    Dim oCPAppletMgr
    Set oCPAppletMgr = CreateObject(“CPApplet.CPAppletMgr”)

    Dim oClientActions
    Set oClientActions = oCPAppletMgr.GetClientActions()

    ‘Loop through the available client actions. Run the matching client action when it is found.
    Dim oClientAction
    For Each oClientAction In oClientActions
       If oClientAction.Name = actionNameToRun Then
       End If

  2. Refresh Compliance State:
    dim newCCMUpdatesStore
    set newCCMUpdatesStore = CreateObject (“Microsoft.CCM.UpdatesStore”)

    ‘Refresh the server compliance state by running the RefreshServerComplianceState method.

The first script Initiate Software Updates Scan is to let the client check if it needs new updates and the second script Refresh Compliance State is to let the client report back to the server that it needs updates.

Note: It can also happen when you are trying to avoid obsolete clients by starting the Task Sequence via Run Advertised Program.