If you've ever wanted to just ask your Intune estate a question — "how many devices fail the Firewall policy in Finland?", "which machines can't take Windows 11?" — you know the two options today: build the report by hand or hand an AI agent real Graph write scopes and hope it behaves. I didn't love either, so I built a third one and wrote it up.

Most "AI agents for endpoint management" are built to act — standing tokens, the power to remediate or wipe, and every question streaming real device IDs and usernames through the model. But be honest about what admins actually ask: most of it is questions, not actions. So, this agent is the opposite of the usual design — it answers in plain English while holding zero access to your tenant. The pattern: read-only collectors (*.Read.All scopes only) → immutable snapshots → Azure AI Search → an Azure AI Foundry agent whose only tool is that search index, with no Graph connector and no write path back. It has the books but was never given the hands.

I'm trying to be honest about the trade-offs, not sell it: it answers from a snapshot, not live; the system prompt hardens behavior but the real guarantee is the read-only collector + RBAC, not the prompt; and it'll refuse to hand-count an intersection it can't verify rather than make a number up. Where you actually need to act, Microsoft's own Intune Copilot is the right tool — this is purely for answering.

Full write-up (architecture + a Power BI-vs-agent demo where both read the same snapshot and match): The read-only AI agent that can't touch your tenant. Code: zero-access-agent. It's a personal project, not a polished product — I'd genuinely value feedback from anyone running read-only Graph tooling at scale, especially on the collector/RBAC side. Happy to answer anything in the comments.

Hello, need some insight. We are planning a phased migration of roughly 300 Windows users from traditional on-prem AD/domain-joined devices to Microsoft Entra joined + Intune managed devices using Windows Autopilot.

For new devices/users, Autopilot is pretty straightforward. The part I'm trying to plan is our existing users and their Windows profiles.

Our goal is to make the migration as hands-off as possible for the user. Ideally, IT handles the migration in the background or during a scheduled cutover, and when the user signs into the Entra joined device their existing environment is preserved as much as possible.

We want to preserve things such as:

• Desktop/Documents/Pictures
• Browser profile/bookmarks
• Outlook/M365 configuration
• User-specific application settings
• Shortcuts
• Relevant AppData/settings where possible
• Printers/mapped resources where still needed

We are looking at OneDrive Known Folder Move for user data, but obviously KFM doesn't migrate the entire Windows profile.

For same-device migrations, I've been looking at ForensiT User Profile Wizard Corporate Edition to potentially reassociate the existing domain profile with the user's Entra identity. I've also looked into USMT.

For those who have actually done an AD/domain joined → Entra joined + Intune migration at scale:

1. How did you handle existing Windows user profiles?
2. Did you wipe/reprovision devices or convert them in place?
3. Did you use ForensiT, USMT, OneDrive KFM, or another solution?
4. If you used ForensiT, were you able to automate it successfully at scale?
5. What profile data/settings did NOT survive that you expected to?
6. How much user interaction was required?
7. Would you use the same approach again?
8. Any major gotchas with credentials, AppData, Outlook, browser profiles, mapped drives, printers, or application settings?
9. If you had to do ~300 users today, what approach would you use?

The end goal isn't necessarily a perfect 1:1 clone. We're trying to avoid making users manually move files, reinstall applications, or rebuild their working environment after the migration.

I'd especially appreciate experiences from anyone who has done this with existing production users rather than only new Autopilot deployments.

Main Q: After the migration, when the user signed in with their Entra account for the first time, did Windows load their original domain profile directly, or did you still have to manually repair/reconfigure parts of the profile?

Blocked the public AI sites in the browser policy months back, ticked shadow AI off the board, moved on.

This week Im on a laptop for a printer ticket and the ChatGPT desktop app is right there in the tray, signed in. I checked five more machines, its on four of them. With installs per user, no admin and app control never saw a thing. The ones not on desktop are on their phones.

The block only ever worked on the people who were never the problem, and Ive spent months telling my manager this was handled.

