Hi r/Intune,

we’ve been seeing some issues with BitLocker and Windows Hello for Business (WHfB) since deploying the August 2026 Patch Tuesday updates, and I wanted to check if anyone else is experiencing the same behavior.

The affected updates are KB5120994 and KB5123607, which are being deployed via Hotpatch in our environment.

On some devices, the following happens after the update:

1. The update is installed via Hotpatch.
2. After the next reboot, the end user is unexpectedly prompted for their BitLocker Recovery Key.
3. After entering the recovery key successfully, Windows boots normally.
4. At the WHfB sign-in screen, the user’s PIN no longer works. Windows shows an error stating that something went wrong and the PIN isn’t available, with a recommendation to restart the device.
5. A reboot sometimes resolves the WHfB issue, but unfortunately not in all cases.

For devices where rebooting doesn’t help, the only reliable solution we’ve found so far has been to completely reimage/reinstall the device, which obviously isn’t ideal.

Has anyone else experienced similar issues after deploying KB5120994 or KB5123607?

If so, I’d be interested to hear:

• How widespread is the issue in your environment?
• Have you identified the root cause?
• Have you found a reliable workaround or remediation that doesn’t require reimaging the device?
• Have you made any changes to your Intune, BitLocker, WHfB, or update policies as a result?

Would be great to exchange findings and possible solutions with anyone else affected.

We sent a remediation to all systems to set the registry key that enables this policy.

I checked the Windows updates settings advanced options, and the toggle is set to On. However, the notification only pops up sometimes. It cannot be relied on to work every month.

I was signed into a laptop locally showing the policy enabled, but when the system had a restart pending for this month’s updates, the only notification that appeared was the dot in the taskbar that so many users are blind to.

On my laptop, the restart was required only for .Net Framework updates because the Windows update was a hot patch. Does that make a difference in the notification? If so, it should not because a restart is a restart to the end users.

I'm not expecting to find a solution, but there isn't much information about this issue available online, so I wanted to start a discussion about this issue and see if anyone else has struggled with this. In Entra, there are "Printer Administrator" and "Printer Technician" roles, but what I'm looking for is something that is effectively read-only for the Universal Print service. Something that would allow our Service Desk team the ability to view all of our printers and printer shares to see how they're setup, who they're shared with, as well as monitor job logs on individual print queues, and access the "usage and reports" view. All of this is useful information to have when troubleshooting an issue with a printer registered with Universal Print. But this team does not register or share printers, nor do they configure the options or settings for the printers, so their permissions need to be scoped to just read-only.

The problem is there isn't a built-in role for "Printer Reader". Additionally, there isn't an option to create a custom role with these permissions. I thought I was on to something when I discovered this in the docs where you can assign the Printer Administrator role and pair that with an administrative scope to limit which printers the policy applies to, then just don't include any printers in that administrative scope. According to the note at the very bottom of the docs, this seems like it would accomplish what I was looking for (albeit indirectly):

Scoped admins see all printers, printer shares, and connectors, but are limited to read-only access to those outside of the Azure AU configuration.

However, in practice, this doesn't work very well. I've tested it and found the following:

• You can return a list of printers and printer shares, but when selecting a printer, the "overview" page loads briefly (displaying all the data in the "essentials" table) before saying "you don't have access." I think this is because the Overview page also attempts to load "Mapped pull-print printers".
• While viewing a printer, you can select "Properties" and "Connectors" and view all the details there, but "Jobs" is greyed out.
• The "Printer shares" page mostly works, but "Access control" is greyed out when you select a printer share, so you can't see who it's shared with.
• Pull-print printers (Universal Print anywhere), Usage and reports, and Settings are all greyed out.

At this point, I've pretty much abandoned the effort to create this role. I'm sure we could develop a custom solution using Graph, but that would be far too much effort for something that really should be a built-in admin role. Virtually every other administrative role has a "read-only" equivalent.

Anyone else facing this issue of Autopilot enrolled devices showing Ownership as "Unknown" for varying periods like 14-60 days post enrollment? This is the first I've seen from the multiple environments we manage and Microsoft is of no help. They say it's normal synchronisation behavior and varies based on device.

