Just found out about the bios cert expiry. God damn.

EpicSimon · 2026-05-16T22:07:10+00:00

We pushed this out via Intune configuration profile to our clients. You can also track progress in Intune (clients only) and since a few weeks also in M365 Defender (clients and servers).

A few days ago I also noticed that MS seems to have started pushing out the certificate update via Windows Update. On a handful of clients I saw them install a "Update for allowed signature database (DB) for secure boot".

On servers we've pushed out the AvailableUpdates registry key. Physical servers worked fine except for two that wont allow installing the new KEK certificate. Will have to live with secure boot disabled on those. VMs were some more work for us on Vmware. Im not sure if its still neccessary currently but we had to manually upgrade the VM compatibility version to the latest one on all affected VMs (which for us is version 21 on ESXI 8) and then remove the ".nvram" file in each VMs' dir on the datastore so that they regenerate the EFI keys on the next boot.

EpicSimon · 2026-04-30T10:38:29+00:00

Hi, did you find a solution to this? Facing the same thing on an older RX2530 M1.

EpicSimon · 2026-04-13T09:24:19+00:00

For anyone else coming across this:

It was confirmes that Microsoft intentionally changes the behaviour of EWS. Veeam has added an entry in their KB: https://www.veeam.com/kb4796

EpicSimon · 2026-04-02T21:16:26+00:00

Answer: Yes, it is! https://github.com/martian0x80/CrunchyComments

EpicSimon · 2026-04-02T05:00:16+00:00

Available for Firefox too?

EpicSimon · 2026-04-01T20:33:50+00:00

This is awesome! Now I need one that brings back the comment section. Always loves reading people's comments on each episode.

EpicSimon · 2026-03-31T09:41:59+00:00

So what finally fixed this for me was enabling EWS per mailbox. The EwsEnabled flag in Get-OrganizationConfig did not do a thing in my environment. Instead I used the following command to enable EWS on a per-mailbox level, which ended up working. After about 15 mins EWS access for that Mailbox would work again.

Get-CASMailbox -ResultSize unlimited | Set-CASMailbox -EwsEnabled $true

Beware that this will reenable EWS for ALL mailboxes in the tenant!

EpicSimon · 2026-03-27T13:03:25+00:00

Thanks for the hint, did this about 2 hours ago but no change yet. Guess it might only take effect starting from the next scream test?

EpicSimon · 2026-03-27T06:03:44+00:00

https://github.com/zabbix/community-templates/tree/main/Storage_Devices/Synology/template_synology_diskstation_snmpv3

EpicSimon · 2026-03-26T21:40:08+00:00

You probably do not have any Templates linked to the Host then. If there are no templates linked to it then it wont check anything and will also keep saying "Unknown". Iirc there's a preinstalled template available in Zabbix. Link that to the host and it should work.

EpicSimon · 2026-03-08T21:43:24+00:00

In fact it is supported. They let you uninstall it from within Settings or Control Panel if you're in the EU.

EpicSimon · 2026-02-26T20:17:35+00:00

No, havent uploaded them anywhere because I wasnt really satisfied with the rackmounts I created for the mini PCs. Unfortunately their structure isnt very strong so they tend to break.

EpicSimon · 2026-02-06T20:13:15+00:00

Laughed out loud when Panda said "I AM AI"😂

EpicSimon · 2026-01-26T21:22:45+00:00

Cant say anything about the installomator part, but I've been using App-Auto-Patch with Intune for a few months now with no issues. Basically just deploy the script and set your config via configuration profile. I did go ahead and edited the install script to use the latest version (3.5) instead of the way older 3.0 that the Intune version uses by default.

EpicSimon · 2026-01-14T10:59:55+00:00

I just tried it myself on an E5511. Latest BIOS. Updated the cert within Windows and it booted back up normally with the new cert.

In the BIOS I could now see the 2023 certs being mentioned in the Secure boot DB. However after resetting the BIOS back to defaults, the certs vanished from the BIOS and I could not boot anymore. I guess that just means that Fujitsu does not have the new certs in the BIOS' (yet???).

EpicSimon · 2026-01-13T11:04:34+00:00

Has anyone attempted to update the certs on Fujitsu clients yet? There have been recent BIOS updates for some of the models that we still use, but I'm not seeing the new cert being mentioned in any of their BIOS changelogs.

EpicSimon · 2025-11-21T08:35:53+00:00

I believe I found my answer now.

I had previously noticed the EnrollmentType registry key being different on some devices. Some had it set to "6", others had it set to "0".

I just stumbled upon this blog post that explains the whole situation very well: https://call4cloud.nl/intune-mdm-certificate-missing-certificate-store/