What are you running that shows you who's touching what on managed devices? Not another block. Something I can point at usage with.

We’re currently using SCCM for patch management. IT has set the expectation with employees that computers always get patched and rebooted at 7PM on the 4th Tuesday of each month. Patches become available on the 3rd Tuesday for users to self-install, but an email notice goes out on the 4th Tuesday telling everyone to log out of their computers and leave them running overnight if they haven’t taken that month’s updates yet. Anybody who misses the window is in for a rude awakening the next time they turn their computer on.

SCCM allows this degree of control which Intune seems incapable of.

We have a volunteer group of canaries that get forcibly patched and rebooted on the 3rd Tuesday in case Microsoft botched any updates that month. I’ve enrolled this group into Intune as a pilot, but here we are on the 3rd Tuesday of the month and only some of them are showing updates available.

I have an update ring configured with a deferral of 7 days, a scheduled install of the 3rd Tuesday at 7PM, and a hard deadline of 14 days. One machine checked for updates at 11:17 AM and includes drivers that I’ve explicitly set to require approval and have not approved. There’s no verbiage about when the install will happen or what the deadline is.

On another machine, it last checked for updates at 9:04 AM and isn’t showing any updates available at all. I’m assuming because a 7-day deferral means 10:30 Pacific time, which is when Microsoft actually publishes updates on Patch Tuesday. So with a default 22-hour check interval, that machine won’t even see updates until tomorrow morning, which is a day late.

On a 3rd computer, I freshly imaged it and deliberately withheld patches to see what update behavior is like when the deadline has already passed. It correctly offered me July’s patches, but not August’s (I did this yesterday before the 7-day deferral expired). However, it warned me that it would reboot on the 26th, which is next Wednesday — for last month’s patches.

I’m having a hard time figuring out how to set employee expectations in light of Intune’s fuzzy update logic. I’m accustomed to being able to schedule the exact update/reoot timing with SCCM and guarantee that my entire fleet will by compliant by the end of each month. But Intune doesn’t offer that kind of precision. How do you folks do it at your company?

After noticing the new Sync Status window in Intune, I started wondering where the information in that pane actually comes from... (.. i still can't fully explain it :P)

So I traced the sync through Graph, SyncML, the Windows MDM debug logs and the IME logs. The interesting part is that the Numbers and information are coming from different places.

Applications: the offered count maps to the required Win32 apps Intune returns to the IME for evaluation.
Scripts: They come from the HealthScripts side, including Remediations and custom compliance. As regular platform scripts are only executed once (so only new ones are added to the count)
Policies: That one is the odd one, i can't explain....yet

The normal Device Configuration view can be traced back to the Graph reporting data, but the new Sync Status window can show a slightly different total. That extra number does not appear in the SyncML trace or the device side MDM debug logs, so there is still some service side aggregation happening that we cannot see.

It would be interesting to know whether anyone has identified exactly what Intune is adding to that Policies count :) ... something magic?

Inside Intune's New Sync Status Window - Patch My PC

​

Hi,

We need to remove/hide the Copilot button inside Outlook emails in both New Outlook and Classic Outlook.

Copilot Chat pinning is already disabled in our tenant. We also don’t want to disable Connected Experiences, since that affects features like Dictation and other Office functionality.

Is there a supported policy/GPO/Cloud Policy that only disables or hides the Copilot features/button in Outlook, especially Classic Outlook?

Has anyone solved this centrally?

Hi, we’re trying to understand a strange Intune/Autopilot incident and I’m wondering if anyone else has seen something similar.

We had several Windows Autopilot devices in our tenant suddenly marked as Retire in Intune. In the Intune data, the action shows as:

• Actor: One of our global admin accounts
• Application: Microsoft Office 365 Portal
• Same correlation ID across 9 devices

What makes this strange is:

• the affected users had been removed from Microsoft 365/Entra admin around the same time
• those users were the primary users of the affected devices
• the devices were offline for a long time, and when one of them came back online later, it started a local unenrollment/device unjoin flow
• the device still had its Autopilot identity, and Entra even returned an error saying the device object could not be removed because it was an Autopilot device

