Hey, IT pros, let’s discuss a common weak link in cybersecurity: third-party application patches. We all patch our Windows OS regularly, but what about apps like Java, Adobe Reader, 7-Zip, or Chrome? Unpatched third-party apps are often the Achilles’ heel in patch management. A considerable portion of cyber attacks – around 75% % – target vulnerabilities in third-party software. Likewise, over half of data breaches (57%) have been traced back to poor patch management practices, which include missed updates in non-Microsoft applications. Keeping those apps up to date is not just a “nice-to-have” – it’s essential for security.

This blog post will explore how you can integrate Patch My PC with Azure Update Manager to automate third-party application patching on Windows servers. We’ll cover why third-party patching matters, how Patch My PC and Azure Update Manager work together (even though they don’t integrate directly out-of-the-box), and provide a step-by-step guide to set it up. We’ll discuss real-world benefits like reducing CVEs, achieving compliance, and centralizing control over updates. We’ll also tackle common challenges (because nothing’s ever as simple as the marketing slides) and share best practices for smooth, ongoing operations.

Let’s dive in and make third-party patching one less thing to worry about in your security arsenal!

Why Third-Party Apps Are the Weakest Link in Patching

You might think, “We’ve got Windows Update and WSUS handling our patches; we’re good, right?” Many breaches don’t come through Windows – they come through apps you installed on top of Windows. Administrators often focus on Windows OS and ignore applications like web browsers, PDF readers, archive tools, and developer runtimes. Attackers know this. They actively exploit vulnerabilities in these third-party apps – vulnerabilities that may linger for months if you’re not patching them.

Consider some real examples: the infamous CVE-2017-11882 in Microsoft Office (allowing remote code execution via a Word file) or the Adobe Acrobat Reader RCE flaws exploited through malicious PDFs. These aren’t hypothetical – they’ve been used in actual attacks. And it’s not just niche software; even widely-used tools like Drupal (“Drupalgeddon” vulnerability) and design platforms like Canva have had serious flaws. The bottom line is that if you leave third-party software unpatched, you leave the door open for attackers. A colorful article likened unpatched apps to “unlocked castle doors” for cyber fiends​– and that’s not far from reality.

Relying on end-users or manual efforts to keep every application updated is a losing battle. We need an automated, centrally managed way to patch third-party apps on our servers, just like we do for Windows itself. This is where Patch My PC and Azure Update Manager come into play, forming a powerful combo to slay those third-party patching dragons.

Meet the Duo: Patch My PC + Azure Update Manager.

Patch My PC is a popular third-party patch management solution that many Microsoft-centric IT teams use alongside ConfigMgr (SCCM) or Intune. In a nutshell, Patch My PC automates the packaging, testing, and deployment of thousands of third-party updates​ (

patchmypc.com). Instead of you repackaging every new version of Adobe or Notepad++, the Patch My PC publishing service handles it. It can plug those updates into your existing update infrastructure (historically via WSUS and SCCM or Intune’s app model). It’s known for its quick turnaround (often adding new updates within 24 hours of release). It even provides vulnerability details (CVEs) associated with each update so you know which critical patches to prioritize. In short, Patch My PC takes the heavy lifting out of third-party application patching – a game changer for keeping your software stack secure and up-to-date.

On the other hand, Azure Update Manager (AUM) is Microsoft’s modern cloud-based service for managing updates on Windows (and Linux) machines across hybrid environments. Think of it as the evolution of WSUS/ConfigMgr’s patching – a way to centrally govern and orchestrate patches from the Azure portal for all your servers, whether they run in Azure, on-premises, or even other clouds. Azure Update Manager works through Azure Arc for non-Azure servers: you install the Arc agent on your server, which enrolls it in Azure management. Then AUM can assess its update compliance and install updates according to schedules or on-demand. A significant benefit is the single dashboard AUM provides – you can oversee update compliance for your entire fleet in one place, with options to do real-time patching, scheduled maintenance windows, and even dynamic grouping of machines.

But here’s the catch: Azure Update Manager is focused on Windows Updates (i.e. Microsoft patches). Out-of-the-box, AUM has no native mechanism for third-party application updates. If you only use AUM alone, it will miss Chrome, Java, Adobe, etc. Microsoft’s documentation makes this clear – AUM still relies on WSUS under the hood for any third-party updates. In other words, to patch third-party apps via Azure Update Manager, you need to feed those updates through a WSUS instance that AUM can leverage.

