Thanks for joining us today. We'll be back next month -- and every third Thursday -- here on the Tech Community. Visit https://aka.ms/Windows/OfficeHours for a list of future dates to add to your calendar.

Good day! 

In Intune, how do we create a policy that automatically do Windows update to all the devices? We currently have Business Premium. 

Currently when using LAPS for macOS in Intune, we can only apply local account configuration during the ADE process as per the Intune documentation. Could someone from the team confirm if this is an Apple limitation, or a Microsoft limitation? This is a snag with the new Apple MDM Migration process in ABM, as migrating devices to Intune do not count as a "new enrollment through ADE"

Regarding Configuration Manager task sequences. Occasionally need to install a Windows cumulative update in a non-OSD task sequence, reboot, and continue running additional steps in the task sequence. This has not been a reliable process. I suspect the task sequence is not able to handle a double/multiple restart. This is discussed in the https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/os-deployment/task-sequence-fails-multiple-restarts article in regard to the Install Software Updates step. But, is there anyway to avoid issue installing Windows cumulative update from an https://learn.microsoft.com/en-us/intune/configmgr/osd/understand/task-sequence-steps#BKMK_InstallPackage step followed by a https://learn.microsoft.com/en-us/intune/configmgr/osd/understand/task-sequence-steps#BKMK_RestartComputer step?

The "Retry this step if computer unexpectedly restarts" option for Install Package step does not appear to do anything. The SMSTS log doesn't even indicate it's enabled.

The action (<step name removed from example>) is either not set for retry or exhausted the number of retry attempts. It will not be retried after the reboot.(Current retry count: 1, Total retries: 0)
...
Task sequence failed due to an external shutdown request received during execution and the Task Sequence action is not configured for retry on reboot.

Just a quick question, anyone having issues updating to win 11 25H2 without having 24H2 applied?

Hello,

Our organization had been using Autopilot V1 for a few years and switched to Autopilot V2 near the first half of this year. We created separate policies for each profile.

Starting around the beginning of August, our fleet of APV1-joined devices started what I affectionately call "brick"locking, where random devices began to randomly lock themselves via bitlocker after a windows update (after either a BSOD saying "INVALID_BOOT_DEVICE" or if the user just restarted their device) and there was no way to recover as all recovery options required a local admin account which did not exist.

This was happening to our Windows 10 Dell devices. We began upgrading them to Windows 11 thinking it would fix it, but it did not. (one support documented suggested it was an issue with TXT in the bios but TXT was disabled in all our machines). It also affected our Hyper-V machines running Windows 10.

I spent countless hours with 365 support which was largely unhelpful as they kept asking for information that we could not provide because we had no access to the drives until I finally got one locally and extracted logs after decrypting the drive. I utilized Copilot to help analyze the logs and the policies we had configured in our tenant. 

We noticed none of our APV2 devices doing this and realized that their bitlocker + tpm policies were different in that APV1 did not allow startup PIN with TPM. Copilot mentioned that this was likely the culprit.

I changed our AVP1 policies to match with our APV2 policies and it seems the "bricklocking" has ceased, but the nature of this problem was odd as we were working fine for years before this.

Not only that, but a number of our APV1-joined devices are still randomly having boot problems where they will boot into Automatic Recovery and the only way to correct the issue is to reset Windows.

Any thoughts on why this was happening and why it started happening in August?

Good day! As we see providers like Jamf and Okta move forward with Simplified PSSO in Device Enrollment phase, does Intune/Entra have any ETAs on when we'd be able to apply it to macOS devices in Intune?

Hello All,

We have about 100 PCs, Dell OptiPlex 5000, some running Windows 11 23H2, some 22H2, and only 4 PCs running Windows 10 22H2. Since the drop in support for Windows 10 on October 14, we have been unable to upgrade to the latest Windows 11 Build. We continue to get the message:

We've set your PC back to way it was right before you started installing windows 11. 

0xC1900101 - 0x40017 

The installation failed in the SECOND_BOOT phase with an error during BOOT operation

We have tried all available steps outlined on the internet to fix this issue but nothing works.

How do we overcome this hurdle?

Thanks, everyone.

Can anyone provide any update of this feature's rollout?
Will thi be available only during prestage enrollment or will it be available to deploy to previously enrolled systems?

---

Microsoft Intune: Recovery Lock management for macOS

https://www.microsoft.com/en-us/microsoft-365/roadmap?id=501457
Microsoft Intune
IN DEVELOPMENT
ROLLOUT START
November 2025
This feature adds the ability to manage the password used to access the macOS recovery partition. Configuring a recovery OS password prevents users from booting company-owned devices into recovery mode, reinstalling macOS, and bypassing remote management.

Hello!

We recently moved to Intune/Entra ID and Windows 11.  We implemented SSPR and a majority of our users receive the following message when they attempt to change their passwords via Ctrl+Alt+Del->Change a password:

The only way they can reset their password is to go to my.microsoft.com, log in, MS Authenticate, then select the Change password tile.

Some users can perform the Ctrl+Alt+Del->Change a password workflow and go directly to the password change screen (after MS Authenticator), but most others get the "Let's try something else" message.  We've looked at everything - CA policies, groups, sign-in logs, and we've yet to find out why some folks are fine yet most are not. 

Interestingly, if we have someone try the password change from a device known to work correctly, they will get to the change a password screen without the "Let's try something else" pop up, but if they go back to THEIR workstation, they get the "Let's try something else".

We've spent a considerable amount of time trying to figure this one out - can anyone lend some guidance in troubleshooting and resolving this issue?

Thanks!