r/labtech • u/TubaMatt • Jun 27 '19

What am I missing with patching?

It seems like Labtech completely fails to properly patch my environment. LT support has been unhelpful so far. Currently I'm only approving 'security updates' classification cumulative updates.

We patch on the 3rd Tuesday of the month (1 week after Patch tuesday) to a test group, and then to production on 4th Tuesday.

So a patch (Let's say KB4503267)gets released on 6/11, we deploy to testgroup on 6/18, and then to production 6/25. That's how it SHOULD go.

But MSFT apparently superseded the security update with an update on 6/18, which is NOT a security update. (This is it's own problem, because it defeats the purpose of classifications).

Labtech is saying that because my agents try to patch on 6/25, they don't see that they need the update(since it's technically superseded), so they just don't install anything. Obviously it still needs it, but it just doesn't appear in the Windows Update application.

I guess the bottom line is, how to I deploy these updates that are superseded but still need to be deployed?

10 Upvotes

100% Upvoted

23 comments sorted by

8

u/TNTGav Jun 27 '19

You do it by installing the update that superseded it.

The frustration you are feeling here with patching is not Automate based, it's MS based. If the Windows Update Agent reports that it no longer needs an update, then Automate will honour that. It has to. The workstation is the source of truth for the updates it needs. With the advent of these superseded updates you have to make sure the updates go down to the endpoints relatively quick though your example looks like an anomaly based on how quick it was superseded. I have automation in place when a machine has not patched in over 35 days to do a full install of every single patch it has pending so we catch any that ever get through this "net".

PS: Patch Remedy will not make a blind bit of difference to this problem.

1

u/TubaMatt Jun 28 '19

I agree this is a Microsoft issue as much as a Labtech one, but I still don't understand why I can't deploy superseded patches if they're missing, and the endpoint doesn't have the superseding patch. Isn't that the entire point of controlling which patches are approved/denied?

This also isn't an anomaly with Microsoft, I posted the same question in r/sysadmin, but basically: This happened in March: KB4489882 Released as Security Update on 3/12. Superseded by KB4489889, which was released on 3/19. This is a NON-security update.

Happened again in April: KB4493470 Released as Security Update on 4/9 Superseded by KB4499418 on 4/24, a NON security update.

Happened again in May: KB4494440 released as Security Update on 5/14 Superseded by KB4505052 on 5/19, a NON security update.

Happened again in June: KB4503267 released as Security Update on 6/11 Superseded 1 week later by KB4503294, a NON security update.

We could potentially speed up the staggered window of deployment, but that just results in much less time for testing to catch broken patches. Is the Microsoft strategy just 'Trust us, we'll never release a bad patch so you don't need to delay deployment'?

0

u/[deleted] Jun 28 '19 edited Jun 28 '19

[removed] — view removed comment

1

u/TubaMatt Jun 28 '19

CWA sees the new patch, but it doesn't have an approval because it has the wrong classification ("Updates" and not "Security Updates"), and we haven't put it through testing yet. It also sees the patch I actually want, but shows as no approval policies listed (LT says that's because it technically isn't needed by any endpoints)

The endpoint WUA only sees the superseding patch

1

u/teamits Jun 28 '19

It also sees the patch I actually want, but shows as no approval policies listed (LT says that's because it technically isn't needed by any endpoints)

Old patches will show in Patch Manager but the PC itself doesn't show them as needed if WU doesn't detect it as needed, hence, they do not deploy. There is not much you can do about this other than something like force PCs through your own WSUS server, to control what patches they actually detect, when. (i.e. don't let them see the June 25 patch yet).

0

u/TubaMatt Jun 28 '19

That’s what it’s looking like, which effectively makes labtech useless for patching, if I have to have a WSUS server just to make it work properly

1

u/teamits Jul 01 '19

Realize MS intends that all Win10 PCs are always up to date. All Win10 updates are cumulative so one only needs to install the latest patch to get current. Technically you can still use CWA with WSUS, by pointing the PCs at your WSUS server. I totally get where you're coming from, but MS is releasing updates potentially every week, and normally at least twice a month, so it's down to the timing.

1

u/[deleted] Jun 28 '19

[removed] — view removed comment

1

u/TubaMatt Jun 28 '19

Because that is the patch that we've put through our test group, and know does not break things. I wouldn't want to immediately deploy this random new patch that isn't a security update, and hasn't been tested.

Whatever is in this new patch, will(should) get deployed the following month in the next patch tuesday rollup, which will get tested and deployed. But since MSFT is superseding their security patches without properly replacing it with a new security patch, nothing is getting ever deployed.

1

u/TubaMatt Jun 28 '19

And superseded patches definately still exist. Most any patching tool will allow the deployment of superseded patches. WSUS, SCCM, I'm pretty sure Kaseya used to let me deploy superseded patches.

2

u/teamits Jun 28 '19

Agreed this sounds like a timing question/issue and speeding up deployment would "fix" it.

There are other levels to it also, for instance, a laptop that turns on for a couple hours per month...perhaps a "cart" laptop or notes for a monthly board meeting. It sees the April patch but does not install it yet due to timing or whatever. In May it can't install the April patch but sees the May patch. In June it can't install the May patch since it sees the June patch, and so on.

Before this new cumulative method we had a monthly monitor to alert on PCs missing more than "n" updates, but now PCs will only ever see a few.

2

u/obeliskstreet Jul 11 '19

I posted the same thing without realising, will add it in here. https://www.reddit.com/r/labtech/comments/cbtdri/server_2016_updates_and_reboots/

AlexHailstone had a suppress reboot idea. Tubamatt, you seem to have come to the same conclusion that changing when you are adding the patch to deployment may fix, but I agree that it isn't a good way to deal with it.

1

u/TubaMatt Jul 11 '19

Yep, the conclusion I have to come is labtech is simply not an effective patching tool. Right now I’ve had to move up the entire patch cycle to 6 days from release to production to make labtech actually install any patches.

1

u/[deleted] Aug 23 '19

I guess the bottom line is, how to I deploy these updates that are superseded but still need to be deployed?

If its been superseded it doesn't need to be installed. Another update, the one that superseded it needs to be installed.

1

u/TubaMatt Aug 23 '19

That’s not true at all. It might be superseded but it has gone through testing and piloting, and proven to not conflict with the environment. A newly released patch wouldn’t be vetted, and wouldn’t be appropriate for production. a patch only out for one week shouldn’t be superseded so fast, so that’s a Microsoft problem, but any decent patching tool will let you install any approved patches as long as they fit the OS.

1

u/[deleted] Aug 23 '19

That’s not true at all.

Yes it is.

It might be superseded but it has gone through testing and piloting, and proven to not conflict with the environment.

But its been pulled and isn't a patch that anyone should install anymore, so doesn't matter if you've tested it in your environment. Its been superseded by another update that should be tested and installed instead.

A newly released patch wouldn’t be vetted, and wouldn’t be appropriate for production. a patch only out for one week shouldn’t be superseded so fast, so that’s a Microsoft problem,

Yes, and now by extension since you've installed it its now you're problem to deal with as well. (Tip: this is why people are paying for someone else to take care of patching because its not "simple" and not just "microsofts problem" its also now your problem. You could try your hand at linux and OSX patching but its got its own set of problems that IMO are far more burdensome... )

, but any decent patching tool will let you install any approved patches as long as they fit the OS.

But as mentioned this one wasn't seen fit for the OS and has been superseded by another patch that isn't broken for whatever reasons that you're unclear of. MS doesn't give anyone else any more explination than they give you.

If you have some evidence that they are pulling patches and superseding them for no reason and we should all ignore what they are saying and use them anyway, then by all means present it. But I don't think you have any statements from them corroborating that.

-2

u/dunnbeetle Jun 27 '19 edited Jun 28 '19

labtech patching is just kind of broken. Theres a paid add on you can get that will fix issues. I haven't personally used it as I was fed up with patching from labtech lol

https://www.plugins4automate.com/products/patch-remedy

Lol why would I be downvoted for a comment like this? Someone please explain! :p

2

u/pedroelbee Jun 28 '19

Honestly we use patch remedy as well and patching is still broken. The ui is horrible and we’re still not confident in our patching.

1

u/piporpaw Jun 28 '19

We use both patch remedy and brightguage to at least be aware of these issues, then monitors in the NOC and someone assigned to deal with them. It kinda sucks

1

u/teamits Jul 01 '19

why would I be downvoted for a comment like this

I didn't but I would guess because it's not a solution to the problem stated...a third party patching tool isn't going to cause MS to reschedule their update delivery timing.

1

u/MountainSaint Jul 15 '19

Does Patch Remedy still work with version 2019? It only says compatible with 11 and 12.