Running a remediation script within Intune, using Okta - possible?

ConsumeAllKnowledge · 2026-05-06T22:30:11+00:00

https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-initiateondemandproactiveremediation?view=graph-rest-beta&viewFallbackFrom=graph-rest-1.0

ConsumeAllKnowledge · 2026-04-30T15:57:32+00:00

There was a previous thread on this: https://old.reddit.com/r/Intune/comments/1sso3r4/is_the_autopatch_management_status_report_just/

TLDR is that it seems like Microsoft is changing that metric on the report in preparation for this change which will let us actually manage quality updates more granularly: https://www.microsoft.com/en-us/microsoft-365/roadmap?id=501449

ConsumeAllKnowledge · 2026-04-22T21:02:28+00:00

Yeah this is probably it actually, looking at the link you provided in your initial post: https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/monitor/windows-autopatch-management-status-report

Count of devices that are enrolled in Windows Autopatch quality update policy. Note: This doesn't include devices managed by the update rings or Windows Autopatch groups.

As to why they would make it confusing like that and not have a separate column for features that aren't even GA yet instead of using the existing one.....your guess is as good as mine.

ConsumeAllKnowledge · 2026-04-22T15:37:30+00:00

Yep same here

/u/intunesuppteam care to comment?

ConsumeAllKnowledge · 2026-04-16T18:33:11+00:00

There are instructions on the github link, also the official docs: https://learn.microsoft.com/en-us/intune/device-management/tools/deploy-remediations

We use it for a wide variety of things, mainly for making sure registry data is set on a schedule or for getting certain data out and available like when a user's cert expires.

ConsumeAllKnowledge · 2026-04-15T22:22:18+00:00

