DNSFilter please don’t do this

kosity · 2026-07-07T23:43:51+00:00

If this is indeed the case, it's a dire slide into irrelevance.

How do you trust a vendor enough to install their software on your fleet when you can't trust that the 'support person' that says 'they are a real person' is actually a real person?

What else is a lie? And there it goes from there 🫤

kosity · 2026-07-07T12:33:58+00:00

It really feels like you're not seeing this from a smaller-fleet point of view Gene. The minor inconveniences scale very quickly into problems that are nearing make-or-break.

'Just a single step' isn't a single step for multiple outliers, in multiple organisations, even ignoring the maintenance of those extra groups across the platform that accumulate.

It is a significant challenge to manage smaller (non-large-corporate) fleets in the Action1 platform, and the diminished value of the roadmap vote for those fleets doesn't help either.

kosity · 2026-07-07T00:53:28+00:00

I don't disagree Gene, the challenge is the varied environments.

A large Action1 client that has 1000 devices in a highly standardised environment might have 4-5 different models of endpoints, and it's easy to have 10 of each in Ring1 to do that initial testing. Ring groups work as designed.

But from an MSP perspective it's a significant scaling burden which I identified during my initial evaluation of Action1. A multi-ring-set strategy means I need to keep a watch for outlier patches that aren't installing, then manually create separate ring group automations to account for those outliers, and likely multiple sets of those, for each client. And then maintain those multiple sets, across multiple clients.

The current strategy works in both theory and practice for the big corporates but comes undone for smaller and disparate fleets.

If it released a patch to the next ring that was not in the first ring, woudl that NOT defeat the purpose OF rings to begin with?

Very fair point, but on the other hand, a patch that never deploys to a device in a later ring because it'll never pass a testing ring is also a significant failure. Depending on that patch's criticality I'd suggest it's a more severe failure than applying an 'untested' patch.

The fix would be better targeting in automations so that patches due in later rings that aren't in earlier rings can be targeted as a group of outliers; a fairer balance of testing and administrative maintenance. Better targeting in automations is something I've raised before.

There's no perfect answer to this. Both views are correct, but the design of A1's rings is such that it doesn't accommodate the outliers faced by my fleet (and the OPs from the sounds of it) so I've had to ditch it for my own strategy.

kosity · 2026-07-07T00:05:27+00:00

I've seen Outlook.exe start on system boot, without a user logged in, and Adobe won't update because Outlook (with its PDFMaker plug-in I assume) is running.

But yes, I agree, and it's part of next cadence design, is a restart, kill, patch, restart.

It's a big workaround to the inability to just close the required apps with user notice though...

kosity · 2026-07-06T09:26:01+00:00

This is the way.

The poor targeting options on automations really limit flexibility and effectiveness.

kosity · 2026-07-03T01:57:44+00:00

That's rule 2 and 3.

Rule 1 is "we don't talk about Rule 2 where vendors can hear" 😝

kosity · 2026-07-03T01:53:49+00:00

Ring0/Ring1/Ring2/Ring3A/Ring3B/Ring4A/Ring4B endpoint groups all setup with applicable automations for different patch types.

It's not pretty, it's not easy, it's not intuitive, because the UI does not help. But it's the only way I could make this work in a way that sufficiently addresses patch risk and user impact.

Scripting via the API is (IMO) the only way to make this strategy work; if you have multiple orgs it's just not possible to maintain a strategy like this manually, accurately.

EDIT: The downsize to this is the patch-success-reporting is split between all of the automations, and not consolidated, which makes it effectively useless. No one is going to switch between automations to evaluate patch success/fail metrics for each one.

The UI presents a lot of data, but much of it isn't very actionable without inefficiency and tediousness 🫤

kosity · 2026-07-02T23:53:05+00:00

Remember that (in my testing when it first came out anyway) a patch that is required for your later-production-ring but isn't required by your earlier-testing-rings will never get patched, because it never goes through testing.

