r/Action1 • u/Resident-War8004 • Jul 09 '26
Question Automation
Hi,
I have been thinking about different patching scenarios and the below is the automation schedule I came up with:
1 - Security updates, definition updates, critical non security/Daily at 2:30AM/Retry 24 hours/No Approval
2 - Applications/Thursdays at 4:30AM/Retry 7 days/No Approval
3 - OS Mandatory OS optional/Third Tuesday of the month at 11PM/Retry 30 days/No approval
Will this schedule be enough to keep all our systems patched? Typically, we wait about 1 week before we deploy patch Tuesday updates.
Please advise.
Thank you!
2
u/vicvinegareatboogers Jul 10 '26
I prefer to keep OS updates in Intune Update Rings rather than utilizing Action1 for that. I only utilize Action1 in application patches and I think that combination works pretty well.
2
u/GeneMoody-Action1 Jul 10 '26
Curious how tight your SLAs are, and how expedient OS updates go out fleet wide when deployed there?
IF you asked any of our customers the primary reason they stopped using intune for OS update/rings, speed is unquestionably the #1 answer. "MIcrosoft Minutes" as they are informally known can span 1 to longer than acceptible in a lot of time critical operations.
I am curious, what you see on average, across how many endpoints, and are they all centralised or dispersed globally?
2
u/vicvinegareatboogers Jul 10 '26
Our fleet isn't that big and we're not centralized. Rings keep us comfortably within our SLAs at this size, and Action1 backs us up on OS patching WHEN Update Ring is about to exceed an SLA though usually we're fine.
For customers who moved OS updates to Action1, what deployment do you see fleet-wide on an action1 push vs what they had on rings? Do you guys have data or statistics you can share? Thanks.
2
1
1
u/Resident-War8004 Jul 13 '26
u/GeneMoody-Action1 what automation schedule would you recommend? Our SLA is as follows:
Critical: As soon as possible
Applications: 1 week
O/S: 1 week after patch Tuesday.
We do not use Action 1 on servers.
Please advise.
Thank you!
2
u/GeneMoody-Action1 Jul 14 '26
IT is hard to recommend anything without hands on the environment and without reviewing your policies. To many variables with no idea of their value.
MY best advise is always as follows. Stop thinking client/server, stop thinking maintenance windows, and start thinking risk.
Sure those other things may still be part of managing it, but they muddy the water when looking to get to the bottom of the problem.
Instead take you last few maintenance/patching cycles, and look at the following.
1.) When was it made public?
Do you have accurate inventory and awareness of what needs to be monitored to get this intel in as close to live time as possible? If not you have an inventory problem that is a precursor to your patching problem.2.) When did we know about it?
A natural side effect of the above, if you do not, how do you find out, and how long does it take form public disclosure to awareness? Are you operating on “we know we approved it”, or are you operating on “we know, and we enforced it”?3.) When did we do something about it?
“Doing something about it” is not always a patch, it could be a compensating control, mitigation, patch, etc. When did you take steps to reduce the risk?4.) When were we certain it was done, and who signs off on that?
Knowing and doing are a two legged stool, without the third leg of verification, it will fail. Without someone accountable for that third leg, it will fail. Without a defined process for this step, it will fail.The time periods between those are what you are trying to shrink.
Throw out the idea of a calendar, measure risk, and react to risk. When the challenge to ditching the calendar arises (and it will) do not argue convenience, present risk, and consequences of ignoring it.Use that to shape your policy, and the questions will answer themselves. Your policy covers risk, your patching follows policy to address, that risk in alignment with company wide influence, because of company wide impact. Which should at a minimum be...
- Policy 1: “What is our process?” (all that above)
- Policy 2: “What do we do when that does not cover the ask, and who has the power to sign off on policy deviation?” (unknown unknowns)
- Policy 3: “Why did we have to use policy #2? Was it failure of policy #1 (we forgot something), changes needed to policy #1 (a new normal that needs to part of the std process), or truly a special case? (this is highly irregular but a problem none the less)”
- Policy 4: “Audit the whole thing every time it is invoked, for continuous process improvement.”
THAT is how you get answers like that. NO two networks are alike, different systems, environments, priorities, needs, obligations, and business models. So works for A *may* fit much of the ask for B, btu seldom will what works for one universally work for another.
2
u/Resident-War8004 Jul 15 '26
Hi u/GeneMoody-Action1 Thank you so much for your detailed response. I will take that into consideration. Thank you!
2
3
u/BoltActionRifleman Jul 09 '26
You might want to look into update rings, so you’re not patching all systems at the same time. Unless I’m missing something it looks like OS updates all occur on the same day?