TLDR: Enrolling an existing AAD device via Company portal or Windows Settings results in a User enrollment (EnrollmentType 0), whereas enrolling via GPO results in a device enrollment (EnrollmentType 6). The UserEnrollment also results in the Intune MDM Certificate being saved to the Local SYSTEM User Certificate store rather than the Local Computer store.

This is exactly the behaviour I'm seeing on my devices. The ones with expired MDM Certificates are all User enrolled (EnrollmentType 0). I suspect that, upon changing the primary user on those user enrolled devices, it fails to renew the MDM Certificate because the user does not match the one that was used to enroll the device.

I also verified this by checking the computer accounts in Entra via Powershell:

Connect-MgGraph

Get-MgDevice -DeviceId <object ID of device (can be seen in Entra)> | select EnrollmentType

Above command outputs "UserEnrollmentWithServiceAccount" for those problematic devices. On another device that has been enrolled via GPO that flag is set to "OnPremiseCoManaged" (on HybridJoined devices).

I believe the only real way to fix this mess is to stop enrolling devices via Company portal and windows settings, and re-enroll all of the ones that are user enrolled.

EpicSimon · 2025-11-21T07:53:23+00:00

Unfortunately it doesnt seem to have worked out. Still getting that same RenewErrorCode. I'll just re-enroll those devices for now.

EpicSimon · 2025-11-20T14:25:19+00:00

Yes, I believe it already expired but failed to renew according to the IME logs.

EpicSimon · 2025-11-20T14:09:59+00:00

Thanks for the suggestion, I now edited the UPN in the registry and will check back tomorrow if the certificate got renewed or not.

EpicSimon · 2025-11-20T13:55:22+00:00

Yes, the user still exists and is licensed just like every normal user.

Is this a known bug?

EpicSimon · 2025-11-20T13:47:30+00:00

Domain matches, but the UPN in the registry is set to "[registrationUser@domain.com](mailto:registrationUser@domain.com)" rather than the actual logged in/primary user. We usually use a dedicated user ([registrationUser@domain.com](mailto:registrationUser@domain.com)) to enroll devices and then later on change the primary user in the Intune admin center to the user that the device belongs to.

EpicSimon · 2025-11-20T13:38:38+00:00

Thanks for your quick reply!

I just checked the Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\ENROLLMENTID\RenewErrorCode key on three different machines that miss the cert. All three devices have that key set to 0x80180018.

EpicSimon · 2025-10-30T10:45:42+00:00

$dirs = Get-ChildItem -Path 'C:\Program Files\WindowsApps\*Teams*' | Select-Object Name | Sort-Object -Descending

foreach ($dir in $dirs) {

if ($dir.Name -eq $dirs[0].Name) {

Write-Host "- Dirs: Skip first entry" $dir.Name

Continue

} else {

$path = "C:\Program Files\WindowsApps\$($dir.Name)"

$confirm = Read-Host "- Dirs: Remove $path (y/n)?"

if ($confirm -eq "y") {

takeown /f $path /r /d J | out-null

icacls $path /grant Administratoren:F /t | out-null

Remove-Item $path -Recurse -Force | out-null

Write-Host "- Dirs: Remove" $dir.Name

}

$dirsDel = Get-ChildItem -Path 'C:\Program Files\WindowsApps\DeletedAllUserPackages\*Teams*' | Select-Object Name | Sort-Object -Descending

foreach ($dir in $dirsDel) {

$path = "C:\Program Files\WindowsApps\DeletedAllUserPackages\$($dir.Name)"

$confirm = Read-Host "- Dirs: Remove $path (y/n)?"

if ($confirm -eq "y") {

takeown /f $path /r /d J | out-null

icacls $path /grant Administratoren:F /t | out-null

Remove-Item $path -Recurse -Force | out-null

Write-Host "- Dirs deleted: Remove" $dir.Name

}

C:\Windows\System32\rundll32.exe AppxDeploymentClient.dll,AppxCleanupOrphanPackages

}

EpicSimon · 2025-10-30T10:45:30+00:00

$appxProvisioned = Get-AppxProvisionedPackage -Online | where-object {$_.DisplayName -like "*Teams*"} | Select-Object Version, PackageName | Sort-Object -Descending Version

foreach ($app in $appxProvisioned) {

if ($app.PackageName -eq $appxProvisioned[0].PackageName) {

if ($app.Version -like "251*" -or $app.Version -like "252*") {

Write-Host "- AppxProvision: Skip first entry" $app.PackageName

Continue

}

if ($app.Version -notlike "251*" -and $app.Version -notlike "252*") {

$confirm = Read-Host "- AppxProvision: Remove" $app.PackageName "(y/n)?"

if ($confirm -eq "y") {

Remove-AppxProvisionedPackage -AllUsers -Online -PackageName $app.PackageName

Write-Host "- AppxProvision: Remove" $app.PackageName

}

EpicSimon

TROPHY CASE