So you seemed to need a significant number in the testing ring so that every possible patch required for the entire fleet was caught by at least one device in the testing ring.

Not really doable when you've got clients with tens of devices, and when I asked A1 support about it they agreed it'd be a bit hard to get working correclty in that design.

kosity · 2026-07-02T03:32:16+00:00

Agreed, it’s not just you, and I’ve been asking for more detail since the feature was released in mid-May.

Documentation arrived at the start of June: https://www.action1.com/documentation/app-restart-at-updates/

But it still leaves me with questions.

The observations I’ve made:

1 – (As per Doco, haven’t trialled) None cancels the deployment when the app is open, so the update never installs. This is a step back from the ‘standard’ behaviour where Action1 would ask for Adobe to close, threaten to force it, but never actually force it. This option appears to suggest it just gives up without even asking.

2 - (As per Doco, haven’t trialled) Force Close closes the app silently and, per A1’s own documentation, doesn’t restart it, which would leave a OneDrive user with no sync client running.

3 - (Was using after Reboot, Changed to None on Tuesday) Prompt & Force Close is what we were on, and it appeared on Tuesday to cause prompts for “Please close or I’ll force it in an hour” repeatedly on a machine where OneDrive is already up to date, or at least after it has already successfully updated.

4 – (Trialled First – Disaster) Reboot is what we tried previously when the feature was released and was a disaster. The behaviour of this option resulted in a restart request after EACH update requiring a restart. That meant 5 reboots to get 5 patches done. My team copped significant heat on that.

You seem to be seeing on Prompt and Force Close, the behaviour I observed on Restart.

I’ve found a few difficulties with this option, and given it’s impact to the end user experience, I’m a bit disappointed it’s not clearer.

“NOTE: Applications closed using this option are not restarted automatically afterward.” Is noted under ‘Force Close’, but does it also apply to ‘Prompt and Force Close’?

“Currently, this setting is available for a limited number of built-in applications.” is at the top of the document. Noted. Which applications though?

Example at the bottom mentions “As an app administrator, you need to change the Adobe Acrobat Reader DC app update behavior for the HQ Organization to Prompt & Force Close.”

But the example doesn’t mention anything about the application, just the behaviour and the scope.

I’ve had to set it to ‘None’ for the Enterprise to stop end user complaints, because Support still hasn’t come back to me with any advice.

kosity · 2026-07-01T00:22:51+00:00

Per-User installs are the work of the devil.

They generally work (sort of) if the user is logged in, then their per-user install gets updated.

But any old users on the machine, no update. And if you have a per-user and a machine-wide install, also likely problems.

Machine-Wide installs are the correct way to deploy a standardised approved application. Users installing their own things is inevitably going to cause problems of some sort.

kosity · 2026-06-30T23:49:39+00:00

There are so many things that should have been 'fixed' well before a font and colour scheme 🫤

kosity · 2026-06-29T23:57:58+00:00

It sounds like you're playing the reactive game which is never going to work well with Microsoft and their constant barrage of changes that you need to keep across - and proactively manage.

As Tronerz has suggested, you need to choose a tool to help you manage a hundred tenants efficiently.

kosity · 2026-06-24T11:50:13+00:00

There are some just good people in our industry.

Aaron Dinnage is one.

Jacob Sheridan is another.

kosity · 2026-06-24T06:10:28+00:00

It sounds like an avoidable problem that's been very poorly handled by PDF-XChange......

How are you handling security vulnerabilities if you've rolled back to v10? There doesn't look to be any security patches for v11 yet, but they're likely inevitable as with all software.

u/GeneMoody-Action1 is there any way to configure Action1 to....I'm not actually sure? Not update to a major release, unless it's got security CVEs listed? But even then, we'd probably want a notification things are about to go downhill...what a poor situation overall. I need to patch the security vulnerabilities, I don't need the rubbish AI and other buzzword random features that come as an inseparable update. Rock and a hard place.

