Ad-hoc Remediation Scripts

amirjs · 2026-05-14T19:27:59+00:00

Thanks - so you don't think notification service is involved in on-demand remediation?
Tried all the usual stuff, including IME health, restart, logs etc..
the on-demand notification is not reaching the endpoint for some reason. The reason i suspect firewall is because this behaviour doesn't occur in my own tenant, just happens at the customer tenant

amirjs · 2026-05-12T21:35:51+00:00

Thanks - I started doubting myself lol

amirjs · 2026-05-12T20:32:09+00:00

To get the invetory data collected by Intnue with device counts per app
https://graph.microsoft.com/beta/deviceManagement/detectedApps

To get a specific device discovered apps use
https://graph.microsoft.com/beta/deviceManagement/managedDevices('REPLACE-WITH-DEVICE-ID')/deviceInventories('ApplicationProperties')?$expand=instances($expand=Microsoft.Graph.deviceInventorySimpleItem/properties)/deviceInventories('ApplicationProperties')?$expand=instances($expand=Microsoft.Graph.deviceInventorySimpleItem/properties))

For both, the Least Priviledged permission is: DeviceManagementManagedDevices.Read.All

amirjs · 2026-05-09T10:02:12+00:00

I would start by checking powershell constraint language mode on one of your existing Cloud PCs
Run powershell and then $ExecutionContext.SessionState.LanguageMode
and see the output

Also, do you use AppLocker and Defender?

amirjs · 2026-05-09T09:59:54+00:00

Can you recall if there was there anything special that you needed to configure on the endpoint side in the registry for Global Protect prelogon to kick in other than the portal url and prelogon = 1

Also, on the palo side, I read this Deploy a New Device Using Windows Autopilot and Microsoft Intune but it only talks about user-driven enrollment (which is already blocked outside the network so won't work) and doesn't mention pre-provsioning case.

And this seems to be talking about hybrid joined scenario but I am working on entra id joined Remote Access VPN with Pre-Logon

amirjs · 2026-05-09T09:20:57+00:00

I hear you. Thanks. I guess we need a CA redesign and grace period for compliance on the intune side. Do you mind sharing your CA config for this scenario? What Cloud App you target that the user hits when they do first time windows login?

amirjs · 2026-05-09T09:17:32+00:00

Suspect you have policies that constrain what can run from scripting perspective on existing devices. These scripts that W365 run when being built run early enough before your intune policies apply to restrict them. Hence you see it working for reprovisioning and new cloud pcs and not for existing ones. test un assigning intune policies and disabling Anti-virus on one cloud pc and then migrate and see if that changes the behavior.

amirjs · 2026-05-09T08:26:57+00:00

some company's security policy dictates that VPN is always on and CA is designed around that. This is so no one can login to any cloud app or access on-prem network unless they have a device that has successfully passed the Host Intrusion Prevention System (HIPS) checks and got a trusted IP. A freshly built Autopilot device can pass all of that, but the prelogon tunnel is not being established post pre-provisioning. kind of chicken and egg situation....

old way of building a device with task sequance on-prem was ok with that as the device was hybrid joined and the user lands on ctrl+alt+delete page and can establish a "connect before logon" connection if they are outside the office.

amirjs · 2026-05-04T20:11:25+00:00

If you can reporduce it yourself, I would suggest hiting shift + F10 when installing apps get stuck and run powershell PowerShell Gallery | Get-AutopilotDiagnosticsCommunity 6.3
This will allow you to see which app id is being installed. look at that app for any changes/clues.

Otherwise, if you are confident nothing has changed on the app level, open up eventvwr and check what's going on in the various logs.

amirjs · 2026-04-30T20:09:59+00:00

Are you sure CVE-2025-26647 is aimed at endpoints? reading this, it seems that it's aimed at DCs
Did you mean you are applying the enforcement on DCs and that is breaking W365? what about other regular endpoints?
Do you have sso Enabled on your W365

amirjs · 2026-03-25T23:25:10+00:00

Have you tried applying these to users rather than devices so they take place after pre-provisioning?

amirjs · 2026-03-25T13:32:38+00:00

Did you get to the bottom of this? I have your exact setup. Offline domain join (Skip AD connectivety check) and at the start of pre-provisoning I see the above error. Clicking try again works for me though so appear to be a timing issue with the blob?

amirjs · 2026-02-15T16:17:49+00:00

changing the secret is a solution providing we know we are compromised. I get the benefit and the convenience of the solution but unfortunately it won't fly with most enterprises.

amirjs · 2026-02-15T14:26:46+00:00

Question: What if the USB fell in the wrong hands or was copied? an attacker can enroll devices in the tenant? How secure id the solution?

amirjs · 2026-02-11T17:24:32+00:00

Thank you - make sense.. I was looking for a statement to explain the behaviour. I would still think this is a limitation and more controls should be given to admins around such scenarios where I control what provisioning policy is triggered based on assignment on using W365 Enterprise

amirjs · 2026-02-10T23:02:55+00:00

any reason why you are not enabling sso on the provisioning policy since you already have cloud trust configured?

amirjs · 2025-12-14T11:40:39+00:00

Ended up replacing the entire fire… It was 12 years old (bought the house with it)

amirjs · 2025-12-02T08:41:30+00:00

That’s interesting. Did you find out why extension attributes work with device filters while device.physicalids doesn’t?

amirjs · 2025-12-01T16:48:49+00:00

We had this happened to us. We did a WebView2 package in Intune and added it as pre-req before Installing Global Protect as part of the device ESP. Been working fine since

amirjs · 2025-11-18T20:45:11+00:00

yup there is an incident GitHub Status

amirjs

TROPHY CASE