That’s precisely where Patch My PC complements AUM. Patch My PC can publish third-party updates into WSUS (it acts as the “third-party catalog” source). Azure Update Manager can then detect and deploy those updates on your servers because they’re available in WSUS. It’s a bit of an indirect integration: Patch My PC doesn’t plug into AUM directly, but they work together through WSUS. The flow looks like this:

Integration workflow: Patch My PC publishes third-party updates into WSUS. Azure Update Manager (via Azure Arc) orchestrates patching on servers, which retrieve Microsoft updates from Windows Update and third-party updates from WSUS. The Arc agent returns compliance data to Azure Update Manager for a unified view.

WSUS is still a critical component in this setup – it is the repository for third-party metadata and content updates. Azure Update Manager orchestrates when and how updates get applied (scheduling, compliance tracking, etc.), but WSUS (fed by Patch My PC) ensures that the what (the actual update files for Notepad++, 7-Zip, etc.) is available to install. If you hoped to ditch WSUS entirely, note that, for now, WSUS remains indispensable for third-party patching with AUM. (Microsoft has deprecated WSUS regarding future development, but they’ve explicitly stated it’s still supported for many years and required for scenarios like this​.)

So, Patch My PC, WSUS, Azure Update Manager, and Azure Arc together provide a full solution: Microsoft updates come from Windows Update (or WSUS), third-party updates come from WSUS (populated by Patch My PC), and Azure Update Manager gives you a cloud-based, centralized control plane to approve, schedule, and monitor patching across all your servers.

How the Patch Workflow Operates

To put it in perspective, let’s outline the update lifecycle in this integrated approach from start to finish:

  1. New Third-Party Update Released: A software vendor (say Adobe) releases a new version with security fixes. It’s associated with certain CVEs.
  2. Patch My PC Catalog Update: Patch My PC monitors for new third-party updates. When one is released, they test it, package it, and add it to their catalog (usually within a day).
  3. Publish to WSUS: Your Patch My PC Publisher service (running either on-prem or in Azure) automatically downloads the new update from the vendor and publishes it into WSUS. This involves creating a WSUS update entry (with metadata like name, version, applicability rules, and the content file). For example, a new Notepad++ 8.5 update or 7-Zip 19.0 update would appear in WSUS via Patch My PC.
  4. WSUS Hosts the Update: WSUS now stores the update binaries (or downloads them on demand) and is aware that this update is available for clients. At this point, WSUS can auto-approve specific third-party updates or manually approve them for installation – similar to how you manage regular WSUS updates.
  5. Azure Arc Check-in: Your Windows Server (which is Azure Arc-enabled and linked to Azure Update Manager) performs an update scan. This can happen on a schedule (Azure Update Manager can trigger periodic scans, e.g., daily), or you can manually trigger a scan from the Azure portal (“Check for updates” on the machine). The key is that the Windows Update Agent on the server is configured to talk to both Microsoft Update and your WSUS.
    • On newer OS like Windows Server 2022+, the agent can do a dual scan: it simultaneously gets Microsoft first-party updates from Windows Update and third-party updates from WSUS. On older servers, dual scan isn’t supported, so you might point them entirely to WSUS for both MS and third-party updates (we’ll discuss this in the setup).
  6. Update Detection: The server reports back which updates are needed. In the Azure Update Manager’s dashboard, you’ll now see missing Windows and third-party patches for that server. For example, it might show that “Notepad++ 8.4.7 (x64) – Republished on 2024-12-17” is required alongside the usual Patch Tuesday cumulative updates. (Azure Update Manager will list third-party app updates by name once this is set up correctly, right next to your OS updates!)
  7. Schedule Deployment: Using Azure Update Manager, you create a maintenance configuration or schedule that includes the relevant classifications (ensure that the “Updates” classification is included since many third-party patches fall under that category in WSUS). You can scope this to specific servers or a group (for example, all servers with a specific tag or in a resource group). Pick a time – maybe your regular patch window – and create the schedule. Azure Update Manager will orchestrate the deployment during that window. You also have the option for on-demand installation (like an “Install now” action in the portal). However, as we’ll note later, targeting specific third-party updates on demand has a known limitation.
  8. Patching in Action: When the scheduled time arrives, Azure Update Manager (through the Arc agent) tells the Windows Update agent on the server to install the needed updates. The server then installs the third-party update content from WSUS (and any Windows updates from Microsoft or WSUS, depending on config). If a reboot is required, Azure Update Manager can manage that reboot (you can configure whether to reboot automatically or not as part of the maintenance plan).
  9. Reporting and Compliance: The Arc agent reports the status back after installation. Azure Update Manager will update the compliance status for that server, showing success or failures for each update. You can view logs or error details if something fails. Over time, the Azure Update Manager compliance dashboard gives you a bird’s-eye view of which machines are fully patched, which have outstanding updates (and of what classification), trending graphs of compliance, etc.​ This satisfies auditors and security teams that our third-party patches are under control just like our OS patches.

