Starting with ConfigMgr Current Branch 1806, you can now enable and deploy Third-party Software Updates from a partner catalog from within ConfigMgr using the existing software update management process. By enabling this feature, it reduces the infrastructure foot print for managing Third-party Software Updates by incorporating it directly into the product. This means that you don’t have to use for instance System Center Update Publisher (SCUP) to handle the publishing of meta data into ConfigMgr. In this blog post we’ll go through the requirements for configuring this new feature including all the required steps necessary to get you up and running. This feature was first released in the ConfigMgr Technical Preview version 1806, however this blog post covers the Current Branch release of ConfigMgr.

Why use ConfigMgr and third-party software updates catalogs

Today it’s more important than ever to stay current, meaning that you ensure that you’re running the latest versions of the applications you deploy in your organization. ConfigMgr provides various methods to accommodate this, however they can be time consuming and require a lot of management. Third-party vendors have for many years now provided their own catalogs with access to the latest version of applications, some containing more applications than others, but they all serve the same purpose, assisting the ConfigMgr administrator in staying current with their deployed applications. There are several vendors offering a catalog service, for example:

Some vendors even offer ConfigMgr console integrated extension, which you may or may not prefer, however ensure that the vendor you decide to go with offers a software update catalog for third-party patching before you go ahead an buy their product, if you want to use the built-in feature in ConfigMgr. As an MVP, I get a free license for Patch My PC and I’ll be using that catalog to show the functionality in this blog post, however this should not in any way be interpreted as me being bias for this vendor.

To summarize, the new Third-party Software Updates feature allows you to subscribe to third-party catalogs, publish their software updates to your Software Update point and then deploy them to your clients.

Infrastructure requirements before enabling third-party software updates

Without configuring anything, you’ll notice that from ConfigMgr Current Branch 1806 and onwards, under Software Library – Software Updates – Third-Party Software Update Catalogs node that it’s empty.

This is because we need to ensure the back-end of the environment is configured for this feature before we start using it. In order to enable this feature, we need to make sure our environment is configured properly which means:

  • The Software Update Point can run in either HTTP or HTTPS when located on the Primary Site server, but when running on a remote server it’s required to be setup in HTTPS mode.
    • Differently from when this new feature was in technical preview, it’s now supported to run this on a remote Site server if the Software Update Point role is not on the same top-level Site server
  • Internet access to download.microsoft.com over HTTPS and 443 for the partner list managed by Microsoft
  • Client Settings deployed that enables the new Third-party Software Updates feature
  • Access to a partner or third-party catalog to sync software updates

On the Site server, a new Third-party Software Updates synchronization server will be running being responsible for the following:

  • Updates the list of available catalogs added in the ConfigMgr console
  • Downloads the catalogs you’ve subscribed to
  • Downloads the software updates from the catalog when published

For more details and the documentation for this new feature, check out the documentation:

https://docs.microsoft.com/en-us/sccm/sum/deploy-use/third-party-software-updates

Enable Software Update point with HTTPS

As for enabling the Software Update point with HTTPS, I’ll not be cover that in this post since it’s already really well documented by my fellow MVP Peter van der Woude on the following URL:

How to configure a Software Update Point to use SSL for communicating with WSUS

After following the steps outlined by Peter, you should be able to run your Software Update point in HTTPS, as shown in the picture below.

Enable Third-party Software Updates feature

This new feature can be enabled on the Software Update Point component in the ConfigMgr console.

Third-party Software Updates are now being enabled and the configuration will take a couple of minutes. If you navigate to Software Library – Software Updates – Third-Party Software Update Catalogs you should now see the HP Client Updates Catalog automatically added. Microsoft is adding this simply by enabling the feature, and they’ll continue to expand the built-in list of catalogs in future releases.

As for the Configuration Manager manages the certificate option, once the next scheduled or manual sync of Software Updates will occur, you’ll notice the following in the wsyncmgr.log:

Enable Client Settings

Before we go ahead and add custom catalogs, we need to enable this feature in the Client Settings as well. Navigate to Administration – Client Settings and open the properties of the settings policy you want the feature to be added in. In the Software Updates section, select Yes in the Enable third party software updates drop down menu as shown below.

Add a custom catalog

Now with all of the configuration in place, it’s time to add a custom catalog to this new feature. The basic workflow for this is to simply add the URL in the ConfigMgr console and then subscribe to it.

  • Navigate to Software Library – Software Updates – Third-Party Software Update Catalogs.
  • Right-click on Third-Party Software Update Catalogs and select Add Custom Catalog.

  • This will launch the Third-Party Software Updates Custom Catalogs wizard. Enter the required details and click Next. I’ve redacted the URL as it’s unique in my case.

  • In the Summary page, click Next.
  • On the Completion page, click Close.
  • In the Third-Party Software Update Catalogs node, you should now the see the new custom catalog added.

You’ve now successfully added your custom catalog. Next up would be to subscribe to the catalog and select which software updates to download.

Subscribe to a custom catalog

