Posts Tagged ‘Updates’

Third Party Software updates not installing during Task Sequence

January 14, 2019 Leave a comment

As of Configuration Manager Current Branch 1806 it is now possibly to natively subscribe to third party software catalogs and deploy third party updates. There is no longer a need for System Center Updates Publisher (SCUP).

Currently there is one shortcoming in the feature: regular deployments of third-party updates are working fine, but when using the Install Software Updates step in an OSD Task Sequence the third-party updates are not installing. This may go unnoticed as the Task Sequence does not error out.

Initial investigation shows this is most likely because of the WSUS signing certificate only being installed on the client when Software Updates client policy lands after the task sequence has completed.  This is logged in the UpdatesDeployment.log :


As a result the third-party updates cannot be installed during the task sequence.

From a security perspective most organizations will want their devices fully patched before they leave the deployment bench. Also from an end-user experience perspective the experience is suboptimal when booting your new device for the very first time … just to have it install new updates (and potentially reboot).

Hopefully we will see this fixed in an upcoming release of Configuration Manager – to help speed up the process and make sure this gets some attention, please make sure to vote up this entry on User Voice.

Thanks – and until next time.

Adding languages for Office 365 update downloads in Configuration Manager only adds the first language

October 13, 2017 Leave a comment

During a recent customer visit I was asked to troubleshoot an issue with Office 365 language specific updates. This blog post outlines my findings and the solution.

The customer is running a Current Branch 1706 environment and needs to support Dutch and French languages for Office 365, next to the default English language. As such he wants to ensure all updates for these three languages are properly downloaded. To achieve this the engineer is following the procedure as documented here.


Let’s first have a look at what is documented the TechNet Docs.

Beginning in Configuration Manager Current Branch 1610, you can add support for Configuration Manager to download updates for any languages that are supported by Office 365, regardless of whether they are supported in Configuration Manager.

The documentation contains a detailed procedure on how to add support to download updates for additional languages. This is done through WMI.

Configuring additional Office 365 update languages is a site-wide setting. After you add the languages using the procedure, all Office 365 updates are downloaded in those languages, as well as the languages that you select on the Language Selection page in the Download Software Updates or Deploy Software Updates wizards.



Initial findings

As the customer did not want to select the additional languages in the Software Updates wizard each month he opted for the site-wide setting and required modifications. As per the outlined procedure the required changes were made in WMI.

Notice in the screenshot below the values are specified exactly as per the screenshot in the TechNet Documentation.


Based on these settings the updates for Dutch and French should be downloaded. English does not have to be specified and is always downloaded. However, when checking the sources in the Software Update Deployment Package, only English and French updates have been provisioned. Dutch is missing.


During a second test the language tags in WMI were switched, so Dutch was first in the list.


After the download completed the Software Update Deployment Package source folder only contains English and Dutch updates. French is missing.


It appears as if only updates for the first language specified are being downloaded.

A few runs later (going through some variants with delimiters etc.) we tested with the following values in WMI


After the download completed we checked the Software Update Deployment Package source folder again – and finally updates for all three languages are properly provisioned.





The screenshot in the TechNet documentation is misleading as the language tags are separated with a comma and a space. Based on our above findings the language tags should be separated with a comma only, the space should be omitted for this to work when specifying multiple languages.

Side note: the TechNet documentation also mentions Use the following procedure on the software update point at the central administration site or stand-alone primary site. This is not correct as the procedure needs to be executed on the site server, not the SUP.

Hope it saves you some troubleshooting time!


Configuration Manager 1511 Updates and Servicing : a closer look at the updating experience

December 19, 2015 2 comments

Earlier this week Microsoft has released update 1512 for Configuration Manager. In this post we will focus on the implementation experience and walk through the steps required to implement this update in an existing TP4 1511 environment. We will look at how an existing site becomes aware of updates, how to validate the prerequisites and update the site. After that we will also see how to update the other components like the console and clients.


Through the service connection point the site becomes aware of new updates. If any updates are available they are listed in the Sites and Servicing node in the Configuration Manager Console.


Behind the scenes you would find more details about this in the dmpdownloader.log file.


In the EasySetupPayLoad folder you will find the actual content that was downloaded.


We will not go to much into detail on this specific topic. If you want to read more details about the updating process I recommend this post by Kent Agerlund.

Prereq Check

From the updates and servicing node you can first run a prerequisite check before installing the update.


As you trigger the check the state is changing


We noticed that CMUpdate.log is logging the prereq check process being triggered


Once all checks are finished the state in the console is again updated.


Details on failures and warnings are logged in the ConfigMgrPrereq.log, located at the root of the System Drive.



