Getting Started with Third Party Patching using Patch My PC

About

This guide will cover an overview of the combination of Patch My PC and ConfigMgr, and how they can be used to deploy 3rd party patches.

 

Getting Started

 

What is Patch My PC?

Patch My PC is a company that provides a service to automate third-party patching and application packaging in ConfigMgr and Intune for Windows-based software.

What will it do for me?

Patch My PC has a couple of areas that it covers: Base application creation in both ConfigMgr + Intune, software update patching in ConfigMgr’s Software Updates (WSUS), and app updates in Intune. View the sections below for more details:

Prerequisites

Before you start, make sure the following are in place:

• A current branch ConfigMgr site with a configured software update point (SUP) and WSUS
• A Patch My PC subscription and the Patch My PC Publisher installer
• A Windows Server (the SUP server is fine) with internet access to the Patch My PC catalog service
• The WSUS signing certificate deployed to clients — third-party updates are signed content, and clients must trust the certificate before they will install them
• For Intune: a tenant where you can consent an enterprise application for the Publisher, plus licensing that covers Win32 app management

Setting Up the Publisher with ConfigMgr

Install the Patch My PC Publisher on the server that hosts your software update point. On first launch, point the Publisher at your ConfigMgr site using the SMS Provider and confirm it can read your site database. Next, configure the WSUS connection so the Publisher can publish update content into WSUS the same way Microsoft updates arrive. In the ConfigMgr console, enable the client setting that allows signed third-party updates — you will find the third-party software updates options under Administration > Client Settings and in the SUP component properties, where you can also let ConfigMgr manage the signing certificate automatically.

Adding the Catalog and Publishing Updates

In the ConfigMgr console, go to Software Library > Software Updates > Third-Party Software Update Catalogs and add the Patch My PC catalog. Subscribe to it and run a synchronization so the catalog metadata lands in the console. Inside the Publisher, choose which products and vendors you want — Adobe, Google, Mozilla, Zoom, and hundreds of others are in the catalog — and decide whether each product publishes as metadata only or with full content. For most environments, the predictable pattern is to auto-publish new versions as full content so they are ready to deploy without manual steps.

After the next SUP synchronization, the third-party updates appear under All Software Updates right alongside Microsoft updates. From there they behave like any other update: add them to a software update group, deploy them to a pilot collection with a deadline, review compliance, and then promote them to your production deployment rings. Automatic deployment rules can handle the recurring flow so new application versions are deployed on the same cadence as Patch Tuesday.

How Scanning and Compliance Work

Once published, third-party updates take part in the same scan cycle as Microsoft updates. During a software update scan, the Windows Update Agent on each client evaluates the published rules against the applications actually installed, so an update for an application the device does not have simply reports as not applicable. Compliance states roll up in the console exactly like security updates, which means your existing patch reports and dashboards start covering third-party software with no extra tooling. When a newer version of an application is published, it supersedes the older update, so clients converge on the latest release and superseded content can be cleaned up during normal WSUS maintenance.

Creating Base Install Applications in ConfigMgr

Patching existing installs is only half of the value. The Publisher can also create base installation applications for ConfigMgr, complete with detection methods, install and uninstall commands, and application icons. New deployments then start from the latest version instead of an old package followed by a patch cycle. When the Publisher releases a newer version, it can automatically update the existing application rather than creating duplicates, keeping your application library clean.

The Intune Path

For Intune-managed devices, connect the Publisher to your tenant and grant the required permissions. You can then create two kinds of Win32 apps: base install apps for new deployments, and update apps that target devices with older versions installed and bring them current. Update apps use requirements and detection logic so they only apply where the outdated application actually exists. Assign base installs as available or required from the Company Portal, and let the update apps run as required assignments so the fleet converges on supported versions without user involvement.

Verification and Troubleshooting

Verify each stage as you go. Confirm the catalog synchronization completes without errors in the console, check that newly published updates show content downloaded, and watch deployment compliance on your pilot collection before expanding. When something stalls, these are the logs and checks that matter:

• SMS_ISVUPDATES_SYNCAGENT.log on the site server — third-party catalog sync and publishing
• wsyncmgr.log — SUP synchronization with WSUS
• The Patch My PC Publisher log — catalog download and publish results
• Client-side UpdatesDeployment.log and WUAHandler.log — update evaluation and install on devices
• Most common root cause: clients that do not trust the WSUS signing certificate, or the client setting for third-party updates not applied — check both before digging deeper

Day-2 Operations: Keeping It Healthy

Treat the catalog like any other production service. Review the subscribed product list quarterly — vendors rename products, and stale subscriptions publish updates nobody needs. Keep a permanent pilot collection in the flow; even automated third-party updates deserve a small proving ring before they reach every device. Watch the WSUS signing certificate expiry date, because an expired certificate silently stops clients from accepting third-party content. Finally, align your automatic deployment rules with the Patch Tuesday calendar so third-party updates are tested, deployed, and reported in the same change window as your Microsoft patches.

Start with a handful of high-impact applications, prove the flow end to end on a pilot group, and then expand the catalog. Within one or two patch cycles, third-party patching stops being a manual scramble and becomes part of the same routine as your Microsoft updates.