Software Updates

This 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.

Prerequisites

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]

Branch=”Current”

Update Deadline

Not Configured | Enabled | Disabled

Deadline: [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]

UpdatePath=”\\server\share”

Target Version

Not Configured | Enabled | Disabled

Update version:[Specify version number]

TargetVersion=”16.1.2.3”

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

This blog post will describe a scenario that I ran into this week. Also, to be honest, I wasn’t aware of this exact behavior and, until this moment, I haven’t been able to find any documentation that describes this behavior.

Scenario

The scenario is that the customer wants to have the ConfigMgr client deployed on their server environment. This server environment is currently patched by using different methods and one of them is WSUS. So far, nothing weird, but the servers patched by WSUS are configured via local group policies.

Behavior

I think that by now everybody knows that the ConfigMgr client uses the local group policy Specify intranet Microsoft update service location to point to the WSUS server of the ConfigMgr environment, if, of course, Enable software updates on clients is set to Yes in the client settings. What I didn’t know is the behavior of the ConfigMgr client when Enable software updates on clients is set to No in the client settings. My understanding was that it would simply disable the Software Updates Agent and, if previously configured by the ConfigMgr client, it would remove the local group policy of Specify intranet Microsoft update service location. Sadly, I was wrong, big time! What actually happens is that the ConfigMgr client will always remove all WSUS related local group policies with the first policy that has Enable software updates on clients set to No in the client settings. This is even the case when Enable software updates on clients is set to No in the default client settings.

At the moment that the first policy arrives at the client with Enable software updates on clients set to No in the client settings the following information will show in the ScanAgent.log.

Basically it’s stating that it’s disabling the Software Updates Agent and deleting a Windows Update policy. At this point I would still assume that the log file is referring to the local group policy Specify intranet Microsoft update service location, but, even if nothing is configured by the ConfigMgr client, it will delete all all WSUS related local group policies. Everything that’s configured in a local group policy located under Computer Configuration\Administrative Templates\Windows Components\Windows Update will be removed. This relates to the registry key’s located under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Once a policy is applied with Enable software updates on clients set to No in the client settings the ConfigMgr client won’t touch these local group policies (and registry keys) again.

This behavior doesn’t cause any problems when domain group policies are used, because directly after deleting the WSUS related policies it triggers a domain group policy update to restore those settings (see event viewer message).

Funny note: When uninstalling the ConfigMgr client it only removes the Specify intranet Microsoft update service location local group policy. In that case it leaves every other WSUS related local group policy untouched.

Solution

Sadly, there is no real solution, as there is no way to prevent the ConfigMgr client from initially removing all WSUS related local group policies. In most situations this won’t be a huge problem. It will only be a problem when there are no domain group policies available, or when domain group policies are not used. The only solutions are actually workarounds. Simply accept this behavior and make sure there is something in place to cover this little gap. Three possible workarounds are:

Use compliance settings to set the correct registry keys;

Export the registry keys and deploy them via an old-school package (use regedit);

Export the local group policy and deploy it via an old-school package (use secedit).

There are a multiple methods to deploy the Cumulative Updates (CU) of ConfigMgr, to all the different components (console, client and server). The most common used method is the old-school packages that are created during the upgrade of a site server. This blog post will be about another less often, but definitely not less effective, method of deploying a CU is via System Center Updates Publisher (SCUP). In this post I will go through the steps required to deliver a CU, via SCUP, to ConfigMgr as a software update.

Prerequisites

Before I will go through the steps, it’s important to know that this post does not describe the installation of SCUP itself. In case SCUP is not yet installed, the following posts provide some good guidelines to set it up:

Step 1: Import the updates in SCUP

The first step is to import the (metadata of the) updates in SCUP. In case your not familiar with this, one of the things delivered during the installation of a CU, on the site server, is also a CAB file. This CAB file is located in the SCUP folder of the specific CU and contains the updates and their information in a form that SCUP can read. To import the CAB file in SCUP follow the next steps:

Step

Action

1

Open the System Center Updates Publisher 2011 Console, navigate to the Updates workspace and select Import in the Home tab.

2

On the Import Type page, select Specify the path to the catalog to import, Browse to the CAB file and click Next.

3

On the Summary page. click Next.

4

On the Security Warning popup, click Accept.

5

On the Confirmation page, click Close.

6

To verify a successful import, either check the SCUP.log (located in the AppData of the user performing the action), or check the Updates node in the SCUP console that should now show the following updates.

Step 2: Publish the updates to WSUS

The second step is to publish the (metadata of the) new updates to WSUS. To publish the (metadata of the) new updates to WSUS follow the next steps:

Step

Action

1

Open the System Center Updates Publisher 2011 Console, navigate to the Updates workspace, select the new updates and select Publish in the Home tab.

2

On the Publish Options page, select Full Content, select Sign all software updates with a new publishing certificate when published software updates have not changed but their certificate has changed and click Next.

To verify a successful publish, either check the SCUP.log (located in the AppData of the user performing the action), or check the Updates node in the SCUP console that should now show a Date Published.

Step 3: Synchronize software updates

The third, and last, step is to synchronize (the metadata of) these updates now to ConfigMgr. To do this it is necessary to perform two synchronization actions. The first time is to synchronize the new product in to ConfigMgr and the second time is to synchronize (the metadata of) the updates to ConfigMgr. Simply do this all by performing the following steps:

Step

Action

1

Open the System Center 2012 R2 Configuration Manager Console, navigate to Software Updates > All Software Updates in the Software Library workspace and select Synchronize Software Updates in the Home tab.

2

After the synchronization is done, navigate to Site Configuration > Sites in the Administration workspace and select Configure Site Components > Software Update Point.

