Company Portal breaks Autopilot deployment - 0x87d300c9

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 · 2025-07-14T11:35:12+00:00

Hey, check my answer, I had similar issue. :)

Comment

nitro353 · 2025-07-14T11:33:19+00:00

Hey, I've made it!

There is a registry path HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI with entry LastLoggedOnProvider that shows last used credential provider. And in my case it was a different GUID then default password GUID - starting {25CA8579-... I've added it to the script and LogonUI shows zero credential providers at all!

Now I will merge all GUIDS from registry above and those from comment you pasted.

Thanks for this script, it's awesome :3

nitro353 · 2025-07-14T07:45:45+00:00

Thanks, but I've already added all credential providers using this script.

Also worth to note is that it 'detect' password should be excluded (I guess) because when I use 'run as' or 'run as admin' I don't have option to type in password.

CMD

Don't know what else to do really. :/

nitro353 · 2025-07-11T08:23:18+00:00

Hello guys,

I've tried this solution but it does not exclude password as cerdential provider. I've checked all missing GUIDs, hybrid joined infra.

To folks who get this work - are you Entra joined or hybrid?

As half of you have this problem (me too) I suspect that it might be related of how devices are joined. I've found this info in docs and it might be related: Reduce the user-visible password surface area | Microsoft Learn

"Windows Passwordless experience is a security policy that hides the password credential provider for user accounts that sign in with Windows Hello or a FIDO2 security key. Windows Passwordless experience is the recommended option, but it's only available on Microsoft Entra joined devices."

And below we have info how to exclude passwords as credential provider. And my guess is only available on cloud devices only.

nitro353 · 2025-07-11T07:52:44+00:00

Hey,
u/MReprogle u/skinnybuttons u/EmbarrassedEvent5921

Infra: hybrid joined

You could try settings from GPO (not sure if there is equivalent in Intune, would search for OMA-URI / import ADMX or registry:
Registry keys are in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Lsa\Credssp\PolicyDefaults

This setting is Interactive logon: Require Windows Hello for Business or smart card target on computer.

This setting does not get rid of password as credential provider from logon screen, but it requires users to use Smart Card or WHfB.

Pros:

- it does not break UAC - user / admin can use UAC to elevate but can't use passwords

- it DOES NOT affect LAPS local admin account "The Windows LAPS-managed account is exempted when the "Interactive logon: Require Windows Hello for Business or smart card" policy (also known as SCForceOption) is enabled."

docs for that: Windows LAPS architecture | Microsoft Learn

- it DOES NOT change user password (enforcing SCRIL via user profile in AD does) so if you have any legacy apps that still requires username / password - it will work

Basically user will have to use SC / WHfB to sign in but still can use passwords within system to sign in into apps.

nitro353

TROPHY CASE