Implementing Intune RBAC and Scope Tags for Zero Trust and Least Privilege
If you’re rolling out Microsoft Intune at scale, the hardest part usually isn’t creating policies—it’s making sure the right people can manage the right things, without turning every admin account into a “keys to the kingdom” risk. In this guide, you’ll learn how to use Intune RBAC and Scope Tags to enforce least privilege, build clear management boundaries by region/agency/environment, and pair device compliance with Entra Conditional Access to strengthen a Zero Trust posture—plus a practical RACI approach so ownership stays clear as your environment grows. TL;DR Use Intune RBAC to align admin permissions to job responsibilities, reducing standing privilege and limiting who can change policies, apps, and security settings. Use Scope Tags to create visibility/management boundaries (region, agency, environment) so admins only see and manage what they own. Pair Intune compliance + Entra Conditional Access to enforce “access only from compliant devices / protected apps,” which supports a Zero Trust posture. Establish a RACI model so ownership is explicit across Endpoint, Identity, Security, Apps, AD, Help Desk, and Compliance teams. Track outcomes (compliance rates, blocked risky sign-ins, RBAC audit events, scope boundary effectiveness, GPO migration progress) and review on a regular cadence. Zero Trust and Least Privilege in Modern Endpoint Management Zero Trust is an approach to security that treats every access attempt as untrusted until it is proven otherwise. Rather than relying on “inside the network = safe,” organizations evaluate each request using signals such as user identity, device health, location, and risk, and they re-check those signals over time. In an endpoint program, Microsoft Intune supports this model by establishing device compliance, applying app protection where appropriate, and working with Conditional Access so that access decisions can depend on verified user and device posture. A practical way to describe Zero Trust is through three recurring themes: (1) make access decisions using explicit verification (strong authentication plus context and risk signals), (2) minimize privilege by granting only the access needed and reducing standing admin rights where possible, and (3) design for compromise by limiting lateral movement and reducing the impact of any single breach. These concepts align with Microsoft’s published Zero Trust guidance. Role-Based Access Control (RBAC) in Intune allows organizations to delegate administrative permissions based on roles, responsibilities, and scope. For modern endpoint environments, RBAC ensures that only authorized personnel can manage devices, deploy configurations, or access sensitive data, which is a foundational control in a Zero Trust model where access is granted based on least privilege and verified identity. By combining Intune's RBAC capabilities with Scope Tags, organizations can create visibility boundaries that align with their organizational structure, whether by region, department, business unit, or function. This prevents over-allowing permissions by assigning only the rights needed for each role, supports Zero Trust by enforcing least privilege and role-based access, and improves operational security by limiting who can manage devices and policies. Understanding Intune RBAC Roles and Permissions Microsoft Intune provides nine built-in RBAC roles designed to address common administrative scenarios. Each role has predefined permissions that determine what actions users can perform within the Intune environment, helping organizations delegate administrative tasks while maintaining control over access to sensitive information. The built-in roles include Intune Administrator with full access to all Intune features and settings (This role should not be used for every day management tasks and should be limited to only a few individuals who would be responsible for performing more elevated tasks in the Intune Portal), Policy and Profile Manager who manages device configuration profiles and compliance policies, Application Manager who manages mobile and managed applications, Endpoint Security Manager who manages security and compliance features, Help Desk Operator who performs remote tasks on users and devices, Read-Only Operator with view-only access, School Administrator for Windows 10 devices in Intune for Education, Intune Role Administrator who manages custom roles and assignments, and Cloud PC roles for managing Cloud PC features and Windows Autopatch roles for managing updates. Built-in Role Primary Permissions Use Case Application Manager Manages mobile and managed applications, app configuration policies, and app protection policies Teams responsible for deploying and managing organizational apps across devices Policy and Profile Manager Manages device configuration profiles, compliance policies, and conditional access policies IT administrators configuring device settings and ensuring compliance across the organization Endpoint Security Manager Manages security baselines, endpoint detection and response, and BitLocker policies Security teams focused on device protection and threat mitigation Help Desk Operator Performs remote tasks including device restart, password reset, and remote lock First-line support staff assisting end users with device issues Read-Only Operator View-only access to all Intune data and reports without modification rights Auditors and stakeholders needing visibility without administrative capabilities Beyond built-in roles, Intune supports custom roles that allow administrators to define specific permissions for users or groups based on their responsibilities. Custom roles enable fine-grained access control by selecting granular permissions for each role, ensuring users have access only to the features and data they require. For example, a custom role could grant only the 'Rotate local administrator password' permission to a specific Helpdesk Managers group, demonstrating the principle of least privilege in action. Create Custom Roles Login to the Intune Admin Portal with the Intune Administrator Role and navigate to Tenant Administration> Roles > All Roles > Create then select the type of role you want to create. I will select “Intune Role” Give your Custom Role a Name and a brief description. Scroll through the list of permissions as they will all be set to no by default and select the permissions relevant to the responsibility of the custom role. If you have already created your Scope Tag add it here, then review and select create Once the role is created you can select the new role and create an assignment. Give it a name and description, then select the admin group to be assigned to the role. Add the groups that the role will be managing. Add your relevant Scope Tags then select create. To take things one step further I would recommend leveraging Privileged Identity Management (PIM) for groups so that you can leverage Just-in-Time Assignments for the Intune roles. One last note on custom roles if you do not want to start from scratch with the permission sets, you can also duplicate a built-in role and modify the permissions as needed. Just select the 3 dots to the right of the role and select Duplicate Implementing Scope Tags for Distributed IT Management Scope Tags are labels that help control what different admins can see and manage in Microsoft Intune. By adding scope tags to Intune items like configuration profiles, apps, policies, or device groups and assigning the same labels to admins, organizations create clear boundaries, so each admin only sees the devices and settings they are responsible for. This capability is essential for distributed IT environments where different teams manage different locations, departments, or business units. Every Intune tenant includes a default scope tag that is automatically applied to all objects and admins, ensuring everything continues working smoothly even without custom tags configured. The key benefits of using scope tags include enabling distributed IT management by allowing regional or departmental admins to manage their specific resources, controlling access by limiting admin visibility to specific resources, enhancing security by preventing unauthorized access, improving organization by grouping resources by scope, and providing flexibility to support multiple administrative models. Scope tags work together with RBAC role assignments through three components: the role defining what actions admins can perform, scope tags determining which objects admins can see, and scope groups limiting which users and devices they can affect. Common use cases for scope tags include managed service providers limiting access to specific customer resources, regional IT administrators ensuring teams only manage and see objects relevant to their region, separating testing versus production environments when a dedicated test tenant is not available, and separating Azure Virtual Desktop resources for AVD administrators. Creating Scope Tags While still under Tenant Administration> Roles select Scope Tags Then Create. Give it a name and description. Assign the proper groups then select create. If this is all implemented properly, the admin will only be able to see items and devices that have the Scope tag that has been assigned to their role. Here are views of the apps in my tenant when signed in as a Intune Administrator (which Scope tags do not apply t And here are the same views when logged in with an admin with the iOS admin role that we created. Establishing a RACI Model for Intune Management While establishing a RACI model is not something done in the Intune portal, it is crucial in my opinion for enterprise customers since Intune covers such a vast number of capabilities that should not all be done by one team if we are practicing least privilege and zero trust. A RACI matrix is a powerful tool for defining organizational roles and responsibilities, identifying who is Responsible, Accountable, Consulted, and Informed for each activity. In Microsoft Intune management, implementing a RACI model eliminates ambiguity about which teams handle security policies, application management, patch compliance, Conditional Access, and GPO migration. The RACI framework defines four key roles: Responsible individuals execute the task or deliverable, Accountable is the single person ultimately answerable for correct completion and decision-making authority, Consulted are experts or stakeholders whose feedback is sought during the task, and Informed are those kept up to date on progress or decisions without actively contributing. For Intune environments, a well-designed RACI matrix promotes organizational alignment by mapping all key stakeholders across central IT and individual agencies or departments, clarifies decision rights by defining who approves, who executes, and who provides input for each Intune activity, ensures accountability by assigning a single accountable party for each deliverable to prevent diffusion of responsibility, and improves communication by identifying upfront who needs to be consulted and kept informed. Based on internal implementation experience and with Microsoft Federal customers, organizations should list deliverables not just activities, define roles not individual names to ensure the matrix remains relevant as people change positions, enforce exactly one Accountable person per task, assign Responsible, Consulted, and Informed roles thoughtfully, validate in a short review session, publish where work happens, and evolve the matrix as the project evolves. RACI Matrix for Security Policies and Compliance The following are just generic examples of some of the workloads and how they could be managed with a RACI matrix. Security policies and compliance management in Intune require clear ownership across multiple teams. Organizations must define who creates compliance policies requiring device encryption and minimum OS versions, who deploy security baselines like the Microsoft Defender for Endpoint Security Baseline, who manages Conditional Access policies that require device compliance, and who responds to non-compliant devices. A typical RACI model for security policies assigns the Cloud Security Team as Accountable for overall security policy strategy and compliance requirements, the Endpoint Team as Responsible for creating and deploying compliance policies and security baselines in Intune, the Application Team as Consulted for application-specific security requirements, the Help Desk as Informed about policy changes that may affect device compliance status, and the Compliance Team as Consulted to ensure policies meet regulatory requirements and as Informed about compliance status reports. For patch management and application compliance, the RACI model shifts slightly with the Endpoint Team becoming Accountable for patch deployment strategy and timing, the Application Team becoming Responsible for testing application compatibility with updates, the Help Desk becoming Responsible for addressing user-reported issues after patches, and the Cloud Security Team becoming Consulted for security update prioritization. Organizations implementing Windows Autopatch benefit from Microsoft managing problematic quality and feature update deployment cancellations using telemetry, automatically splitting devices into rings based on percentage of total devices, and managing patching behavior for Windows, Microsoft 365 Apps, Edge, Teams, and Drivers. This shifts some Accountable and Responsible designations to Microsoft while keeping internal teams Informed and Consulted. Intune Activity Accountable Responsible Consulted Informed Security Policy Creation Cloud Security Team Endpoint Team Application Team, Compliance Team Help Desk Compliance Policy Deployment Cloud Security Team Endpoint Team Compliance Team Help Desk, Application Team Security Baseline Management Cloud Security Team Endpoint Team Application Team Help Desk, Compliance Team Patch Management Strategy Endpoint Team Application Team Cloud Security Team Help Desk, Compliance Team Non-Compliance Response Cloud Security Team Endpoint Team, Help Desk Compliance Team Application Team Application and Conditional Access Management Responsibilities Application management and Conditional Access in Intune span multiple organizational functions requiring coordinated responsibility. For application lifecycle management, the Application Team is both Accountable and Responsible for deployment strategy, app protection policies, creating and testing app packages and configurations. The Endpoint Team is Consulted for deployment targeting and device compatibility, while the Help Desk is Informed about new applications and support procedures. For Conditional Access policy management, multiple teams coordinate their expertise. The Cloud Security Team is Accountable for overall Conditional Access strategy and Zero Trust implementation. The Endpoint Team is Responsible for ensuring device compliance status feeds correctly into Conditional Access decisions. The Identity Team is Responsible for configuring Conditional Access policies in Microsoft Entra ID. The Application Team is Consulted about application-specific access requirements, and the Help Desk is both Informed about access restrictions and Responsible for assisting users blocked by Conditional Access policies. Conditional Access integration with Intune creates a powerful Zero Trust security model where Intune evaluates device compliance based on compliance policies, compliance status is reported to Microsoft Entra ID, Conditional Access policies check device compliance status, and access is granted or blocked based on compliance status. For mobile application management, the Application Team is both Accountable and Responsible for app protection policies including data protection settings, access requirements like PIN and biometric authentication, and integration with Conditional Access. The Cloud Security Team is Consulted for security requirements, and the Endpoint Team is Informed about app-level controls that complement device-level policies. GPO Migration to Intune: Roles and Responsibilities Migrating Group Policy Objects from on-premises Active Directory to Microsoft Intune represents a critical transformation requiring clear ownership and phased execution. The migration process uses Group Policy Analytics, a built-in tool in Intune that analyzes on-premises GPOs by importing them as XML exports and translating them against the Settings Catalog to determine which policies are supported, deprecated, or unsupported in Intune. Organizations export GPOs from the Group Policy Management Console by right clicking the GPO, selecting Save Report, and saving as XML format. After importing to Intune via Devices > Group Policy Analytics, the tool generates a percentage-based report showing exactly how many settings have a direct 1:1 mapping to modern Intune settings. The Group Policy Analytics tool categorizes settings into three distinct types: Supported settings that have a direct counterpart in Intune and can be migrated via Settings Catalog policies, Deprecated settings no longer applicable to modern Windows versions, and Not Supported settings that do not currently have a CSP mapping and often require alternative management methods like PowerShell scripts or Proactive Remediations. Approximately 45% of GPOs can be successfully migrated to Settings Catalog, 30% require alternative approaches via PowerShell remediations, and 25% can be deprecated and retired based on typical migration outcomes. RACI Model for GPO Migration For the RACI model, the Endpoint Team is Accountable for the overall GPO migration strategy and timeline, the Active Directory Team is Responsible for exporting GPOs and documenting current policy structures, the Application Team is Consulted to validate that application-specific GPOs migrate correctly and that applications continue functioning, the Cloud Security Team is Consulted to ensure migrated policies maintain security posture, and the Help Desk is Informed about changes to device configurations and becomes Responsible for user communication about policy transitions. Integrating Conditional Access with Device Compliance Conditional Access integration with Intune device compliance creates an additional layer of security by enforcing access controls based on device compliance status and app protection policies. This integration ensures that only compliant devices and protected apps can access organizational resources, forming a cornerstone of Zero Trust architecture. Device-Based Conditional Access Implementation Device-based Conditional Access uses device compliance status from Intune to control access to organizational resources through a four-step process: Intune evaluates device compliance based on compliance policies Compliance status is reported to Microsoft Entra ID Conditional Access policies check device compliance status Access is granted or blocked based on compliance status To implement device compliance Conditional Access, organizations first create and assign device compliance policies in Intune requiring elements like BitLocker encryption, Microsoft Defender antivirus enabled, Windows Firewall enabled, and minimum OS version requirements. Then in the Microsoft Entra Admin Center under Security > Conditional Access, administrators create policies specifying: Users as target groups like Corporate Users Cloud apps as All cloud apps or selected Microsoft 365 apps Device platform as Windows or other platforms Access control requiring device to be marked as compliant Measuring Success and Continuous Improvement Organizations implementing Intune RBAC and Scope Tags should establish metrics to measure success and identify areas for continuous improvement. Key performance indicators include percentage of devices compliant with security policies, time to resolve non-compliance issues, number of unauthorized access attempts blocked by Conditional Access, percentage of GPOs successfully migrated to Intune Settings Catalog, and administrative efficiency measured by reduction in time spent on routine management tasks. Compliance reporting in Intune provides visibility into device compliance status across the organization, with reports showing compliant versus non-compliant devices, specific compliance policy violations, and trends over time. Organizations typically see compliance rates improve from a 65% baseline to 95% or higher within 12 months of implementing proper RBAC roles and Scope Tags. This improvement results from clearer ownership, faster policy deployment, and more focused administrative oversight. Conditional Access sign-in logs in Microsoft Entra ID reveal which access attempts are granted or blocked, the reasons for access decisions, and patterns of risky sign-ins that may indicate compromised credentials or devices. For RBAC effectiveness, organizations should monitor audit logs to track which administrators are performing which actions, identify any privilege escalation attempts or suspicious administrative activity, and ensure separation of duties is maintained. Scope tag effectiveness can be measured by confirming that administrators only see resources within their designated scope, tracking incidents where admins requested access outside their scope, and validating that regional or departmental segregation is working as intended. Organizations should establish a regular review cadence with monthly compliance and security posture reviews, quarterly RBAC and Scope Tag access reviews, bi-annual GPO migration progress assessments, and annual Zero Trust maturity assessments. Disclaimer All screenshots are from a non-production lab environment and can/will vary per environment. All processes and directions are of my own opinion and not of Microsoft and are from my years of experience with the Intune product in multiple customer environments References Role-based access control (RBAC) with Microsoft Intune - Microsoft Intune | Microsoft Learn Use role-based access control (RBAC) and scope tags for distributed IT - Microsoft Intune | Microsoft Learn Aligning responsibilities across teams - Cloud Adoption Framework | Microsoft Learn How to Require Device Compliance with Conditional Access - Microsoft Entra ID | Microsoft Learn Configuring Microsoft Intune just-in-time admin access with Azure AD PIM for Groups | Microsoft Community Hub
Delivery Optimization breaking Windows 11 update downloads?
We started seeing Delivery Optimization–related issues with Windows updates after upgrading devices to Windows 11 24H2. In our SCCM environment, Windows updates begin downloading but consistently fail or stall partway through the download. In many cases, the download restarts multiple times and eventually errors out. This behavior is consistent across multiple devices and different boundaries. These same devices were patching normally prior to the 24H2 upgrade. Since moving to 24H2, patching has become unreliable, especially for larger updates. From what we’re seeing, this doesn’t look like a traditional content or boundary issue. It feels like Delivery Optimization is failing mid-transfer or not resuming downloads correctly after the OS upgrade. So far we’ve checked the following: - Boundaries and boundary groups are unchanged - Content is available and distributed correctly on DPs - No recent SCCM site or infrastructure changes - Network connectivity looks normal On the client side, we’ve been reviewing: - DataTransferService.log (downloads start but fail or restart mid-way) - DeliveryOptimization logs (showing repeated retries / stalled transfers) - CAS.log and LocationServices.log (content location looks normal) - WUAHandler.log (update detection looks fine) Overall, detection and policy seem healthy — the issue appears during the actual download phase. Has anyone else seen Delivery Optimization downloads stall or fail during Windows patching after upgrading to Windows 11 24H2? If so, did you find a specific DO setting, policy change, or workaround that stabilized patching?Close the Year Strong with Surface for Business Deals
As organizations look to maximize their remaining budget and prepare for 2026, now is the moment to modernize device fleets with Surface for Business. These limited-time Surface promotions make it easier to accelerate refresh cycles, strengthen endpoint security, and equip employees with devices that are AI-ready from day one. Surface for Business devices combine productivity-forward design, leading AI capabilities, and Microsoft security at multiple layers. Whether refreshing a subset of users or upgrading entire departments, organizations can close the year with hardware that helps reduce risk, assists in lowering management overhead, and positions teams for the next wave of AI-driven productivity. Secure by Design Surface for Business devices deliver hardware-based protections aligned with Secured-core PC standards. Hardware-based security, advanced firmware protections, and a growing number of memory-safe drivers help reduce exposure across the stack, providing peace of mind that clears the way for AI innovation. AI-Ready With advanced processors including powerful AI chips on supported models, Surface for Business devices are ready to help employees maximize their skills using AI to drive business forward. From a dedicated Copilot key 1 to Foundry on Windows 2 for developing local agents, these devices provide the foundation for people to achieve their best. Learn more about unlocking AI innovation in our new eBook. Ready to Deploy Surface for Business devices support Windows Autopilot 3 , enabling IT teams to deploy devices directly to employees, preconfigured with corporate profiles and security baselines, without imaging or desk-side setup. Combined with centralized management through Microsoft Intune 4 , organizations can reduce deployment time and help keep endpoints consistent from day one. Make the Most of Year-End Purchasing Opportunities Maximize remaining 2025 budget by exploring end-of-year savings on select Surface for Business devices. Work with your preferred reseller to capitalize on year-end spend, or purchase directly through Microsoft Store in the US 5 to take advantage of available offers that make modernizing your device fleet easier as you prepare for 2026. Resellers can help organizations align device selection, deployment plans, and support needs while optimizing budget utilization. Businesses purchasing through Microsoft Store benefit from fast, free shipping and a 60-day return window on most physical products. 6 Across both channels, Surface for Business offers provide a cost-effective path to refresh devices now rather than deferring upgrades—helping IT leaders complete their roadmap, meet procurement targets, and deliver new value to end users before the new year. Find a reseller [https://www.microsoft.com/surface/business/where-to-buy-microsoft-surface Buy from Microsoft Store US [https://www.microsoft.com/en-us/store/collections/surface-deals-bundles] References Feature availability varies by device and market. See Key Support for details. Some capabilities may require additional subscriptions not included with Windows or Surface devices. Windows Autopilot device preparation depends on specific capabilities available in Windows client and Microsoft Entra ID. It also requires a mobile device management (MDM) service such as Microsoft Intune. These capabilities can be obtained through various editions and subscription programs. Additional licenses required, not included with Surface. Offers and promotions vary by market. Terms apply. Microsoft Store only ships to certain countries; see Shipping options, costs, and delivery times - Microsoft Support for details.Gpresult Like Tool For Intune
Hi, Jonas here! Or as we say in the north of Germany: "Moin Moin!" I had to troubleshoot a lot of Intune policies lately and I used a variety of tools for that. At the end, I built my own script to have a result which looks similar to what “GPresult /h” creates for on-premises group polices. The script is inspired by the following article: https://doitpshway.com/get-a-better-intune-policy-report-part-2 by Ondrej Sebela. It follows a similar approach, but without any module dependencies and fewer output options, as my script only generates an HTML page. What started as a script is now a module which might have more functions in the future. Feel free to read any of my other articles here: https://aka.ms/JonasOhmsenBlogs How to get the module The PowerShell module is called: "IntuneDebug" and can be installed or downloaded from the PowerShell Gallery. Install the module by running the following command: Install-Module -Name IntuneDebug The module repository can be found here https://aka.ms/IntuneDebug in case you want to download the module manually or want to contribute to it. The command to get the report is called: “Get-MDMPolicyReport” How to use Get-MDMPolicyReport The function can run without administrative permissions and without any parameters on a windows machine. But you can also start the function with administrative permissions to get more data about Intune Win32Apps and their install status. Use parameter “-MDMDiagReportPath” to load MDM report data captured on a remote machine. But more on that in section “How to use parameter -MDMDiagReportPath“ So, in summary, the function can run locally to output information specific to that device, or it can parse already captured data via the “-MDMDiagReportPath” parameter. It cannot gather data remotely, though. The function output As mentioned earlier, the only output of the function is an HTML file which will automatically open in Edge. The output is grouped into sections to make the report easier to read. The page looks like this when all sections are collapsed: Section: "DeviceInfo <Devicename>" DeviceInfo shows general information about the device and the Intune sync status: Section: "PolicyScope: Device" This section shows all the settings applied to the device grouped by area/product. Note: If you’re coming from ConfigMgr you might expect a policy ID in the report. While an Intune policy has an ID, the ID is not stored on the device. That’s by-design and that’s the reason why we just see the settings that apply to a device in this report. The following example shows some basic Defender and Delivery Optimization settings grouped together. You can also see the system's default value if there is one and the winning settings provider. This should typically be the MDM provider like Intune, but it could also be a different provider for some settings depending on the setup. Section: "PolicyScope: <SID> <UPN>" This section shows all the policies applied to a user. The user’s SID and UPN (UPN only when run locally) are visible in the policy-scope header. If there are multiple users working on a machine, each user will have their own section in the report. Section: "PolicyScope: EnterpriseDesktopAppManagement" This section shows all MSI installation policies from Intune. NOTE: Win32 and store apps are visible in the “Win32Apps” section. The application name is not available, instead I show the MSI filename to give an indication of what type of app that is. Section: "PolicyScope: Resources" Under resources we will see policies which typically contain some sort of payload. Like a certificate or Defender firewall rule. I tried to make each section as readable as possible. So, the output varies by type. Certificates for example, are shown in a different format as Defender firewall rules. NOTE: If the function runs without the parameter “-MDMDiagReportPath” it will try to enrich the policy info with as much data as possible. This is not possible when working with captured MDM-reports from a remote machine. The output might be limited in that case. Section: "PolicyScope: Local Admin Password Solution (LAPS)" This section shows all the settings applied to the device coming from a LAPS policy as well as some local settings. Section: "PolicyScope: Win32Apps" This section shows all available Win32App policies. Those apps can be installed already or just assigned as available. If you need more information about the installation status, you need to run the function with administrative permission. This only works locally and cannot be used with parameter “-MDMDiagReportPath” since the extra data is coming from the local registry. If a script is used for the detection or requirement, the script will be parsed and shown as it is. Use the copy button to copy the script and test it locally if needed. When the script is run as administrator locally, it will try to get more information about the actual installation status of an application: Section: "PolicyScope: Intune Scripts" Intune Scripts will show script policies and their current state. The example below shows a remediation script with the detection output string "Found". It does not have an remediation action and therefore no data for the related properties. Unfortunately, the script name is not part of the policy and cannot be shown here. But you can use Graph Explorer https://aka.ms/ge and use the following endpoint to get the script name by entering the script ID of your script: "https://graph.microsoft.com/beta/deviceManagement/deviceHealthScripts/<ScriptID>?$select=id,displayName" Where the data comes from The function will use the following command to generate an MDM report: MdmDiagnosticsTool.exe -out “C:\Users\PUBLIC\Documents\MDMDiagnostics\<DateTime>” NOTE: The tool MdmDiagnosticsTool.exe is part of the Windows operating system. More about it can be found HERE The tool will export the data to C:\Users\PUBLIC\Documents\MDMDiagnostics to a folder in the following format: "yyyy-MM-dd_HH-mm-ss" The function will then parse the following two files to extract the required data without administrative privileges: MDMDiagReport.html MDMDiagReport.xml Some data is directly read from the registry to enrich the output and in some cases administrator permissions are required. The Win32Apps and Intune script policy data is coming from the Intune Management Extension logfiles: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload*.log C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\HealthScripts*.log NOTE: The folders under “C:\Users\PUBLIC\Documents\MDMDiagnostics” will be deleted when the creation time is older than one day. This can be changed with parameter “-CleanUpDays” set to a higher value than one day. How to use parameter “-MDMDiagReportPath” Simply generate MDM report data, either with the MdmDiagnosticsTool.exe, via the settings app or via Intune. Then copy the files to a system with the IntuneDebug module on it and unpack the report data. You can now run the function with the parameter “-MDMDiagReportPath” and point it to the unpacked report data. NOTE: The report header will contain the following when the parameter was used: “Generated from captured MDM Diagnostics Report” MdmDiagnosticsTool.exe example: mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip C:\temp\MDMDiagnosticsData.zip Settings app example: Intune Example: I hope you find this tool helpful. In case of any issues or suggestions, head over to GitHub via https://aka.ms/IntuneDebug and create an issue or pull request. Stay safe! Jonas Ohmsen Code disclaimer This sample script is not supported under any Microsoft standard support program or service. This sample script is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of this sample script and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of this script be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use this sample script or documentation, even if Microsoft has been advised of the possibility of such damages.
MDM Work Portal Settings – Android – iOS
Hello Team, Please help me with some questions I have regarding the implementation of my MDM policy on Android and iOS mobile devices. When installing these applications, the following questions arise: Why is "location" required, and why is its activation necessary? It requests permission to access the phone's storage — why is this needed? How is web browsing managed or controlled? Defender asks to activate a VPN — I would like to understand why this is necessary. How does Defender classify the severity level as high, medium, or low, and how is this used to determine whether a device is considered compliant?
Safe to delete the Surface Hub 3 "admin" account?
We manage our Surface Hubs with Teams Rooms Pro (and Intune where needed). The Windows default local administrator account is disabled during enrollment by the Deployment policy. Intune is configured to add an Entra group to the Local Administrators group, whose membership we manage with an Identity Governance policy. We are all set for administration. And if we were ever to be locked out of a Surface Hub, we would re-image it and begin again. During the Out-of-box experience, a new administrator account named ".\admin", with a well-known simple three letter password, is added to Surface Hub 3 devices. Presumably, the account is added a "convenience". All my testing and research has shown that this account is not needed or used. Is it safe to delete ".\admin" account? Or later, will I find Microsoft expected to use that account in some way? Thanks, in advance.
Make Required applications visible in Intune Company Portal on iOS
Hi everyone, I'm new to Intune and have a question. Is it possible to make required applications visible in the Intune Company Portal on iOS (supervised devices)? Currently, only "available" apps are shown. This would be really helpful because if a user deletes a required app, the automatic re-installation can sometimes take a long time. Thanks!Required and Available Apps visibility in ICP
Hi everyone, I'm new to Intune and have a question. Is it possible to make required applications visible in the Intune Company Portal on iOS (supervised devices)? Currently, only "available" apps are shown. This would be really helpful because if a user deletes a required app, the automatic re-installation can sometimes take a long time. Thanks!
Query regarding MDM Unenrollment initiated by the User.
Hi, We are facing one Issue regarding MDM Unrenrollment process initiated by User, In which when MDM server is receiving Unenrollment the request, it does not contain Meta value for Alert(1226) in the SyncBody. Please find following logs for the same behavior : [Windows MDM Sync request for device guid <> <SyncML xmlns="SYNCML:SYNCML1.2"> <SyncBody> <Alert> <CmdID>2</CmdID> <Data>1201</Data> </Alert> <Alert> <CmdID>3</CmdID> <Data>1224</Data> <Item> <Meta/> <Data>user</Data> </Item> </Alert> <Alert> <CmdID>4</CmdID> <Data>1226</Data> <Item> <Meta/> <Data>1</Data> </Item> </Alert> <!-- other device information --> <SyncBody> Earlier, Under this Alert tag we had a Meta tag which contained string : "com.microsoft:mdm.unenrollment.userrequest" as part of User Initiated disconnection, on basis of which MDM Server proceeds with further action. <Alert> <CmdID>4</CmdID> <Data>1226</Data> <Item> <Meta> <ns2:Type>com.microsoft:mdm.unenrollment.userrequest</ns2:Type> </Meta> <Data>1</Data> </Item> </Alert> But now the above <Meta> that MDM Server receives is Empty tag without any String (<Meta/>). This behavior can be seen on various windows versions like : 1803, 1809, 1903, 1909 and 2004 that has been tested and getting the same result. In the document : https://docs.microsoft.com/en-us/windows/client-management/mdm/disconnecting-from-mdm-unenrollment#user-initiated-disconnection , nothing is updated or mentioned regarding change in unenrollment process initiated by the User. Can we use the alert value 1226 without the "com.microsoft:mdm.unenrollment.userrequest" value be used to trigger unenrollment for the device. Any reason why the type has been removed from these versions. Please clarify on same so that we can proceed on this. Thanks.
