SCCM Third-Party Software Update Catalog Expired updates

[wokkeltje]

I notice an issue with the patch catalog (since the order is still pending in our administration, I use the Trial Catalog to get used with the system, so excuse me if the issue is only related to the Trial catalog).

Let me explain: we deploy patches once a month, and only once a month except some urgent emergency reason (day after MS Patch Tuesday) all the approved patches follow a couple of stages (available on test machines for 5 days, accept machines the 7 days after test phase and another week later, all our production machines)

Now with 3rd party patching using the PatchMyPC catalog we experience that the patches in the catalog not contain superseed info. For example the moment a new Google Chrome update becomes available and SCCM did the sync of the catalog, the previous update immediately expires. This means that our production machines never receive the Chrome update since the available time of the approved update is past the expire date.

I know that you should always deploy the latest version, but since we use Chrome in a production environment, a new version need to pass the test/accept stage.The same for Java updates and so.

Can the catalog be expanded with the superseding info the same way MS is providing their patches? Chrome version 70 superseeds verion 69.
In SCCM you can define the time before a superseeded update gets expired to get rid of old versions.

thanks in advance

[Justin Chalfant (Patch My PC)]

We expire the updates rather than supersede. We may change this in the future though depending on customer needs. You can choose to delay expiring the updates that are replaced by newer updates from the advanced tab of our publishing service. You can keep updates active for up to 30 additional days after we expire them in our catalog.

[wokkeltje]

thx, but I do not use the publishing service, I use native Third Party Software Update Catalog in latest SCCM build.

It would be nice to have supersedence, this is what updates are, they superseed the previous version.

[Justin Chalfant (Patch My PC)]

Thanks for the feedback!

[john.lozon]

Piggybacking on this thread since we are also evaluating Patch My PC via the Trial Catalog, and have similar testing and deployment requirements. I'm wondering, if we download and deploy an update from the catalog (Chrome, for example), and the update gets marked 'expired' via a catalog update because a newer version becomes available, will the original update still continue to deploy? Would we be able to finish deploying the now 'expired' version?

It looks like updates that are marked as 'Expired' can no longer be downloaded and deployed if they weren't originally, but I'm wondering what happens to existing content and deployments when the catalog sync happens and the metadata changes to 'expired'.

[Justin Chalfant (Patch My PC)]

Expired updates won't deploy anymore to clients and will be removed from ConfigMgr on a schedule.

[john.lozon]

Thanks for the reply - is there anyway to manually unexpire a third party update from the catalog and have it remain unexpired after future syncs? Or are there any immediate plans to switch the catalog to use supersedence for third party updates?

We've had a lot of success with the trial catalog in our proof of concept testing and have been considering Patch My PC for production use, but the current expiration workflow wouldn't work for us

[Justin Chalfant (Patch My PC)]

The best way today is to use the publishing service rather the SCCM 1806 for the publishing piece that would allow the delay of publishing expired updates. I expect if we don't hit any issues moving from an expired to superseded model that may be within a month or 2.

[quackpatch]

+1 for the superseded model as we create new SUGs each time the ADR runs and it could be over a month before even hitting some systems. The defer expiration of updates model could work for us, however there'll be some exceptions whereby we'd need the 30 day limit increased to 60 days, say.

[elangeland]

A model where updates are superseded for at least 47 days before being expired would be very helpful, as we have encountered the same issues with updates being expired before we can complete our deployment cycle.
Our solution (using the new SCCM 1806 publishing) has been to unsubscribe the catalog after publishing and downloading the updates. However, I have a suspicion this process is leading to errors with some updates. WinSCP in particular is giving us error 0x80070002, "The file you specified could not be found. This may be because it is not signed." Others gave this error in October, but seem OK after getting newer versions in November or December.

By the way, the 47 days is to cover up to 5 weeks (35 days) between monthly patch Tuesdays (for a patch released just after the start of one month's patch cycle) plus the 12-day duration of our deployment sequence.

[Justin Chalfant (Patch My PC)]

I have a suspicion this process is leading to errors with some updates. WinSCP, in particular, is giving us error 0x80070002, "The file you specified could not be found. This may be because it is not signed." Others gave this error in October, but seem OK after getting newer versions in November or December.

The WinSCP wouldn't have anything to do with the expiring/supersedence model. WinSCP does have a few second redirect for the actual download. We have seen a couple customers where this causes the download of the EXE to not actually complete. Shoot us an email support@<ourdomainname>, and we could take a look.

[Justin Chalfant (Patch My PC)]

we changed to a supersedence model in today's catalog update

https://patchmypc.com/moving-to-supersedence-software-update-model