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 HubHow to easily apply DISA STIGs with Intune
Introduction In today's digital landscape, ensuring the security and compliance of IT infrastructure is paramount. The Defense Information Systems Agency (DISA) provides Security Technical Implementation Guides (STIGs) to optimize security for various software and systems. Utilizing Microsoft Intune, administrators can create configuration profiles that adhere to these STIGs, thereby enhancing their organization's security posture. This blog will walk you through the process of creating Intune Configuration Profiles for DISA STIGs, complete with screenshots and detailed steps. Prerequisites Before diving into the configuration process, ensure you have the following: Access to the Intune admin center. Appropriate administrative privileges to create and manage configuration profiles. Familiarity with DISA STIGs and their requirements. Step-by-Step Guide Step 1: Access Intune Acquire DISA STIG Files: The first step in this process is to acquire the DISA STIG files from their official website (Group Policy Objects – DoD Cyber Exchange). These files contain the specific security guidelines and requirements you need to implement. Visit the DISA website, locate the relevant STIG files for your systems, and download them to your local machine. Prep files: Unzip the file you just downloaded then inside you should find another zipped file named like “Intune STIG Policy Baselines.” Unzip this file as well. Login to Intune with proper permissions: To begin, navigate to the Intune admin center at https://intune.microsoft.com or https://Intune.microsoft.us for Intune Government GCC-H/DoD (I am using a GCC-H instance of Intune, but these steps should be the same no matter what impact level you are using). Sign in with your administrator credentials: If you are using RBAC and least privilege you will need to have at least the “Policy and Profile Manager” role. Step 2: Create a New Configuration Profile Once logged in, follow these steps to create a new configuration profile: In the left-hand menu, select Devices -> Configuration profiles. Click on the Create profile button at the top, select “import policy” Select “Browse for files” and browse to the location where you unzipped the Intune STIG Policy Baselines, inside that folder go to the Intune Policies folder then Settings Catalog. Select your STIG of choice and provide a meaningful name and description for the profile and select save. Step 3: Configure Profile Settings Next, verify the profile settings align with the DISA STIG requirements: Once the profile has been created select view policy. Navigate through the settings and ensure every setting is meticulously configured to meet the STIG compliance guidelines. This may include settings such as password policies, encryption, and network security configurations. Ensure every setting meets the compliance standards of your organization. For example, Windows Spotlight is a feature that rotates the wallpaper and screensaver randomly if your organization uses custom wallpaper or screensavers you may want to have this completely disabled. Step 4: Assign the Profile and TEST, TEST, and TEST Again!! After configuring the profile settings, assign the profile to the appropriate groups: Next to Assignments select edit. Select the user or device groups that the profile should apply to, this should be a small but diverse group of devices or users that can provide feedback on the user experience of the settings being applied and or issues they cause because STIGS never break anything right!? Once you have assigned your groups click Review & Save then Save. Conclusion Creating Intune Configuration Profiles for DISA STIGs is a crucial step in maintaining robust security and compliance within your organization. By following this step-by-step guide, you can effectively configure and deploy profiles that adhere to stringent security standards, safeguarding your IT infrastructure. Stay vigilant and periodically review your profiles to ensure they remain compliant with evolving STIG requirements. Disclaimer While DISA has made this a fairly easy process with Microsoft Intune there are some caveats. In the folder where we found the Intune policies is a “Support files” folder which hold an excel spreadsheet with valuable information. There are still several STIG settings that are not natively set by Intune for various reasons (Not in Windows CSP, organization specific settings, etc.) They have also provided the Desired State Configuration (DSC) files to set a lot of these settings that will need to be deployed as a Win32_APP. This is outside the scope of this blog but stay tuned! Lastly, the spreadsheet provides STIG settings that will be a false positive when you use the Security Content Automation Protocol (SCAP) tool. This is due to the settings being set now through the Configuration Service Providers (CSP) and the tool is looking at the legacy registry locations. Unfortunately, until that tool gets updated to look in the new locations we will need to provide that to prove the settings have been configured. All screenshots and folder paths 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 Additional Resources Microsoft Intune Documentation: Microsoft Intune documentation | Microsoft Learn DISA STIGs: Security Technical Implementation Guides (STIGs) – DoD Cyber Exchange Intune Admin Center: intune.microsoft.com (Commercial/GCC) or Intune.microsoft.us for government (GCC-High/DoD) Stay tuned for future posts where we delve deeper into advanced configurations and best practices. Happy securing!Installing Offline Microsoft Store Apps with Intune for Intune Government Customers
Hey everyone, Chris Vetter Sr. Cloud Solution Architect at Microsoft. As organizations strive to enhance their digital workplace, the need for seamless app deployment and management becomes more critical. For government entities using an Intune Government Subscription, installing Offline Microsoft Store Apps can present unique challenges and opportunities. This blog post aims to provide a step-by-step guide to help you navigate this process efficiently. Why Choose Offline Microsoft Store Apps? Offline Microsoft Store Apps offer several benefits, especially for government entities that require stringent security and compliance measures: Enhanced Security: Offline apps are not dependent on an internet connection, significantly reducing the risk of external threats. Controlled Deployment: Admins have full control over the app versions being deployed, ensuring that all devices are running the same, tested software. Compliance: Many government organizations have policies that restrict internet access, making offline apps a viable solution. Prerequisites Before you begin, make sure you have the following prerequisites: An active Microsoft Intune subscription Administrative access to Microsoft Intune Access to the download offline apps with Windows Package Manager (Winget) Step-by-Step Guide Acquiring Offline Apps The Microsoft Store for Business/Education was officially retired on August 15 th , 2024, and can no longer be accessed for downloading the offline app packages and their dependencies. The current method to obtain the files is with Windows Package Manager (Winget tool). I am not covering this process in this blog as there are other helpful articles on this which I will link at the bottom of this blog. Downloading the App Package and License Download the app package (in .APPX or .MSIX format) and the corresponding license file. Make sure to store these files in a secure location, as they are required during the Intune deployment process. As of this writing Intune does not have any built-in method to deploy the license so your targeted endpoints will need to be able to reach out to the Microsoft license server to retrieve the license. For this article, I will be using “Company Portal” as the LOB App. Below is a sample of my Winget to download the files and what the downloaded files should look like after a successful download. "Winget download --name "Company Portal" --architecture x64 --accept-package-agreements --accept-source-agreements --authentication-account <Account with Proper Role Assigned>" As for this writing I know version 11.2.900.0 is the latest version for Windows 11 so that is the one I will be selecting. Uploading the App to Intune Now, log in to the Microsoft Intune admin portal. Navigate to Apps > Windows > Add. Select the option to add a Line-of-business app, as this is the category for offline Microsoft Store apps. Configuring the App Information Select the “.AppXBundle” from the downloaded content. You will see a list of dependencies that will need to be uploaded as well. These will be in the dependencies folder in the downloaded content. I specified x64 when I downloaded the content so those are the only dependencies I will have to upload. Fill in the necessary details such as the app name, publisher, and version. You can also add a description and logo to make the app easily identifiable for end users (*HINT: If you use the –show parameter with Winget it will provide most of the info just like from the store application). Assigning the App to Devices Next, assign the proper scope tag (scope tags are necessary for applying RBAC efficiently). Navigate to Assignments and choose the user or device groups that should receive the app. You can configure the deployment to install the app automatically. Monitoring the Deployment After assigning the app, monitor the deployment status in the Microsoft Endpoint Manager admin center. Navigate to Apps > Monitor to check the installation progress and troubleshoot any issues that may arise. Best Practices To ensure smooth deployment, here are some best practices: Test Before Deployment: Always test the app on a few devices before rolling it out organization wide. Regular Updates: Keep track of app updates and new versions to ensure your devices are running the most secure and efficient version. Documentation: Maintain detailed documentation of the deployment process and any issues encountered for future reference. Monitor for new version releases as you will have to repeat this process to update the application Conclusion Installing Offline Microsoft Store Apps with Intune for Intune Government customers can streamline app management and enhance security. By following the steps outlined in this guide, you can ensure a smooth and efficient deployment process. Stay proactive in monitoring and updating your apps to maintain a secure and productive digital environment. Thank you for reading, and happy deploying! Disclaimer The sample scripts are not supported by any Microsoft standard support program or service. The sample scripts are 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 the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts 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 the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. All screenshots and folder paths 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 Distribute LOB apps to enterprises - Windows apps | Microsoft Learn Downloading Microsoft Store apps using Windows Package Manager - Microsoft Community Hub Windows Package Manager | Microsoft Learn