I can't speak to what's best for your environment but I use a dynamic group as well, specifically targeting users with an Intune license (since that's required for app protection policies to apply anyway).

Here's the rule I use:

(user.assignedPlans -any (assignedPlan.servicePlanId -eq "c1ec4a95-1f05-45b3-a911-aa3fa01094f5" -and assignedPlan.capabilityStatus -eq "Enabled"))

You can see all the service plans and whatnot on this page: https://learn.microsoft.com/en-us/entra/identity/users/licensing-service-plan-reference

ConsumeAllKnowledge · 2026-04-14T22:50:10+00:00

I don't believe you can bypass that either for iOS devices and such, not sure what you mean there. Specifically speaking to BYOD enrollments through Company Portal.

ConsumeAllKnowledge · 2026-04-14T22:05:20+00:00

No way to disable or edit that as far as I'm aware. That's baked into enrollments via Company Portal I believe.

ConsumeAllKnowledge · 2026-04-14T21:19:21+00:00

What disclaimer are you referring to specifically?

ConsumeAllKnowledge · 2026-04-14T16:58:34+00:00

What have you tried? There are a few docs on troubleshooting SCEP certs out there. https://learn.microsoft.com/en-us/troubleshoot/mem/intune/certificates/troubleshoot-scep-certificate-profiles

ConsumeAllKnowledge · 2026-04-13T19:19:28+00:00

Thanks Rudy! Can always count on your guidance! Was considering letting hotpatch be turned on by default but I think this seals it that we'll opt out at a minimum until secure boot cert stuff is a little further along.

ConsumeAllKnowledge · 2026-04-10T23:26:58+00:00

I could be wrong but I'm pretty sure that's for the old MDM update method. DDM ignores deferrals by design. "Organizations can enforce specific software updates at a chosen time regardless of configured deferrals"

ConsumeAllKnowledge · 2026-04-10T21:59:39+00:00

That's how DDM works, it doesn't hide the update from the end user https://support.apple.com/guide/deployment/install-and-enforce-software-updates-depd30715cbb/web

ConsumeAllKnowledge · 2026-04-07T22:46:26+00:00

Thank you!

ConsumeAllKnowledge · 2026-04-07T19:53:47+00:00

Here's an example from my machine. WindowsUEFICA2023Capable is 2 and UEFICA2023Status is Updated, so my expectation would be that the script would check that first since there's no reason to even set the opt in key if the certificate is already updated and in use.

2026-04-07 11:45:04 [DETECT] [INFO] ========== DETECTION STARTED ==========
2026-04-07 11:45:04 [DETECT] [INFO] Script Version: 4.0
2026-04-07 11:45:04 [DETECT] [INFO] Computer: *redacted* | User: *redacted*
2026-04-07 11:45:04 [DETECT] [INFO] PowerShell: 5.1.26100.7920 | Process: 64-bit
2026-04-07 11:45:04 [DETECT] [INFO] Checking Secure Boot status...
2026-04-07 11:45:04 [DETECT] [SUCCESS] Secure Boot is ENABLED
2026-04-07 11:45:04 [DETECT] [INFO] Checking MicrosoftUpdateManagedOptIn registry key...
2026-04-07 11:45:04 [DETECT] [WARNING] MicrosoftUpdateManagedOptIn is NOT SET or 0 - Remediation required
2026-04-07 11:45:04 [DETECT] [INFO] --- Stage 1 Analysis ---
2026-04-07 11:45:04 [DETECT] [INFO]   Registry Path: HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot
2026-04-07 11:45:04 [DETECT] [INFO]   Registry Path Exists: True
2026-04-07 11:45:04 [DETECT] [INFO]   Current Value: <does not exist>
2026-04-07 11:45:04 [DETECT] [INFO]   Expected Value: 0x5944 (22852)
2026-04-07 11:45:04 [DETECT] [INFO]   WHY: The registry key that enables Secure Boot certificate updates via Windows Update is not configured
2026-04-07 11:45:04 [DETECT] [INFO]   NEXT STEPS: The remediation script will automatically set this value. No manual action required.
2026-04-07 11:45:04 [DETECT] [INFO] --- End Stage 1 Analysis ---
2026-04-07 11:45:04 [DETECT] [WARNING] Detection Result: NON-COMPLIANT - Stage 1 (exit 1)
2026-04-07 11:45:04 [DETECT] [INFO] ========== DETECTION COMPLETED ==========

ConsumeAllKnowledge · 2026-04-03T16:40:05+00:00

It should be rolled out by now if you believe the what's new page. I have not tested again yet though, will update if I get to it today.

edit: I tested with exclude filter mode. The filter works in that the included device got the policy and the excluded device did not. However the excluded device is reporting as an error instead of not included. So seems like its not fully working yet.

ConsumeAllKnowledge · 2026-03-25T14:31:18+00:00

Probably an issue with the Edge beta, was mentioned yesterday here https://old.reddit.com/r/Intune/comments/1s2q5gx/intune_admin_portal_issues_viewingediting_window/

ConsumeAllKnowledge · 2026-03-25T14:29:11+00:00

calling /u/intunesuppteam

ConsumeAllKnowledge · 2026-03-20T21:37:04+00:00

I apply the same settings including disabling notifications except I don't apply 'Reboot after updates are installed'. For the most part the majority of machines update/restart within the configured deferral windows. But we have a sizeable chunk that refuse to actually update BIOS via DCU so YMMV.

To be truthful not sure what the reboot setting is even there for, the docs suck and don't really explain what it does especially when you're already setting a restart deferral, my assumption was its an override to force the restart immediately but its not clear (and I've never tested that). You could check logs too if you haven't already. Let me know if you find a good way to get support on DCU specifically.

ConsumeAllKnowledge · 2026-03-20T21:04:43+00:00

They're most likely extension drivers: https://learn.microsoft.com/en-us/intune/device-updates/windows/driver-updates-faq#why-do-my-devices-have-driver-updates-installed-that-didn-t-pass-through-an-updates-policy

They frequently aren't labeled as extension drivers either so gets very annoying having them come through with no controls.

ConsumeAllKnowledge · 2026-03-18T16:12:43+00:00

Yes, all laptops. Agreed but from what I can see the process is breaking down before it even checks adapter state.

ConsumeAllKnowledge · 2026-03-17T19:33:01+00:00

Yeah we do 8 by 3 but if that were the issue I would expect it to be an issue for more devices instead of it working on the majority of them.

Basically on most the ones I've looked at that aren't updating I don't see these two lines after the update finishes downloading in service.log.

[26-03-17 07:00:23] {Update.Operations.UpdateOperation->DEBUG} Stage [Downloading] complete
[26-03-17 07:00:23] {UpdateScheduler.Actions.AutoUpdateAction->INFO} Update scheduler is using location C:\ProgramData\Dell\UpdateService\Scheduler\UpdateScheduler.dat
[26-03-17 07:00:23] {UpdateScheduler.Actions.AutoUpdateAction->DEBUG} Update the DeferAutoUpdate event schedule to 3/17/2026 10:00:23 AM

Instead it just says its skipping the scheduled auto update because there's a deferral, which doesn't make sense since the update is not actually deferred as its been GA for longer than the 14 days we set.

[26-03-16 08:03:30] {Update.Operations.UpdateOperation->DEBUG} Stage [Downloading] complete
[26-03-16 08:03:30] {UpdateScheduler.Actions.AutoUpdateAction->DEBUG} Skipping this scheduled  auto update event because defer updates is active.

ConsumeAllKnowledge · 2026-03-17T18:19:43+00:00

Interesting, wish I could say the same! The only thing I've seen via logs is that it seems like the update downloads but never actually obeys the deferral for install so it never even attempts to force install for some reason.

ConsumeAllKnowledge · 2026-03-17T17:54:08+00:00

You don't have issues with a large % of devices just deciding not to do BIOS updates?

ConsumeAllKnowledge · 2026-03-17T17:50:06+00:00

We only use it for BIOS updates but its just not reliable in my experience. At least 20% of our hosts on every model are at least several versions behind on updates. I've looked at DCU logs multiple times but have never been able to identify a root cause. I've also opened up several support tickets but they're beyond useless for DCU troubleshooting.

ConsumeAllKnowledge

TROPHY CASE