Deploy third-party app patches to the vulnerable systems automatically using SCCM patch management infrastructure. Native plug-in for SCCM Patch the applications you want, with out filtering through the complete list of third-party applications in the SCCM Console.
- Wsus Management
- Third Party Patch Management Software
- 3rd Party Patch Management Wsus
- Party Patch Independence Mo
-->Applies to: System Center Configuration Manager version 1806
Beginning with version 1806, the Third-Party Software Update Catalogs node in the Configuration Manager console allows you to subscribe to third-party catalogs, publish their updates to your software update point (SUP), and then deploy them to clients.
Prerequisites
- Sufficient disk space on the top-level software update point's WSUSContent folder to store the source binary content for third-party software updates.
- The amount of required storage varies based on the vendor, types of updates, and specific updates that you publish for deployment.
- If you need to move the WSUSContent folder to another drive with more free space, see the How to change the location where WSUS stores updates locally blog post.
- The third-party software update synchronization service requires internet access.
- For the partner catalogs list, download.microsoft.com over HTTPS port 443 is needed.
- Internet access to any third-party catalogs and update content files. Additional ports other than 443 may be needed.
- Third-party updates use the same proxy settings as the SUP.
Additional requirements when the SUP is remote from the top-level site server
SSL must be enabled on the SUP when it's remote. This requires a server authentication certificate generated from an internal certificate authority or via a public provider.
- Configure SSL on WSUS
- When you configure SSL on WSUS, note some of the web services and the virtual directories are always HTTP and not HTTPS.
- Configuration Manager downloads third-party content for software update packages from your WSUS content directory over HTTP.
- Configure SSL on WSUS
When setting the third-party updates WSUS signing certificate configuration to Configuration Manager manages the updates in the Software Update Point Component Properties, the following configurations are required to allow the creation of the self-signed WSUS signing certificate:
- Remote registry should be enabled on the SUP server.
- The WSUS server connection account should have remote registry permissions on the SUP/WSUS server.
Create the following registry key on the Configuration Manager site server:
HKLMSoftwareMicrosoftUpdate ServicesServerSetup, create a new DWORD named EnableSelfSignedCertificates with a value of1.
To enable installing the self-signed WSUS signing certificate to the Trusted Publishers and Trusted Root stores on the remote SUP server:
The WSUS server connection account should have remote administration permissions on the SUP server.
If this item isn't possible, export the certificate from the local computer's WSUS store into the Trusted Publisher and Trusted Root stores.
Note
The WSUS server connection account can be identified by viewing the Proxy and Account Settings tab on the Site System role properties of the SUP. If an account is not specified, the site server's computer account is used.
Enable third-party updates on the SUP
If you enable this option, you can subscribe to third-party update catalogs in the Configuration Manager console. You can then publish those updates to WSUS and deploy them to clients. The following steps should be run once per hierarchy to enable and set up the feature for use. The steps may need to be rerun if you ever replace the top-level SUP's WSUS server.
In the Configuration Manager console, go to the Administration workspace. Expand Site Configuration, and select the Sites node.
Select the top-level site in the hierarchy. In the ribbon, click Configure Site Components, and select Software Update Point.
Switch to the Third-Party Updates tab. Select the option Enable third-party software updates.
Configure the WSUS signing certificate
You'll need to decide if you want Configuration Manager to automatically manage the third-party WSUS signing certificate using a self-signed certificate, or if you need to manually configure the certificate.
Automatically manage the WSUS signing certificate
If you don't have a requirement to use PKI certificates, you can choose to automatically manage the signing certificates for third-party updates. The WSUS certificate management is done as part of the sync cycle and gets logged in the wsyncmgr.log.
- In the Configuration Manager console, go to the Administration workspace. Expand Site Configuration, and select the Sites node.
- Select the top-level site in the hierarchy. In the ribbon, click Configure Site Components, and select Software Update Point.
- Switch to the Third-Party Updates tab. Select the option Configuration Manager manages the certificate.
- A new certificate of type Third-party WSUS Signing is created in the Certificates node under Security in the Administration workspace.
Manually manage the WSUS signing certificate
If you need to manually configure the certificate, such as needing to use a PKI certificate, you'll need to use either System Center Updates Publisher or another tool to do so.
- Configure the signing certificate using System Center Updates Publisher.
- In the Configuration Manager console, go to the Administration workspace. Expand Site Configuration, and select the Sites node.
- Select the top-level site in the hierarchy. In the ribbon, click Configure Site Components, and select Software Update Point.
- Switch to the Third-Party Updates tab. Select the option for Manually manage the certificate.
Enable third-party updates on the clients
Enable third-party updates on the clients in the client settings. The setting sets the Windows Update agent policy for Allow signed updates for an intranet Microsoft update service location. This client setting also installs the WSUS signing certificate to the Trusted Publisher store on the client. The certificate management logging is seen in updatesdeployment.log on the clients. Run these steps for each custom client setting you want to use for third-party updates. For more information, see the About client settings article.
- In the Configuration Manager console, go to the Administration workspace and select the Client Settings node.
- Select an existing custom client setting or create a new one.
- Select the Software Updates tab on the left-hand side. If you don't have this tab, make sure that the Software Updates box is enabled.
- Set Enable third-party software updates to Yes.
Add a custom catalog
Partner catalogs are software vendor catalogs that have their information already registered with Microsoft. With partner catalogs, you can subscribe to them without having to specify any additional information. Catalogs that you add are called custom catalogs. You can add a custom catalog from a third-party update vendor to Configuration Manager. Custom catalogs must use https and the updates must be digitally signed.
Go to the Software Updates Library workspace, expand Software updates, and select the Third-Party Software Update Catalogs node.
Click Add Custom Catalog in the ribbon.
On the General page, specify the following items:
- Download URL: A valid HTTPS address of the custom catalog.
- Publisher: The name of the organization that publishes the catalog.
- Name: The name of the catalog to display in the Configuration Manager Console.
- Description: A description of the catalog.
- Support URL (optional): A valid HTTPS address of a website to get help with the catalog.
- Support Contact (optional): Contact information to get help with the catalog.
Click Next to review the catalog summary and to continue with completing the Third-party Software Updates Custom Catalog Wizard.
Subscribe to a third-party catalog and sync updates
When you subscribe to a third-party catalog in the Configuration Manager console, the metadata for every update in the catalog are synced into the WSUS servers for your SUPs. The sync of the metadata allows the clients to determine if any of the updates are applicable. Perform the following steps for each third-party catalog to which you want to subscribe:
- In the Configuration Manager console, go to the Software Library workspace. Expand Software Updates and select the Third-Party Software Update Catalogs node.
- Select the catalog to subscribe and click Subscribe to Catalog in the ribbon.
- Review and approve the catalog certificate.
Note
When you subscribe to a third-party software update catalog, the certificate that you review and approve in the wizard is added to the site. This certificate is of type Third-party Software Updates Catalog. You can manage it from the Certificates node under Security in the Administration workspace.
- Complete the wizard. After initial subscription, the catalog should start to download in a few minutes.
- The catalog synchronizes automatically every 7 days.
- Click Sync now in the ribbon to force a sync.
- After the catalog is downloaded, the product metadata needs to be synchronized from the WSUS database into the Configuration Manager database. Manually start the software updates synchronization to synchronize the product information.
- Once the product information is synchronized, Configure the SUP to synchronize the desired product into Configuration Manager.
- Manually start the software updates synchronization to synchronize the new product's updates into Configuration Manager.
- When the synchronization completes, you can see the third-party updates in the All Updates node. These updates are published as metadata-only updates until you choose to publish them.
- The icon with the blue arrow represents a metadata-only software update.
Publish and deploy third-party software updates
Wsus Management
Once the third-party updates are in the All Updates node, you can choose which updates should be published for deployment. When you publish an update, the binary files are downloaded from the vendor and placed into the WSUSContent directory on the top-level SUP.
In the Configuration Manager console, go to the Software Library workspace. Expand Software Updates and select the All Software Updates node.
Click Add Criteria to filter the list of updates. For example, add Vendor for HP. to view all updates from HP.
Select the updates that are required by your organization. Click Publish Third-Party Software Update Content.
- This action downloads the update binaries from the vendor then stores them in the WSUSContent folder on the top-level software update point.
Manually start the software updates synchronization to change the state of the published updates from metadata-only to deployable updates with content.
Note
When you publish third-party software update content, any certificates used to sign the content are added to the site. These certificates are of type Third-party Software Updates Content. You can manage them from the Certificates node under Security in the Administration workspace.
Review the progress in the SMS_ISVUPDATES_SYNCAGENT.log. The log is located on the top-level software update point in the site system Logs folder.
Deploy the updates using the Deploy software updates process.
On the Download Locations page of the Deploy Software Updates Wizard, select the default option to Download software updates from the internet. In this scenario, the content is already published to the software update point, which is used to download the content for the deployment package.
Clients will need to run a scan and evaluate updates before you can see compliance results. You can manually trigger this cycle from the Configuration Manager control panel on a client by running the Software Updates Scan Cycle action.
Monitoring progress of third-party software updates
Synchronization of third-party software updates is handled by the SMS_ISVUPDATES_SYNCAGENT component on the top-level default software update point. You can view status messages from this component, or see more detailed status in the SMS_ISVUPDATES_SYNCAGENT.log. This log is on the top-level software update point in the site system Logs folder. By default this path is C:Program FilesMicrosoft Configuration ManagerLogs. For more information on monitoring the general software update management process, see Monitor software updates
Known issues
- The machine where the console is running is used to download the updates from WSUS and add it to the updates package. The WSUS signing certificate must be trusted on the console machine. If it isn't, you may see issues with the signature check during the download of third-party updates.
- The third-party software update synchronization service can't publish content to metadata-only updates that were added to WSUS by another application, tool, or script, such as SCUP. The Publish third-party software update content action fails on these updates. If you need to deploy third-party updates that this feature doesn't yet support, use your existing process in full for deploying those updates.
- Configuration Manager has a new version for the catalog cab file format. The new version includes the certificates for the vendor's binary files. These certificates are added to the Certificates node under Security in the Administration workspace once you approve and trust the catalog.
- You can still use the older catalog cab file version as long as the download URL is https and the updates are signed. The content will fail to publish because the certificates for the binaries aren't in the cab file and already approved. You can work around this issue by finding the certificate in the Certificates node, unblocking it, then publish the update again. If you're publishing multiple updates signed with different certificates, you'll need to unblock each certificate that is used.
- For more information, see status messages 11523 and 11524 in the below status message table.
- When the third-party software update synchronization service on the top-level software update point requires a proxy server for internet access, digital signature checks may fail. To mitigate this issue, configure the WinHTTP proxy settings on the site system. For more information, see Netsh commands for WinHTTP.
Status messages
| MessageID | Severity | Description | Possible cause | Possible solution |
|---|---|---|---|---|
| 11516 | Error | Failed to publish content for update 'Update ID' because the content is unsigned. Only content with valid signatures can be published. | Configuration Manager doesn't allow unsigned updates to be published. | Publish the update in an alternate way. See if a signed update is available from the vendor. |
| 11523 | Warning | Catalog 'X' does not include content signing certificates, attempts to publish update content for updates from this catalog may be unsuccessful until content signing certificates are added and approved. | This message can occur when you import a catalog that is using an older version of the cab file format. | Contact the catalog provider to obtain an updated catalog that includes the content signing certificates. The certificates for the binaries aren't included in the cab file so the content will fail to publish. You can work around this issue by finding the certificate in the Certificates node, unblocking it, then publish the update again. If you're publishing multiple updates signed with different certificates, you'll need to unblock each certificate that is used. |
| 11524 | Error | Failed to publish update 'ID' due to missing update metadata. | The update may have been synchronized to WSUS outside of Configuration Manager. | Synchronize the update with Configuration Manager before attempting to publish it's content. If an external tool was used to publish the update as Metadata only, then use the same tool to publish the update content. |
Working with third-party updates video
Next step
Value-added resellers (VARs) and security consultants who formerly used Microsoft's Software Update Services to...
manage their customers' patches have several options for replacing SUS. This tip, reposted courtesy of SearchSecurity.com, describes those options in detail.
With Microsoft discontinuing support for Software Update Services (SUS), organizations using the patch management tool have a decision to make. Do they adopt Windows Server Update Services – Microsoft's next generation replacement for SUS – or Microsoft Systems Management Server, or do they turn to a third-party solution? Let's look at the differences between SUS, WSUS, and SMS and when or if companies might want to invest in a non-Microsoft patching and update tool.
Sorting through the acronyms
Microsoft Windows Server Update Services (WSUS) started shipping in June of 2005 and is available free of charge. WSUS is an update to its predecessor, SUS, and is the Microsoft recommended patching and update tool for the SMB market. WSUS runs on Windows Server 2000 and 2003, and interacts with the Microsoft Update agent on Windows 2000 (with SP3) and XP hosts to support patch delivery and installation. While functional, the tool doesn't support some features that are required by large enterprises such as complex flexible scheduling and inventory management.
If your organization is willing to shell out a few dollars, Microsoft offers Systems Management Server 2003. SMS provides more advanced administrator management features than WSUS. Specifically, SMS includes control over installation and rebooting, an inventory component piece to help with compliance reporting and a customizable interface.
While SMS provides relatively robust patch and update support, there are some drawbacks. SMS doesn't support non-Windows systems. Enterprises with mixed systems, such as *NIX and MacOS still need to find a way to manage patching and updates on those systems. Many large organizations invest time and effort into configuring vulnerability management components that are managed and overseen by network or desktop operations teams. For example, a company that gathers and stores asset inventory information using IBM/Tivoli or performs all software update and package delivery using CA/Unicenter may not want to change operational procedures to perform these functions via SMS. In fact, there may be a compelling reason to keep these functions where they are.
Is the third party the charm?
A complete vulnerability management solution is comprised of more than simply sending patches to Windows devices. Comprehensive vulnerability management includes keeping a current inventory of all systems and applications on the network, using scanning and informational mechanisms to determine current vulnerabilities and exposures, and maintaining correct patch and configuration levels on systems. Robust management and reporting is also of high importance for most enterprises. Before deciding on any solution, be sure to document business requirements for the solution, such as which systems must be covered and how granular reporting capabilities need to be.
For companies that are concerned about vulnerabilities related to Windows-based but non-Microsoft applications, sifting through the alerts and advisory postings can be extremely time consuming. Third-party vulnerability management vendors keep current lists of vulnerabilities for a variety of systems and applications, and can send alerts and updates to customers.
Many third-party vulnerability management providers also offer coarse-grained prioritization of vulnerabilities and the ability to change classification levels of assets based on importance to the organization. By classifying important assets and ranking vulnerability severity, companies can prioritize their remediation efforts. For larger enterprises that may not be able to send out all patches or updates at once, the ability to first target the most critical and vulnerable systems can mean the difference between dodging a worm and shutting down production servers.
Third Party Patch Management Software
One more option
3rd Party Patch Management Wsus
There's one more Microsoft tool that bears mention -- the Microsoft Baseline Security Analyzer. MBSA is intended for the SMB market and scans Windows systems for current patch and update level and configuration state. It can be used in conjunction with security solutions from third-party vendors Citadel Security, IBM/Tivoli and PatchLink.
Microsoft has a number of offerings for patch and update management, but patching is only part of the vulnerability management story. For some enterprises, SMS 2003 may fit business needs, but for many, the best fit is found in the more robust and feature-rich offerings of third-party vulnerability management vendors.
About the author
Diana Kelley is a Senior Analyst with Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.
This tip originally appeared on SearchSecurity.com.