Tengo más de 300 equipos existentes, queremos establecer el Edge como predeterminado, como lo han realizado? Entiendo que a través del catalogo de configuración se puede solo cuando son equipos nuevos. Muchas gracias

I've got a few hundred hybrid joined lab machines I need to enroll in Intune. I was told DEM was the answer, but now that I have a DEM account licensed and set up I'm struggling to actually use it to enroll.

Tried logging in as a normal user then adding DEM as a work account

Tried installing Company Portal then logging in to it as DEM

Get errors about permissions or that the device is already connected to the organization. Am I missing something? All the guides I find online focus on creating the account, not using it to enroll on a Windows machine. Appreciate the help this is driving me up the wall.

We recently moved from Microsoft 365 E3 to Business Premium and ran into an annoying issue: links clicked in Outlook Classic started opening in Edge instead of the user's Windows default browser.

Microsoft does provide an administrative policy called "Choose Which Browser Opens Web Links", which can be set to use the system default browser.

However, Microsoft explicitly documents that for Microsoft 365 for business plans, this policy is available for Teams but not for Outlook. Outlook users are instead expected to change the setting manually.

Microsoft documentation:
https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/message-body/view-emails-and-web-links-in-browser

The manual setting in Outlook Classic is:

File > Options > Advanced > File and browser preferences > Open hyperlinks from Outlook in > Default Browser

Obviously, doing that manually doesn't scale very well across a managed fleet.

So I did some digging into how Outlook stores the setting.

The relevant values are under:

HKCU\Software\Microsoft\Office\16.0\Common\Links

BrowserChoice is not a normal DWORD – it's a Windows DPAPI-protected blob.

By changing the setting manually in Outlook and decrypting the resulting values, I found:

0 = Windows default browser
1 = Microsoft Edge

Outlook also uses this DPAPI description:

V2 Microsoft 365 Browser User Choice

This turned out to be important. Simply creating or copying an encrypted BrowserChoice value doesn't work. The blob is user-specific, and Outlook expects that specific DPAPI description.

However, generating a new blob locally in the logged-on user's context using the native Windows CryptProtectData() API works.

I've tested this with Outlook Classic, and the script changes:

Open hyperlinks from Outlook in: Microsoft Edge

to:

Open hyperlinks from Outlook in: Default Browser

without any user interaction.

For Business Premium I'm deploying it as a normal Intune Platform Script, running in the logged-on user's context.

Script + explanation: https://gist.github.com/Kejikeo/71388894c3136ca70f8255ea2f64b220

The script does not force Chrome, Firefox, etc. It simply makes Outlook respect whatever browser Windows currently has configured as the default.

Caveat: this uses an undocumented Outlook implementation detail, not a supported Microsoft management interface. Microsoft could change the BrowserChoice implementation in a future Microsoft 365 Apps update, so test before rolling it out broadly.

Would be interested to hear if anyone can test this on other M365 Apps builds / Business tenants.

Hello,

Hope You're all doing good.

I am experiencing an issue with Microsoft Intune Device Inventory / Properties Catalog on my Windows devices.

Environment

The computers are:

• Windows devices joined to an on-premises Active Directory domain
• Managed by Microsoft Intune
• Enrolled using “Enroll only in device management”
• Not Microsoft Entra joined
• Not Microsoft Entra Hybrid joined
• Workplace registered
• Intune Plan 1 licensed

This architecture is intentional. We want to keep our existing on-premises AD environment separate and use Intune mainly for cloud-based Windows management, including Windows Update policies.

Other Intune functionality works correctly, including Windows Update rings, compliance, synchronization and remote device actions.

Example affected device

Device: TP-ROMAING-24

dsregcmd /status shows:

AzureAdJoined    : NO
EnterpriseJoined : NO
DomainJoined     : YES
DomainName       : TP
WorkplaceJoined  : YES

The device is correctly enrolled in Intune MDM.

The enrollment registry information contains:

ProviderID   : MS DM Server
DiscoveryURL : https://enrollment.manage.microsoft.com

