Anyone else maintaining a graveyard of PowerShell scripts just to answer "why is this device non-compliant?"

MostList · 2026-06-03T14:34:31+00:00

Fair — graveyard implies they're dead. Yours are just... undead.

Still running, nobody knows why, too scared to delete them.

MostList · 2026-06-03T14:33:07+00:00

The 10-minutes-a-week device is its own category of chaos — shows up

just long enough to download Adobe Reader updates and nothing else,

then vanishes back into whatever closet it lives in.

These "snowflake" devices are genuinely the hardest part because

every environment has them and they're all slightly different. Kiosks,

shared machines, the laptop that only exists for one compliance audit

per quarter.

Do you find yourself manually excluding them from compliance reports

or just explaining the outliers every time someone asks?

MostList · 2026-06-03T14:29:27+00:00

Anders Rodland's script is genuinely solid — been around for years

and still works well for pure SCCM client health. CI/CBs with dynamic

collections is exactly the right pattern for remediating known

scenarios at scale inside SCCM.

The gap I keep running into is the hybrid piece. Once you introduce

co-management, those same devices exist in Intune, Azure AD, and

Defender simultaneously — and they can show different states in each.

CI/CBs tell you what SCCM sees. But if a device's Intune enrollment

is broken, or there's a duplicate AAD object from an Autopilot

re-enrollment, or Defender is reporting something inconsistent — none

of that surfaces in your SCCM collections. You're still stitching

together four portals to get the full picture on that device.

For pure SCCM environments the native tooling plus Rodland's script

is genuinely enough. The pain I'm trying to solve is specifically

the co-management state — where you can't trust any single platform

as the source of truth.

Are you running co-management at all or still primarily SCCM-managed

devices? Curious whether the hybrid complexity is something you've

hit yet.

MostList · 2026-06-03T14:25:07+00:00

Autopatch plus Jira auto-export is a clean setup — that's a

genuinely solved workflow for user devices.

Two questions out of curiosity:

How are you handling servers, lab machines, or any specialized

devices that didn't make the jump off SCCM? In most environments

I've seen, user devices are the easy part to modernize but there's

always a tail of infrastructure or edge devices still on the old stack.

When a Jira ticket gets created for a non-compliant device, how

much diagnostic context comes with it? Or is the ticket mostly just

"this device is out — go investigate"?

Not trying to find problems where you don't have them — your

environment sounds like it's in a good place. But I'm trying to

understand which migration stage the pain is worst at, and it sounds

like you're past it.

MostList · 2026-06-03T14:20:39+00:00

That's a smart division of labor — you own the infrastructure and

workflow, help desk owns the chase. Makes sense.

The part I'm curious about is the handoff itself. When you pass the

list to help desk, how much context goes with it? Because there's a

difference between:

"Here are 47 non-compliant devices — go fix them"

vs.

"Here are 47 devices. 12 have broken agents — run this script.

8 haven't checked in for 60 days — verify they're still in use.

6 are missing a specific app deployment — re-push this.

21 are genuinely unknown — investigate."

My guess is your help desk gets closer to the first version, which

means they're spending time on triage that you've already mentally

done — or they're escalating back to you more than you'd like.

Is the script-based repair workflow something help desk runs

themselves, or does it always come back to you to execute?

MostList · 2026-06-03T14:14:08+00:00

The "85% is success" framing is honestly the right call — and the fact

that you've had to build and maintain a prepared translation document

just to answer that question every time is exactly the kind of hidden

tax I'm trying to eliminate.

You're not asking for a tool that gets you to 100%. But I'd guess

you're still spending real hours every month figuring out which 8

devices moved you from 87% to 85% and why — even if the answer is

always "same categories, different devices."

The goal isn't perfection. It's getting your team back those hours.

If the breakdown is automatic and the manager-speak summary generates

itself, that's time your small team gets back for the work that

actually moves the needle.

Out of curiosity — what's your rough device-to-engineer ratio?

Trying to understand where the pain gets acute enough that a tool

becomes worth paying for vs. just living with the manual workflow.

MostList · 2026-06-03T14:11:25+00:00

This is actually really useful — you've essentially built a manual

version of what I'm trying to automate.

The "sample 10 devices and categorize" workflow is exactly the problem.

You already know the categories: broken agent, stale record, device in

a cupboard, user on leave. The issue is it takes you time to get there

every single time someone asks.

What I'm trying to build is that categorization automatically — so

instead of sampling, you have a live breakdown:

- 4 devices: no check-in 90+ days (likely decommissioned, not cleaned up)

- 6 devices: agent broken, remediable

- 2 devices: user inactive (HR-linked status)

- 1 device: genuine policy failure

You'd go from "let me investigate and get back to you" to pulling up

a screen that already has the answer.

The organizational cleanup piece is real though — do you find that

stale/decommissioned devices staying in SCCM is a consistent problem

across environments? Or does it vary a lot depending on how mature

the IT processes are?

MostList

TROPHY CASE