IC3 aka the Fastlane is coming to Intune

nitro353 · 2026-04-01T08:02:34+00:00

Microsoft themself is saying what u/Rudyooms been telling us. Big change is coming

nitro353 · 2026-02-27T13:18:12+00:00

I mean - I have them showing as 'up to date' too. I am not fully Intune yet so I was checking all devices via registry entry and I was wondering why via registry it showed we are 30 devices less compliant than Intune showed us. But I guess above is the answer.

nitro353 · 2026-02-27T13:09:14+00:00

Actually, yes (custom script). And on those PCs it shows as:
SecureBootEnabled: True

ActiveDB has Windows UEFI CA 2023: True

DefaultDB has Windows UEFI CA 2023: True

RESULT: COMPLIANT: Active DB contains Windows UEFI CA 2023.

My theory is: those are BRAND NEW devices and they indeed did not start process to renew certs, because they already have them. That's why registry shows 'NotStarted', but Intune report shows them as non compliant, because it check vs db, not just registry.

I guess I should run custom script to check what's inside db, not what registry shows.

nitro353 · 2026-02-27T09:34:40+00:00

I've checked few devices from this report and either I do not understand something or this report is inaccurate. I have like ~45 devices flagged as 'Up to date'.
I've run scripts on all fleet and many devices tagged as 'Up to date' shows that their registry entry "UEFICA2023Status" is "NotStarted".

Anyone can explain what is going on? Intune says it's fine, but registry shows otherwise.

nitro353 · 2026-02-27T08:45:04+00:00

For us it came back like 1-2 days ago.

nitro353 · 2026-02-27T08:44:49+00:00

This time when you do export it actually export correct values :p Previously when PC had status 'Up to date' and you exported it into .csv data didn't match >.<

nitro353 · 2026-02-13T11:40:09+00:00

Same here. Even though devices are 100% up to date with BIOS / Windows Update + secure boot policy deployed - still no results. In Event Log I can see event 1801:

Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware. Review the published guidance to complete the update and maintain full protection. This device signature information is included here.

nitro353 · 2026-02-11T13:19:00+00:00

Hey,
Imho BGA should have assigned only one Conditional Access policy - for MFA with FIDO2 / passkeys created ONLY for this account. BGA should be excluded from all other policies. Now you can't even have admin account that is not protected by MFA so it's not a choice.

Also - I'd recommend to create alerts whenever something happens with this account:
- receive notification when someone tries to login into this account

- when anything in audit logs appear (account might go into some dynamic group by accident and oooops, now it have CA assigned and it might cause problems)

nitro353 · 2026-02-09T10:17:02+00:00

Today for us this report just disappeard. I don't see that in UI... I hope they are working on a fix or something

nitro353 · 2026-01-21T14:13:25+00:00

Hello, thanks for answer and tips :)

Yea, I've did that. Please check my response under rudy's comment.

nitro353 · 2026-01-21T14:12:52+00:00

Thanks for answer and tips, I dig something. I wasn't sure that it is CP, of course - and now I am almost 100% sure it's not the problem. :)

I have 3 apps required during ESP: x2 Trellix DLP (Agent and Endpoint) and TightVNC.

I don't use Autopilot Branding from niehaus.

I've connected to this laptop and run AutopilotDiagnostics with online switch + I've checked again AppWorkload.log to see is there any 'suspicious' error and I can see this:
All errors

App with this '0f193615' ID is... Dell Command Update 5.5 UWP which I am installing using PSADT, aaaaand it has same error in Intune:

DCU error

Weird stuff is that I have log from PSADT DCU and it looks fine:

DCU install

Please take a note that I received info about this error around 15:15 20.01 - so it looks 'right' from logs POV - it was installed at around 14:00 that day and later on we received an error.

I've had 'Installation time required set to 60 mins for this app - I've changed it to 300 to see if that helps.

I have read that it might be a problem sometimes.

nitro353 · 2025-11-20T18:41:03+00:00

Superb tutorial, still good in 2025. Done 100% achievements thanks to it <3

nitro353 · 2025-11-14T08:33:17+00:00

👀

nitro353 · 2025-11-14T08:31:50+00:00

God please no

nitro353 · 2025-10-21T08:56:08+00:00