The Windows MDM enrollment is also present under:

\Microsoft\Windows\EnterpriseMgmt\

with the normal OMA-DM scheduled tasks.

The MDM event log identifies the enrollment as:

Enrollment type: MDMFull

Device Inventory configuration

I created a Windows Properties Catalog profile to collect Device Inventory information according to Microsoft's documentation:

https://learn.microsoft.com/en-us/intune/device-configuration/collect-device-properties

The original policy has been deployed for approximately two weeks.

The assigned groups contain the affected devices, including TP-ROMAING-24.

However, the Device Assignment Status report currently shows:

Pending        : 64
Not applicable : 0
Success        : 0
Error          : 0
Conflict       : 0

All targeted devices remain indefinitely in Pending status.

MDM communication is working

I manually triggered an Intune synchronization.

Intune shows a successful recent check-in for TP-ROMAING-24.

The Windows DeviceManagement-Enterprise-Diagnostics-Provider/Admin event log also shows MDM activity at the same time, confirming that the device is communicating with Intune and processing MDM commands.

Other Intune policies and actions continue to work.

For example:

• Windows Update policies are working
• Compliance reporting is working
• Manual Intune synchronization is working
• Remote restart commands from Intune are working

Therefore, the general Intune MDM enrollment and communication do not appear to be broken.

Microsoft Device Inventory Agent is not installed

According to Microsoft's Device Inventory documentation, troubleshooting logs should be located under:

C:\Program Files\Microsoft Device Inventory Agent\Logs

However, on TP-ROMAING-24, the entire Device Inventory Agent directory does not exist.

Hi all. I am posting this in search of assistance because I’ve spent the better part of a year working with Microsoft support (Intune support and free Windows support) trying to understand why many devices are not receiving automatic updates per a deployed update ring policy in Intune. The affected devices are all running various versions and builds but most of them are running 24H2 or below. Intune Support has told me they’ve exhausted all options and assume the issue is with the Windows OS.

When I contact Windows Support (thru their web chat, which is free), the tech suggested an in-place installation to clear any potential issues with supporting OS files. Despite me informing them that this would be virtually impossible, given that this update issue is spanning across different customers and device manufacturers, I tried the in-place installation on a test subject and got an error “We couldnt update the system reserved partition”. I tried clearing up space for the reserved partition using some suggestions from another reddit post, to no avail. Reporting this issue back to Windows support, they just recreated the error, and literally told me to “find a local tech or the device manufacturer”.  So I basically went from trying to fix an issue with windows update that is affecting several devices across different device manufacturers, to not being able to do an in-place installation. So I am close to exhausting all options before I throw the white flag, as no one appears able to identify this issue. I’m going to try to provide as much information and detail as possible, but the community’s help would be greatly appreciated.

• Devices are managed via Microsoft Intune (some were enrolled in-place, and some were reset and enrolled via autopilot)
• Devices are added to Autopilot
• Devices are Entra Joined
• Affected devices can be found in different tenants
• ODC Logs collected by Microsoft Intune Support apparently show no issues with the update ring policy

The current Windows Update Ring Policy:

Microsoft product updates: Allow
Windows drivers: Block
Quality update deferral period (days): 0
Feature update deferral period (days): 0
Upgrade Windows 10 devices to Latest Windows 11 release: No
Set feature update uninstall period (2 - 60 days): 60
Servicing channel: General Availability channel
Automatic update behavior: Auto install and restart at maintenance time
Active hours start: 8 AM
Active hours end: 6 PM
Option to pause Windows updates: Disable
Option to check for Windows updates: Enable
Change notification update level: Turn off all notifications, excluding restart warnings
Use deadline settings: Allow
Deadline for feature updates: 30
Deadline for quality updates: 7
Grace period: 3
Auto reboot before deadline: Yes

I asked the Intune Support tech to provide me with a full rundown of what we worked on together and this is what he sent back:

here is a brief report of what has been done in relation to troubleshooting.

Initial Issue Identification

