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:

How to use Task Sequence Variables in a running Task Sequence by script in ConfigMgr 2007

Using Task Sequence variables in a running Task Sequence by script is actually really straight forward. Also for most of you this might be common knowledge, but I noticed this week that it doesn’t count for everyone, yet. So in this post I will show the two (only two!) steps it takes to get or set variables with your script.

The first step is to create an instance of Microsoft.SMS.TSEnvironment. As this is a COM automation object, you could use every language that can use those. I will use VBScript in this example. Creating the object can be done by the following line of code:

set env = CreateObject(“Microsoft.SMS.TSEnvironment”)

Now that we’ve got our object the second step is to get, or set Task Sequence variables. This can be done by either one of the following lines of code:

GET: machineName = env(“_SMSTSMachineName”)

SET: env(“YourCustomVariable”) = “Your Custom Value”

By setting the new variable you can use any variable(name) that you want. If the variable does not exist, it will be created. If the variable does exist, its value will be updated.

For more information:

Remember this?: Software Distribution is currently paused on this computer with ConfigMgr 2007

This is more of a remember this for my self then probably in general, as this is a problem that we don’t run into that much. Only for me it was the second time already, but I couldn’t directly remember anymore what the problem was. So this post will be more of a reminder for the eventually next time…

RegLocStateX64Also this will be a short post as it will just describe the problem we ran into with my current customer and what the solution was. The problem we ran into was that after we deployed a new machine we could advertise software to it, but the installation would never start. Looking into the execmgr.log we could see the following message: “This program cannot run because a reboot is in progress or software distribution is paused.”.

Well, the solution for this was actually quit simple, just the searching for it took a while… Looking into the registry we could see that the Software Distribution-State-Paused-key was set to 1 and changing this back to 0 resolved the problem. This key can be found in the following location:

  • x86 – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\State\
  • x64 – HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Software Distribution\State\ (see picture)

We’re still not quite sure what caused this problem, but it seems to be something with ending a Task Sequence with a restart. After resolving the issue we found some other people with the same issue here and they are also guessing and linking it to the last step of the Task Sequence.

Remember this?: Re-run Advertisement for one (or more) specific client(s) with ConfigMgr 2007

I’m not sure if this is going to be a ‘remember this’ –series, but at least in this case it fits really good. We all know it, but sometimes we need a refreshment.

RegLocX64We all know those scenario’s where we send an Advertisement to a Collection of clients and for some reason we may want to rerun the Advertisement for only one (or more) specific client(s). In this case we can use the general rerun options of an Advertisement (like always rerun), but they will affect all clients in the collection and won’t work for user-targeted Advertisements. So what’s left in this case? Well the option I like the most is that there is a registry change that we can make to trick the Advertisement to run again. When we look at a client’s registry, we will see the following the following registry key (depending on the architecture). 

  • x86 – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System\
  • x64 – HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System\ (see picture)

As this key is located in the HKEY_LOCAL_MACHINE, it can also be found by opening regedit and then make a connection with a remote client. Under System we will find the PackageID of each Package that has previously run. When we now delete the PackageID, for the Program that we want to rerun, it will trigger the Program to run again (during the next evaluation) even though it already completed successfully.

To find the PackageID that we need we can open the Configuration Manager Console and select the Packages –node (under Site Database > Computer Management > Software Distribution). In the overview there will be a list of all the packages with the corresponding PackageID.

ConfigMgr 2007 and creating a non-recurring Maintenance Window by script

At my current customer they’re not using the Software Updates of ConfigMgr 2007 (yet), but there was a wish for a more controlled company-wide deployment without having to change all the current advertisements (and the whole deployment system). So the idea came to create (and delete) maintenance windows by script (when needed).

Luckily the ConfigMgr 2007 SDK has some pretty straight forward examples of creating and deleting maintenance windows (see also the links at the end of this post). Deleting a maintenance window was almost just copy-paste from the SDK, the tricky part was creating a maintenance window and then especially the non-recurring schedule. At the end, this is (the short version of) what we ended up with:

‘ MAIN – Set connection, schedule and call
Set Connection = ConnectToSMSProvider("SiteServerName")
Schedule = NonRecurringScheduleString(connection, 3, “StartTimeInWMIFormat”, FALSE)
CreateMaintenanceWindow(connection, "CollectionID", "Name of Maintenance Window", "", Schedule, TRUE, 1)