To sum up, Patch My PC ensures the content is there, and Azure Update Manager ensures the application process is automated and visible. It’s the best of both worlds: a rich catalog of third-party updates feeding into a cloud-based patch management system.

Now, let’s get our hands dirty and walk through how to set everything up step by step.

Step-by-Step Setup Guide: Integrating Patch My PC with Azure Update Manager

Setting up this integration involves properly configuring both sides (Patch My PC/WSUS and Azure Update Manager/Azure Arc). Below is a step-by-step guide:

1. Prepare Your WSUS (or ConfigMgr) Environment

First, you need a WSUS to host third-party updates. In many environments, ConfigMgr (SCCM) is already integrated with WSUS – if so, you could use that WSUS instance. If you’re doing a fresh setup without SCCM, install a standalone WSUS server (on-prem or even on an Azure VM). Ensure this WSUS is reachable by your Windows servers (network connectivity and firewall rules in place) and configured to sync at least the product categories you care about (Windows Server OS, etc.). If you use WSUS only for third-party updates (and let Windows updates come directly from Microsoft), you might not need WSUS to sync every Microsoft patch, reducing the WSUS load. We’ll cover that scenario shortly.

Important: Ensure WSUS has a code-signing certificate for publishing third-party updates. Patch My PC’s setup guide usually helps configure this. The certificate must be trusted by your target servers (usually, it gets placed in the “Trusted Root Certification Authorities” and “Trusted Publishers” on clients). If you have SCCM, this is often handled for you. For standalone WSUS, you might have to distribute the cert via Group Policy. Patch My PC’s publishing service can automatically configure WSUS with a self-signed cert if needed. Just keep this in mind – without that cert trust, clients will refuse to install third-party updates.

2. Set Up Patch My PC Publisher and Catalog Subscription

Install and configure the Patch My PC Publisher utility on a server that can talk to WSUS. During setup, you’ll specify the WSUS server name, port, and credentials so that Patch My PC can publish updates to it. You’ll also select which third-party applications you want to enable from Patch My PC’s catalog. For example, you might check the boxes for “Adobe Acrobat Reader DC,” “Google Chrome,” “7-Zip,” “Notepad++,” etc., depending on what you have in your environment. Patch My PC supports hundreds of apps, so choose what you use to avoid clutter.

Patch My PC will then connect to the vendor sites and download the latest installers for those apps. It will publish update entries into WSUS for any it finds missing. You can usually configure whether to automatically publish just metadata or full content—typically, you’d do full content so that the binaries are ready in WSUS.

At this stage, verify that Patch My PC is successfully publishing to WSUS. In the WSUS console, under “All Updates,” you should see your third-party apps listed (you might have to filter by “Third Party” updates or look under a custom Patch My PC category). They might show as “Not approved” initially. You can create WSUS auto-approval rules for these if you want all patches from Patch My PC to be auto-approved for installation or manually approve them per update or computer group. The most straightforward route in a small environment is auto-approve all Patch My PC updates for your server group.

Tip: Enabling email reports or alerts in Patch My PC Publisher will ensure your catalog stays healthy. This will notify you if publishing fails (e.g., due to a new update that didn’t download correctly).

3. Onboard Servers to Azure Arc (if not already)

Azure Update Manager requires that your on-prem or non-Azure servers be Azure Arc-enabled. This means installing the Azure Arc agent so the server appears in the Azure portal and can be managed. If you haven’t done this:

  • In the Azure portal, search for Azure Arc and go to Servers. Click Add a new server. You’ll be guided to download an installer script. Run that on your Windows server. (It will require Azure credentials to register the machine.)
  • During Arc onboarding, you might attach the server to a Resource Group, specify tags, etc. Ensure it’s in the subscription and resource group you intend to use for Update Manager.
  • Once done, the server should appear as an Arc-enabled machine in Azure.