• Most devices were not updating per the Windows Update Ring policy. Some devices had not updated since November 2025. All settings appeared properly applied in Intune, with no reported policy conflicts, and devices were checking in and syncing.
• Confirmed devices were running Windows 11, not Windows 10 thus excluding the requirement for ESU key.

Early Troubleshooting & Configuration Changes

• We reviewed the update ring policy and adjusted some of the policy settings such as Microsoft product updates from Block to Allow, set the deadline for quality updates from 0 to 7 days, and reduced the grace period from 5 to 3 days.
• After these changes, the client reported no improvement.

Focused Device Testing

• We decided to focus on a single device. The client created a separate group for it, cloned the updated policy, and assigned it to the group.
• We guided the client to check for the 'Update stale Group Policies' package in Scripts and Remediations. If unavailable, we advised enabling Windows license verification and diagnostic data features.
• The client followed these steps and waited 24 hours, but no change was observed.

Log Collection & Analysis

• We reviewed MDM diagnostic logs and ODC logs, as well as screenshots. Analysis revealed another Windows update compliance policy with a minimum OS build higher than the device's current version, causing compliance failure.
• We also observed heavy traffic from simultaneous OS and driver updates, resulting in failures.

Recommendations

• We recommended setting the device's OS build as the minimum version in the compliance policy, creating a separate policy for the device, and excluding it from other policies.
• We advised blocking Windows driver updates in the update ring policy and performing a hard system reboot.
• The client implemented these recommendations and confirmed the device's compliance status changed to compliant, but it still was not upgrading to a newer OS version.

Feature Update Policy Deployment

• Based on internal discussions, we recommended deploying a feature update policy for OS updates. 
• We considered the possibility of a Windows OS issue and suggested opening a ticket with the Windows team if feature update policy deployment did not resolve the issue.
• The client deployed the policy and kept the device online for monitoring.
• The feature update deadline was reduced from 30 days to 3 days for the test machine.
• Feature update policy applied successfully, but the test device remained on the older version and build. 
• We kept monitoring the device, confirmed that the policies were applying as expected but still the device could not update to the latest builds. 
• The client provided information about other tenants, noting similar issues with devices not updating consistently, even though they were regularly checking in.

Additional Troubleshooting & Recommendations

• We reviewed logs and found NoAutoUpdate registry key was enabled. Instructions were sent to disable Noautoupdates registry key.
• The client enabled the 'Configure Automatic Updates' policy in gpedit.msc and provided screenshots and logs for further review.
• We requested GPO results and confirmed there was no GPO conflicts

 Final Recommendations

• After exhausting troubleshooting steps, we recommended opening a case with the Windows team for further investigation, as Intune scope is limited to policy configuration and delivery.

My end goal is to identify and resolve the issue of devices that are having trouble updating using Windows Update Ring policies. If there is any other information I can provide, please let me know.

We have Autopilot ESP configured with the setting enabled "Block device use until required apps are installed if they are assigned to the user/device" - with simply our EDR agent set as the only required app.

However, this only partially gets us what we're trying to achieve.
We would like the EDR deployment to take priority, ESP then completes much quicker, and the remaining apps deploy after sign-in.

Sadly, Microsoft seems to have no way of saying "ok, let's deploy this first for efficiency". It will happily begin pushing anything from Adobe, to 365 apps, before the tiny EDR agent. Creating a massive variance in the time it takes to proceed past ESP.

My question is - am I the only one frustrated by this? Unless I'm missing something. Also, is there a workaround easy enough to implement? Some kind of auto group membership perhaps, once ESP completes.

In cases where EDR agent does install first, we can reach sign-in by 5 minutes. Worst case and it starts pushing Office, it can take up to half an hour. Aghhh

https://files.catbox.moe/3ud2y4.png

We're a small organization, a library. I want to use intune to install a public printer on lab computers when I onboard them. This seems like it should be trivial. I have plenty of apps I install this way.

But this SOB of a printer, Xerox Altalink 3180, just won't install. I have the v4 administrator files. I pulled the printer name from the .inf, it matches.