‘ Sub to add a Maintenance Window to a Collection
Sub CreateMaintenanceWindow(connection, targetCollectionID, newMaintenanceWindowName, newMaintenanceWindowDescription, newMaintenanceWindowServiceWindowSchedules, _
                            newMaintenanceWindowIsEnabled, newMaintenanceWindowServiceWindowType)
    Set allCollectionSettings = connection.ExecQuery("Select * From SMS_CollectionSettings Where CollectionID = ‘" & targetCollectionID & "’")
    If allCollectionSettings.Count = 0 Then
        Set collectionSettingsInstance = connection.Get("SMS_CollectionSettings").SpawnInstance_
        collectionSettingsInstance.CollectionID = targetCollectionID
    End If 
    Set collectionSettingsInstance = connection.Get("SMS_CollectionSettings.CollectionID=’" & targetCollectionID &"’" )
    Set tempServiceWindowObject = connection.Get("SMS_ServiceWindow").SpawnInstance_
    tempServiceWindowObject.Name = newMaintenanceWindowName
    tempServiceWindowObject.Description = newMaintenanceWindowDescription
    tempServiceWindowObject.ServiceWindowSchedules = newMaintenanceWindowServiceWindowSchedules
    tempServiceWindowObject.IsEnabled = newMaintenanceWindowIsEnabled
    tempServiceWindowObject.ServiceWindowType = newMaintenanceWindowServiceWindowType
    tempServiceWindowArray = collectionSettingsInstance.ServiceWindows
    ReDim Preserve tempServiceWindowArray (Ubound(tempServiceWindowArray) + 1)
    Set tempServiceWindowArray(Ubound(tempServiceWindowArray)) = tempServiceWindowObject
    collectionSettingsInstance.ServiceWindows = tempServiceWindowArray
End Sub

‘ Function to RETURN a Non Recurring Schedule
Function NonRecurringScheduleString(connection, hourDuration, startTime, isGmt)
    Set recurInterval = connection.Get("SMS_ST_NonRecurring").SpawnInstance_()
    recurInterval.StartTime = startTime
    recurInterval.DayDuration = 0
    recurInterval.HourDuration = hourDuration
    recurInterval.MinuteDuration = 0
    recurInterval.IsGMT = isGmt
    Set clsScheduleMethod = connection.Get("SMS_ScheduleMethods")
    clsScheduleMethod.WriteToString Array(recurInterval), scheduleString
    NonRecurringScheduleString = scheduleString
End Function

‘ Function to RETURN a Date/Time in WMI Format
Function ConvertToWMIDate(strDate)
    strYear = year(strDate):strMonth = month(strDate)
    strDay = day(strDate):strHour = hour(strDate)
    strMinute = minute(strDate)
    If len(strmonth) = 1 Then strMonth = "0" & strMonth
    If len(strDay) = 1 Then strDay = "0" & strDay
    If len(strHour) = 1 Then strHour = "0" & strHour
    If len(strMinute) = 1 Then strMinute = "0" & strMinute
    ConvertToWMIDate = strYear & strMonth & strDay & strHour & strMinute & "00.000000+***"
End Function

‘ Function to RETURN a Connection to the SMS Provider
Function ConnectToSMSProvider(ServerName)
   Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
   Set objSWbemServices = objSWbemLocator.ConnectServer(ServerName, "root\sms")
   Set ProviderLocation = objSWbemServices.InstancesOf("SMS_ProviderLocation")
   For Each Location In ProviderLocation
      If Location.ProviderForLocalSite = True Then
         Set objSWbemServices = objSWbemLocator.ConnectServer(Location.Machine, "root\sms\site_" + Location.SiteCode)
         Set ConnectToSMSProvider = objSWbemServices
      End If
End Function

More information about creating a maintenance window:
More information about deleting a maintenance window:

Using USMT 4.0 and ConfigMgr 2007 while migrating from local profiles to partially redirected profiles

This time I want to devote a post to a situation I haven’t been in that often. The customer was migrating from Windows XP to Windows 7, well.. nothing special here, but also migrating from local profiles to (partially) redirected profiles, well.. that’s a challenge. So to capture the userdata AND -settings we had to come up with something special. Of course we could do some things with scripting, but the biggest challenge was the fact that the new (partially redirected) profile location was only available after the first logon to Windows 7.

With this information I started thinking about USMT 4.0 again. Most often you use this to migrate on a computer basis, but we made an exception on this. We came up with the following five steps that should do the trick:

  1. (On Windows XP) A batch file that kicks of Scanstate. Nothing special here, just used /uel:1 or /uel:0 to get the user profile we need (0=Logged on user, 1=Modified accounts last 24 hours).
  2. (On Windows XP) A batch file that copies the captured data and settings to the users share on the network.
  3. (On Windows 7) A batch file that copies the captured data and settings back to a local drive.
  4. (On Windows 7) A batch file that kicks of Loadstate. Nothing special here, just used /ue to exclude some possible captured local/ admin account.
  5. (On Windows 7) A batch file that copies the last bits of data straight in to the redirected profile.

