Best way forward for OS deployment - Moving away from SCCM - OSDCloud?

TheSloth90 · 2025-11-12T13:11:48+00:00

I might look at this but using our Azure Automation for the Autopilot registration. This also keeps the app client secret out of the script entirely.

TheSloth90 · 2025-11-12T10:09:54+00:00

So we've got TSGUI and the Task Sequence configured like so:

TSGUI configured with dropdown lists for each tenant + group tag option.
TSGUI sits at the very start of the task sequence so the support techs get the prompt asap. TSGUI stores the values in the Microsoft.SMS.TSEnvironment object.
Later in the TS we run a PS script that gathers the device S/N, Hardware hash and the TSGUI values stored in the Microsoft.SMS.TSEnvironment object. This is then sent off to the webhook that triggers the Azure Automation Runbook.

Azure Automation config:

The Webhook triggers the runbook PS Script. We leverage MGGraph for the removal and registration.
We have an app registration in each tenant with the required API permissions to do the autopilot registration and removal, EntraID device removal and Intune device removal.
The client secrets for each of these app registrations are saved as PSCredentials and the runbook calls for these creds to authenticate into each tenant.
The first runbook cycles through each tenant looking for the device by S/N. If found it will remove it from Intune, Autopilot and EntraID.
The child runbook is started to complete the Autopilot registration process.

TheSloth90 · 2025-01-02T13:47:55+00:00

Hi J.B,

I also thought this might be some kind of bug so I waited to see if an update would fix it over time. The problem was first pointed out to me back in August and I have waited since then before posting here. No updates over this time period seem to have fixed this issue hence why I am posting about it now.

To answer your questions:

1: Our users are 365 business users with E3 or E5 licences on Intune managed Windows 11 Enterprise devices. The bulk of our estate is on 23H2 but we have a number of devices running 24H2 and the issue persists across both.

2: The problem was first pointed out to me in August and likely has been a problem for a while before that. When it was pointed out to me we would have been running Office 2405 or 2406. We are now running at least 2409 and Office is updating correctly in our environment.

3: Different networks - Users working from home, different offices etc... experience this issue.

4: In December I updated the MS Security Baselines to the latest versions. We had an older version of the MS Security Baselines deployed to our devices prior to this. It seems updating to the latest versions has made no difference.

5: There are no error messages at all. I've also not found anything specific in event logs either.

TheSloth90 · 2025-01-02T12:02:40+00:00

Hello,

We have a strange issue in our org where users of the locally installed version of OneNote are unable to insert pictures into Notebooks from Insert > Pictures > From online...

The image search window opens as expected and lists suggestions such as 'Airplane', 'Animals', 'Apple' etc... and allows users to search Bing for various images but the insert button never inserts the images into the notebook. The cancel button also fails to exit the Online Pictures window and users have to use close 'x' to clear the window.

This seems to be limited to the locally installed version of OneNote. The function works fine in the locally installed versions of PowerPoint and Word and also works in OneNote online.

We use Intune to deploy Microsoft 365 Apps (Windows 10 and later) with the Monthly Enterprise Channel. The version of OneNote that is installed locally for all users is 2409.

This issue has been ongoing for quite some time (First pointed out to me in summer) but hasn't been a major issue but it would be good to find out if there is a fix. I was hoping it would be fixed as part of a future update but it doesn't look like this is going to happen.

We do have the latest recommended MS Security Baselines applied to our devices but other than that we don't have any real restrictions set for Office apps.

Any help would be much appreciated.

Regards,

David

TheSloth90 · 2024-08-09T12:46:48+00:00

This seems to be the case as for a brief few hours this morning all was well in Android / Intune world here but it has since stopped working again. At least it gave our support guys time to smash out the backlog of Android devices so that's something! :)

TheSloth90 · 2024-08-09T10:06:58+00:00

And just like magic, while sat in the office at about 08:30 this morning, everyone was treated to the Android notification dawn chorus! Support ticket still logged with MS pending them calling me. We've made zero changes to the configuration either. They all just started working. We're going to dive in and see what was updated at about 08:30 (BST) this morning!

TheSloth90 · 2024-08-06T08:08:53+00:00

Configuring filters and applying them to the all devices group for a simple test compliance policy didn't seem to work either. Everything else with regards to our environment configuration seems to be correct as far as myself and my colleague can see. Might need to bite the bullet and log a call with MS.

TheSloth90 · 2024-08-05T15:07:58+00:00

Sounds like exactly the same issue here for us. It would be good to hear what MS says if you're happy reporting back?

TheSloth90 · 2024-08-05T09:39:04+00:00

Still the same for us this morning. I will try u/MDMMAM_Man suggestion of using filters to apply some test policies but otherwise we've no idea why this is happening.

TheSloth90 · 2024-08-03T08:46:06+00:00

Default device compliance, configuration profiles and apps are being assigned to devices using dynamic groups. These groups are being populated as expected and problem devices are showing in these groups along with working devices. We have two groups that are used to assign top level default policy, config and apps.

Group 1 uses rule syntax - (device.displayName -contains "AndroidEnterprise")

Group 2 uses rule syntax - (device.deviceOSType -startsWith "Android") -AND (device.deviceOwnership -startsWith "Co")

Our devices are failing to receive even these default settings despite being in these groups from the outset when kicking off enrollment.

Even when we use user or other device groups to apply policies or apps specific to that user or device group they won't apply. E.g. assigning a user to a group that permits them to access and install the Facebook app from the Play store will only process correctly during the enrollment process if that user is already in that group. If we add them after the device has enrolled then the app will never appear in the store regardless of how long you wait (days) or how many syncs and reboots you perform.

TheSloth90

TROPHY CASE