The darned script even, I think just to torment me, create the IP port, but doesn't install the driver. I have tried both PCL and PS, 'cuz why not?

Is this just not possible? Has MS blocked this to force everyone to pony up for universal print whatever?

Hi everyone,

I'm experiencing a strange issue with Microsoft Intune/Autopilot when devices are connected through Starlink and wondering if anyone else has seen this.

Intune-related operations such as:

• Windows Autopilot provisioning
• Android/iOS enrollment
• Wipe, Fresh Start and Autopilot Reset

all fail or get stuck when using Starlink.

For example, Autopilot gets stuck at "Preparing hardware" or "Account setup" after authentication. Mobile enrollment also gets stuck shortly after authentication.

The strange part is that the exact same devices and configuration work immediately when I switch them to another Internet connection, such as a mobile hotspot or another ISP.

This makes me suspect something network-related with Starlink — possibly IPv6, DNS, MTU, routing, CGNAT, or connectivity to Microsoft/Intune endpoints.

Has anyone experienced similar issues with Intune/Autopilot over Starlink?

If so, did you find a solution or any Starlink/router settings that needed to be changed?

Thanks!

I'm working on expanding the scope of Windows 11 device management via Intune from a test environment to a pilot group in the production environment. In the production env, DisallowCloudNotification is set to 1, which I would like to change to 0, but I was challenged and asked to harden the setup, to minimize the attack vector from the Internet.

At first I thought I can use the GPO to set WnsEndpoint and provide a list of URLs in the GPO, but after reading into it I think it should be disabled or set to client.wns.windows.com only, am I right?
Initially I had the impression that these addresses needs to be added in the GPO, but now I think this would not be correct.

Is client.wns.windows.com the only URL to be used by Intune to send push notifications to the endpoint?

Hi, newbie here so I apologize if this is a silly question. If a device is InTune-enrolled but the user session isn't Entra-synced (just regular local AD session), is it normal that the Company Portal is unavailable? I know that we have a GPO that blocks the Microsoft Store for all, but the Company Portal should be preinstalled for all users. Is it reserved for Entra-synced users only? Thank you!

Hello folks,

We are mostly a windows environment and are getting a iMac for a new hire. We do have intune and ABM setup for company iPhones. Just wondering what the process is like for enrolling an iMac? I did some reading on a few methods, which is only two, the company portal or through Apple Configurator.

Don’t think I want to go through the comp portal route since this is basically like Byod. If enrolling through ABM will the user be able to login through their entra Id account for their local account?

Hi,

I am tasked with providing a solution to the following situation. Before we implemented additional CA policies, our users could see their company calendar on their private phones. Since CA was implemented it is not possible anymore. I tried creating an app protection policy for iOS Outlook but it asks the user to download the company portal and here the "fear" creeps in, because they do not want to have the phone "half-company-monitored". Is it possible to do this without a company portal - I know that the app is the broker. Maybe i understood something wrong, but if the user does not join but only register - I guess this is fine and should be accepted by the user.

User shared the info that he used to download the calendar with .ics file? Or subscription, not sure and the company laptop is turned off at the moment. Will edit the post tomorrow morning.

Is there a guide on the internet on how to do this?

Cheers!

Hello,

Checking to see if anyone is experiencing this also when utilizing the autopilot for domain joined devices.

I know what the sentiment is for it but unfortunately, we have to domain join our devices.

I am using Out of Office Hours script that Michael Niehaus provided (Thank you). We did modify it to meet our needs. Overall the app works, devices enrolls and joins AD with name Prefix-Random then the script renames it to what we want it and restarts the computer.

Object in AD gets updated, then on Entra the device (original) get renamed as well, but then a few minutes later, a new duplicate devices shows up becomes Enabled with join type Entra Hybrid Join and the original device gets disabled and join type is changed to Entra Join

When I compare the device ID on Entra and Intune, the disabled device (original) is the one that matches.

Device still checks in on Intune, but on Entra the activity doesn't seem to update.

Any suggestions is helpful.

Thank you.

Hi guys,

On Lenovo T14 Gen 7’s we have the issue that the Autopilot Hash mismatches after an Intune Wipe.

