Automatically Publish Full Content for Third Party Software Updates
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.
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.
I really want a PowerShell cmdlet to publish third-party software update content - this would cover my automation needs.
Sean Huggans' solution would be good.
Christopher Mackintosh commented
The problem is that we have to manually select "Publish Third-Party Software Update Content"
ie The update turns from blue to green in the "All Software Updates" node in SCCM. afterits published and WSUS has performed another software sync.
An ADR will only see the updates after they are published, so its not really Automated as well as it could be.
+1 for Sean Huggans answer.. Are there any powershell commands to automate this in the mean time?
@ITrooster, I'm fairly certain that the cert requirement is because in order for ConfigMgr to manage the update signing cert it needs to move private keys around. You don't want that done outside of a secure/encrypted channel. I'd be happy to be wrong though.
Integrate the download of third party updates and not require certificates setup when SUP is off box from the Primary site (which is the recommended setup by Microsoft.) A checkbox for approving the third party content as trusted would suffice.
So. current process for me is -
- Manually synch 3rd party catalog (it doesn't synch automatically for me)
- Synch Software Updates
- Publish 3rd party update content.
- Synch Software Updates
- Either manually download and deploy or trigger ADR rule ...
Seems a lot of work for an automation tool. Was hoping to find a scripted method somewhere that could be scheduled on the server.
just ran into the same issues here. Really need this fixed as the idea of integrating is great but closing the loop to automate things is needed.
Would be great to get the full process automated.
Maybe by doing a automatic catalog sync within the scheduled standard Update sync and a automatic publish check-mark within the ADR like here https://imgur.com/6Ctf0L8 suggested from Sean.
I've spent the last two days trying to figure out why they weren't publishing automatically, so happy I found this page and can move on to doing the ADR updates publishing manually. I am about 25% through a migration of desktops to W10, so I guess, I just need to put it in my calendar to go back in and publish any newly identified drivers so the ADR can pick them up. Then we'll need it as part of our process for every new model we implement to identify and publish the updates manually so they are included in the ADR. Next time I get a vote back, I'll be adding here for sure.
maybe autopublish any that have a "Required" tag...
Great suggestion Bryan. Came here to make the exact same.
I would be happy if they at least bring the ability to schedule the sync. That way I can at least sync the 3rd party patches so they can display in the console.
+1 For Sean Huggans's suggestion
+1 For Sean Huggans's suggestion
Gerhard Eriksson commented
Right... Today (SCCM1806) its minimum 2 manual processes (In my mind) you have to do before you can get new content to client. Both must be addressed. Proposed ADR only fix the last one. So why just automate 1 of 2 manual steps?
1. Syncing of 3-party catalog for updates (get metadata of updates). You must right-click on catalog and sync it before part 2.
2. Right-click on update, Publish Third-party content to client (get binary from source specified in metadata) = Here is the authors solution comes in, yes we need this as well, but what about step 1?
Normal WSUS-sync does not include 3party catalog sync, that's correct. Not even SCUP download new metadata automatically. SCUP can see that catalog(s) has been changed by fingerprinting but it never updates its own database. For me anyway... But you can make it to download and publish binaries automatically if it’s find "a number of clients" how needs the update by the Required-field in the SCCM database when you run import/update catalog in SCUP, as long you have connected SCUP to SCCM and set your published updates as automatic…
The "Schedule..." option IS to automatically update catalog metadata from 3-party in SCCM/WSUS. With "new/fresh" metadata you can match it with clients. So you can get number of clients how needs the update, or even know there is an update to begin with.
Today (SCCM1806) there is no option for this, you can smash the “Sync. Software Updates” button in SCCM how many times you like, and it won’t update 3-party metadata. The only option you have is to click on every separate 3-party catalog and click sync now.
And why a separate Sync-Schedule per catalog? Because not every catalog change as often as once every 24 hours. “HP clients, drivers and firmware” catalog is just fine running once a week or mouth. But “Adobe Flash” catalog would be nice to run a check every 24 hours.
Another thing is that 3-party catalogs import and publish all metadata into WSUS and if there’s a lot of catalogs with over 3000-6000 updates so will it be a strain on the WSUS database even if you only want 3 out of 3000-6000 possible updates, you will get them all. Paraphrasing “If you don’t want to publish all metadata into WSUS, then use SCUP.” – Microsoft
THEN use ADR to auto-approve and download the binary(s) within its rule base and publish it.
(This step is what the author is referring to in my mind. And what I'm proposing too, but you still need metadata to find updates/binaries you are trying to publish.)
Only using ADR solution will not get the new metadata from the 3-party catalog if you don’t expand its programmed role. Which in my opinion is a bad idea because it’s not ADR’s inherit role to solve.
Highlight – Expand 3-party catalog with Schedule 3-party sync, Use ADR to approve, download and distribute content.
Jason J commented
The whole point of SCCM is automation so having this force a manual step (or multiple) is kind of counterproductive. I like Sean Huggans' idea below with the "Automatically Publish..." checkbox in ADR properties.
Andreas Aufmuth commented
Sync schedule: unfortunately, you are wrong (at least from my experience). I read, that it is synced after every normal update sync. Which is every night for us. But 3rd party was never synced automatically since I've set it up.
But I totally agree with the main request: let us handle 3rd party just the very same way we handle MS updates. Fully sync and let ADR do its job.
Right now, it is more work to publish 3rd party in SCCM than just using SCUP
Gerhard Eriksson commented
- Why not include a "Schedule..." under right-click menu for just that catalog? So you can set different sync schema per 3-part catalog. ?
- why not add same mekanism that's in SCUP with automatic content deployment when required update is example "1>=" ?
Sean Huggans commented
As an alternative to the above, add an "Automatically Publish Third-Party Software Update Content for all software updates found by this rule" checkbox on the Deployment Settings tab in ADR properties. Ex: https://imgur.com/6Ctf0L8