Once the custom catalog has been added, it’s time to subscribe to it. This is mainly to download the catalog and review and approve the certificate for the catalog so that ConfigMgr trusts it.

  • Navigate to Software Library – Software Updates – Third-Party Software Update Catalogs.
  • Right-click on the catalog you wish to subscribe to and select Subscribe to Catalog.

  • The Third-Party Software Updates wizard appears. Verify the general information for this catalog subscription and click Next.
  • On the Download page, make sure that the wizard can successfully download the catalog and click Next.

  • Review and approve the certificate from the catalog by clicking the View Certificate button. Once reviewed and approved, select the I have read and understood this message check box and click Next.

  • On the Summary page, click Next.
  • On the Completion page, click Close.

Now that the custom catalog has been approved and downloaded, it’s time to sync and publish the software updates to the Software Update point.

Synchronize software updates from custom catalog

In this part of the post we configure the third-party software update catalog service to synchronize from the custom catalog added previously.

  • Navigate to Software Library – Software Updates – Third-Party Software Update Catalogs.
  • Right-click on the catalog you wish to sync and select Sync now.

  • In the popup window that appears, click Yes.

  • Synchronization has now been initialized.
  • We can now follow the synchronization process in the SMS_ISVUPDATES_SYNCAGENT.log log file located in <ConfigMgr installation path>\Microsoft Configuration Manager\Logs.

  • Navigate to Administration – Site Configuration – Sites and from the Configure Site Components ribbon menu select Software Update Point component.
  • Select the Products tab and ensure that you’ve enabled the products published from the custom catalog, in my case Patch My PC.

  • Click OK.
  • Navigate to Software Library – Software Updates and right-click on All Software Updates and select Synchronize Software Updates.

  • Follow the synchronization process in wsyncmgr.log log file located in <ConfigMgr installation path>\Microsoft Configuration Manager\Logs.

  • Once the synchronization has finished, the software updates from the custom catalog will then be available in the All Software Updates node.

Software updates from the custom catalog are now published to the Software Update point and synchronized into ConfigMgr. From this point on we can go ahead start manage these by deploying them to clients.

Deploy third-party software updates

At this point we’ve come to the last part of the blog post, where we go through the required steps to deploy a software update from a custom catalog. As an example, I’ll go through the manual steps of deploying a single software update item to patch Adobe Reader. The update will be deployed as available to give you an overview of the entire process from start to end. This however, would most likely not fit any enterprise like organization workflows where automation would be involved, but it gives a good overview of what’s required.

  • From the Software Library – Software Updates – All Software Updates node, search for a software update, in my case Adobe Reader.
  • Right-click on the software update and select Publish Third-Party Software Update Content.

  • Click OK in the window that appears.

  • Follow the content publishing process in the SMS_ISVUPDATES_SYNCAGENT.log log file located in <ConfigMgr installation path>\Microsoft Configuration Manager\Logs. Have patience, it takes some time.

  • When the content publishing process has completed, perform another synchronization of the Software Update Point from the All Software Updates node by selecting Synchronize Software Updates. If you do not complete this synchronization, the software update will only be available as meta data and you’ll not be able to either download or deploy it.
  • Once the synchronization has completed, refresh the All Software Updates nodes.
  • Search for the software update item again, in my example Adobe Reader and notice that the icon has now changed from blue to green.
  • Right-click again on the same software update item as before and select Deploy. You could also select to manually download the content and place it in a Deployment Package, however that part is covered from within the deployment wizard.

  • Complete the Deploy Software Update wizard and deploy the software update to a device collection. This blog does not cover the steps required to deploy a software update, as it should be common knowledge for any ConfigMgr administrator that manages software updates.

End user experience

With everything taken care of from the administrator perspective resulting in the Adobe Reader software update being deployed, it’s time to take a look at the end user perspective. For one of the systems that received the software update item to patch Adobe Reader, let’s first examine how it looks before we manually select to install the update. On the system, Adobe Reader is currently installed with version 18.011.20040 as can be seen in the picture below:

From Software Center in the Updates section, there’s a new software update available, the Adobe Reader DC Update 18.011.20055.

From here on out the end user would install the software update and Adobe Reader would be updated to the version deployed.

In the background on the system the ConfigMgr agent has automatically installed the self-signed certificate that was created by ConfigMgr when we selected it to manage the certificates. This can be found in the UpdateDeployments.log log file and should show the following entry that it successfully installed the certificate in the Machine\TrustedPublisher store.

The remaining piece that’s taken care of by the ConfigMgr agent is to ensure that the Allow signed updates from an intranet Microsoft update service location GPO policy setting is set. If this is not set already by a GPO, the ConfigMgr agent will automatically set it to Enabled. In the picture below it was already configured and managed through GPO, however my fellow MVP Nick Hogarth tested this new feature without a GPO just to ensure it works as designed.

Summary

For organizations that require a little more automated work flows rather than manually performing all the steps shown in this post, I’ll revisit this topic in the near future with more information and most likely a blog post regarding the subject.

(12174)

Nickolaj Andersen

Principal Consultant and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Currently working for TrueSec as a Principal Consultant. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences and user groups.

There are no comments.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.