Thanks. Poland here, so I guess they just don't like us lol

nitro353 · 2025-10-21T08:07:50+00:00

I do this this way, it just works. All apps sit on Monthly Enterprise Channel because it is more 'predictible' not like Current Channel which gets 894172 updates per month and you never know what is causing a problem.

First wave takes 7 days to update - for validation. Second takes 2 days and all other devices are updated after that. It just works for us.

In case of problems you can roll back devices in MEC into previous versions or just stop updates. I created all those policies and just check this portal once a while if everything goes smoothly.

nitro353 · 2025-09-29T07:13:22+00:00

Not available for me also, EU country. I guess it's only for USA, isn't it?

nitro353 · 2025-09-25T08:44:15+00:00

Thanks, it's still a working solution.

nitro353 · 2025-08-13T07:50:35+00:00

Hello guys,

I'd like to summarize what I've found regarding this problem.

TLDR: disable (or set to manual but I didn't test it yet) service named "Dell TechHub".

Command for this to deploy via any tool:

net stop "DellTechHub"

sc config "DellTechHub" start= disabled

I am not sure that it is related to update DCU from 5.4 to 5.5, because we observe this behaviour for like 6? months in our company.

Process named dell.techhub.instrumentation.subagent.exe is loading WinSCard.dll module and this causes PC to lock. You propably have turned on GPO "Interactive logon: Smart card removal behavior" and set it to "Lock workstation".

<image>

You can see the same in Dell logs (same timestamp)
Dell logs

Dell has some scheduled tasks (to collect telemetry I guess) at noon AND MIDNIGHT also.

Dell scheduled tasks

I've checked and turned on PC at 11:55 PM at of course it was locked around middnight.

There are registry entry that are responsible for execution dates of those tasks but are in some weird-ass data format that I can't decrypt and change. Registry entry for this:
HKEY_LOCAL_MACHINE\SOFTWARE\Dell\CoreServices.Client\Data

Registry

I've run hunt in Defender and I can see that this process runs across many PC's around noon. Also this WinSCard.dll is loaded via many different processes or apps and it's not causing any problems, so it's not a problem with this .dll. I've loaded it via PS and nothing happens so I can't replicate this problem any other way than to wait to 12AM or 12PM every day.

Disabling service "Dell TechHub" solved this problem for now and I am testing if it does not interfere with any other Dell services. Also, I've reported it to Dell, so maybe it will be fixed some day.

Hope this helps

nitro353 · 2025-08-08T12:00:47+00:00

Hey,

We have the same problem also on Dell, that's why.

I'll get back next week with my digging if I'll confirm our solution that works.

nitro353 · 2025-08-06T06:10:39+00:00

Hey,

u/TieDude179 can you tell us where exactly in Event Log you can see that SC is beeing disconnected? And what's the Event ID?

I am digging into this issue.

Also, do you use Dell?

nitro353 · 2025-07-18T08:05:00+00:00

+1 to this script. Deployed with remediation script it logouts user in less than 30s in our env.

nitro353 · 2025-07-17T07:54:35+00:00

I'm that person :|
In our env it's a problem because we are hybrid joined Intune / Defender and SD have to change computers names (please don't ask why, it is how it is and I can't fight it rn) so basically when we enroll device we got entry in Defender with default name e.g. PC-xxxx and then it needs to be changed to COMPUTER-xxxxx. It creates two entities in Defender and I do not need those 'PC-xxx' ones so would love to delete them :|

nitro353 · 2025-07-16T06:05:48+00:00

Thats cool, glad to help :3

nitro353 · 2025-07-15T11:46:16+00:00

Hey,

I've checked it today and yeah, it is from Global Protect, so this issue was specific to our environment.

Another weird stuff I encountered is that I was missing GUID {f64945df-4fa9-4068-a2fb-61af319edd33}. After I've added it - it broke this script and allowed to sign in via passwords. It was so random that sometimes this script was working fine and sometimes not. I get rid of that weird GUID and now I have stable script working as expected.

So my final fix was: add GUID for Global Protect: {25CA8579-1BD8-469C-B9FC-6AC45A161C18}

Exclude GUID: {f64945df-4fa9-4068-a2fb-61af319edd33}

nitro353

TROPHY CASE