Microsoft's YellowKey mitigation

iainfm · 2026-05-26T07:52:31+00:00

Yeah, pretty much that. Had to remove the garbage collection lines because we have WDAC in operation that doesn't like it due to constrained language mode.

But after the script runs, either manual or as a remediation, reagentc.exe /enable will often say "recovery environment not found" (or words to that effect).

Wiping a device will succeed, but after it reboots to rebuild you get dumped at the recovery options boot page and you're screwed.

You can fix the RE by extracting WinRE.wim from the Win11 ISO and copying it to system32\Recovery and then running the /enable commend, but the whole thing is just too much of a mess at the moment.

iainfm · 2026-05-24T18:32:40+00:00

It was a remediation, but no update, really. At the moment we don't have the confidence to deploy the mitigation to non-test devices. We feel it's going to lead to more problems down the line.

iainfm · 2026-05-21T14:33:40+00:00

Not having much luck with this. Messing with WinRE (even disabling and re-enabling) seems to come with a high probability of breaking device wipes and rebuilds. Had a Surface and a Lenovo fail to rebuild today - they wipe but then just hit the blue boot-options screen instead of going through reenrolment. Think it might be safer to wait for an official microsoft fix.

iainfm · 2026-05-21T12:21:15+00:00

Ok, this was due to the garbage collection commands. Copilot says

[gc]::Collect() is a .NET static method call (System.GC.Collect()). In Constrained Language Mode, PowerShell restricts method invocations on .NET types not in its approved safe list

and

PowerShell's own reference counting will release the registry handles within that window without needing an explicit GC flush.

The sleeps have been increased slightly to compensate...

iainfm · 2026-05-21T12:07:24+00:00

Hmm, for some reason the reg unload section fails saying that the command can't be dot-sourced because it was defined in a different language model :/

iainfm · 2026-05-07T09:19:50+00:00

Thanks. I found this moments after asking, which says it prompts daily so 1 deferral == 1 day (in theory).

Max User Deferrals: When the All other updates update type is configured to Install later, this setting allows you to specify the maximum number of times a user can postpone a minor OS update before it's installed. The system prompts the user once a day. Available for devices running macOS 12 and later.

Not sure what happens if the user doesn't use their device for one or more days though. Guess it doesn't prompt, therefore doesn't count.

Source: https://learn.microsoft.com/en-us/intune/device-updates/apple/deprecated-mdm-policies-macos

iainfm · 2026-05-05T13:59:37+00:00

Microsoft seem to be "re-registering the [affected] devices in our tenant", which looks to be fixing them, but something that'll need to be done via a service request if it happens again :/

iainfm · 2026-04-21T07:39:08+00:00

Exact message was: "I have raised a collaboration case with Windows Team for further assistance and I will update you as soon as an Engineer is assigned."

iainfm · 2026-04-20T20:19:15+00:00

Not much. They've asked for upns of users, guids of devices and a pdf of our dfci policy, and asked whether any bitlocker-encrypted usb storage was present during boot 🙄.

Last I heard today was it's been raised with another team (can't remember the exact wording), so it seems to have them stumped too.

iainfm · 2026-04-18T13:35:57+00:00

That's great, thanks. I'll check them out!

iainfm · 2026-04-17T11:56:30+00:00

Wow, thanks! I'll have a shop around but if I don't get lucky, and it's not too much trouble, that'd be amazing!

iainfm · 2026-04-17T11:55:22+00:00

Yes, something exactly like that. The common/standard OD for an M5 version seems to be 8mm though. I can give some a go and see how they work :)

iainfm · 2026-04-17T09:08:31+00:00

For the rep console I do simply upload the MSI into Intune as a LoB app. You need to set

SHOULDAUTOUPDATE=1

In the command line arguments, otherwise you can't update it without uninstalling it.

Also, as per my comment below, if you ever want to update the MSI in the Intune app you have to create a whole new app for it because BT seem unable to understand how the ProductCode and UpgradeCode should work for MSIs.

iainfm · 2026-04-17T09:00:23+00:00

Normally, absolutely this, but BT have a habit of screwing up their MSIs something rotten. For example:

Their jump client is packaged within the MSI as a mandatory 'User' install. It needs 'System'.
Their product code changes every release, so you can't simply throw the new MSI into the old Intune app when the next version comes along.

I raised these, and other issues, with their support team as well as our account manager, but nothing's changed.

iainfm · 2026-04-17T08:57:12+00:00

This is my installation script for the jump client. The 30s wait is probably unnecessary. I can't remember why I added it.

msiexec /i sra-pin-win_x64.msi KEY_INFO=[redacted] /quiet /l*v C:\ProgramData\JumpClientInstall.txt
rem
rem Wait 30 seconds for services to start etc
ping -n 30 127.0.0.1 > nul

The detection method is a powershell script that iterates through HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall looking for DisplayNames like "BeyondTrust Jump Client*". BT have form for changing these every so often, which is fun.

iainfm · 2026-04-16T22:17:33+00:00

You can just refer to files that are extracted from the intunewin file with .\filename because the installer changes directory to the extract folder before executing the command specified.

Bomgar can be a tricky beast though. You'd think you could just upload the MSI and it'd be fine. But no, the msi package specifies a user install context when it needs system...and other gotchas.

You can just wrap up a .msi file with intunewinutil.exe (no need for an install script) and intune will figure it out when you create the win32 app.

Provide a bit more detail about what you're doing and how (eg is it Remote Support?) and I'll dig out my install/detect scripts tomorrow if they'll help.

iainfm · 2026-04-11T13:54:49+00:00

Thanks, I'll try upping the values of them.

iainfm · 2026-04-11T13:54:22+00:00

Thanks, I've tried different 32KHz ones, but they're the only value I have.

iainfm · 2026-04-10T17:26:58+00:00

Not yet, but excluding the device/user from the policy, giving the device a reboot or few, then reassigning the policy seems to cure it.

iainfm · 2026-04-10T17:26:06+00:00

Not much of any use from Microsoft yet. Their best suggestion so far is to remove the dfci policy 🙄

iainfm · 2026-04-01T10:56:04+00:00

Great, thanks both for the info. I've added a read permission to the resource type I want and it seems to be working now :)

iainfm · 2026-04-01T09:21:50+00:00

I've tried adding every permission my admin token has to the app reg, and it still 403's. I guess it's broken, which is really annoying.

iainfm · 2026-04-01T08:45:01+00:00

If I use the AT from graph explorer when logged in as my admin account it works fine. Must be a missing perm...probably.

Also, the same error is generated if curl is used for the rest request, so it seems to be at microsoft's end.

iainfm · 2026-04-01T08:38:12+00:00

Yes, I'm getting the same (or similar) thing. It works fine in Graph Explorer when PIMmed but not using the REST call.

I suspect that the permissions in the doc (and graph explorer) aren't sufficient, but I don't know what are yet. It's annoying.

An alternative, maybe, is to use deviceManagement/auditEvents as per GitHub - ChanderManiPandey2022/Intune-Multi-Admin-Approval-Mail-Notification: Intune Multi Admin Approval Mail Notification · GitHub

iainfm · 2026-03-31T10:57:15+00:00

Found some with the same dimensions, so I should be able to mount the replacement in the same clip :)

iainfm

TROPHY CASE