In the Software Update Point Component Properties, in the Products tab select System Center 2012 R2 Configuration Manager (located under All Products > Microsoft – Local Publish) and click Ok.

3

Navigate back to Software Updates > All Software Updates in the Software Library workspace and select Synchronize Software Updates in the Home tab.

4

To verify a successful synchronization check the wsyncmgr.log.

Result

At the end it’s always nice to look at the results. Navigate to Software Updates > All Software Updates in the Software Library workspace and in the product filter it’s now possible to select the product System Center 2012 R2 Configuration Manager. By doing this the console will show the newly synchronized updates. After this the CU can be deployed as any other normal (security) update.

Actually since the first release of ConfigMgr 2012, I’ve seen and got question about software updates. Besides, of course, questions about setting it up, these questions are mainly focused about the memberships of software updates. Simple questions like “In which software update group is this software update?” or “In which deployment packages are the updates of this software update group?” are not that simple to answer. This is all going to change, starting today!

I created this simple tool that can perform searches based on a specific software update, a software update group, or a deployment package. Simply specify the Name (in case the of a software update the article id), select the Type (software update, software update group, or deployment package) and click Execute.

Search on Software Update: Show the software update groups and deployment packages of which this update is a member;

Search on Deployment Package: Show the software update groups of which the updates in the deployment package are a member;

Search on Software Update Group: Show the deployment packages of which the updates in the software update group are a members.

Overview

The following table will provides an overview of what this tool exactly does and the information that it will show in every situation.

To prevent weird errors from happening this script/ form does some basic error catching. The following errors can appear:

Please select a valid type;

Please provide a valid name;

Please provide a valid article id of a software update;

Please provide a valid name of a software update group;

Please provide a valid name of a deployment package

To show that the form/ script is still busy, the name and type field will be disabled. This can be very useful with overactive admins in combination with many updates in a deployment package or software update group. This will prevent them from trying a new query while the old one is still running, because it might take a while before all results are shown.

In case the Deployment Package type is used in combination with a valid name, the result will look like this. To indicate that the Deployment Package type is used the name of the corresponding group box will change. The Software Update Group information will show per update in which Software Update Group it exists. For updates that are not within a Software Update Group it displays <NoSoftwareUpdateGroup>.

In case the Software Update Group type is used in combination with a valid name, the result will look like this. To indicate that the Software Update Group type is used the name of the corresponding group box will change. The Deployment Package information will show per update in which Deployment Package it exists. For updates that are not within a Deployment Package it displays <NoDeploymentPackage>.

In case the Software Update type is used in combination with a valid article id, the result will look like this. The Software Update Group information will show in which Software Update Group it exists and the Deployment Package information will show in which Deployment Package it exists. When it’s not within a Software Update Group it displays <NoSoftwareUpdateGroup> and when it’s not within a Deployment Package it displays <NoDeploymentPackage>.

Last week I read a forum question about downloading updates in a software update group. I thought that I could create an easy example, but it wasn’t all as easy as I thought it would. As there is no cmdlet available that performs this specific action, I went back to WMI. In WMI there is a method AddUpdateContent in the SMS_SoftwareUpdatesPackage that should do the trick. After playing around with it for a while I noticed that this method is not as straight-forward as it looks.

The method

The main problem I had with this method, was the documentation, or better, the lack of documentation. The SDK only contains a very old example that also doesn’t seem to use the right order for the parameters. Let’s start with what the parameters should be and walkthrough them in the order that they should be used:

A boolean to indicate whether or not the content has to be replicated to the distribution points.

An array that contains the IDs of the content that has to be added to the deployment package.

An array that contains the source path where the content files are located.

Note: The content of the updates have to be downloaded to a local, or network path already.

With these three parameters, it is possible to invoke the AddUpdateContent method, of the SMS_SoftwareUpdatesPackage class on a specific PackageID. An easy way to do that would be invoking the method on the WMI object path to the specific deployment package. This makes the following example:

The usage

To use this method it’s necessary to fill those parameters and to do that it’s necessary to collect some information. As I don’t think it’s very user-friendly to supply a CI ID as a function parameter, I will first search the CI ID of the software update group based on its display name in the SMS_AuthorizationList class.

With that CI ID I can find the software updates that are a member of the software update group. The easiest way to do that is to “join” the SMS_CIRelation class with the SMS_SoftwareUpdate class. This will provide a list with all the software updates that are a member of the specific software update group (a big thanks here to the SMSProv.log for providing me with the main part of the query).

After finding the updates we can use the CI ID of the updates to find the associated content information. To get this information the easiest and quickest way is to use a “join” again, but this time between the SMS_CIToContent class and the SMS_CIContentFiles class. This will provide a list with the source locations of the software updates.

The content IDs can now be used to fill the first array of the AddUpdateContent method. The second array has to be filled with the location to were the content IDs are downloaded. The complete script including the missing, and not explained, little bits-and-pieces and including a download function is available via the TechNet Galleries.

The result

Download the complete script and run it with a command line like .\Add-UpdateToPackage.ps1 <DeploymentPackage> <SoftwareUpdateGroup> <SiteCode> <SiteServer>. After the script starts the AddUpdateContent method theresult can be followed in the SMSProv.log.

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.

Open the fepsuasetup.cab 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 SourceConfigMgrServer, select as ComponentSMS_WSUS_SYNC_MANAGER, fill in as Message ID6702 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.

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.

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:

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.

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!

Batch-file

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.

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 – Presents the volume that can be used to store the temporary folders.

%2 – Presents the full location of the Software Updates Package source.

%3 – Presents the architecture of the Operating System.

%4 – Presents the full location of the Operating System Image, including the name of it.

%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]

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!