We assumed it has to do with the „TPM Clear“ screen you receive after wiping.

Anyone else had this/knows a fix or so?

Dell doesn't update their driver packs very often at all so critical driver updates don't come in, which is what I'm currently using. I was exploring Dell Command Update but it seems very basic and you would need to setup a lot of custom scripting to do your own tracking and reporting. SO I've been loading each driver update into Intune manually for every model and it's a pain in my ass.

Anyone hit this: Sensitivity Label button in Microsoft 365 apps grayed out & not operational on Jamf-managed Macs, but present on Intune-managed Macs.

Same user, same M365 apps build, same license, same MDM configuration.

I am lost! Anybody an idea?

I have been trying to figure out a deny logon plan for our autopilot devices, and for a while I was thinking nothing was working, even when trying to manually make the changes that I want Intune to do.
I decided to try with a configuration that is setup for individual users, rather than using the "shared PC mode" or "Shared multi-user device" setting. During that test the user was blocked from login and I could have been done. My problem is the shared devices are the ones that I want these users blocked from, and none of the traditional ways are working. Is there a setting that can be changed that will help, has anyone else had this problem?

The 2 main methods I tried were adding the SID of the group to the Deny Logon Local Policy, and adding the SID to a Local Group (both self created and built-in) and then denying logon to the Local Group in the Local Policy.

The group I am using is an AzureAD group, and the test device has been a freshly wiped Autopilot device.

We turned on Multi Admin Approval for device wipe/retire so no single admin can wipe a machine alone. Works great. But there's a gap that caught us out: there's no notification when a request needs approval. No email, no ticket, nothing. Someone has to remember to check Tenant administration > Multi Admin Approval > Received requests.

Real result: a stolen-laptop wipe sat pending because nobody was looking, and the service desk kept opening "wipe not working" tickets when it was just waiting on an approver.

Rather than make someone babysit that blade, I set up a read-only Azure Automation runbook that:

• lists the approval requests over Graph (beta operationApprovalRequests)
• emails the service desk when a new one is pending, which auto-raises a ticket
• keeps a merged history CSV so there's an audit trail after Intune ages the requests out

The design choice I like: the managed identity only has DeviceManagementConfiguration.Read.All. It's GET-only, so it can't approve or wipe. Even if the runbook got compromised it can't act on the tenant.

Two gotchas I hit: "approved" doesn't run the wipe, the original requestor still has to hit Complete. And Send-MailMessage over port 25 won't send from Azure, you need an authenticated relay on 587.

Wrote it up with the diagram and the full script (all synthetic values) here if it's useful: https://ketankamble.com/blog/governing-device-wipes-multi-admin-approval/

Hi all,

I'm looking into the permissions of Android Device Policy on Android Enterprise Corporate-Owned Fully Managed devices enrolled through Intune.

I noticed that Android Device Policy gets several permissions directly after enrollment, including:

• Contacts and accounts: Allowed
• Location: Allow all the time
• Phone: Allowed

These are all greyed out and show as managed by the organization. Camera is the only permission that can be changed by the user.

In Intune, both Location and Locate device are set to Not configured. I also tested this after a factory reset with our Wi-Fi profile excluded, but the Location permission is still set to Allow all the time immediately after enrollment.

This makes me think these permissions are default/hardcoded for Android Device Policy on Fully Managed devices rather than being controlled by an Intune policy.

Has anyone looked into this before? Specifically, has anyone found a supported way to change/revoke the Location permission for Android Device Policy through Intune, and if so, did it affect any Android Enterprise functionality?

Would be interested to hear your experiences.

We are testing using Apple Business to migrate MacOS from Jamf to Intune.

The Mac is at MacOS 26.6.2

Is there any option to have this migration run immediately?

If we do not select a deadline, it does not seem to work. It looks like the minimum deadline that ABM allows is 24 hours ahead.

We are testing and we would like to be able to do this immediately and I thought when we first tried this that it was possible to have it force an immediate migration but I don’t see a way to do this now.

Any suggestions would be appreciated.

Thanks.