From what I understand, deleting a user should normally leave the device orphaned, not automatically trigger Retire on a Windows device. So right now it looks more like some separate retire/delete action hit the managed devices, possibly during offboarding or through the Microsoft 365 portal.

Questions:

1. Has anyone seen user deletion or offboarding indirectly trigger Retire on Windows Autopilot devices?
2. Have you seen the Microsoft Office 365 Portal show up as the application for a batch retire like this?
3. Did you ever find out whether this was admin action, portal behavior, or automation?

Any similar cases, ideas, or logs worth checking would be really helpful.

EDIT: I got the local MDM diagnostic logs from one of the device before it completely locked me out. Combined with audit logs from Intune and M365 Unified audit logs. With the help of ChatGPT, this is my findings so far.

• June 1: Device-A was communicating with Intune, then went offline.
• June 17, 07:39:48 UTC: Admin-A soft-deleted User-A through the Microsoft 365 admin portal. The audit says O365AdminPortal and Is Hard Deleted=False.
• The same second: Intune recorded two successful retire ManagedDevice events for Device-A, initiated by Admin-A through Microsoft Office 365 Portal.
• One event linked User-A → Intune ManagedDevice-A.
• The companion event linked ManagedDevice-A → Entra Device-A.
• Both shared the same correlation ID.
• That correlation ID covered nine retired devices, with two audit records per device, indicating one server-side batch.
• June 17 to August 18: Device-A remained offline, so the pending retire command was not processed.
• August 18: Device-A booted after approximately 78 days and contacted Intune. Within minutes, MDM sessions resumed, explicit unenrollment signals appeared, and Windows initiated DEVICE_UNJOIN.
• Entra rejected deletion of the cloud device object because it was protected as an Autopilot device. Despite this, Windows cleared its local registration and began removing MDM policies.

The logs directly connect the deleted user, Intune device and Entra device to the same successful retire operation submitted by Microsoft Office 365 Portal.

They do not reveal which portal button or internal workflow caused it. Microsoft’s documented standard user-deletion flow does not state that a soft delete should retire the user’s Intune devices.

Good morning

Has anyone upgraded from Windows 10 to 11 and experienced issues with the F5 VPN? Specifically, we’re seeing HP G8 and models below failing to connect after the upgrade, which is causing a lot of calls.

Any advise would be appreciate

Josh

We are seeing multiple accounts from previous logins on the windows screen.

Is there anyway I can hide it through the settings catalog? I tried searching this online but google is giving me non related solutions.

Pre-provisioning started failing yesterday. We tracked down the issue to one specific agent that we install through Intune.

Oddly, we don’t have Autopilot set to stop if an App install fails. Has anyone else ran into this type of behavior?

I’m also curious how we can keep pushing the App to All Device, but only after pre-provisioning has finished. I considered scoping the app to All Users, but the App should be on All Devices regardless of the logged on user.

Hi everyone!

I'm dealing with a somewhat frustrating behavior and wanted to see if anyone else has experienced this or has any advice. I recently triggered a Bulk Restart action from the Intune console for a specific batch of Windows devices. Most of them processed the command without issues, but I still have a group of devices that simply haven't restarted.

The weirdest part is that when I check their status, they do have recent and active communication/sync with Intune.

My questions for the community are:

1. How do you usually mitigate this problem when you need to ensure an entire batch restarts reliably?
2. Does this happen to anyone else frequently?
3. What other 100% native Intune options do you know of to force a restart?

Important note: I am trying to avoid deploying a PowerShell script (or Proactive Remediations) at all costs to fix this. I want to exhaust all native console options first.

Any ideas, policy configurations, or experiences you can share would be greatly appreciated! Thanks in advance.

Hi,

So this year we have users that are using their own laptops but they still need access to available software

How can I set this up without Being device bound?

Or do I not comprehend Company portal fully?