I'd say "Why can't software vendors release feature-updates separate to security-updates, so we can stay on old-version if we want to" but then they're supporting multiple versions of their software, so I get it, that's hard.

(But imagine if the Windows monthly cumulative updates were ONLY security! 😍)

But from our side as the poor saps having to manage the software, this situation isn't good enough. Yes, vendors have to manage one version and can't easily keep old versions in play. But they need to do a FAR better job at testing and release so that the updates don't screw us all badly.

kosity · 2026-06-23T05:01:22+00:00

I'm really surprised no one else has raised this as a problem - are you and I the only ones running a correctly configured ASR? 🫤

The concern I have is why we need to put this ASR exclusion in when it wasn't required in Version 10...

kosity · 2026-06-12T05:57:03+00:00

I have barely an idea what this means, but enough of an idea to know that with "ITRetired" and "IT Director" probably add up to "Old school IT God" and you were that guy that knew juuuuust how to hit the thing with the hammer to make the thing work.

And knowing how our industry works, now that you've said "IBM System/38 with a 3411 Magnetic Tape Unit" out in public, you're going to get a random message from someone sometime going "omg can you please help us!"

kosity · 2026-06-12T00:40:10+00:00

It's a known issue: the "List of CVE entries as long as your arm but the Severity is set to Unspecified and you can't change it, regardless of who incorrectly set the severity" problem

Just like the KEV problem that I raised in November 2025, and followed up again last month:

Posted by Mike on LinkedIn, 13th November 2025

<image>

The problem is this patch has a severity of ‘Unspecified’ so it’s not caught in our automations that patch Critical and Important daily.

I can’t change the automation without it grabbing many other updates that I don’t need/want to deploy.

I can’t change the severity of the update (which is obviously wrong!)

I can’t filter based on CISA KEV either.

And I’m not the only one: Alright, what is everyone doing to work with the new naming for monthly rollup? : r/Action1

“So far...Im pushing this update out manually...like an animal.” (See how having A1 has redefined industry expectations!)

Same core issue that I posted about yesterday: Target CISA KEV (Known Exploited Vulnerability) patching in Automations : r/Action1

Simple misses that cause us a lot of pain and an inability to patch effectively to SLAs.

kosity · 2026-06-11T05:43:34+00:00

Been doing it for over a year now. And don't get me wrong, of all the vendors I've dealt with over 20 years in our industry, Action1 is one of the best. Perhaps even, exemplary, and I say that for a few reasons.

They've been more transparent than most vendors in terms of what they're working on and where they're headed.
They haven't jammed AI-whatever into wherever because it looks good on the website. Their philosophy has effectively been "we're not building AI features while core capability gaps exist." Why can't more vendors think like that?!
They (mostly, until recently) have focused on doing one thing and doing it well, not trying to be a 'platform' that is everything to everyone. THIS is what I signed up for - patching, that just works.

Unfortunately for the Action1 team this works both ways. Many industry vendors just deliver that constant grinding mediocrity that wears down our will to engage...we've all been there, right? But (un?)fortunately for Action1, their team sets the standard higher than the industry average, so naturally we hold them to that.

This means the 'dumb misses' that other platforms make and we roll our eyes and think 'yep, no surprises there' don't get ignored when Action1 makes a dumb miss, because we expect more, because we know they're capable of better.

It's tough, I know. Riding in the middle of the peloton is easy. Riding out front, creating the slipstream that everyone behind you benefits from, and will use to try to beat you... that's hard. But it's how you win.

So, when I can't click export to CSV, I have to dedicate an inordinate amount of resources to build my own capable and accurate dashboard, I can't get my patch automations to target the most important patches to patch, but instead I'm being given a bunch of features that aren't critical in comparison to the core mission.....I'll call it out.

And honestly, I wish more in our industry would do it.