Make sure to repeat this for each Windows server that you plan to patch via Azure Update Manager. This could be your on-prem SQL servers, web servers, etc., and Azure VMs if you want to manage them with AUM (Azure VMs can also use AUM directly without Arc since they’re already in Azure).

4. Enable Azure Update Manager and Configure Update Settings

Azure Update Manager might already be available in the Azure portal (generally GA as of late 2024/early 2025). If you haven’t used it before, there’s minimal setup – it’s a SaaS service. But you should ensure that:

  • If required, the Log Analytics agent or Azure Monitor agent is configured. (Azure Update Manager uses Azure Monitor under the covers to track update data, but Azure Arc onboarding usually handles installing the necessary monitoring agent extensions.)
  • Navigate to Azure Update Manager in the portal. Under Machines, you should see your Arc-enabled servers listed. If not, double-check that the Arc agent is installed and connected.
  • For each server, go to Update Settings. Here, you can enable periodic assessment (so the machine regularly checks for updates) and optionally Automatic VM guest patching (which auto-installs Windows patches outside a maintenance config—we usually leave that off if we’re scheduling via AUM). Enable periodic assessment to get continuous compliance data.
  • Also, ensure the machine’s maintenance window/patch orchestration is set to Azure Update Manager (the settings might differ if you previously used Azure Automation Update Management, but with AUM handling the orchestration, it should default to AUM).

One crucial configuration for third-party updates: if you want to split sources (Microsoft updates from Windows Update cloud and third-party from WSUS), you need to adjust the “scan source” policy on the server. Azure Update Manager supports a scenario where the Windows Update Agent can scan its default (Windows Update) and WSUS. This is controlled via either Group Policy or registry settings:

  • For Windows Server 2022 and above: Configure the “Specify source service for specific classes of Windows Updates” policy. Essentially, set Feature Updates, Quality Updates, Driver Updates, and Other Updates to Windows Update (which is value 0 for each in the registry). Also, set UseUpdateClassPolicySource to 1. This tells the agent to get those classes from Windows Update (cloud). There is no specific toggle for third-party – by setting all those to Windows Update, you implicitly allow third-party (which WSUS handles) to still come from WSUS. This is the “dual scan” replacement in newer OS. On Server 2022+, the machine can simultaneously scan WSUS for third-party updates while getting OS updates from the cloud.
  • For older Windows Server versions (2016, 2019, etc.): they don’t support that modern scan policy. In this case, your choice is to either:
    • Point the server entirely to WSUS (via the WUServer registry/GPO and not using dual scan). Then, WSUS must provide both Microsoft and third-party updates. This works, but you’re using WSUS like in the old days. Azure Update Manager will still orchestrate the installation, but behind the scenes, the server will get all updates from WSUS. (Ensure your WSUS is syncing the necessary Microsoft updates in this scenario!)
    • Or upgrade the server OS to 2022+ to allow the split scan. (That might not be feasible quickly, but it’s a consideration for long-term strategy.)

In either case, configure the WSUS server location on the client via GPO so the server knows about your WSUS. This is done by setting the HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer (and WUStatusServer) registry to your WSUS’s URL. If you had ConfigMgr before, those might already be set from the earlier client policy.

To summarize this step: Azure Update Manager setup involves enabling the service, ensuring Arc/monitoring is in place, and configuring the Windows Update agent on each server to talk to the right update sources (WSUS for third-party, optionally Windows Update for Microsoft). Once that’s done, the servers will report their update compliance, including third-party.

5. Verify Update Visibility and Approvals

Give it some time, or manually trigger an “Assess Updates” on a server in Azure Update Manager (there’s a “Check for updates” button). The server should scan and report back. Now, in Azure Update Manager’s Updates view for that machine, you should see a list of needed updates. This will likely include:

  • Windows OS updates (e.g., “2025-02 Cumulative Update for Windows Server…”) with classification Security Updates, etc.
  • Third-party updates that Patch My PC published via WSUS. In the UI, these might appear with the name, classification “Updates,” and severity. For example, Notepad++ 8.4.7 (x64) – Republished on 2024-12-17 might appear with Severity “Moderate” (if Patch My PC tagged it as such). You might also see “7-Zip 24.0.0 (x64) – Republished on [date]” as an update with Severity “Important”, etc. This confirms that Azure Update Manager is detecting the third-party updates from WSUS.