Site Update

Now we have verified the prerequisites are in place, the next step is to install the Update Pack. This is also done in the console through the Updates and Servicing node.


The installation experience is wizard based – and there are only a few steps to walk through. The first window gives some more details on what changes are included. Notice that here you can also opt to ignore any prereq check warnings and run the update anyway. For now we leave this option disabled.


Client Piloting is a new feature which allows testing of the new client version on a set of pre-production systems first. Here we opted to do the validation and we are targeting a pre-production client collection which we had already created during the initial implementation of this lab enviroment.


We need to accept the license terms.


Review the summary


… and we are ready to run the update.


As we chose not to ignore any prereq check warnings the installation did not kick off. If you are confident that the warning(s) can be ignored or they have been resolved you can retry the installation.


In our case we wanted to ignore the warnings so we can click OK on the next dialog box.



This is also reflected in the CMUpdate.log file.


The state is now updated to Installing.


And approximately 10 minutes later the update was successfully completed.



Console Update

As part of this update we also need to update the Configuration Manager console. As the update of the site was triggered in the console it has not been closed during the entire process. So how do we trigger the console update?  In our lab this was triggered by trying to open the site properties (one of the first places we wanted to visit in order to verify the build number). The following dialog box popped up:


Clicking OK automatically closes the console and launches the update.


Once completed the console is automatically started again and shows the What’s new workspace. This is also a new element in this build which we will discuss in detail in a later blog post.


Note:  At this point we have no remote console(s) to test but I would assume similar behavior there.

Client Update

Next we need to get our clients up to par. Remember that we already opted to update our pre-production clients during the setup wizard earlier.

As a result an advertisement is automatically created to update the clients in the pre-production collection. Details about this are logged in the hman.log.


Note though that no client will update before you have distributed the content of the client packages to your distribution points.


Details on the client upgrade are logged in the ccmsetup.log file (on the client itself)


Updated clients should show version 5.00.8336.1000 in the control panel


… or in the console




For sure there are a lot more details to check and elements to uncover but for now and based on this first experience we can conclude that the new updating process is really an improvement: straightforward, covering all infrastructure aspects, and pretty fast.

And one more thing: happy to see that the update has also reset the time bomb mechanism. This means we get more time to play in this lab!


Until next time!


Update for Windows Update Client addresses ConfigMgr 2012 Update Scan Issue – Windowsupdate.log Error 8007000E

June 3, 2015 1 comment

Exclamation-iconYesterday Microsoft has released an update for the Windows Update client. This relates to the issue with Windows 7 and Software Updates which I blogged about a few weeks ago.

This is the KB article: Windows Update Client for Windows 7 : June 2015

Interesting: the KB Article mentions this update does not only address the out-of-memory issue but also contains general improvements made to support upgrades to a later version of windows.

If you have Windows 7 x86 clients in your environment the best approach would be to release this update in your environment as soon as possible. Important : you need to install the hardening update KB2938066 on your WSUS servers prior to releasing this update!

Hope it helps!


Update on the ConfigMgr 2012 Update Scan Issue – Windowsupdate.log Error 8007000E

April 16, 2015 1 comment

Last week Kim blogged about an issue with Windows 7 and Software Updates that some of his customers had been reporting.

Kim had already outlined the issue and the symptoms, plus also provided a few workarounds which may help in resolving it. Through this post I wanted to inform you that now Microsoft has published a blog post that:

a) gives some more details on the root cause of the problem

b) outlines some possible workarounds and

c) most importantly : states a hotfix is in the pipeline which will be available in (late) Q2

You can find the full details here.

I ran into the same issue at one of my customers last week and have been working with Microsoft support to get this resolved. Below you can read some findings and experiences from the past days.

The workaround to Move wuauserv (Windows Update Agent) to its own SVCHost.exe instance did not prove to be very successful. Although we saw the scan job succeeding on a few clients at first, after a few additional scans the issue returned.

Next step was cleaning up WSUS. First we needed to verify what we could potentially clean up using the script provided by Microsoft:


To get things back on the rails in the end the only successful method was to run WSUS cleanup script to decline all superseded updates. Running the script with the –DeclineLastLevelOnly switch was not sufficient.

Important: Before running this cleanup script make sure to identify if any of the updates are still needed! It could be a superseding update has not yet been released due to your internal approval and/or release processes!

And while you are checking that also note that the script output may be misleading. Set the LastLevel column filter to False if you are actually looking for the Last Level Superseded Updates.


Running the script itself took around 15 minutes.

Note: if you are running multiple SUPS in your environment you should only run this on one SUP – the one with Windows Update set as synchronization source.

Hope it helps!