Intune App inventory Graph
Hi All, I've enabled the configuration profile to receive app inventory data in Intune. In the GUI the data I can view the data just fine, but I would like to use Graph to automate this data and create custom reports. When I use the following https://graph.microsoft.com/beta/deviceManagement/managedDevices/[device-id]/deviceInventories('ApplicationProperties') I get an error: "Forbidden - 403 - 199 ms Either the signed-in user does not have sufficient privileges, or you need to consent to one of the permissions on the Modify permissions tab" even though the docs I can find about permissions are OK.Windows Compliance
Hi All I hope you are well. Anyway, I'm having a nightmare with Device Compliance on Windows devices. Recent research of Microsoft and other guides and documents reveals seriously conflicting information. To sum up, we have a mixture E3 and F3 users logging onto Windows devices. These Windows devices have a basic compliance policy deployed that requires BitLocker, AV, Firewall etc. The problem starts when multiple users logon to a Windows device, as one would expect in a shift based org, with the device showing as compliant for one user but not the other(s). One of the biggest non compliance issues is with BitLocker, but it does vary. Now reading online, I can see a Shared / Multi User config which can be deployed to Windows devices. Is this what I need? Furthermore, our Compliance policies which contain Require BitLocker are currently deployed to devices. Should this policy be deployed to users instead? The info available online is massively confusing and conflicting with some "guru's" stating that Compliance policies are best deployed to users but other state that BitLocker policies should be deployed to devices. Can anyone help me solve this E3 / F3 Compliance riddle? SKConditional Access Reporting for Intune Enrolled Windows Devices
Hi All I hope you are well and that this is the right community for this. Anyway, I have a Conditional Access policy that requires Intune enrolled Windows devices to be compliant. Prior to turning this on, I'd like to use Reporting Mode with Insights and Reporting. Now, I do have Insights and Reporting setup and working. What I want to ensure is: My policy has the correct device filter so that it only targets company devices I can see failures from users on company devices only My current device filter is: Include - device.deviceOwnership -eq "Company" However, in the Insights and Reporting, I'm still seeing failures from unmanaged devices. Is my device filter or something else wrong? Info appreciated Stuart
co-managed Working flow
Hi SCCM Expert, I would like to understand how co-management works in a multi-tenant scenario. Currently, my SCCM environment manages devices from two different domains: abc.com → Integrated with ABC Intune Tenant xyz.com → Integrated with XYZ Intune Tenant To enable co-management, we configured the Cloud Attach/Co-Management settings in SCCM using a Global Administrator account from the abc.com tenant. We then created a pilot collection and added devices from both abc.com and xyz.com domains. My questions are: Since co-management was configured using credentials from the abc.com tenant, how can devices belonging to the xyz.com tenant successfully become co-managed and receive Intune workloads from their respective tenant? During the co-management enrollment process, what determines which Intune tenant a device enrolls into? Is the SCCM co-management configuration tied to the tenant used during setup, or does the device use its own Azure AD/Entra ID registration information to identify the target tenant? What is the actual trigger point for the transition from SCCM management to co-management/Intune enrollment? If devices from multiple tenants exist in the same SCCM hierarchy, how does SCCM ensure that each device is enrolled into the correct Intune tenant? Could you please help clarify the architecture and enrollment flow in this scenario?
[IME 1.106.151.0] Win32 app RequiredUninstall intent not refreshed until restart IME service
we changed assignment intent from Required to Uninstall for win32 app. However, AppActionProcessor.log continuously evaluates the app with the old target intent:RequiredInstall. It never enters the uninstall evaluation workflow during normal periodic check-ins, even after waiting for the default IME check-in cycle and triggering sync from Access work or school. Only after restarting the IntuneManagementExtension service will the IME process reload the payload, and AppActionProcessor.log finally show targeted intent:RequiredUninstall, then proceed to evaluating uninstall enforcement actions.
Secure Enterprise Onboarding and Domain Join Method - Concept
Hey Microsoft Hub community — Rodrigo here. After nearly two decades working in enterprise Windows environments, I’ve seen the same onboarding problem repeat everywhere: trust is granted too early, too inconsistently, and across too many disconnected systems. To address this, I created APilot — a Microsoft‑aligned concept for secure Windows onboarding and domain join. We’ve modernized identity. We’ve modernized device management. We’ve modernized compliance. But onboarding — the moment trust is established — remains fragmented. APilot — A Unified, Microsoft‑Aligned Trust Orchestration Lifecycle APilot reframes onboarding as a governed trust event, not just a technical step. It brings together Microsoft Entra ID, AD DS, Intune, Windows Autopilot, Conditional Access, PKI, and CMDB governance into a single zero‑trust onboarding lifecycle. The core principle: A device should not be considered trusted or productive until identity, asset ownership, posture, and certificate state are validated together. Why This Matters Enterprise onboarding is often split across identity, device management, compliance, PKI, and asset lifecycle systems. This fragmentation leads to: failed joins and poor first‑time success rates partially trusted devices entering production stale or orphaned device records certificate drift and expired trust artifacts inconsistent onboarding experiences across teams increased helpdesk and support burden higher risk from lost, stolen, or decommissioned devices APilot addresses these issues through a governed lifecycle that includes: identity validation device identity collection CMDB verification compliance gating temporary trust windowing join authorization quarantine and rollback wipe and decommission controls Microsoft Ecosystem Alignment APilot aligns directly with: Entra ID identity governance Intune compliance & Autopilot provisioning AD DS domain join PKI certificate trust Conditional Access CMDB / ITSM asset governance ZTNA segmentation The result: a device becomes trusted only when identity, posture, certificate state, and asset ownership converge. Who This Concept Is For APilot is intended for: Microsoft ecosystem stakeholders identity & endpoint engineering teams Zero Trust and security architects enterprise IT operations leaders CMDB / ITSM governance teams If this resonates with Microsoft PMs or architects, I’d be happy to collaborate on deeper exploration or refinement. Full technical concept: https://github.com/RodrigoACriscuolo/criscra/blob/main/Domain-Join_Knowledge.is.Power.md?utm_source=copilot.com This is my first contribution, and I invite fellow engineers and architects to contribute their perspectives. Today, many enterprises still rely on custom scripts or adopt tools like NinjaOne simply because they lack a unified Microsoft‑aligned approach. My hope is that APilot helps us elevate our Microsoft environment and improve the operational reality we face every day.
New MD-102 : Weird departure from course traditional design
The first slide deck is tremendously long. It takes me 5 hours of lecture to get students into the first lab. The slide decks are very repetitive and could often be replaced with Instructor Demonstration slides. The topics are far-ranging: it mixes identity administration, Intune RBAC, Android enrollment, LAPS, Windows enrollment, and Autopilot before students have a stable mental model of the fundamentals of: Device enrollment > Policy/app creation > Targeting assignment. The first lab is disjointed, with many configurations, such as Creating Administrative units, Assigning Scope tags, and Custom Intune Roles, not implemented until later in the week in Exercise 5. The delegation model, administrative-unit work, and Android restrictions obscure the basics students should understand first. The course design seems to be a big departure from most, if not all, Microsoft courses I have ever taught. No Entra Connect Lab and no real Autopilot lab are a disappointment to some students as well
Call for perspectives: Endpoint Management Experiences of IT Professionals Survey
Hi Endpoint management community, we’d love to hear from you! How do you manage employee devices today? Where do you turn for guidance and support? And how are you thinking about AI-enabled ways of working? 🔗 Share your perspective in our 15-minute survey: https://lnkd.in/gmjkFx8P We’re especially interested in hearing from people in their first five years in the field, but all experience levels are welcome. If someone in your network comes to mind who has relevant experience, feel free to pass the survey along!WHFB - Intune - Only PIN works and it causes print issues
Hello, I have personally attempted to deploy this for my environment and so has a colleague. We deploy windows hello specifically to a single machine or user, the PIN ends up being the only option which can be used, the device will say every other option is not available. It will constantly pop up at the bottom right that the password needs to be put in again to authenticate the user and printing will not work at all. The devices are fully capable of using facial recognition. Has anyone encountered any of these issues in a similar fashion with an AD > Entra environment ? Thank you, Jamie.