If you do not see the third-party updates but only Windows updates, double-check the previous steps (particularly the WSUS GPO configuration and ensure that the update was approved in WSUS. Remember, Azure Update Manager will only list updates approved for installation. If your WSUS has the update in the “Not Approved” state for that machine, the agent might not consider it installable. So be sure those Patch My PC updates are approved (you can set Patch My PC to auto-approve or use WSUS auto-approval rules to make this easier).

Azure Update Manager view of a server: In this example, Azure Update Manager shows both Microsoft and third-party updates required on a Windows Server. Notice the Notepad++ and 7-Zip updates listed alongside Windows updates, thanks to Patch My PC publishing them to WSUS. This integrated view helps ensure no critical third-party patch (like a 7-Zip vulnerability) slips through the cracks.

6. Create a Patch Deployment Schedule

With updates now visible, the next step is to automate their installation. In Azure Update Manager:

  • Go to “Schedule updates” (from the machine’s or main Update Manager page to cover multiple machines).
  • Create a Maintenance Configuration, giving it a name like “Monthly Patching—Servers.” Select the scope (it could be a specific machine, multiple machines, or a dynamic group via Azure Arc tags or saved search). For example, you might target all servers with the environment=Prod tag in a group.
  • Set the patch window schedule: perhaps every second Saturday at 2 AM, with a 4-hour window, or whatever fits your org’s maintenance policy.
  • Crucially, under Included classifications, make sure to include Updates (and Security Updates, Critical Updates, etc., as needed). Third-party app patches often fall under the “Updates” classification (as defined in WSUS). If you omit “Updates,” you might accidentally skip third-party fixes! (I’ve seen folks accidentally do this and wonder why apps aren’t patching.)
  • You can also set reboot options (reboot if required, skip reboot, etc. – usually allow reboot for servers that can reboot in that window, or “reboot if required” and use your clustering/drain procedures to avoid downtime).
  • Save the schedule.

Azure Update Manager will now take it from here. It will orchestrate patch installation on the target servers at the next scheduled time. It smartly handles things like sequencing (to avoid patching all at once if you set some max concurrency) and will ensure all included updates (including those third-party ones) are installed if possible.

7. Monitor Patch Results

After a patch job runs, constantly review the results:

  • Check if the updates were installed successfully in Azure Update Manager’s History or the specific maintenance instance. Any failures (perhaps an update couldn’t install or a server was offline) will be reported. From here, you can drill down if the Notepad++ update failed – maybe the app was not present (so detection failed) or the WSUS content was not reachable.
  • Azure Update Manager provides a nice compliance summary per server, such as “Compliant” or “X updates missing.” You can use the Update Compliance tab to get an overview across many machines.
  • You can even use Azure Workbooks or Log Analytics for deeper analysis or reporting. Azure Update Manager logs data to a Log Analytics workspace (if configured), so you can run queries or use a pre-built workbook to see compliance over time, pie charts of missing vs installed updates, etc. This is great for management reports.

And that’s it – you have a system in place where third-party application updates flow from vendor to Patch My PC to WSUS and get deployed via Azure’s cloud-managed service alongside regular patches. No more forgotten Java updates or outdated WinZip lingering around as ticking time bombs!

Real-World Benefits of This Integration

Implementing Patch My PC with Azure Update Manager isn’t just a “cool” technical feat; it delivers tangible benefits:

  • Dramatically Reduced Vulnerabilities (CVEs): This is the big one. By patching previously neglected apps, you close off significant avenues of attack. Each third-party update applied means dozens of CVEs are potentially eliminated from your environment. For example, if a new 7-Zip patch fixes a critical vulnerability, getting that out quickly can prevent a nightmare. Patch My PC even highlights which CVEs are addressed by an update​so you know the risk of delaying it. Over time, organizations see their vulnerability scan reports or Microsoft Secure Score improve, thanks to covering third-party software. Fewer unpatched CVEs means a significantly lower chance of being breached via known exploits.
  • Improved Patch Compliance and Audit Readiness: With Azure Update Manager’s single pane of glass, you can prove to auditors and management that all your systems are up to date – not just Windows, but the software running on Windows, too. Compliance frameworks (like CIS, Essential Eight, etc.) often require timely software patching. This integration helps meet those requirements. The integrated compliance dashboards show the patch status across your servers. You can easily generate reports of compliance by server or by application. It’s much easier to say “we’re 98% compliant on patches” when you have data that includes third-party updates, rather than sheepishly admitting you don’t have good visibility into application patch levels.
  • Centralized, Cloud-Based Control: No more juggling WSUS consoles for third-party patches separately from your Azure portal for Windows updates. AUM brings it together. You manage patch schedules and approvals from Azure using modern tooling. There’s also integration with things like Azure Policy and RBAC – meaning you can enforce patching policies and control who can approve or postpone updates. This central control is especially valuable in hybrid scenarios; whether a VM is on-prem, in Azure, or AWS, as long as it’s Arc-enabled, you manage it the same way. In short, you get a consistent, centralized patch management process across the board.
  • Less Infrastructure and Maintenance Overhead: If you’re coming from a pure on-prem solution (like SCCM for patching), moving to Azure Update Manager can reduce the infrastructure you maintain. You might keep a WSUS server (for third-party content), but you no longer need a full SCCM stack just for patching. Azure Update Manager is SaaS, meaning Microsoft runs the heavy lifting (compliance scanning service, scheduling service, etc.) for you. And if you configure dual-scan on a newer OS, your WSUS can be slim – only hosting third-party updates, while Windows updates come directly from Microsoft to each server (saving WSUS storage). This offloading of first-party updates can significantly reduce WSUS storage needs and replication traffic if you have many servers.
  • Faster Response to Zero-Days: When that next big zero-day in Chrome or Notepad++ drops, you can respond fast with Patch My PC and AUM. Patch My PC will have the update ready shortly after the vendor releases it, and you can deploy it via AUM in a coordinated way (even outside the normal patch cycle if needed). The ability to do on-demand patching or an extra emergency maintenance window means you’re not waiting for the next monthly cycle to address critical app flaws. This agility dramatically enhances your security posture.
  • Happier IT Teams and Users: Patching might not make anyone truly happy, but automating tedious tasks certainly does help. IT admins no longer need to package third-party updates or script installations manually. This frees them up for more important projects (or frankly, to get a good night’s sleep during Patch Tuesday week!). Users/end-users benefit because their servers and apps are more reliable and secure – fewer surprise incidents due to an exploit means less emergency downtime. Also, with properly scheduled maintenance, you can coordinate patch reboots to minimize user impact.

Integrating these tools helps you achieve “patching peace of mind”—you know that both OS and application patches are handled, and you have the data to prove it.

Common Challenges and How to Overcome Them

No solution is without hurdles. You might encounter a few challenges while setting up Patch My PC with Azure Update Manager. Here are the common ones and tips to deal with them:

  • Misconception: “WSUS is no longer needed.” Many admins initially thought that Azure Update Manager alone could do third-party patching. As we’ve made clear, you still need WSUS in the mix. The challenge is justifying keeping WSUS around if you hope to retire it. The key message to convey (upward to management, perhaps) is that WSUS is providing an essential service (third-party update distribution) that Azure’s cloud service currently doesn’t replace. The good news is that you can scope WSUS narrowly (only storing what you need) , and there’s no need for user-facing WSUS consoles or heavy maintenance once it’s stable. Embrace WSUS as a content cache for third-party updates – it’s not dead yet!
  • Older Servers (no dual scan): If you have Windows Server 2016 or 2019 machines, they cannot simultaneously scan WSUS and Windows Update. A common issue is that those servers either:
    • Only get Windows updates from WSUS (so if WSUS weren’t syncing something, they’d miss it).
    • Or if pointed to Windows Update, they miss third-party entirely.

Solution: It’s recommended to point these servers to WSUS for everything, at least until you can upgrade them. That means ensuring that WSUS syncs Microsoft patches for those OS versions. Yes, it’s heavier, but it’s required to patch them fully. Alternatively, plan an upgrade to Server 2022+ sooner rather than later for those boxes—not just for dual scan but for all the other benefits and support lifecycle.

Also, be mindful that Windows 10/11 clients are not supported by AUM (it’s servers only as of now). So, this whole integration focuses on your server infrastructure.

  • Scan Source Policy Confusion: The “Specify source for updates” policy with multiple classes can be confusing. Some admins set it wrong (like setting those values to 1 (WSUS) when they meant 0). Remember:
    • 0 = Windows Update (cloud)
    • 1 = WSUS​
  • For third-party via WSUS and Windows via cloud, set all to 0 and enable UseUpdateClassPolicySource=1.​
  • If you accidentally set it incorrectly, the server might not scan WSUS at all or ignore Windows Update. Double-check those registry values or GPO settings on one server and verify in WindowsUpdate.log or the registry that they took effect.
  • Third-Party Updates Not Showing in AUM: If, after setup, you don’t see any third-party updates in Azure, a few things to check:
    • Is the update applicable? Patch My PC might have published an update, but if that software isn’t installed on the server, the agent might not list it as needed. (No Notepad++ on that server means a Notepad++ update won’t appear.) That’s normal.
    • WSUS approval: Ensure the updates are approved for the group the server is in. If using auto-approval, check the logs that it did approve.
    • Trust and connectivity: Ensure the server can communicate with WSUS (check the Windows Update log or Event Log for WSUS connection errors). Also, if using HTTPS WSUS, verify the certificate trust. If using HTTP, ensure the firewall allows it.
    • Policy conflict: If the server also had an SCCM agent or some other policy, make sure there was no conflict in Windows Update configurations.

Usually, once WSUS and Patch My PC are configured correctly, the updates will show if the server can reach WSUS. The Q&A from Microsoft reminds us that without WSUS in the picture, AUM can’t see third-party updates, so it’s all about that connection.

  • Install on Demand Limitations: Azure Update Manager has a feature to “Install updates on demand” (like telling a machine to install a specific update now). However, it may not work correctly with Patch My PC updates due to how Patch My PC formats their update IDs. They use a format like PMPC-YYYY-MM-DD as an identifier, which AUM doesn’t always parse the same as a typical KB ID. This can result in AUM’s inability to execute an on-demand install for a single third-party update by ID.
    • Workaround: If you need to push a third-party update immediately, you can create a maintenance schedule that runs “now” and covers that machine (a one-time deployment including that update). Or use WSUS itself to target and trigger installation (less ideal, but an option).
    • The Patch My PC team is aware of this and is considering adjusting its catalog to align with AUM’s expectations. In the meantime, this feature might be hit-or-miss for third-party patches.
  • WSUS Maintenance: WSUS, being WSUS, can get bloated over time (especially if you enabled a broad sync in scenario 1). Keep an eye on it—run the WSUS Cleanup Wizard periodically to remove expired and superseded updates. Patch My PC periodically cleans up its published updates (like removing old versions), but WSUS may still accumulate a lot. Monitor disk space and consider using tools like Patch My PC’s WSUS Cleanup or community scripts to decline superfluous updates.
    • Also, watch WSUS performance if it’s handling thousands of updates; splitting roles (scenario two where WSUS only has third-party) can help keep WSUS lean.
  • Network Bandwidth Considerations: When servers get Microsoft updates from Windows Update (internet) and third-party from WSUS, each server will download patches from Microsoft’s CDN individually. This could strain internet bandwidth if you patch many servers at once. Mitigate this by:
    • Staggering patch times (AUM can do patches in batches).
    • Use Delivery Optimization or caching proxies for Windows Update if needed (though DO is more for clients).
    • Ensure that critical sites have sufficient bandwidth, or consider keeping WSUS for first-party updates at those sites.

Plan network capacity for potentially significant downloads (e.g., a 2 GB cumulative update per server). The trade-off of not downloading everything to WSUS at once is worth it for storage, but be mindful of the network side.

  • Security of the Solution: Some might question “is it secure to rely on a third-party (Patch My PC)?” Patch My PC is well-established and used by thousands of enterprises; their catalog files are code-signed, and you control what gets published. Azure Arc communication is secured to Azure. Ensure your WSUS is locked down (require HTTPS if possible, and limit access to needed subnets). It’s a balance of trust: you’re trusting Patch My PC to supply clean, tested updates – which historically has proven very reliable. It’s certainly more secure than manually downloading random installers from the web when you remember to update an app!

By anticipating these challenges, you can address them proactively. Once the system is running, it tends to be low-maintenance. As one user quipped, “Patch My PC is a game changer… pays for itself 10x” (particularly in time saved and breaches avoided).

Best Practices for Smooth Operations

Finally, let’s round up some best practices to keep this integrated patch management process running optimally:

  • Regularly Review Patch My PC Catalog Selections: Periodically audit which products you’re patching via Patch My PC. Remove any you no longer use (no need to publish updates for software not installed anywhere). Add new apps if teams introduce them. This keeps your updated catalog targeted and efficient.
  • Staged Deployments / Ring-Based Patching: Just as you might stagger Windows updates (Dev, Test, Prod), do the same for third-party patches. Perhaps apply updates to a subset of servers (or a test server) first, verify no issues (especially with things like .NET or Java updates that could affect applications), then roll out to all. Azure Update Manager can help by using dynamic groups or tags – e.g., tag some servers as “PatchRing:Test” and patch them first, then Prod later.
  • Leverage Azure Tags and Dynamic Groups: Use Azure Arc tags to your advantage. You could tag servers with roles or compliance requirements and create dynamic patch schedules. For instance, tag critical servers as “Critical=true” and have a separate maintenance window for them (maybe patch more frequently or with more oversight) vs non-critical servers. This adds flexibility and ensures the right timing for the right systems.
  • Enable Alerts for Patch Failures: Set up Azure Monitor alerts on Update Manager results. For example, trigger an email or Teams alert if a patch deployment fails on any server or if a server hasn’t reported compliance for over X days. This way, you are immediately aware of issues (like a server not patching) and can investigate. Azure Update Manager can integrate with Azure Monitor Logs, so you can write queries to detect anomalies. At the very least, check the Update Manager dashboard after each patch window.
  • Maintain WSUS Health: I mentioned cleanup—do it. Also, monitor WSUS services and the IIS app pool. If WSUS is on an older OS, consider moving it to a newer OS for better performance with the latest WSUS version. Only sync categories you need (there is no need to sync every Windows product under the sun if you only have Windows Server OS and maybe Office on servers). Less is more with WSUS.
  • Test Patches in a Lab (if possible): For highly sensitive environments, consider having a staging WSUS and a couple of test Arc-enabled servers that get patches first (maybe via a different Patch My PC instance or just a delay in approvals) to catch any bad updates. This could be overkill, as Patch My PC does test updates to avoid bad ones, but it’s an extra safety net.
  • Stay Informed on Azure Update Manager Updates: AUM is a relatively new service and is evolving. Keep an eye on Azure updates or the Azure Update Manager documentation for new features (for example, if Microsoft ever adds native third-party support or changes how Arc interacts). Join community forums or follow experts (Dave Kawula and others) who often discuss these changes. Microsoft’s Learn site and Patch My PC’s blog are great resources – e.g., Patch My PC’s knowledge base article on this integration is a must-read​ for deeper technical details and will be updated as things change.
  • Security Best Practice: Ensure the least privilege where applicable. The Patch My PC service account should only have the needed rights on WSUS. The Azure Arc agent runs under its service context; avoid exposing these channels. Also, consider network segmentation: if WSUS is on-prem, only allow your servers to contact it, not every machine on the network.
  • Disaster Recovery Plan: Document how your patching works now. If Patch My PC or WSUS had an outage, what’s the fallback? Perhaps keep an eye on vendor announcements, too (for supercritical patches, you could manually intervene if absolutely required). Having this process documented also helps onboard colleagues and ensure consistency.

These best practices will keep the patch train running smoothly on the tracks. In my experience, after the initial setup and a couple cycles of patches, admins are often pleasantly surprised: “Wait, you mean Java updated on all those servers and I didn’t have to do anything?!” Yes – that’s the automation doing its magic.

Conclusion

Third-party applications have long been the bane of patch management, but it doesn’t have to be that way. By integrating Patch My PC’s third-party update catalog with Azure Update Manager’s cloud-first patching orchestration, we get the best of both worlds: a robust library of application updates and a modern, scalable deployment mechanism. This duo addresses the “weakest link” in many organizations’ security posture – those sneaky outdated apps – and brings them into your regular patch process.

We’ve covered how to set it up, step by step, and what pitfalls to watch out for. The approach is insightful and pragmatic, much like guidance from a seasoned IT pro (hat tip to Dave Kawula’s style of keeping it real). The message is clear: With some upfront work, you can drastically reduce your exposure to threats by eliminating the third-party patch gap.

No more sleepless nights worrying if that Flash (hopefully you’re not using that!), Apache Tomcat, or VMware Tools on your servers is unpatched and exploitable. No more juggling multiple tools and spreadsheets to track who updated Adobe Reader this month. Instead, you’ll have a unified, cloud-powered view and control of patching across your infrastructure – from Windows OS to the apps running on it. The rewards are fewer CVEs, better compliance, and a smoother operations workflow.

So go ahead – take Patch My PC for a spin (they offer trials​ patchmypc.com) and connect it with Azure Update Manager and Arc. Your future self, seeing a near-100% patch compliance dashboard with both software and OS patches applied, will thank you. And the hackers scanning for an old version of 7-Zip or VLC on your servers? They’ll have to go empty-handed because you’ve got third-party patching on lockdown now.

Happy patching, and stay secure!

Steve Labeau – Principal Consultant / Blogger