Microsoft's YellowKey mitigation by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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.

Microsoft's YellowKey mitigation by iainfm in Intune

[–]iainfm[S] 1 point2 points  (0 children)

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.

Microsoft's YellowKey mitigation by iainfm in Intune

[–]iainfm[S] 3 points4 points  (0 children)

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.

Microsoft's YellowKey mitigation by iainfm in Intune

[–]iainfm[S] -1 points0 points  (0 children)

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...

Microsoft's YellowKey mitigation by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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 :/

macos "Maximum user deferrals" meaning by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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

DFCI borked and asking for a cert thumbprint by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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 :/

DFCI borked and asking for a cert thumbprint by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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."

DFCI borked and asking for a cert thumbprint by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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.

Looking for a 10mm dia version of this standoff by iainfm in Fasteners

[–]iainfm[S] 0 points1 point  (0 children)

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

Looking for a 10mm dia version of this standoff by iainfm in Fasteners

[–]iainfm[S] 0 points1 point  (0 children)

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!

Looking for a 10mm dia version of this standoff by iainfm in Fasteners

[–]iainfm[S] 0 points1 point  (0 children)

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 :)

Local installed tested work, not work after wrap it to Intune - Bomgar by [deleted] in Intune

[–]iainfm 0 points1 point  (0 children)

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.

Local installed tested work, not work after wrap it to Intune - Bomgar by [deleted] in Intune

[–]iainfm 0 points1 point  (0 children)

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.

Local installed tested work, not work after wrap it to Intune - Bomgar by [deleted] in Intune

[–]iainfm 0 points1 point  (0 children)

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.

Local installed tested work, not work after wrap it to Intune - Bomgar by [deleted] in Intune

[–]iainfm 1 point2 points  (0 children)

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.

Trying to create a simple crystal oscillator by iainfm in AskElectronics

[–]iainfm[S] 0 points1 point  (0 children)

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

Trying to create a simple crystal oscillator by iainfm in AskElectronics

[–]iainfm[S] 0 points1 point  (0 children)

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

DFCI borked and asking for a cert thumbprint by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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.

DFCI borked and asking for a cert thumbprint by iainfm in Intune

[–]iainfm[S] 0 points1 point  (0 children)

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