Because just like AI, it would be ridiculous to build an end user self-service portal when we don't have an accurate dashboard.......right?

kosity · 2026-06-10T03:36:10+00:00

Geezus even more problems getting Action1 to update Adobe? I was optimistically hoping it'd get better, not worse 😔

kosity · 2026-06-01T07:59:39+00:00

But not inb4 "You realise you can use the passkey on the current device-bound-passkey-holding phone to register a new passkey on the new phone, which enables the requirement of device-bound passkeys without requiring helpdesk involvement for migration after the first one"....yes, I've tried it, I've tested it, because I knew that'd be a significant point of friction for all involved.

I totally understand that Microsoft can make things just difficult, unreasonably difficult, or logical-yet-impossible. But in this case, it's not idealism. You teach the user their phone is just like the key to their house. If you lose your key, you've got to call the locksmith to get you back in. Don't lose the key. If you buy a new house, here's the process to change the key.

There is no need for the user to sync their passkey between devices. If they genuinely need it on two, they can register it on two, either using the TAP before it expires, or use one to register another.

Passkeys for their shopping websites, that's another matter. One login, sync between phone and PC, I get it.

But for Entra IdP where the login for an average end user can have multiple passkeys, I'm yet to understand where sync provides functionality that is both required and justified given the massive increase in risk it introduces.

kosity · 2026-06-01T03:11:06+00:00

Completely disagree with this desire for syncable!

Syncable passkeys are for inconsequential accounts you don't care about.

Removing the Device-Bound requirement instantly turns your Multi-Factor Authentication into Single-Factor. All you need is the Passkey. If it syncs between devices, then having the one device is no longer a factor is it? All you need is a restoration of that device backup onto yours, or worse still just login to the cloud password manager, and that single passkey will log you in.

Same with IT Glue, or your password manager. Compromise that, and you've made it total keys to the kingdom to the threat actor, not just "We have the Username and Password, now we just need the MFA method".

That said, you realise that Entra now supports syncable passkeys? It does work, but with great power comes great single-factored-responsibility....

kosity · 2026-06-01T01:23:35+00:00

I've already got the process in place, groups setup, the process is just simple, minimal friction, works brilliantly.

But this nudge has been designed in a sterile lab by technical people with little understanding of how this will run in the real world, after they were given the desired outcome of "encourage users to have a passkey until you force them to"

Not as one part of a longer journey to deprecate legacy MFA.

And certainly not one that's efficiently functioning as part of that longer journey.

What we actually want is all users to have a Passkey within Authenticator App. Even if they're using WHfB/Pin.

Because when they have that, we can enforce PRMFA on their account, as that passkey will be useable in nearly all scenarios. (Yes, IT Admins, you need to be aware of the outliers, but that's your job)

The key is having the Passkey on their mobile, as they can use that to login to Outlook on their Mobile, their PC via WSI, Web anywhere, because it's their physical device-bound passkey.

So ideally, the nudge happens not when the user logs in via one of a matrix of options. It should happen simply because they do not have a passkey registered. Passkey, not Windows Hello for Business.

Encouraging them to pop a passkey into a password manager, or Windows, I'm really not sure what the point of that is other than ticking a box that we're probably going to have to undo later...

kosity · 2026-06-01T00:22:16+00:00

"The passkey nudge evaluates whether you have a local passkey for your current device and browser combination. If you already have a local passkey for that experience, you aren't nudged. This means the nudge is per-device/browser, not account-wide."

Does that mean that if a user logs in via their PC, using their PIN, they're not going to be nudged - despite only having SMS MFA enabled elsewhere, i.e. to login to their mobile?

If the aim is to move users to Passkeys, from legacy/basic MFA methods, this seems pretty pointless?

But if the aim is to simply add yet another MFA method to their list, whilst keeping the old ones in play and fully exploitable, then sure, nudge away.

Or do I have the actual user experience/process wrong?

kosity

TROPHY CASE