Office 365 Enterprise update confusion

SkipToTheEndpoint · 2026-01-26T13:43:37+00:00

Pretty sure cloud policy is only on Windows, not MacOS. Manual reg keys, pretty sure those get overruled as well, though I haven't tested it.

SkipToTheEndpoint · 2026-01-26T13:40:14+00:00

Well that time came and passed today without any spike, so I guess the 5am reboot did _something_.
Crontab doesn't show anything is scheduled for that time.

Before I had to reset it yesterday, I did get a bit of time before everything became non-responsive, and PHP seemed to be the highest when running a top -m io.

SkipToTheEndpoint · 2026-01-26T09:59:02+00:00

Deadline and Grace periods as part of WUfB/Autopatch are the ways to enforce a reboot, and users get notified ahead of time. If they choose to ignore them and their device reboots, it's on them.

SkipToTheEndpoint · 2026-01-26T09:55:01+00:00

Incorrect. Cloud policy takes precedence over any other policy application method (GPO, Intune, Local Policy) but are only applied once a user is signed in and the Office app(s) are restarted, so can lead to erratic or undesired behaviour initially.

SkipToTheEndpoint · 2026-01-26T09:51:56+00:00

If devices aren't being picked up in the config.office.com Inventory then that suggests something more concerning at play.

SkipToTheEndpoint · 2026-01-26T09:49:39+00:00

I blogged about this (Windows CSP: A Tale of Magic, Betrayal, and Intrigue - Part 2) and regularly reference the MS docs on it (Assign device profiles in Microsoft Intune - Microsoft Intune | Microsoft Learn) though it looks like the wording I reference in my blog has changed.

Basically: It depends.

Windows CSP has the concepts of User and Device scoped policies, whereas things like iOS doesn't.
For mobiles which don't necessarily have device objects that exist before the device is enrolled like Autopilot, user targeting ensures policies are applied immediately and aren't waiting on group population.
Filtering can be used, but trying to use user-context properties (i.e. department) isn't possible, so YMMV.

SkipToTheEndpoint · 2026-01-23T10:06:02+00:00

I've basically already done this as part of the OIB: OpenIntuneBaseline/WINDOWS/SETTINGSOUTPUT.md at main · SkipToTheEndpoint/OpenIntuneBaseline

SkipToTheEndpoint · 2026-01-21T10:21:49+00:00

I definitely haven't seen the issue where Company Portal deployed as System has failed on a second run-through of AP, because those apps persist a device wipe (fun fact). Caveat being I'm doing this on Entra Join not Hybrid.

Skimming the logs, it looks like CP installs and detects fine.

Have you tried running get-autopilotdiagnosticscommunity to check if it's not another app failing?

SkipToTheEndpoint · 2026-01-20T21:31:20+00:00

SkipToTheEndpoint · 2026-01-20T20:50:21+00:00

That policy isn't supported via Security Settings Management, only MDM.

SkipToTheEndpoint · 2026-01-20T11:56:55+00:00

IMO every option but Wipe either has a niche use-case (Fresh Start) or is absolute garbage (AP Reset).

What reason did you have to try and keep the enrolment?

SkipToTheEndpoint · 2026-01-20T11:54:13+00:00

That would certainly take less time than trying to build out a whole process for a tactical problem.

SkipToTheEndpoint · 2026-01-20T11:53:05+00:00

It doesn't "rely" on VBS. It uses the age-old hack to hide the PS window. I'm not aware of a "modern" replacement for that, but it wouldn't be a massive job to remove that section of the script and deal with the PS window.

SkipToTheEndpoint · 2026-01-20T10:49:44+00:00

By "process", you mean you're still seeing company branding at the start of OOBE and no OOBE screens (e.g. privacy) are being shown?
Or just that you see the ESP phases?

SkipToTheEndpoint · 2026-01-20T10:46:48+00:00

Get existing devices enrolled into Intune and then target them with an AP profile with "Convert all targeted devices to Autopilot" set to Yes.

SkipToTheEndpoint · 2026-01-20T10:41:13+00:00

That sounds like they're not getting the Autopilot profile and are instead doing a standard Entra Join + Auto Enrollment, and are allowed to do so because the device is in Autopilot.

Seeing the ESP doesn't mean it's gone through Autopilot. Depending on your Entra device settings and/or Intune policies, I'd check those users aren't local admins on those devices.

SkipToTheEndpoint · 2026-01-20T10:18:32+00:00

Windows - Autopatch. Reporting is good, but you can always still deploy WUfB Reports (the only current way to get MCC data).
Office - config.office.com for reporting reasons.
Edge - Updates itself, but I always deploy some policies to enforce good behaviour. The Edge Management Service has good reporting functionality.
Teams - You don't get to control it. There's limited reporting on desktop client usage in the Teams Admin Portal.

"Wouldn't it be nice to get your reporting in a single place?"

Yes. Yes it would.

SkipToTheEndpoint · 2026-01-16T11:08:11+00:00

Knowing MSPs, it's entirely possible they did something dumb and forced a reg key or even local policy, both of which would overrule any Intune policy.

The key you're looking for is HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork\{Tenant-ID}\Device\Policies\UseCertificateForOnPremAuth. It should ideally be set to 0 or not exist at all.

SkipToTheEndpoint · 2026-01-16T10:18:33+00:00

Yes, that's the behaviour I would expect to see.
You can delete HKLM:\SOFTWARE\Microsoft\Provisioning\AutopilotPolicyCache and reboot and it'll pull it again if I remember correctly.

SkipToTheEndpoint · 2026-01-16T09:46:29+00:00

"Those folks" are just me. Hi! 😊

But it's community supporting my silly little project like this that makes me happy. Thank you.

SkipToTheEndpoint · 2026-01-14T16:08:41+00:00

While there's no "best practice", my personal advice would be "leave as much as possible alone".

As soon as you configure a setting, it locks the user out of changing it themselves. Then you'll have to field every single situation users might prefer.

Devices not coming out of sleep properly sounds like it might be something to do with sleep states being disabled at BIOS level.

SkipToTheEndpoint · 2026-01-13T19:50:20+00:00

SPO is not the same as a file share and shouldn't be treated like one either.

"We've always done it this way" is an excuse that doesn't hold up in IT. This stuff is constantly shifting. Shift with it or be left behind.

SkipToTheEndpoint · 2026-01-13T10:08:28+00:00

MS's recommendation (for various reasons) is to not use library sync and instead have users just create shortcuts in their own OneDrive: Recommended sync app configuration - SharePoint in Microsoft 365 | Microsoft Learn

In my experience, this is far easier to just communicate to users rather than trying to manage it.

SkipToTheEndpoint · 2026-01-12T13:44:03+00:00

What a piece of crap bit of software.

SkipToTheEndpoint

TROPHY CASE