With the release of CB 1806 we are now able to publish third party updates using custom catalogs. Ideally, third party patches would function exactly like first party patches from an administration and automation perspective. Currently there's two main areas where this is not the case.

Synchronization Schedule:
I could be wrong on this but I believe that subscribed catalogs sync automatically every 24-hours. While that's nice, it would be great to simply integrate with the existing sync schedule. Sync the catalogs, publish relevant metadata to WSUS, then sync the SUP(s).

Automatic Deployment Rules:
Currently, only update metadata is published by the automated sync process. In order to actually deploy an update you must manually right click on it and select 'Publish Third-Party Software Update Content'. That a big cold automation wet blanket. A few ideas, in increasing order of greatness:
-Publish the full content of a given catalog. Not ideal, but it solves the automation problem.
-Publish full content for only the product selected to sync in ConfigMgr. Much better than everything, solves automation, but still will include updates you don't want.
-Publish full content when selected by an ADR. A bit tricky since you'd need to publish the content, resync, and then deploy but your the best team ever so I know you have it in you.

 Bryan

When creating Automatic Deployment rules, it would be useful to be able to configure multiple deployments.

You may for example want test, pilot and live deployments to different collections and possibly with different settings. It doesn't make sense to have to create different rules with the same updates criteria just for additional deployments.

The CM administrator may choose to have the additional deployments disabled to allow for testing, but enabling a deployment leaves less room for error, and is less administrative overhead than creating these additional deployments manually each time for pilot/live.

It would also be useful to have the option to set deployments as available rather than required too (as far as I remember you can't do this from an ADR).

When SCCM expires updates based on the configured Supersedence Rules it only does so in SCCM, not WSUS. Additionally, SCCM does not approve updates in WSUS.
Because of these two facts the WSUS Cleanup Wizard will never decline superseded updates. They are neither expired (as they are in SCCM) nor are their superseding updates approved (a requirement for the WSUS Cleanup Wizard). This causes a bloated Update Catalog that can cause very real client issues. There are scripts available to handle this situation but this is the last mile issue in regards to WSUS maintenance. If the product declined the updates in WSUS when it expires them in SCCM then there would be no additional steps that admins needed to take.

It would be extremely helpful to have an option in the software update point site system to bypass a proxy for a local address. The only options today are (see Current-SUP-Proxy-Options.png):

• Use a proxy server when synchronizing


• Use a proxy server when downloading content by ADRs

The issue is when an ADR tries to download a third-party software update, it will attempt to use a proxy server and often fail because the proxy doesn't route correctly to the internal WSUS server. For example in patchdownloader.log, you will see something like <Download-Error-PatchDownloader.png>.

There needs to be an option to not use a proxy for local addresses (Third-party software updates being downloaded from the WSUS server) and Microsoft updates would continue using the proxy as needed. Today it's either proxy enabled for all ADR content downloads or for none. Bypassing proxy when the ADR see's it's a local address would be extremely helpful.

We probably get 3-4 cases a week from customers using our Patch My PC solution for third-party software updates in SCCM.

• Justin Chalfant

Per: https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-express-installation-files-for-windows-10-updates

"Using express installation files provides for smaller downloads and faster installation times on clients."

Through a case I opened with Microsoft, it was communicated to me that the current express update design is solely meant to reduce network bandwidth. There is no promise of expedited installation time. This is misleading and limits the purpose of express updates for remote office scenarios.

Additionally the express update deltas have to be decompressed and recombined in order to complete the installation which requires significant CPU usage.

The combination of these issues causes express updates to provide little benefit to customers in it's current state. I propose that express updates be reworked for faster client installation.