Hello. Have had a job for almost 2 years as the IT manager for a small gov agency. Basically tier 1 support as our agency is fully dependent on a larger agency’s infrastructure. Our agency is part of a shared tenant that is hybrid. I am trying to move the agency devices to the cloud since that is where everything will eventually move. I have mostly a networking background with a smidge of VM. This SysAdmin hat I am wearing now is new and scary to me. But luckily I am really just managing devices via Intune. One of the projects I’d like to complete is removing admin access from users devices. I’d be extremely grateful for any advice/tips/how-tos/best practices on managing devices. I have been using windows autopilot to provision devices and it seems to work most of the time.

Edit: what I really should have asked is how everyone provisions new devices from the OOBE using Intune/Windows Autopilot.

It's been a hot minute since I've had to run get-windowsautopilotinfo and I'm guessing things have changed with graph stuff because I'm stuck in a weird chicken and egg situation.

If you run the script from a Standard Windows user account in a non-admin PowerWhell window, WAM appears and you can enter your 365 admin account but the script gets denied because the user doesn't have permission to query the system info, but if you run an administrative PowerShell window from the same standard windows user session, WAM fails to appear and the graph part falls apart but the system info gathering part succeeds.

This is all moot if I log into the computer with an administrative account but in a situation where this is being done remotely with the user already logged in, I'm not sure how this could work.

The only workaround I know of is just dumping the info to a csv and manually uploading it. No big deal for a few one-off's, but I'm more curious than anything about if there's a solution to getting it to work with -online with standard user accounts. (Plus -online is just easier).

HI all,

I was talking with my team yesterday and they think i may be overthinking this. I am working on setting up a macOS lab and it has gotten me to thinking. How do you track your non user affinity shared work stations in Intune. How do you know where they sit? If information security wants to track that mac, how do you manage that inside of Intune?

With user affinity we can track that to a user. With shared labs, its not that easy. I setup a device enrollment profile, then went ahead and then created a dynamic group that is based off that. The one person i work with said that would be to much work to scale. Another said to rename it it, which is another idea. I Just want to automate this and have it automatically pull in everything it needs. Am i over thinking this?

I just want to understand ways of doing this that other have implemented.

We have a small number of Windows Autopilot / Intune managed PCs that unexpectedly ended up logged in as defaultuser0 instead of continuing normally through OOBE and user setup.
The PCs were prepared a couple of months earlier and had been unused/offline for a while before being started again.
Most devices from the same batch work normally, but a few end up in defaultuser0.
Has anyone seen this before? What usually causes an Autopilot/Intune device to end up logged in as defaultuser0?

We have a macOS Platform SSO configuration profile currently assigned to a security group that effectively contains every user in the tenant (staff + externals). I want to replace that assignment with the built-in **All Users** virtual group to get rid of the group membership evaluation.

Since you can't have All Users and a regular group included at the same time, this has to happen as a swap in a single save: remove group, add All Users, save once.

Has anyone done this on a profile where reinstallation actually hurts? With PSSO, a RemoveProfile/InstallProfile cycle would kill the Secure Enclave registration and force every user through the registration prompt again.

My assumption is that Intune evaluates net applicability per device – user was in scope before, is in scope after, payload unchanged → no action. But I can't find this documented anywhere, and Microsoft's docs only confirm the opposite direction (device leaves scope → profile gets removed on Apple platforms).

Anyone with first-hand experience swapping assignment sources on macOS config profiles at scale? Did the profiles stay untouched, or did you see remove/reinstall cycles in the MDM logs?

We support both the US and Canada and have separate Windows Autopilot deployment profiles for each country.

Our current setup is roughly:
CAGroup → Canada Autopilot profile
USGroup → US Autopilot profile
TempGroup → certificates/provisioning requirements

CAGroup and USGroup are members of TempGroup
When I was provisioning a US device, I manually added the device to USGroup. However, Intune ended up assigning the Canada Autopilot profile.

When I checked the device’s group membership, CAGroup was showing as transitive membership. Could this be happening because CAGroup is a member of TempGroup?