The important part is something a didn’t mention yet. In the migration XML files there is the possibility to copy data to an alternative location and that’s what we used for the parts of the profile that would get redirected. The reason for that is simple, because the SYSTEM account has no security rights to write something to there, as it is a network location. Here is a sample of the part we added to the migration XML files:

<locationModify script="MigXmlHelper.RelativeMove(‘%CSIDL_DESKTOP%\’, ‘C:\Temp\Desktop’)">
      <pattern type="File">%CSIDL_DESKTOP%\* [*]</pattern>

This specific part would copy the desktop items to C:\Temp\Desktop instead of the desktop location in the (redirected) profile. Also important to note is that, in this case, all the copy actions have to run with user rights, as it’s all copied to the users directory.

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):

The best informational links about FEP 2010 (and its integration with ConfigMgr 2007)

FEP_Logo This time I want to devote a post to some of the best informational links about Forefront Endpoint Protection (FEP) 2010 (and its integration with ConfigMgr 2007). These links can make it a lot easier to plan, scale, install, manage and troubleshoot your ConfigMgr 2007 with FEP 2010 integrated -environment.

Microsoft Deployment Toolkit 2012 Beta is available!

For those who didn’t read it on Twitter, Facebook or mail yet, MDT 2012 B1 is available for download! Some of the best things that are mentioned in the release notes, are that it supports ConfigMgr 2012 B2 and also still supports ConfigMgr 2007 SP2! Besides that it also supports the deployment of ALL operating systems from Windows XP and Windows Server 2003 until now. So it only delivers extra’s! For more information, read here the mail of Microsoft Connect:

Thanks for your ongoing interest and participation in the MDT beta review program. We hope you’ll take the time to preview and provide feedback on MDT 2012 Beta 1.

Download the beta materials on Connect:

Microsoft Deployment Toolkit (MDT) 2012 Beta 1 rides the next wave of System Center releases with support for System Center Configuration Manager 2012. For Lite Touch installations, MDT 2012 improves the overall client-side user experience, while also providing behind-the-scenes enhancements for partitioning, UEFI, and user state migration. These features, combined with many small enhancements, bug fixes, and a smooth and simple upgrade process, make MDT 2012 Beta 1 more reliable and flexible than ever.

Key Benefits:

  • Fully leverages the capabilities provided by System Center Configuration Manager 2012 for OS deployment.
  • Improved Lite Touch user experience and functionality.
  • A smooth and simple upgrade process for all existing MDT users.

Tell us what you think!
We value your input. Download the beta on Connect and tell us what you think!Please submit your feedback through Connect and direct any support questions you may have to

This program is now open. The beta review period will run through August 2011.

Tell your friends
To join the beta review program for Microsoft Deployment Toolkit (MDT) 2012, visit Microsoft Connect:

Learn more
Visit the MDT home page:

Get the latest news straight from the MDT team:

MDT works with the Microsoft Assessment and Planning Toolkit and Security Compliance Manager to help you plan, securely deploy, and manage new Microsoft technologies—easier, faster, and at less cost. Learn more at

Thank you for your interest in the development of MDT. We look forward to receiving your feedback!

Solution Accelerators MDT Team
Microsoft Corporation

Asset Intelligence Reports are not showing correct data since the upgrade to ConfigMgr 2007 SP2

AIReportClassSettThis blog post is going to be a short explanation about why the Asset Intelligence (AI) Reports are not showing the correct data after an upgrade to ConfigMgr 2007 SP2. The cause of not showing data was actually more logic then I first thought. One of the items on the checklist for an upgrade ( is the following:

If you have customized the default SMS_def.mof hardware inventory reporting file, you must create a backup of this file before upgrading the site. When upgrading a site, customizations made to the existing SMS_def.mof file will be overwritten.

Maybe this still doesn’t make sense, but it will after the following piece of history about enabling AI in ConfigMgr 2007. In the ConfigMgr 2007 RTM version AI had to be enabled by manually editting the SMS_def.mof. This got renewed in ConfigMgr 2007 SP1 by adding the Asset Intelligence Reporting Class Settings dialog box, BUT these settings are still written in the SMS_def.mof.

So the combination of these two point mean that after the upgrade to ConfigMgr 2007 SP2, the AI settings have to be re-enabled. This can be done through the Asset Intelligence Reporting Class Settings dialog box by reselecting the needed items, or by manually editing the SMS_def.mof.