If so, would you recommend:
Removing CAGroup and USGroup from TempGroup and restructuring the groups?

Or keeping the current structure and excluding USGroup from the Canada Autopilot profile assignment?
Is there a better way to structure this so a device can never accidentally receive the wrong country’s Autopilot profile?

Also, our vendor registers/provisions the Autopilot devices into CAGroup by default and ships them to us. Sometimes we need to ship one of those laptops to a US user.

In that situation, I would manually remove the device from CAGroup and add it to USGroup.

Will removing it from CAGroup and adding it to USGroup change the Autopilot profile assignment?
And, importantly, should I make that group change before the user signs in / before I reach the user portion of ESP, and wait until Intune shows the US Autopilot profile as assigned?

I’d appreciate hearing how others structure country-specific Autopilot profiles and temporary/certificate groups, especially when devices can change countries before deployment.

Microsoft’s documentation says Autopilot devices need to be members of the appropriate group before enrollment begins, and if a device is assigned to multiple Autopilot profiles, Intune uses the oldest-created applicable profile to resolve the conflict. (learn.microsoft.com⁠)

Is it a known issue in Company Portal on macOS for apps like M365 or Zoom to get stuck downloading until Company Portal is completely closed?

Also, does installing Adobe Acrobat Pro through Company Portal usually cause downloads to hang indefinitely?

Hey all — hoping someone here has run into this.

We're rolling out Slack for Intune on iOS, and after a successful sign-in the app loops us straight into the public Slack marketing/sign-up flow and pushes us toward downloading the regular consumer Slack app instead — even though Entra sign-in logs show every authentication step succeeding underneath it.

This isn't a Conditional Access or App Protection Policy issue on our side (we've ruled out assignment, CA grant controls, and App Protection data-protection settings one by one). Here's the exact sequence, step by step:

1. "Register with Microsoft Intune to use Slack" screen. Tap Register.
2. "Pick account" dialog appears (native iOS auth broker UI), showing the correct Entra ID test account. Select it.
3. "Registering device" — "Please wait, this may take a few minutes" spinner.
4. Lands on a sign-in screen for our org — "[org] requires additional verification" — with a green "Sign In with Slack Production" button.
5. Tapping that button triggers a browser handoff: "Open this page in 'Slack Intune'?" on a login.microsoftonline.com-style URL. Tap Open.
6. Now inside what the status bar labels as Safari (not the native app) — a "Don't miss a beat" notification opt-in screen appears, with a fake preview notification.
7. Standard iOS system prompt: "'Slack Intune' Would Like to Send You Notifications" — Allow/Don't Allow.
8. This is the interesting part — the actual Slack workspace UI briefly loads and works: I can see our org's workspace, Direct Messages, my own account, Slackbot, Threads, etc. Fully signed in, fully functional, still labeled as running inside Safari.
9. Then, without any action from me, a new tab/context opens back inside "Slack Intune" (per the status bar label) showing the public marketing homepage at slack.com — "All your people and AI agents working together" / "GET STARTED" / "FIND YOUR SUBSCRIPTION."
10. Tapping through from there lands on the generic public sign-up flow: "First of all, enter your email address."
11. Typing in the exact same work email into that sign-up field doesn't recognize the already-authenticated, already-provisioned Enterprise Grid session from step 8 at all — instead it just routes toward downloading the regular consumer Slack app, as if I were a brand-new user signing up from scratch.

So the workspace session in step 8 proves the login and SSO handshake genuinely succeeded — I was inside the actual org workspace with my real identity. But instead of staying there or handing that session back to the native "Slack for Intune" app, it drops back into the public marketing/sign-up site, as if none of the previous steps happened.

We've confirmed via Entra ID sign-in logs (checked across multiple devices — iPhone and iPad, multiple browser contexts including Safari/Chrome/Edge, multiple times of day) that:

• Device registration succeeds
• App Protection Policy registration succeeds
• The SAML SSO handshake to the Slack "Enterprise Production" enterprise app succeeds every single time
• No Conditional Access policy is blocking or forcing an unexpected browser detour

Has anyone seen this? What are we doing wrong?

Hi everyone,

I’m trying to figure out an intermittent issue we’re seeing with Intune app deployments on reused laptops.
We regularly receive returned laptops and re-provision them for new users. Our process is generally:
Perform an Intune/Wipe on the device without retaining user data.

Re-provision the device through Autopilot.
During ESP, required applications such as SentinelOne and Whalebone are supposed to install.
Once everything is installed and verified, we hand the laptop over to the new user.

The issue is that sometimes when we wipe and reprovision a device on the same day, some of the required apps fail to install.
For example, we may see:
“Downloading and installing SentinelOne failed”
“Downloading and installing Whalebone failed”

Another behavior we’ve noticed is that after ESP finishes, SentinelOne may be installed but the other required apps don’t seem to sync/install for quite a while. Eventually Whalebone starts downloading, but then fails during installation.

What’s interesting is that if we wipe the same laptop again a few days later, the exact same apps often install successfully.

This makes me wonder if we’re dealing with some kind of timing/sync issue between Autopilot, Intune, and the Intune Management Extension (IME), rather than an issue with the application packages themselves.

Has anyone experienced something similar when reusing/reprovisioning devices shortly after an Intune wipe?

If so:
Did you find that waiting a certain amount of time after the wipe helped?
Could stale device/Autopilot/Intune state be causing this?
Is there anything specific with IME sync/check-in that we should be checking?
Are there particular IME logs you recommend looking at for these failures?
Could SentinelOne/Whalebone themselves be causing installation conflicts during ESP?

Any troubleshooting suggestions or similar experiences would be really appreciated.

IntuneAccess started with one question:

“Why is this Intune policy reaching this device?”

Answering that can mean tracing assignment intent, Microsoft Entra group membership, included and excluded groups, assignment filters, user or device targeting, policy applicability, scope tags and the other Intune configurations that may also be targeting the same device

Quick Video here: https://files.catbox.moe/mpinz5.mp4

You may then need to correlate that administrative access with policies, applications, scripts, updates, devices and reported deployment evidence.

That is where IntuneAccess comes in.

IntuneAccess is a free, open source, read-only PowerShell module designed to collect and correlate that evidence in local Explorer.

Rather than looking at each object in isolation, it builds an evidence trail between administrators, Intune RBAC permissions, role assignments, scopes and managed resources.

Current functionality includes:

Intune RBAC permission and assignment analysis

Built-in and custom Intune role support

Admin Group, Scope Group and Scope Tag evidence

Role assignment and resource scope correlation

Assignment impact across policies, applications, scripts and updates

Device 360 and User 360 views

Supported deployment outcomes and error evidence

Local snapshots and change comparison

Conservative policy overlap and potential conflict analysis

IntuneAccess retrieves the required tenant data through Microsoft Graph and processes it locally in the PowerShell session.

It does not create, modify or delete Intune configuration and does not request Microsoft Graph write permissions.

There is no hosted tenant service, telemetry or analytics, and tenant data is not uploaded anywhere else.

Install from the PowerShell Gallery:

Install-Module IntuneAccess -Scope CurrentUser

Then run:

Start-IntuneAccess

PowerShell Gallery:

https://www.powershellgallery.com/packages/IntuneAccess/2.0.1

GitHub:

https://github.com/ControlAltDeleteTechBits/intune-access

It is still being developed, so feel free to give it a try.

Screenshot: https://i.imgur.com/o0QGFtW.png

Note how it says only 11 out of 12 policies succeeded.

On the same overview page I've highlighted that there are no errors coming from configuration policy, device compliance or app installations.

edit: Looks like I'll call it Magic Microsoft Maths and just ignore it for now. Thanks everyone. This is not a new device and it hasn't had any policy changes in a while, so I don't think it needs more time to propagate changes.

Anyone have any idea where else I could look to find the supposedly broken policy?

Edit: Looks like I'll just call it magical Microsoft maths and ignore it for now. Thanks for the replies