Microsoft Endpoint Administrator Study Guide

Explanation

Choosing a device join type determines how identity, management, and authentication work for a device. In Microsoft Entra environments you decide between Entra joined, hybrid joined, or registered devices. The choice impacts single sign-on behavior, Conditional Access enforcement, and whether on-premises infrastructure is required.

Think of it as: Choosing a passport type — Entra join is a cloud-only passport (works everywhere modern), hybrid join is dual citizenship (works cloud + legacy on-prem), and Entra registration is a visitor badge (user identity only, no full device trust).

Key Mechanics: - Entra join: corporate device, cloud-only identity, no on-premises AD required, full Intune MDM - Hybrid join: corporate device, AD + Entra dual identity, requires Azure AD Connect with device writeback - Entra registration: personal/BYOD device, user-level registration, limited MAM-only management possible - Wrong choice = blocked legacy app access (Entra joined devices cannot issue Kerberos tickets for on-prem resources) - Join type is set at enrollment time and cannot be changed without re-enrolling the device

Examples

Example 1 — [Success] Cloud-first laptop deployment A remote sales hire receives a new laptop shipped directly from the OEM. During OOBE she selects "Work or school," signs in with her Entra credentials, and the device becomes Entra joined. Intune policies apply within minutes and she accesses Microsoft 365 apps without a VPN — no domain controller contact required.

Example 2 — [Blocked] Wrong join type for legacy app A finance admin configures new workstations as Entra joined to modernize management. Users immediately report they cannot authenticate to the on-premises ERP system. Root cause: The ERP requires Kerberos tickets issued by a domain controller — only available to hybrid joined or domain-joined devices, not cloud-only Entra joined devices. Fix: Re-enroll workstations as hybrid joined.

Key Mechanisms

- Core function: Choosing a device join type determines how identity, management, and authentication work for a device. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Cloud-first laptop deployment - Decision clue: Industry: Healthcare

Review Path

Steps — Entra Admin Center: Devices → Device settings

1. Sign in to Entra admin center (entra.microsoft.com) 2. Navigate to: Devices → Overview → Device settings 3. Review "Users may join devices to Azure AD" — set to All or Selected group 4. Review "Users may register their devices" — controls BYOD registration 5. Confirm MDM auto-enrollment scope in Intune admin center → Devices → Enrollment → Automatic Enrollment 6. For hybrid join: Open Azure AD Connect → Configure → Configure device options → Enable device writeback 7. Verify SCP in AD Sites and Services or via: Get-ADObject -Filter {objectClass -eq "serviceConnectionPoint"} 8. Test result on enrolled device: run dsregcmd /status — check AzureAdJoined and DomainJoined fields

Docs: https://learn.microsoft.com/en-us/entra/identity/devices/concept-device-registration https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-azuread-join-plan https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment

Explanation

Planning a Microsoft Entra device deployment involves assessing organizational requirements, existing infrastructure, and user needs to determine the optimal device identity strategy. This planning phase considers device ownership models (corporate vs. personal), management requirements, application compatibility, and security policies before implementation begins. Think of it as: Creating a blueprint before building a house — you need to know how many rooms, who will use them, and what utilities are available before you start construction. Key Mechanics: - Inventory existing devices and assess current infrastructure (AD DS, network connectivity) - Evaluate application compatibility with cloud-native authentication - Determine device ownership models and corresponding join types - Plan for user identity synchronization if hybrid approach needed - Define success criteria and pilot groups before full rollout

Examples

Example 1 — [Success] Phased cloud deployment plan A global company with 15,000 employees inventories all devices, identifies 40% as remote-capable cloud workers, and creates a phased plan: Entra join for remote staff first, hybrid join for factory floor second, Entra registration for contractors. Pilot groups validate each phase before full rollout.

Example 2 — [Blocked] Planning skipped, hybrid join fails at scale An IT team skips the planning phase and deploys hybrid join to all 1,200 devices simultaneously without verifying Azure AD Connect version or SCP configuration. Half the devices fail to register in Entra ID — the Azure AD Connect version is too old and device writeback was never enabled. Root cause: Missing infrastructure audit before deployment.

Key Mechanisms

- Core function: Planning a Microsoft Entra device deployment involves assessing organizational requirements, existing infrastructure, and user needs to determine the optimal device identity strategy. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Phased cloud deployment plan - Decision clue: Industry: Financial Services

Review Path

Steps: 1. Run the Microsoft Entra device deployment planning checklist from Microsoft Learn 2. Inventory current devices using Microsoft Defender for Endpoint or Configuration Manager 3. Identify applications requiring on-premises authentication (Kerberos, NTLM) 4. Document user personas: remote, office-based, shared workstations, kiosks 5. Choose join types per persona using decision matrix 6. Configure Entra Connect if hybrid join is required (check sync requirements) 7. Create pilot groups in Entra ID with 50-100 devices 8. Define monitoring and success metrics before production rollout Docs: https://learn.microsoft.com/en-us/entra/identity/devices/plan-device-deployment https://learn.microsoft.com/en-us/entra/identity/devices/device-management-plan https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-plan-guide

Explanation

Entra hybrid join enrollment connects on-premises Active Directory domain-joined devices to Microsoft Entra ID, creating a unified identity while maintaining legacy application compatibility. These devices appear in both on-premises AD and Entra ID, with automatic registration occurring through Azure AD Connect or Configuration Manager. Think of it as: Dual citizenship — the device maintains its on-premises identity for legacy apps while gaining a cloud identity for modern services like Intune and Conditional Access. Key Mechanics: - Requires Azure AD Connect sync with device writeback enabled - Devices must have line-of-sight to domain controller periodically - Registration occurs during domain sign-in via scheduler task - Supports Windows 10/11, Server 2016+ (for non-users) - Devices appear in Entra ID with "Hybrid Azure AD joined" status

Examples

Example 1 — [Success] Office hybrid join enrollment A hospital configures hybrid join for 500 clinical workstations. Devices are domain-joined, Azure AD Connect syncs them with writeback enabled, and a GPO triggers automatic registration. Workstations appear in Entra ID as "Hybrid Azure AD joined" and receive Intune policies while still authenticating to on-premises AD for legacy imaging software.

Example 2 — [Blocked] Remote device fails hybrid join during OOBE A technician ships a new Windows 11 laptop directly to a remote employee who attempts hybrid join during OOBE from home. The enrollment fails at the registration step. Root cause: Hybrid join requires line-of-sight to a domain controller during OOBE — the remote device has no VPN and cannot reach the on-premises DC. Solution: Use Autopilot user-driven mode with Entra join instead, or require VPN during first login.

Key Mechanisms

- Core function: Entra hybrid join enrollment connects on-premises Active Directory domain-joined devices to Microsoft Entra ID, creating a unified identity while maintaining legacy application compatibility. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Office hybrid join enrollment - Decision clue: Industry: Manufacturing

Review Path

Steps: 1. Verify Azure AD Connect version 1.1.819.0 or later is installed 2. Enable Device Writeback in Azure AD Connect configuration 3. Configure Service Connection Point (SCP) in on-premises AD 4. Deploy Group Policy Object for automatic device registration 5. Verify registration: dsregcmd /status shows AzureAdJoined : YES 6. Confirm devices appear in Entra admin center → Devices 7. Target Intune enrollment via GPO or co-management slider 8. Test hybrid join with pilot OU before full rollout Docs: https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-azuread-join-plan https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-azuread-join-enable https://learn.microsoft.com/en-us/mem/configmgr/comanage/overview

Explanation

Joining devices to Microsoft Entra ID registers the entire device as an identity principal in the cloud, enabling cloud-native authentication, single sign-on to cloud apps, and centralized management via Intune. The join process occurs during Windows Out-of-Box Experience (OOBE), through Settings, or via Windows Autopilot. Think of it as: Giving the device its own cloud passport — it can authenticate directly with Entra ID without needing an on-premises domain controller. Key Mechanics: - Creates a device object in Entra ID with a unique device ID - Establishes device trust (primary refresh token) - Enables SSO to cloud and on-premises apps (via hybrid cloud trust) - User must have "User can join devices" permission - Device receives Intune management automatically if MDM auto-enrollment configured

Examples

Example 1 — [Success] Zero-touch remote join A sales organization ships new laptops directly from the OEM to remote hires. During OOBE each user selects "Work or school," signs in with their @company.com credentials, and the device joins Entra ID automatically. MDM auto-enrollment triggers and Intune policies apply — fully managed before the employee completes their first Teams call.

Example 2 — [Blocked] User lacks join permission An IT admin issues a laptop to a new contractor but forgot to include contractors in the "Users may join devices to Azure AD" scope. The contractor's OOBE fails at the Entra join step with "Your organization does not allow personal devices." Root cause: Enrollment scope set to "Selected" group that excludes the contractor. Admin must add contractor to the allowed group before re-attempting.

Key Mechanisms

- Core function: Joining devices to Microsoft Entra ID registers the entire device as an identity principal in the cloud, enabling cloud-native authentication, single sign-on to cloud apps, and centralized management via Intune. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Zero-touch remote join - Decision clue: Industry: Technology Consulting

Review Path

Steps: 1. Navigate to Microsoft Entra admin center → Devices → Device settings 2. Confirm "Users may join devices to Azure AD" is set to All or Selected 3. Configure MDM auto-enrollment: Mobility (MDM/MAM) → Microsoft Intune 4. For new devices: User joins during OOBE with work/school account 5. For existing Windows 10/11: Settings → Accounts → Access work or school → Connect 6. Verify join: dsregcmd /status shows AzureAdJoined : YES 7. Check device appears in Entra admin center → Devices 8. Confirm Intune enrollment in Intune admin center → Devices Docs: https://learn.microsoft.com/en-us/entra/identity/devices/device-join-plan https://learn.microsoft.com/en-us/entra/identity/devices/device-join-how-to https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll

Explanation

A Microsoft Entra joined device is a device that is registered exclusively to Microsoft Entra ID as its identity provider, with no connection to on-premises Active Directory. These devices sign in using organizational credentials stored in the cloud and are managed through Intune or other MDM providers. Think of it as: A cloud-native device that treats Entra ID as its home directory — it doesn't know or care about on-premises domain controllers. Key Mechanics: - Primary identity source is Entra ID (no AD domain membership) - Users sign in with Entra credentials (UPN format) - Supports single sign-on to cloud and federated apps - Can access on-premises resources via hybrid cloud trust or VPN - Managed entirely via cloud MDM (Intune) or third-party solutions

Examples

Example 1 — [Success] Cloud-native startup fleet A 200-person SaaS company with no on-premises infrastructure deploys all employee laptops as Entra joined via Autopilot. Devices sign in with Entra credentials, receive Intune security baselines automatically, and users access Microsoft 365, Salesforce, and Slack via SSO without ever touching a domain controller.

Example 2 — [Blocked] Entra joined device cannot reach legacy app After migration to Entra join, an accounting department reports that the on-premises invoicing system is inaccessible. Root cause: The invoicing system requires NTLM authentication tied to an on-premises AD account — Entra joined devices have no domain trust. Fix: Deploy Always-On VPN profile via Intune to bridge cloud-joined devices to on-premises resources.

Key Mechanisms

- Core function: A Microsoft Entra joined device is a device that is registered exclusively to Microsoft Entra ID as its identity provider, with no connection to on-premises Active Directory. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Cloud-native startup fleet - Decision clue: Industry: E-commerce

Review Path

Steps: 1. Verify device is Entra joined: Settings → Accounts → Access work or school 2. Run dsregcmd /status to confirm AzureAdJoined : YES and DomainName : N/A 3. Check device object in Entra admin center → Devices (Join Type: Azure AD joined) 4. Verify Intune management: Intune admin center → Devices → Windows devices 5. Review user sign-in experience: UPN login, optional MFA, Windows Hello setup 6. Test SSO to cloud apps (portal.office.com, teams.microsoft.com) 7. Configure Conditional Access policies targeting Entra joined devices 8. Monitor device compliance through Intune compliance reports Docs: https://learn.microsoft.com/en-us/entra/identity/devices/concept-azure-ad-join https://learn.microsoft.com/en-us/entra/identity/devices/device-management-azure-portal https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-management

Explanation

A Microsoft Entra hybrid joined device is an on-premises Active Directory domain-joined device that is also registered with Microsoft Entra ID. These devices maintain their traditional domain membership while gaining a cloud identity, enabling them to benefit from both on-premises management and cloud-based services like Intune and Conditional Access. Think of it as: A bridge device — it keeps its legacy identity for compatibility while gaining cloud superpowers for modern management. Key Mechanics: - Device is domain joined to on-premises AD first - Automatically registers with Entra ID via Azure AD Connect - Users sign in with on-premises credentials (down-level or UPN format) - Device object exists in both on-premises AD and Entra ID - Supports hybrid scenarios where some apps require Kerberos/NTLM

Examples

Example 1 — [Success] Government agency dual-identity fleet A government agency keeps 5,000 workstations domain-joined for classified app Kerberos auth while enabling hybrid join via Azure AD Connect. Devices appear in both on-premises AD and Entra ID, allowing Intune to deliver security baselines and Conditional Access to enforce compliant device requirements — all without breaking legacy app access.

Example 2 — [Blocked] Hybrid join stuck in pending state After enabling hybrid join via GPO, an admin notices hundreds of devices show "Registered: Pending" in Entra admin center for days. Root cause: Azure AD Connect device writeback is not enabled — devices are registering locally but the cloud object is never created. Admin must re-run the Azure AD Connect wizard and enable device writeback, then wait for the next sync cycle.

Key Mechanisms

- Core function: A Microsoft Entra hybrid joined device is an on-premises Active Directory domain-joined device that is also registered with Microsoft Entra ID. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Government agency dual-identity fleet - Decision clue: Industry: Higher Education

Review Path

Steps: 1. Verify device is domain joined (System Properties → Computer Name) 2. Run dsregcmd /status to confirm AzureAdJoined : YES 3. Check device registration via scheduled task: Task Scheduler → Microsoft → Windows → Workplace Join 4. View device in Entra admin center → Devices (Join Type: Hybrid Azure AD joined) 5. Confirm device appears in Intune if co-managed 6. Test user sign-in with both domain credentials and UPN 7. Validate on-premises resource access (file shares, printers) 8. Monitor sync status in Azure AD Connect dashboard Docs: https://learn.microsoft.com/en-us/entra/identity/devices/concept-azure-ad-join-hybrid https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-azuread-join-plan https://learn.microsoft.com/en-us/mem/configmgr/comanage/overview

Explanation

Registering devices to Microsoft Entra ID creates a device identity for personally-owned (BYOD) or lightly managed devices, establishing a user-device relationship without giving the device full corporate trust. Registered devices support single sign-on to cloud apps and can receive Conditional Access policies targeting user and app protection rather than device compliance. Think of it as: A visitor badge for personal devices — the device is recognized but not fully trusted like corporate-owned hardware. Key Mechanics: - Device registration is user-driven (add work/school account) - No device management enrollment required (optional) - Device object created with Registered join type - Supports SSO to cloud apps through primary refresh token - Can be combined with App Protection Policies (MAM) for data protection

Examples

Example 1 — [Success] Contractor BYOD registration A consulting firm allows contractors to add their work account to personal iPhones via Settings → Accounts. The device registers with Entra ID, enabling SSO to Microsoft 365. App Protection Policies prevent corporate email from being copied to personal apps — no MDM enrollment required, contractor retains full personal device control.

Example 2 — [Blocked] Registered device blocked by Conditional Access A contractor registers their personal Android phone and can access the company portal, but the SharePoint CA policy requires a "compliant" device. Registered devices cannot be marked compliant — only MDM-enrolled devices get compliance status. Root cause: CA policy targets device compliance, not just device registration. Fix: Change CA policy to target App Protection Policies (MAM) instead.

Key Mechanisms

- Core function: Registering devices to Microsoft Entra ID creates a device identity for personally-owned (BYOD) or lightly managed devices, establishing a user-device relationship without giving the device full corporate trust. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Contractor BYOD registration - Decision clue: Industry: Retail

Review Path

Steps: 1. Configure Entra ID to allow device registration: Entra admin center → Devices → Device settings 2. Set "Users may register their devices with Azure AD" to All 3. Instruct users: Settings → Accounts → Access work or school → Connect 4. For mobile: Install Company Portal app and sign in with work account 5. Verify registration: Entra admin center → Users → [user] → Devices 6. Optionally configure App Protection Policies without enrollment 7. Create Conditional Access policy requiring registered devices 8. Test user experience: Access portal.office.com, verify no password prompts Docs: https://learn.microsoft.com/en-us/entra/identity/devices/concept-device-registration https://learn.microsoft.com/en.com/entra/identity/devices/device-registration-how-to https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy

Explanation

Microsoft Entra registered devices represent personally-owned or lightly managed devices that have a work or school account added for cloud resource access. These devices have a user-focused identity rather than a device-focused one, supporting scenarios where full device management is inappropriate or unwanted. Think of it as: A library card for personal devices — the user is known and trusted, but the device itself isn't owned by the institution. Key Mechanics: - Join type shows as "Registered" in Entra admin center - Device registration is per-user, not system-wide - No device management enrollment unless explicitly configured - Supports Workplace Join (legacy) and modern registration methods - Device object is soft-matched to Intune if later enrolled

Examples

Example 1 — [Success] University BYOD portal access A university enables device registration for students. Students add their university account to personal laptops and phones via Settings → Accounts. Device objects appear in Entra ID as "Registered," enabling SSO to the student portal, Office 365, and library databases without IT managing the personal devices.

Example 2 — [Blocked] Registered device cannot receive configuration profiles An IT admin tries to push a Wi-Fi configuration profile to all registered student devices via Intune. The profile targets "All Devices" but registered devices do not receive it. Root cause: Configuration profiles require MDM enrollment — registered devices are not MDM-enrolled. Fix: Provide the Wi-Fi password via a self-service portal, or require enrollment for configuration profile delivery.

Key Mechanisms

- Core function: Microsoft Entra registered devices represent personally-owned or lightly managed devices that have a work or school account added for cloud resource access. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] University BYOD portal access - Decision clue: Industry: Healthcare

Review Path

Steps: 1. View registered devices: Entra admin center → Devices → All devices 2. Filter by Join Type: Registered 3. Review device details: Owner, OS, Registration timestamp 4. Check user's registered devices: Users → [user] → Devices 5. Verify no MDM enrollment: Intune admin center → Devices → Check if device appears 6. Configure App Protection Policies targeting registered devices 7. Create Conditional Access policy requiring registered device status 8. Test by registering a personal device and accessing protected apps Docs: https://learn.microsoft.com/en-us/entra/identity/devices/concept-azure-ad-register https://learn.microsoft.com/en-us/entra/identity/devices/device-management-azure-portal https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy

Explanation

Planning groups for devices involves creating logical collections of devices in Entra ID and Intune to efficiently target policies, applications, and configurations. Groups can be assigned (static) or dynamic based on device attributes, enabling automatic membership updates as devices join, change status, or meet compliance criteria. Think of it as: Organizing your device fleet into squadrons — you can give orders (policies) to the entire squadron at once rather than commanding each device individually. Key Mechanics: - Groups exist in both Entra ID (identity) and Intune (management) - Dynamic groups use rules based on device properties (OS, join type, compliance) - Assigned groups require manual membership management - Group nesting is supported (groups within groups) - Group membership determines policy targeting and app deployment

Examples

Example 1 — [Success] Dynamic policy targeting across platforms An organization creates three dynamic groups: "All Windows 11 Corporate Devices" (device.os -eq "Windows"), "All iOS BYOD" (device.os -eq "iOS" and device.deviceOwnership -eq "Personal"), and "Non-Compliant Devices." Each group automatically receives the appropriate compliance policy, and new enrollments are instantly added without admin action.

Example 2 — [Blocked] Wrong group type blocks policy assignment An admin creates a Microsoft 365 group (not a Security group) and assigns a device compliance policy to it. The policy never applies. Root cause: Intune compliance and configuration policies require Security groups — Microsoft 365 groups are for collaboration tools like Teams and SharePoint and cannot be used as Intune policy targets.

Key Mechanisms

- Core function: Planning groups for devices involves creating logical collections of devices in Entra ID and Intune to efficiently target policies, applications, and configurations. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Dynamic policy targeting across platforms - Decision clue: Industry: Education

Review Path

Steps: 1. Plan group strategy: Document device types, ownership models, locations, roles 2. Navigate to Entra admin center → Groups → New group 3. Choose Group type: Security (for policies) or Microsoft 365 (for collaboration) 4. Select Membership type: Assigned (static) or Dynamic Device 5. For dynamic groups: Write rule syntax (see dynamic-group-rule-syntax concept) 6. Create complementary groups in Intune for app targeting (optional) 7. Test group membership with pilot devices before production 8. Monitor group membership changes and policy application Docs: https://learn.microsoft.com/en-us/entra/identity/users/groups-create-rule https://learn.microsoft.com/en-us/mem/intune/fundamentals/groups-add https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership

Explanation

Dynamic group rule syntax enables automatic device group membership based on device attributes stored in Entra ID. Rules use property expressions, operators, and values to evaluate devices in real-time, adding or removing members as device properties change without manual intervention. Think of it as: A smart filter that continuously scans your device fleet and automatically sorts devices into the right buckets based on their current characteristics. Key Mechanics: - Rules use device object attributes (device.os, device.manufacturer, etc.) - Supports operators: -eq, -ne, -startsWith, -contains, -in, -match - Multiple expressions combined with -and, -or, -not - Parentheses for complex logic grouping - Preview functionality validates rules before saving - Processing occurs automatically every few hours

Examples

Example 1 — [Success] Regional policy targeting with dynamic groups A multinational company creates a dynamic group "EMEA Windows Devices" using the rule: (device.countryCode -eq "GB") -or (device.countryCode -eq "DE") -or (device.countryCode -eq "FR"). The group validates correctly in the rule preview and 300 EMEA devices are automatically added. Regional compliance policy applies without manual membership management.

Example 2 — [Blocked] Syntax error silently excludes all devices An admin writes the rule: (device.deviceOwnership -eq "Company") -and device.os -eq "Windows" — missing parentheses around the second condition. The portal saves the rule with a warning, but the group populates with zero devices and shows no error in the group blade. Root cause: Malformed rule syntax silently excludes all devices. Fix: Use the rule builder UI to validate syntax, or click "Validate rules" before saving.

Key Mechanisms

- Core function: Dynamic group rule syntax enables automatic device group membership based on device attributes stored in Entra ID. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Regional policy targeting with dynamic groups - Decision clue: Industry: Global Manufacturing

Review Path

Steps: 1. Navigate to Entra admin center → Groups → New group → Dynamic Device 2. Click "Add dynamic query" to open rule builder 3. Select property from dropdown (e.g., device.os) 4. Choose operator (e.g., -eq) 5. Enter value (e.g., "Windows") 6. Add additional expressions with -and/-or as needed 7. Use parentheses to group complex logic 8. Click "Validate Rules" to test with sample devices 9. Save group and monitor membership updates Docs: https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-rule-member-of https://learn.microsoft.com/en-us/mem/intune/fundamentals/groups-dynamic-rules

Explanation

Configuring enrollment settings in Intune establishes the rules, restrictions, and options for how devices join management. These settings control enrollment methods allowed, device platform restrictions, enrollment limits per user, and device type approvals, ensuring only authorized devices in appropriate configurations can enroll. Think of it as: Setting up the front door security for your device management system — you decide who can enter, what devices they can bring, and under what conditions. Key Mechanics: - Enrollment restrictions block or allow platforms (iOS, Android, Windows) - Device platform configurations set minimum/maximum OS versions - Enrollment limits prevent users from enrolling too many devices - Device categories allow automatic grouping based on device purpose - Terms and conditions require user acceptance before enrollment

Examples

Example 1 — [Success] Platform restriction for school district A school district configures enrollment restrictions: iOS allowed (minimum iOS 16), Android personal devices blocked, Windows corporate-only. Students are limited to one enrolled device. A student tries to enroll with an Android personal phone and receives "Your device is not allowed to enroll" — the restriction works as intended.

Example 2 — [Blocked] Enrollment limit hit at wrong time A manager has four devices already enrolled and receives a new corporate laptop. Enrollment fails with "This user has too many devices enrolled." Root cause: The enrollment limit is set to 5 but IT already enrolled four devices earlier in testing under the manager's account. Admin must delete one enrolled device or raise the limit for the manager's group.

Key Mechanisms

- Core function: Configuring enrollment settings in Intune establishes the rules, restrictions, and options for how devices join management. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Platform restriction for school district - Decision clue: Industry: Financial Services

Review Path

Steps: 1. Navigate to Intune admin center → Devices → Enrollment → Enrollment device platform restrictions 2. Create restriction for each platform: Windows, iOS, Android, macOS 3. Set allowed/blocked platforms and minimum/maximum OS versions 4. Go to Enrollment restrictions → Enrollment limits 5. Configure maximum devices per user (default 5, adjust as needed) 6. Create Device categories under Device enrollment 7. Configure Terms and conditions under Enrollment 8. Test enrollment with different device types and user accounts Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/enrollment-restrictions-set https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment-limits https://learn.microsoft.com/en-us/mem/intune/enrollment/terms-and-conditions-create

Explanation

Android enrollment in Intune varies significantly based on device ownership (corporate vs. personal) and management requirements. Android Enterprise offers multiple enrollment paths including fully managed (corporate dedicated), work profile (BYOD), and corporate-owned with work profile, each providing different levels of separation between personal and work data. Think of it as: Different apartment types for Android devices — studios (fully managed), duplexes (work profile separation), or dorms (dedicated devices). Key Mechanics: - Android Enterprise is Google's modern management framework - Work profile creates container separating personal/work apps and data - Fully managed gives IT complete control over corporate devices - Dedicated devices (COSU) for kiosks, signage, single-purpose devices - Requires Managed Google Play connection for app deployment

Examples

Example 1 — [Success] Multi-mode Android deployment for retail A retail chain deploys three Android enrollment types: fully managed for inventory scanners (corporate-owned, locked to work apps), work profile for employee personal phones (BYOD, personal/work separation), and dedicated kiosk mode for digital signage displays. Each mode receives the appropriate Intune policies from Managed Google Play.

Example 2 — [Blocked] Work profile enrollment fails without Managed Google Play An IT admin tries to deploy Android work profile enrollment but users get stuck at the "Set up work profile" screen with an error. Root cause: Intune tenant has not been connected to Managed Google Play — Android Enterprise enrollment requires this connection first. Admin must complete the Google Play connection in Intune → Tenant admin → Connectors → Google before enrollment can proceed.

Key Mechanisms

- Core function: Android enrollment in Intune varies significantly based on device ownership (corporate vs. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Multi-mode Android deployment for retail - Decision clue: Industry: Logistics

Review Path

Steps: 1. Connect Intune to Managed Google Play (Intune admin center → Tenant admin → Connectors → Google) 2. Configure enrollment restrictions for Android (Device enrollment → Restrictions) 3. Create enrollment profiles for each Android Enterprise type: - Work profile: Enrollment → Android enrollment → Work profile - Fully managed: Android enrollment → Corporate-owned, fully managed - Dedicated: Android enrollment → Corporate-owned dedicated devices 4. For fully managed/dedicated: Generate enrollment token or QR code 5. Distribute enrollment instructions to users based on device type 6. Deploy apps via Managed Google Play (Apps → Android → Add) 7. Configure compliance policies for Android Enterprise 8. Test enrollment with each device type Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/android-enroll https://learn.microsoft.com/en-us/mem/intune/enrollment/android-work-profile-enroll https://learn.microsoft.com/en-us/mem/intune/enrollment/android-dedicated-devices-enroll

Explanation

Connecting your Intune tenant to Managed Google Play establishes the link between Microsoft Intune and Google's enterprise app store, enabling deployment and management of Android apps. This connection is mandatory for Android Enterprise management and allows IT to approve, deploy, and configure apps from the Google Play store at scale. Think of it as: Creating a diplomatic relationship between Microsoft and Google — once established, apps can flow freely between the two platforms for managed deployment. Key Mechanics: - One-time binding between Intune tenant and Google account - Requires Google account (Gmail) with enterprise verification - Enables app approval workflow in Managed Google Play - Allows private app publishing for line-of-business apps - Synchronizes approved apps to Intune for deployment

Examples

Example 1 — [Success] Hospital clinical app via Managed Google Play A hospital connects their Intune tenant to Managed Google Play using a dedicated Google admin account. They approve the Epic Haiku clinical app in the Play console and sync it to Intune. The app deploys as Required to all clinical Android device groups — devices receive it silently without user interaction from the Google Play Store.

Example 2 — [Blocked] App not visible in Intune after approval An admin approves a work scheduling app in Managed Google Play but the app does not appear in Intune → Apps → Android. Root cause: Manual sync is required after approving new apps — automatic sync occurs only every 24 hours. Admin must trigger a manual sync in Intune → Tenant admin → Connectors → Google → Sync.

Key Mechanisms

- Core function: Connecting your Intune tenant to Managed Google Play establishes the link between Microsoft Intune and Google's enterprise app store, enabling deployment and management of Android apps. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hospital clinical app via Managed Google Play - Decision clue: Industry: Field Services

Review Path

Steps: 1. Create a dedicated Google account for IT administration (if not existing) 2. Navigate to Intune admin center → Tenant admin → Connectors → Google 3. Click "Connect" and sign in with Google account 4. Accept the terms to bind your Intune tenant to Google 5. Click "Launch Google Play" to open Managed Google Play console 6. Search for and approve apps needed by your organization 7. For custom LOB apps: Click "Private apps" in Google Play console → Upload APK 8. Return to Intune → Apps → Android → Sync to import approved apps 9. Deploy synced apps to device groups Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/connect-intune-android-enterprise https://support.google.com/work/android/answer/9429551 https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-android-for-work

Explanation

Automatic enrollment in Intune automatically registers devices with Microsoft Intune when users sign in with their work or school accounts on Windows or mobile devices. This seamless process eliminates manual enrollment steps, ensuring devices become managed as soon as users authenticate, with policies applying immediately. Think of it as: Automatic passport control for trusted travelers — once configured, devices are cleared for management without stopping at each checkpoint. Key Mechanics: - Configured in Entra ID under Mobility (MDM/MAM) - Applies to Windows 10/11, iOS/iPadOS, Android, macOS - User must have appropriate license (Intune) assigned - Device join type determines enrollment timing - Can scope to specific user groups (all vs. selected users)

Examples

Example 1 — [Success] Zero-touch new hire enrollment A company sets MDM user scope to "All" in Entra ID Mobility settings. A new hire unboxes her laptop, joins Entra ID during OOBE, and by the time she reaches the desktop, the device is already enrolled in Intune and receiving security baselines — no IT intervention required.

Example 2 — [Blocked] User not in MDM scope — enrollment silently skipped A contractor signs into a Windows device with their work account successfully, but the device never enrolls in Intune. No error is shown. Root cause: The MDM scope is set to "Some" and the contractor is not in the included group. Admin must add the contractor to the MDM-scoped group, then trigger enrollment manually from Settings → Accounts → Access work or school.

Key Mechanisms

- Core function: Automatic enrollment in Intune automatically registers devices with Microsoft Intune when users sign in with their work or school accounts on Windows or mobile devices. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Zero-touch new hire enrollment - Decision clue: Industry: Professional Services

Review Path

Steps: 1. Navigate to Entra admin center → Identity → Devices → Mobility (MDM and MAM) 2. Select "Microsoft Intune" from the list 3. Configure MDM user scope: - None: Disable auto-enrollment - Some: Select specific groups - All: All users auto-enroll 4. Configure MDM terms of use URL (optional) 5. Configure MDM discovery URL (pre-populated) 6. Configure MDM compliance URL (pre-populated) 7. Set MAM user scope separately if needed for BYOD 8. Save configuration 9. Verify licensed users can enroll devices automatically Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/quickstart-setup-auto-enrollment https://learn.microsoft.com/en-us/entra/identity/devices/mdm-provisioning https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll

Explanation

Automatic enrollment for Windows integrates with Entra ID to enroll devices during sign-in, while bulk enrollment for iOS and Android allows IT to provision multiple corporate devices using enrollment tokens, QR codes, or Apple Business Manager. These methods streamline large-scale device deployments without manual per-device configuration. Think of it as: Factory assembly line vs. custom workshop — bulk methods efficiently process many identical devices, while automatic enrollment handles individual user devices seamlessly. Key Mechanics: - Windows: Auto-enrollment via Entra ID MDM configuration - iOS bulk: Apple Business Manager (ABM) with Device Enrollment Program (DEP) - Android bulk: QR code or NFC bump for fully managed devices - Enrollment tokens have expiration dates and device limits - Zero-touch deployment possible with Apple Configurator or Google Zero Touch

Examples

Example 1 — [Success] ABM supervised iPad deployment A school district orders 500 iPads through Apple Business Manager. The devices automatically appear in ABM, are assigned to the Intune MDM server, and an enrollment profile is applied. When students unbox and power on their iPads, they automatically enroll into Intune and receive the school app configuration without any student or IT action.

Example 2 — [Blocked] ABM-synced devices not assigned to Intune MDM An IT team adds 200 iPads to Apple Business Manager but the devices still prompt users for manual enrollment during OOBE. Root cause: ABM devices must be explicitly assigned to the Intune MDM server in ABM — being in ABM alone is not enough. Admin must navigate to ABM → Devices → Assign to MDM server → Select Intune.

Key Mechanisms

- Core function: Automatic enrollment for Windows integrates with Entra ID to enroll devices during sign-in, while bulk enrollment for iOS and Android allows IT to provision multiple corporate devices using enrollment tokens, QR codes, or Apple Business Manager. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] ABM supervised iPad deployment - Decision clue: Industry: Healthcare

Review Path

Steps: 1. **For Windows Auto-Enrollment:** Configure Entra ID → Mobility → MDM scope 2. **For Windows Bulk:** Download Windows Configuration Designer → Create provisioning package → Save to USB 3. **For iOS Bulk:** - Set up Apple Business Manager → Connect to Intune (Tenant admin → Connectors → Apple) - Sync devices → Create enrollment profile → Assign devices 4. **For Android Bulk:** - Intune admin center → Devices → Android → Enrollment → Create token - Generate QR code for fully managed devices - Configure Google Zero Touch portal if available 5. Test with small batch before mass deployment 6. Monitor enrollment success in Intune admin center → Devices 7. Troubleshoot failed enrollments using platform-specific logs Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-bulk-enroll https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment-program-enroll-ios https://learn.microsoft.com/en.com/mem/intune/enrollment/android-dedicated-devices-enroll

Explanation

A Device Enrollment Manager (DEM) is a special Intune account that can enroll and manage multiple corporate-owned devices without assigning a licensed user to each device. DEM accounts are ideal for kiosks, shared devices, or devices that don't have a dedicated primary user, allowing a single IT account to enroll hundreds of devices. Think of it as: A master key holder for device enrollment — one person can unlock and configure many devices without needing individual keys (user licenses) for each. Key Mechanics: - DEM account requires Intune license (can be shared across devices) - Each DEM account can enroll up to 1,000 devices - Devices enrolled by DEM appear as "Corporate" owned - No primary user associated (device-centric management) - DEM accounts have no access to company data (apps can be installed)

Examples

Example 1 — [Success] Kiosk enrollment via DEM account A hospital creates a DEM account (dem-kiosk@hospital.org) with an Intune license and enrolls 50 patient check-in tablets. Each tablet runs a single healthcare check-in app. No individual user license is required per device — the single DEM license covers all 50 devices, and the tablets appear in Intune as corporate-owned with no primary user.

Example 2 — [Blocked] DEM used for user-affinity device — enrollment fails An IT admin uses a DEM account to enroll employee laptops that need to be linked to specific users for conditional access and SSO. After enrollment, users report they cannot access personal OneDrive, Teams, or user-specific apps. Root cause: DEM-enrolled devices have no User Affinity — they cannot be associated with a primary user after enrollment. For devices requiring user affinity, use Autopilot user-driven mode or standard user enrollment instead.

Key Mechanisms

- Core function: A Device Enrollment Manager (DEM) is a special Intune account that can enroll and manage multiple corporate-owned devices without assigning a licensed user to each device. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Kiosk enrollment via DEM account - Decision clue: Industry: Retail

Review Path

Steps: 1. Create a dedicated user account in Entra ID (e.g., dem@company.com) 2. Assign an Intune license to this account 3. Navigate to Intune admin center → Devices → Enrollment → Device enrollment managers 4. Click "Add" and search for the DEM user account 5. Confirm the user now appears in DEM list 6. Sign in to each target device using DEM account credentials 7. Enroll device via Settings → Accounts → Access work or school → Connect 8. After enrollment, verify device in Intune → Devices (Owner: Corporate) 9. Configure policies targeting "All Corporate Devices" or specific groups Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment-manager-enroll https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment-manager-account https://learn.microsoft.com/en-us/mem/intune/fundamentals/planning-guide-enrollment

Explanation

Android enrollment profiles define how Android Enterprise devices enroll based on ownership type and use case. Profiles include fully managed (corporate devices), dedicated (kiosks), corporate-owned work profile (company phone with personal use), and work profile (BYOD), each with specific enrollment methods and management capabilities. Think of it as: Different contracts for different housing situations — fully managed is a company apartment, work profile is a duplex with shared walls, dedicated is a studio apartment with strict rules. Key Mechanics: - Each profile type has specific enrollment methods (QR, NFC, token, email) - Fully managed: Complete device control, no personal apps - Work profile: Container separates work/personal data - Dedicated: Single/multi-app kiosk mode, no user sign-in - Corporate-owned work profile: Company device allowing personal use

Examples

Example 1 — [Success] Three-profile Android enrollment strategy A logistics company creates three enrollment profiles: "Scanner-FullyManaged" (QR code, fully managed, company-only apps), "Driver-BYOD" (email token, work profile, personal data untouched), and "Terminal-Kiosk" (QR code, dedicated single-app mode). Each device type enrolls automatically into the correct management level.

Example 2 — [Blocked] Fully managed enrollment token expired An IT admin generates a fully managed enrollment token and then takes a two-week vacation. When returning to enroll 50 new scanners, every device fails at the QR code scan with "This enrollment token has expired." Root cause: Fully managed enrollment tokens expire after 90 days by default and must be regenerated. Admin must create a new token in Intune → Devices → Android → Android enrollment → Corporate-owned fully managed.

Key Mechanisms

- Core function: Android enrollment profiles define how Android Enterprise devices enroll based on ownership type and use case. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Three-profile Android enrollment strategy - Decision clue: Industry: Transportation

Review Path

Steps: 1. Navigate to Intune admin center → Devices → Android → Android enrollment 2. **For Fully Managed:** - Select "Corporate-owned, fully managed" - Click "Create profile" → Name → Generate token (QR code available) 3. **For Work Profile:** - Select "Work profile" → Configure enrollment settings - Choose enrollment methods (Company Portal, email) 4. **For Dedicated:** - Select "Corporate-owned dedicated devices" - Create profile → Generate enrollment token → Download QR code 5. **For Corporate-owned work profile:** - Select "Corporate-owned work profile" → Create profile - Configure user affinity requirements 6. Distribute QR codes or enrollment instructions per profile 7. Monitor enrollment in Intune → Devices → Android Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/android-fully-managed-enroll https://learn.microsoft.com/en-us/mem/intune/enrollment/android-dedicated-devices-enroll https://learn.microsoft.com/en.com/mem/intune/enrollment/android-corporate-work-profile

Explanation

Android management in Intune spans three main categories: legacy Android device administrator (deprecated), Android Enterprise (modern Google management framework), and Android Open Source Project (AOSP) for specialized devices like Teams displays or rugged hardware without Google Mobile Services. Android Enterprise is the recommended path with work profile and fully managed options. Think of it as: Three different Android ecosystems — Android Enterprise is the secure, managed city; legacy DA is the old town being phased out; AOSP is the industrial zone with specialized equipment. Key Mechanics: - Android Enterprise: Requires Google Mobile Services, managed via Play Store - AOSP: No Google services, managed via Intune directly, limited capabilities - Legacy DA: Deprecated, new enrollments blocked since 2024 - Android Enterprise supports work/profile separation, app management - AOSP devices: Teams displays, rugged scanners, custom hardware

Examples

Example 1 — [Success] Multi-mode Android management in healthcare A hospital manages three Android types in Intune: doctor personal phones use Android Enterprise work profile (personal/work separation, BYOD), clinical Zebra scanners use fully managed enrollment (corporate, work-only), and patient room Teams displays use AOSP enrollment (no Google services required). Each device type gets appropriate policies.

Example 2 — [Blocked] AOSP device enrolled as fully managed — app deployment fails An IT admin enrolls Teams display hardware using the fully managed enrollment profile rather than the AOSP profile. The enrollment succeeds but the device shows app deployment errors because it has no Google Play services. Root cause: Teams display hardware runs AOSP (no Google Mobile Services) — it must be enrolled using the AOSP enrollment token, not the Android Enterprise fully managed profile.

Key Mechanisms

- Core function: Android management in Intune spans three main categories: legacy Android device administrator (deprecated), Android Enterprise (modern Google management framework), and Android Open Source Project (AOSP) for specialized devices like Teams displays or rugged hardware without Google Mobile Services. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Multi-mode Android management in healthcare - Decision clue: Industry: Hospitality

Review Path

Steps: 1. **Android Enterprise Setup:** - Connect to Managed Google Play (Tenant admin → Connectors → Google) - Choose enrollment types (work profile, fully managed, dedicated) - Create profiles per use case - Deploy apps from Managed Google Play 2. **AOSP Setup:** - Intune admin center → Devices → Android → AOSP enrollment - Click "Create profile" → Name → Generate token - Download token file for device provisioning - On AOSP device: Settings → Security → Device administration → Enrollment - Upload LOB apps directly (no Play Store) 3. **Legacy DA (if still present):** - Plan migration to Android Enterprise - Block new DA enrollments via enrollment restrictions - Re-enroll existing DA devices as Android Enterprise Docs: https://learn.microsoft.com/en-us/mem/intune/enrollment/android-enterprise-enroll https://learn.microsoft.com/en-us/mem/intune/enrollment/android-aosp-enroll https://learn.microsoft.com/en-us/mem/intune/fundamentals/migration-guide-android

Explanation

Managing roles in Intune involves assigning administrative permissions to control who can perform specific tasks within the Microsoft Intune console. Roles define what actions admins can take (create policies, wipe devices, view reports) and scope groups determine which devices or users those actions apply to. Think of it as: Creating an organizational chart for IT — help desk can reset passwords but not change policies, security admins can view compliance but not deploy apps. Key Mechanics: - Built-in roles: Help Desk Operator, Policy Manager, Application Manager, etc. - Custom roles can be created with specific permissions - Scope groups limit role visibility to specific device/user collections - Role assignments combine: Role + Members + Scope + (optional) Scope tags - Multiple roles can be assigned to a single user

Examples

Example 1 — [Success] Tiered IT role assignments A company assigns the built-in Help Desk Operator role to Level 1 support (reset passcode, sync device, view device details) and the Policy and Profile Manager role to senior admins (create and assign policies). Scope tags ensure Level 1 only sees devices in their region — no accidental global policy changes.

Example 2 — [Blocked] Help desk admin accesses wrong tenant section A help desk admin is assigned the Help Desk Operator role in Intune but then tries to access Entra ID to reset a user's MFA. They receive "Access Denied." Root cause: Intune RBAC roles only apply to Intune — Entra ID requires separate role assignments (e.g., Authentication Administrator). Intune roles and Entra roles are independent permission systems.

Key Mechanisms

- Core function: Managing roles in Intune involves assigning administrative permissions to control who can perform specific tasks within the Microsoft Intune console. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Tiered IT role assignments - Decision clue: Industry: Healthcare

Review Path

Steps: 1. Navigate to Intune admin center → Tenant admin → Roles → All roles 2. Review built-in roles and their permissions 3. To create custom role: Click "Create" → Name → Description 4. Select permissions categories (e.g., Managed apps, Device configurations) 5. Add specific permissions within each category 6. Click Create → Then "Assign" the role 7. In assignment: Add Members (users/groups), Scope (groups), Scope tags 8. Save assignment 9. Verify effective permissions by signing in as test admin Docs: https://learn.microsoft.com/en-us/mem/intune/fundamentals/role-based-access-control https://learn.microsoft.com/en-us/mem/intune/fundamentals/create-custom-role https://learn.microsoft.com/en-us/mem/intune/fundamentals/scope-tags

Explanation

Role-Based Access Control (RBAC) in Intune provides granular permission management by separating administrative responsibilities into roles, assignments, and scope tags. RBAC ensures administrators have only the permissions necessary for their job functions, following the principle of least privilege. Think of it as: A library with different key cards — the janitor can enter supply closets, librarians can access catalog systems, and the director has keys to everything, but no one has unnecessary access. Key Mechanics: - RBAC consists of: Roles (permission sets), Assignments (who gets them), Scopes (what they apply to) - Built-in roles cover common admin functions - Custom roles allow precise permission control - Scope tags further restrict visibility within assignments - Azure AD roles (Global Admin) override Intune RBAC

Examples

Example 1 — [Success] Regional RBAC with scope tags A global company applies scope tag "EU-Region" to all European devices and creates a role assignment giving the Europe Help Desk team the Help Desk Operator role scoped to the EU-Region tag. European admins can view and manage only EU devices — US-based devices are invisible to them in the Intune console.

Example 2 — [Blocked] Global Admin bypasses Intune RBAC scope A regional IT manager notices that a Global Administrator account can see all devices across all regions, ignoring the scope tags the team carefully configured. Root cause: Azure AD Global Administrator (and Intune Service Administrator) roles override all Intune RBAC scopes — they always see everything. Scope tags only restrict custom Intune roles, not Azure AD admin roles.

Key Mechanisms

- Core function: Role-Based Access Control (RBAC) in Intune provides granular permission management by separating administrative responsibilities into roles, assignments, and scope tags. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Regional RBAC with scope tags - Decision clue: Industry: Education

Review Path

Steps: 1. Plan RBAC strategy: Document admin roles, responsibilities, and scope requirements 2. Navigate to Intune admin center → Tenant admin → Roles 3. Review built-in roles for potential matches to your needs 4. Create custom roles if built-in roles don't meet requirements 5. Create Scope Tags for organizational divisions (region, department, device type) 6. Apply scope tags to devices via configuration profiles or dynamically 7. Create role assignments: Select Role → Members → Scope → Scope Tags 8. Test assignments by signing in as test admin users 9. Audit assignments regularly using Intune RBAC reports Docs: https://learn.microsoft.com/en-us/mem/intune/fundamentals/role-based-access-control https://learn.microsoft.com/en-us/mem/intune/fundamentals/scope-tags https://learn.microsoft.com/en-us/mem/intune/fundamentals/create-custom-role

Explanation

Compliance policies in Intune define the rules and settings that devices must meet to be considered compliant with organizational security requirements. These policies span all platforms (Windows, iOS, Android, macOS) and cover areas like OS version, encryption, jailbreak detection, password requirements, and threat protection levels. Think of it as: A security checkpoint with different requirements for different vehicle types — cars (Windows) need seatbelts, motorcycles (iOS) need helmets, but all must have valid registration. Key Mechanics: - Each platform has platform-specific compliance settings - Compliance is evaluated regularly and on check-in - Non-compliant devices can be blocked or receive remediation actions - Compliance state feeds into Conditional Access decisions - Can be combined with device health attestation (Windows)

Examples

Example 1 — [Success] Cross-platform baseline compliance A company creates separate compliance policies for Windows (BitLocker + Defender), iOS (passcode + jailbreak detection), and Android (work profile + encryption). All policies require OS version minimums. Devices that pass all checks are marked compliant and gain full access to corporate apps via Conditional Access.

Example 2 — [Blocked] Compliance policy created but access not blocked An admin creates a Windows compliance policy requiring BitLocker but notices that a non-compliant device can still access SharePoint without restriction. Root cause: Compliance policies alone do NOT block access — they only set the compliance state. A Conditional Access policy requiring "Device must be compliant" must also be created to enforce the block. CA enforcement is a separate configuration.

Key Mechanisms

- Core function: Compliance policies in Intune define the rules and settings that devices must meet to be considered compliant with organizational security requirements. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Cross-platform baseline compliance - Decision clue: Industry: Financial Services

Review Path

Steps: 1. Navigate to Intune admin center → Devices → Compliance policies → Create policy 2. Select platform: Windows, iOS, Android, or macOS 3. Configure platform-specific settings: - Device Health: Require BitLocker, Secure Boot (Windows) - System Security: Password requirements, encryption - Microsoft Defender for Endpoint: Threat level (if integrated) 4. Set "Actions for noncompliance": Mark device non-compliant, send email, etc. 5. Assign policy to device groups 6. Create policies for each platform used in your organization 7. Monitor compliance in Intune → Devices → Monitor → Compliance reports 8. Integrate with Conditional Access for access control Docs: https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started https://learn.microsoft.com/en-us/mem/intune/protect/compliance-policy-create-windows https://learn.microsoft.com/en-us/mem/intune/protect/compliance-policy-create-ios

Explanation

Creating a device compliance policy involves defining the specific rules and settings a device must meet to be considered compliant in Intune. The process includes selecting the target platform, configuring security requirements, setting compliance thresholds, defining actions for non-compliance, and assigning the policy to appropriate device groups. Think of it as: Writing the rulebook for device security — you define what "good behavior" looks like and what happens when devices break the rules. Key Mechanics: - Start by selecting platform (Windows, iOS, Android, macOS) - Configure settings: password, encryption, OS version, threat protection - Set grace periods for compliance remediation - Define actions for non-compliance (email, remote lock, retire) - Assign to groups; compliance evaluation runs automatically

Examples

Example 1 — [Success] Windows compliance policy with enforcement An IT admin creates a Windows compliance policy: BitLocker required, minimum Windows 10 22H2, Defender real-time protection on. The policy is assigned to "All Windows Devices." A Conditional Access policy then blocks non-compliant devices from accessing Microsoft 365 — a laptop with BitLocker disabled is immediately blocked from Exchange Online.

Example 2 — [Blocked] Compliance policy applies to wrong platform An admin creates a compliance policy with iOS-specific settings (jailbreak detection) and assigns it to a group that includes both iOS and Windows devices. Windows devices report "Not applicable" for the iOS settings and appear in a mixed compliance state. Root cause: Compliance policies are platform-specific — iOS policies only apply to iOS devices. Create separate policies per platform and assign to platform-specific groups.

Key Mechanisms

- Core function: Creating a device compliance policy involves defining the specific rules and settings a device must meet to be considered compliant in Intune. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Windows compliance policy with enforcement - Decision clue: Industry: Legal

Review Path

Steps: 1. Sign in to Intune admin center → Devices → Compliance policies → Create policy 2. Select platform (Windows, iOS, Android, macOS) 3. Configure **Basics**: Name, description 4. Configure **Compliance settings** per platform: - Device Health: BitLocker, Secure Boot (Windows) - Device Properties: Minimum OS version - System Security: Password settings, encryption - Microsoft Defender for Endpoint (if integrated) 5. Configure **Actions for noncompliance**: Add actions and schedules 6. Configure **Assignments**: Select groups to receive policy 7. Configure **Applicability rules** (optional): Filter by OS edition, etc. 8. Review and create policy 9. Monitor compliance in Intune → Devices → Monitor → Compliance reports Docs: https://learn.microsoft.com/en-us/mem/intune/protect/create-compliance-policy https://learn.microsoft.com/en-us/mem/intune/protect/compliance-policy-create-windows https://learn.microsoft.com/en-us/mem/intune/protect/actions-for-noncompliance

Explanation

Actions for noncompliance define what happens when a device fails to meet compliance policy requirements. These automated responses range from simple notifications to progressive enforcement actions, allowing organizations to remediate issues gradually before applying stricter measures like blocking access or retiring the device. Think of it as: A progressive disciplinary system — first a warning, then restricted privileges, and finally removal if the issue isn't fixed. Key Mechanics: - Actions are sequenced with time delays (e.g., notify immediately, block after 7 days) - Multiple actions can be configured per policy - Actions include: mark non-compliant, email notification, remote lock, retire device - Grace periods allow users time to fix issues before enforcement - Different platforms support different action types

Examples

Example 1 — [Success] Graduated noncompliance enforcement A company configures three actions: immediately mark device non-compliant (triggers CA block), send email to user after 1 day, retire device after 14 days. A laptop with outdated OS triggers the chain — the user gets an email, fixes the update within 3 days, and the device returns to compliant status before retirement fires.

Example 2 — [Blocked] Actions fire out of order — user locked out immediately An admin adds "Mark device non-compliant" as the third action (scheduled after 7 days) and sets "Block access" as an immediate action first. All devices are locked out immediately regardless of compliance status. Root cause: "Mark device non-compliant" must be the first action with the lowest schedule (0 days) — it triggers all subsequent enforcement. Setting block actions before marking non-compliant causes immediate lockout without a grace period.

Key Mechanisms

- Core function: Actions for noncompliance define what happens when a device fails to meet compliance policy requirements. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Graduated noncompliance enforcement - Decision clue: Industry: Retail

Review Path

Steps: 1. Navigate to Intune admin center → Devices → Compliance policies 2. Select an existing policy or create new one 3. Go to "Actions for noncompliance" tab 4. Click "Add" to create new action 5. Select action type: - Mark device non-compliant - Send email to end user - Retire device - Remote lock (iOS only) 6. Configure schedule (immediate or days after non-compliance) 7. For email actions: Select message template (create in Tenant admin) 8. Add multiple actions in sequence (lowest days first) 9. Save policy 10. Test by intentionally making a device non-compliant Docs: https://learn.microsoft.com/en-us/mem/intune/protect/actions-for-noncompliance https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-remote-lock

Explanation

Monitoring device compliance in Intune involves tracking the compliance status of enrolled devices through reports, dashboards, and alerts. This visibility helps IT identify non-compliant devices, understand compliance trends, and take corrective action before security risks escalate. Think of it as: A security camera system for your device fleet — you can see at a glance who's following the rules and who needs attention. Key Mechanics: - Compliance status: Compliant, Non-compliant, In grace period, Not evaluated - Reports available in Intune console and via Graph API - Export capabilities for external reporting - Real-time compliance data feeds into Conditional Access - Historical trends available for compliance over time

Examples

Example 1 — [Success] Weekly compliance reporting workflow An IT manager runs the "Device compliance" report weekly, filtering by platform = Windows and compliance = Non-compliant. The report exports to CSV for the security team. Trend data shows compliance improved from 78% to 94% over four weeks after the BitLocker enforcement policy was deployed.

Example 2 — [Blocked] Report shows compliant but user is blocked by CA A user's device shows "Compliant" in the Intune compliance report but is still blocked from SharePoint by Conditional Access. Root cause: Compliance state in Intune updates on check-in (typically every 8 hours) — if the device just became compliant, CA has not yet received the updated token. Fix: Force device sync in Intune (or from device Settings → Access work or school → Sync) to push the updated compliance state immediately.

Key Mechanisms

- Core function: Monitoring device compliance in Intune involves tracking the compliance status of enrolled devices through reports, dashboards, and alerts. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Weekly compliance reporting workflow - Decision clue: Industry: Healthcare Compliance

Review Path

Steps: 1. Navigate to Intune admin center → Devices → Overview for summary dashboard 2. View compliance status widget for high-level metrics 3. For detailed reports: Go to Devices → Monitor 4. Select report type: - "Device compliance" for list view - "Non-compliant devices" for filtered view - "Compliance trend" for historical analysis 5. Apply filters: Platform, Compliance state, Policy assignment 6. Export reports using "Export" button (CSV format) 7. Schedule compliance report exports using Microsoft Graph API 8. Set up compliance alerts in Microsoft Sentinel or using Intune notifications Docs: https://learn.microsoft.com/en-us/mem/intune/protect/compliance-reports https://learn.microsoft.com/en.com/mem/intune/protect/device-compliance-monitor https://learn.microsoft.com/en-us/mem/intune/fundamentals/reports

Explanation

Troubleshooting policies and profiles in Intune involves identifying why configurations aren't applying correctly, resolving conflicts between policies, and ensuring devices receive expected settings. This requires understanding policy delivery mechanisms, checking device check-in status, and using built-in troubleshooting tools. Think of it as: Being a detective for device configuration — you need to follow the evidence trail from Intune cloud to the local device to find where things went wrong. Key Mechanics: - Policy application depends on device check-in frequency (typically 8 hours) - Conflicts resolved by most restrictive or last applied (depending on type) - Troubleshooting tools: Device check-in status, policy reports, logs - Common issues: Targeting wrong groups, conflicting settings, device not checking in - PowerShell and Graph API can force sync for testing

Examples

Example 1 — [Success] Policy conflict resolved via Intune troubleshooting A help desk technician discovers a BitLocker policy shows "Conflict" on a device. They open Intune → Device → Device configuration, identify two overlapping policies with conflicting BitLocker settings, remove the redundant custom policy, force a sync, and confirm the policy changes to "Succeeded" within minutes.

Example 2 — [Blocked] Policy assigned but device never receives it An admin assigns a kiosk configuration profile to "All Corporate Devices" but the target kiosk never enters kiosk mode. Root cause: The kiosk device was enrolled under a test account that was added to the excluded group. The device is in both the target group AND the exclusion group — exclusions always win. Admin must remove the device from the exclusion group.

Key Mechanisms

- Core function: Troubleshooting policies and profiles in Intune involves identifying why configurations aren't applying correctly, resolving conflicts between policies, and ensuring devices receive expected settings. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Policy conflict resolved via Intune troubleshooting - Decision clue: Industry: IT Support

Review Path

Steps: 1. **Verify Device Health:** - Intune → Devices → Select device → Check "Last check-in" time - If >24 hours, use "Sync" remote action 2. **Check Policy Assignment:** - Open policy → Properties → Assignments - Confirm device group is targeted - Check exclusion rules and filters 3. **View Device Policy Status:** - Device → [Device] → Device configuration - Review each policy status (Succeeded/Pending/Error/Conflict) 4. **Identify Conflicts:** - Look for policies with same settings but different values - Use "Settings catalog" view to see all applied settings 5. **Review Logs:** - On Windows device: C:ProgramDataMicrosoftIntuneManagementExtensionLogs - On iOS: Company Portal app → Device details → Logs 6. **Force Policy Refresh:** - Remote action: "Sync" in Intune - On device: Settings → Accounts → Access work or school → Info → Sync 7. **Escalate with Support:** - Collect logs, device IDs, policy details - Open Microsoft support ticket if needed Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/troubleshoot-policies-in-microsoft-intune https://learn.microsoft.com/en.com/mem/intune/fundamentals/help-desk-operators https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-sync

Explanation

Conditional Access policies that require device compliance use the compliance status reported by Intune to control access to cloud applications. When a device is marked non-compliant, Conditional Access can block access to corporate resources, creating a powerful security control that ensures only healthy, managed devices can access sensitive data. Think of it as: A bouncer at a club who checks your ID (compliance status) before letting you in — if your ID is expired or fake (non-compliant), you're not getting past the door. Key Mechanics: - Conditional Access evaluates compliance status in real-time - Requires devices to be enrolled in Intune (or have compliant claim) - Compliance claim is only present for managed devices - Can target specific apps or all cloud apps - Works with "Require device to be marked as compliant" condition

Examples

Example 1 — [Success] Compliant device enforcement for Microsoft 365 A company creates a CA policy: target all users + Exchange Online + SharePoint, grant access only if "Device is marked as compliant." A compliant Intune-enrolled laptop passes the check and receives an access token. A non-compliant laptop (missing BitLocker) is blocked at sign-in with a "Your device must be compliant" message.

Example 2 — [Blocked] Compliance policy set but access still works on non-compliant device An admin creates a compliance policy requiring BitLocker, marks the device non-compliant in testing, but the user can still access SharePoint. Root cause: Compliance policies alone do NOT block access — they only set the compliance state. A separate Conditional Access policy with "Require device to be marked as compliant" must also be configured to enforce the block. Creating the compliance policy without a CA policy does nothing to restrict access.

Key Mechanisms

- Core function: Conditional Access policies that require device compliance use the compliance status reported by Intune to control access to cloud applications. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Compliant device enforcement for Microsoft 365 - Decision clue: Industry: Legal Services

Review Path

Steps: 1. Ensure devices are enrolled in Intune with compliance policies assigned 2. Navigate to Entra admin center → Protection → Conditional Access 3. Click "New policy" or "+ Create new policy" 4. Name policy (e.g., "Require Compliant Device for Office 365") 5. Under **Assignments**: - Users: Select appropriate groups (test with pilot first) - Cloud apps: Select target apps (Office 365, Exchange Online, etc.) - Conditions: Configure device platforms, locations as needed 6. Under **Access controls** → Grant: - Check "Require device to be marked as compliant" - Select "Require all selected controls" 7. Under **Enable policy**: Set to "Report-only" for testing 8. Monitor sign-in logs to verify expected behavior 9. After validation, set policy to "On" 10. Test from non-compliant device to confirm block Docs: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-grant https://learn.microsoft.com/en-us/mem/intune/protect/conditional-access https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-compliant-device

Explanation

Device-based Conditional Access policies use device state and attributes (join type, compliance status, domain membership) as conditions for granting or blocking access to cloud apps. These policies ensure that access decisions consider the security posture of the device itself, not just user identity. Think of it as: Airport security for cloud access — your boarding pass (user identity) gets you to the gate, but your carry-on screening (device health) determines if you actually board the plane. Key Mechanics: - Device conditions include: Compliant, Hybrid joined, Entra joined, Registered - Can require specific join types for sensitive apps - Device filters allow targeting by model, manufacturer, OS - Works alongside user and location conditions - Real-time evaluation during authentication

Examples

Example 1 — [Success] ERP access locked to corporate devices A company creates a device-based CA policy for the financial ERP system: grant access only to Entra joined + compliant devices. A corporate laptop (Entra joined, compliant) gets through. A personal MacBook (registered, not managed) is blocked. An unmanaged home PC is blocked. Device state is the gate, not just user credentials.

Example 2 — [Blocked] CA filter targets wrong attribute — wrong devices blocked An admin creates a device filter to target corporate devices using device.deviceOwnership -eq "Company" but accidentally blocks ALL access when the filter operator is set incorrectly to "Exclude" instead of "Include." All corporate users are now blocked from the ERP. Fix: In CA policy → Conditions → Filter for devices, verify the operator is "Include" for the trusted device attribute.

Key Mechanisms

- Core function: Device-based Conditional Access policies use device state and attributes (join type, compliance status, domain membership) as conditions for granting or blocking access to cloud apps. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] ERP access locked to corporate devices - Decision clue: Industry: Government Contractor

Review Path

Steps: 1. Navigate to Entra admin center → Protection → Conditional Access 2. Click "New policy" 3. Configure **Assignments**: - Users: Select target user groups - Cloud apps: Select specific apps requiring device control - Conditions: Configure device platforms as needed 4. Under **Conditions** → "Filter for devices": - Configure rule to include/exclude specific device types - Example: (device.deviceOwnership -eq "Corporate") -and (device.isCompliant -eq True) 5. Under **Access controls** → Grant: - Select requirements (compliant, hybrid joined, etc.) 6. Set policy to "Report-only" initially 7. Monitor sign-in logs for impact 8. Enable policy after validation 9. Create complementary policies for different scenarios Docs: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-conditions https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-compliant-device https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-condition-filters-for-devices

Explanation

Configuring Windows Hello for Business replaces passwords with strong two-factor authentication on Windows devices, using biometrics (fingerprint, facial recognition) or PIN tied to a device's TPM chip. This passwordless solution enhances security while improving user experience by providing seamless sign-in to both devices and cloud resources. Think of it as: Replacing your house key (password) with a fingerprint scanner and a unique, device-specific PIN that only works on your front door. Key Mechanics: - Requires Windows 10/11 devices with TPM 2.0 - Two-factor: Device-specific credential + user gesture (PIN/biometric) - Keys stored in TPM (hardware-based security) - Integrates with Entra ID and on-premises AD (for hybrid) - Can be configured via Intune policy or Group Policy

Examples

Example 1 — [Success] Passwordless laptop sign-in with facial recognition A company deploys a Windows Hello for Business Intune policy requiring TPM 2.0 and enabling biometrics. Employees set up facial recognition during first sign-in and subsequently unlock their laptops and access Microsoft 365 via SSO without ever typing a password. Phishing attempts are ineffective because credentials are bound to each device's TPM.

Example 2 — [Blocked] Windows Hello setup fails — TPM not present An IT admin deploys a Windows Hello for Business policy with "Require TPM" enabled to a group that includes some older Dell laptops without TPM chips. Those devices show a Windows Hello setup error at first sign-in: "This PC doesn't meet the requirements for Windows Hello." Root cause: Windows Hello for Business with "Require TPM" will not provision on devices without a TPM 2.0 chip. Fix: Filter the policy to exclude devices without TPM, or set TPM to "Preferred" instead of "Require."

Key Mechanisms

- Core function: Configuring Windows Hello for Business replaces passwords with strong two-factor authentication on Windows devices, using biometrics (fingerprint, facial recognition) or PIN tied to a device's TPM chip. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Passwordless laptop sign-in with facial recognition - Decision clue: Industry: Financial Services

Review Path

Steps: 1. **Prerequisites Check:** - Verify devices are Windows 10/11 with TPM 2.0 - Ensure Entra ID Premium licenses assigned - For hybrid: Set up Entra Connect with password hash sync 2. **Create Intune Policy:** - Go to Intune admin center → Devices → Configuration profiles - Click "Create profile" → Platform: Windows 10/11 - Profile type: Identity protection 3. **Configure Windows Hello Settings:** - Set "Configure Windows Hello for Business" to Enable - Configure PIN requirements (length, complexity, expiration) - Set biometrics options (enable/disable) - Configure certificate settings for on-premises auth (if needed) 4. **Assign Policy:** - Select target device groups - Use filters to exclude test/devices as needed 5. **Communicate to Users:** - Send setup instructions before policy applies - Guide users through Windows Hello setup at next sign-in 6. **Monitor Deployment:** - Check policy status in Intune - Verify successful Windows Hello registration on devices Docs: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/ https://learn.microsoft.com/en-us/mem/intune/protect/windows-hello https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works

Explanation

Windows Hello for Business is a passwordless authentication method in Windows that replaces passwords with strong two-factor authentication using biometrics or PIN combined with cryptographic keys stored in hardware. It provides seamless single sign-on to both Azure AD and on-premises resources while significantly improving security posture. Think of it as: A biometric passport for your Windows device — it's uniquely yours, extremely difficult to forge, and gets you through security checkpoints without pulling out documents. Key Mechanics: - Two-factor: Something you have (device with TPM) + something you know/are (PIN/biometric) - Keys generated on device, private key never leaves TPM - Supports facial recognition (Windows Hello), fingerprint, iris, and PIN - Works with Entra ID, Active Directory (hybrid), and third-party services via FIDO2 - Provides SSO to Microsoft 365 and federated apps

Examples

Example 1 — [Success] Nurses authenticate with facial recognition A hospital deploys Windows Hello for Business to shared clinical workstations with facial recognition cameras. Nurses walk up to any workstation, their face is recognized in under 2 seconds, and they access the EHR system via SSO without typing a password. No shared credentials exist on any machine — each device's TPM holds individual key pairs.

Example 2 — [Blocked] PIN-only policy blocks biometric users An admin configures Windows Hello with "Use biometrics: Disabled" in the Intune policy, intending to enforce PINs only. Employees who enrolled facial recognition before the policy applied now find it blocked. Root cause: Disabling biometrics via policy prevents future biometric setup AND disables existing enrollments. Users can only use PIN going forward. If biometric support is needed, set "Use biometrics: Enable."

Key Mechanisms

- Core function: Windows Hello for Business is a passwordless authentication method in Windows that replaces passwords with strong two-factor authentication using biometrics or PIN combined with cryptographic keys stored in hardware. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Nurses authenticate with facial recognition - Decision clue: Industry: Education

Review Path

Steps: 1. **Plan Deployment:** - Assess device compatibility (TPM 2.0, cameras/biometrics) - Choose deployment model (cloud-only, hybrid, or on-premises) - Determine trust type (key trust or certificate trust) 2. **Configure Infrastructure:** - For hybrid: Set up Entra Connect with password hash sync - Ensure devices are Entra joined or hybrid joined 3. **Create Intune Policy:** - Devices → Configuration profiles → Create profile - Windows 10/11 → Identity protection → Windows Hello for Business - Configure settings as needed 4. **Communicate to Users:** - Prepare setup instructions - Explain benefits and features 5. **Enable and Monitor:** - Deploy policy to pilot group first - Monitor successful registrations - Expand to all users Docs: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/ https://learn.microsoft.com/en-us/mem/intune/protect/windows-hello https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-guide

Explanation

Windows Local Administrator Password Solution (LAPS) manages local administrator passwords on domain-joined or Entra joined Windows devices by rotating them regularly and storing them securely in Active Directory or Entra ID. This prevents lateral movement attacks where compromised local admin passwords are reused across multiple machines. Think of it as: A hotel key card system that changes the code for every room each night — even if someone steals yesterday's key, it won't work today. Key Mechanics: - Automatically rotates local admin password on each device - Stores passwords securely in AD (attributes) or Entra ID - Authorized users can retrieve current password when needed - Configurable password complexity and rotation frequency - Works with both on-premises AD (legacy LAPS) and Entra ID (Windows LAPS)

Examples

Example 1 — [Success] LAPS provides just-in-time local admin access A help desk technician needs to troubleshoot a remote laptop. They navigate to Entra admin center → Devices → [Device name] → Local administrator password. After MFA verification, the current LAPS password is shown. The technician uses it for the remote session — the password automatically rotates after the post-authentication window expires, eliminating standing access.

Example 2 — [Blocked] LAPS password retrieval fails — missing permission A Level 1 help desk member tries to view the LAPS password for a device but receives "Access Denied" in the Entra admin center. Root cause: Viewing LAPS passwords requires the "microsoft.directory/device/localCredential/standard/read" permission — the Help Desk Operator built-in role does not include it by default. Admin must create a custom role with this permission or assign a role that includes it explicitly.

Key Mechanisms

- Core function: Windows Local Administrator Password Solution (LAPS) manages local administrator passwords on domain-joined or Entra joined Windows devices by rotating them regularly and storing them securely in Active Directory or Entra ID. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] LAPS provides just-in-time local admin access - Decision clue: Industry: Financial Services

Review Path

Steps: 1. **Choose LAPS Type:** - For hybrid/on-prem: Use classic LAPS - For cloud/Entra joined: Use Windows LAPS 2. **For Windows LAPS (Entra ID):** - Ensure devices are Entra joined or hybrid joined - Navigate to Intune admin center → Devices → Configuration profiles - Create profile → Windows 10/11 → Templates → Windows LAPS - Configure settings: - Backup directory password: Enable - Password complexity: High - Password length: 14-16 - Password age: 30 days - Post-authentication reset: Enable - Assign profile to device groups 3. **Configure Permissions:** - In Entra ID, grant users/groups permission to read LAPS passwords - Use least privilege principle (only help desk, admins) 4. **Test Retrieval:** - As authorized user, view device in Entra admin center - Click "Show local administrator password" - Verify password works for local sign-in 5. **Audit Usage:** - Monitor Entra ID sign-in logs for LAPS access - Set up alerts for unusual retrieval patterns Docs: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview https://learn.microsoft.com/en-us/entra/identity/devices/howto-manage-local-admin-passwords https://learn.microsoft.com/en-us/mem/intune/protect/windows-laps-overview

Explanation

Windows LAPS integrated with Entra ID provides cloud-native management of local administrator passwords for Entra joined and hybrid joined devices. Passwords are securely stored in Entra ID device objects, rotated automatically, and can be retrieved by authorized users through the Entra admin center or Microsoft Graph API.

Think of it as: A cloud-based safe deposit box for each device's local admin password — only authorized personnel have keys to open specific boxes, and the combinations change regularly.

Key Mechanics: - Passwords encrypted and stored in Entra ID device objects - Automatic rotation based on schedule or post-retrieval - Access controlled via Entra ID roles and permissions - Supports both Entra joined and hybrid joined devices - Audit logs track all password retrievals

Examples

Example 1 — [Success] LAPS Entra ID retrieval for remote support A support technician retrieves the LAPS password for a remote employee's Entra joined laptop via Entra admin center. They use it to connect via Remote Assistance, fix a software issue, and close the session. Intune's post-authentication reset triggers and the device automatically generates and uploads a new password to Entra ID on the next check-in.

Example 2 — [Blocked] LAPS password used again after retrieval — access denied A technician retrieves the LAPS password on Monday and saves it in a text file for "future use." On Thursday they try to log in with the same password and are denied. Root cause: Windows LAPS with post-authentication reset enabled automatically rotates the password after use — the saved password is now invalid. LAPS passwords are one-time use; every support session requires a fresh retrieval from Entra ID.

Key Mechanisms

- Core function: Windows LAPS integrated with Entra ID provides cloud-native management of local administrator passwords for Entra joined and hybrid joined devices. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] LAPS Entra ID retrieval for remote support - Decision clue: Industry: Technology Consulting

Review Path

Steps:

Prerequisites: - Devices must be Entra joined or hybrid joined - Windows 10/11 21H2 or later - Entra ID Premium P1/P2 licenses

1. Enable Windows LAPS in Intune: - Intune admin center → Devices → Configuration profiles - Create profile → Windows 10/11 → Templates → Windows LAPS - Configure backup directory: Azure AD, password complexity, length, age - Configure post-authentication actions - Assign to device groups

2. Configure Access Permissions: - Entra admin center → Roles and admins - Create custom role or use built-in Helpdesk Administrator - Add permissions for LAPS password read - Assign role to appropriate groups

3. Test Retrieval: - As authorized user, go to Entra admin center → Devices - Select a device → Show local administrator password - Verify MFA authentication if prompted

4. Monitor Access: - Check Entra ID audit logs for LAPS operations - Set up alerts for unusual retrieval patterns

Docs: https://learn.microsoft.com/en-us/entra/identity/devices/howto-manage-local-admin-passwords https://learn.microsoft.com/en-us/mem/intune/protect/windows-laps-overview https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-available-permissions

Explanation

Managing local group membership on Windows devices via Intune allows IT to control which users and groups have local administrative privileges or other rights on managed devices. This ensures consistent local access across the device fleet while maintaining security through least-privilege principles. Think of it as: A centralized control room for door access — instead of changing locks on every door individually, you manage who has keys from one location. Key Mechanics: - Uses Intune device configuration profile (Administrative Templates or Settings Catalog) - Can add or remove users/Azure AD groups from local groups - Supports built-in groups: Administrators, Users, Remote Desktop Users, etc. - Applies at device check-in, overwriting any manual changes (if configured) - Can target based on device or user groups

Examples

Example 1 — [Success] IT support group added to local Administrators via Intune An organization creates a Settings Catalog profile targeting local Administrators group with Action: Add and members: AZUREADIT_Support_Group. All corporate Windows devices pick up the policy on next check-in. Help desk staff log in with their Entra credentials and have local admin rights for troubleshooting without sharing a local password.

Example 2 — [Blocked] Replace action removes all local admins including default account An admin creates a policy with Action: Replace on the Administrators group, listing only the IT_Support_Group. After the policy applies, devices lose the built-in local Administrator account and the device's primary user admin rights — all future local logons require IT staff credentials. Root cause: Replace removes ALL existing members and replaces with only the specified list. Use Action: Add to augment existing members without removing the built-in Administrator.

Key Mechanisms

- Core function: Managing local group membership on Windows devices via Intune allows IT to control which users and groups have local administrative privileges or other rights on managed devices. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] IT support group added to local Administrators via Intune - Decision clue: Industry: Education

Review Path

Steps: 1. **Identify Requirements:** - Which local groups need management? (Administrators, Users, RDU) - Which Azure AD groups should be members? - What action type? (Add, Remove, Replace) 2. **Create Configuration Profile:** - Intune admin center → Devices → Configuration profiles - Create → Platform: Windows 10/11 - Profile type: Settings Catalog 3. **Add Local Users and Groups Settings:** - Search for "Local Users and Groups" - Select "Local Users and Groups" category - Choose "Configure local group" setting 4. **Configure Group Settings:** - Group name: Administrators (or custom group) - Action: Replace (for strict control) or Add (for augmentation) - Members: Add Azure AD groups or users (format: AZUREADGroupName) 5. **Assign Profile:** - Assign to appropriate device groups - Use filters to target specific device types or locations 6. **Test and Monitor:** - Test on pilot devices first - Verify membership on test device: net localgroup administrators - Monitor policy status in Intune Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/settings-catalog https://learn.microsoft.com/en-us/mem/intune/configuration/local-user-groups https://learn.microsoft.com/en-us/mem/intune/configuration/administrative-templates-windows

Explanation

Managing local administrators on Entra joined devices involves controlling which users and groups have elevated privileges on cloud-native devices. Unlike traditional AD, Entra joined devices use Azure AD groups and users as security principals, allowing centralized management of local admin rights through Intune policies. Think of it as: Remote control for who has the master keys — you can grant or revoke administrative access to any Entra joined device from the cloud, without ever touching the device. Key Mechanics: - Azure AD groups can be added to local Administrators group - Users added as local admins get elevated rights on sign-in - Intune policy manages membership (add/remove/replace) - Default local admin account can be disabled or renamed - Primary user automatically gets admin rights (configurable)

Examples

Example 1 — [Success] Scoped local admin rights for executive support A company creates an Intune Settings Catalog policy that adds "Executive_IT_Support" Entra group to local Administrators on executive laptops (filtered by device.extensionAttribute1 -eq "Executive"). Specialized support staff can manage executive laptops without giving general help desk access to those devices.

Example 2 — [Blocked] Primary user loses local admin rights after Intune policy After deploying an Intune policy with Action: Replace on the Administrators group, a power user reports they can no longer install software on their own laptop. Root cause: On Entra joined devices, the primary user is initially given local admin rights, but an Intune Replace action removes them. Fix: Explicitly add the "Device Owner" or the user's Entra account to the member list, or use Action: Add to preserve existing membership.

Key Mechanisms

- Core function: Managing local administrators on Entra joined devices involves controlling which users and groups have elevated privileges on cloud-native devices. - Category fit: This concept belongs to device enrollment and infrastructure and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Scoped local admin rights for executive support - Decision clue: Industry: Legal Services

Review Path

Steps: 1. **Plan Admin Groups:** - Create Azure AD groups for different admin tiers (IT_Support, Senior_IT, etc.) - Define which groups need admin access on which devices 2. **Create Intune Configuration Profile:** - Intune admin center → Devices → Configuration profiles - Create → Platform: Windows 10/11 → Profile type: Settings Catalog 3. **Add Local Users and Groups Settings:** - Search: "Local Users and Groups" - Select: "Local Users and Groups" → "Configure local group" 4. **Configure Group Settings:** - Group name: Administrators - Action: Replace (for strict control) or Add (for augmentation) - Members: Add Azure AD groups (format: AZUREADGroupName) 5. **Target the Profile:** - Assign to "All Entra Joined Devices" group - Use filters for granular targeting if needed 6. **Test:** - Sign in as test user from IT_Support_Group - Verify UAC elevation available - Run whoami /groups to confirm admin token 7. **Monitor:** - Check policy status in Intune - Verify membership with: net localgroup administrators Docs: https://learn.microsoft.com/en-us/entra/identity/devices/assign-local-admin https://learn.microsoft.com/en-us/mem/intune/configuration/settings-catalog-local-users-groups https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-localusersandgroups

Explanation

Windows Autopilot and Provisioning Packages are two cloud-based methods for deploying Windows devices, but they serve different scenarios. Autopilot is a cloud-first deployment solution that uses OEM-optimized hardware and requires minimal IT intervention, while Provisioning Packages (PPKG) are offline deployment files created with Windows Configuration Designer that can be manually applied to devices.

Think of it as: Autopilot = Cloud concierge service that preps devices before user logs in Provisioning Packages = USB-based setup wizard you hand to someone

Key Mechanics: - Autopilot requires device registration (hardware hash) in Intune/Entra ID - PPKG files work offline, no internet connection needed during initial setup - Autopilot integrates with ESP for app/provisioning tracking - PPKG can be applied via USB, email, or NFC tap - Autopilot provides zero-touch experience; PPKG requires physical access or user interaction

Examples

Example 1 — [Success] OEM ships directly to remote user via Autopilot A company registers hardware hashes with the OEM before purchase. The OEM ships laptops directly to 50 remote employees. Each employee powers on during OOBE, signs in with their Entra credentials, and the device is fully managed and compliant within 30 minutes — no IT involvement or physical contact required.

Example 2 — [Blocked] Autopilot fails at store kiosk — no internet during OOBE A retail store IT team attempts Autopilot for store kiosks during a slow internet connection window. The OOBE never reaches the Autopilot provisioning screen — the device can't contact the Autopilot service. Root cause: Autopilot requires reliable internet connectivity during OOBE. Fix: Use a Provisioning Package (PPKG) via USB for offline environments where internet is unreliable at setup time.

Key Mechanisms

- Core function: Windows Autopilot and Provisioning Packages are two cloud-based methods for deploying Windows devices, but they serve different scenarios. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] OEM ships directly to remote user via Autopilot - Decision clue: Industry: Education

Review Path

Steps:

1. Access Windows Configuration Designer from Microsoft Store or download 2. Choose "Provision desktop devices" and configure: - Device name pattern - Wi-Fi credentials - Entra join or local account setup - Applications to install 3. Export as .ppkg and distribute via USB/email 4. For Autopilot: Go to Intune admin center → Devices → Windows enrollment 5. Import device hashes from CSV or OEM 6. Assign Autopilot deployment profile 7. Configure Enrollment Status Page for app tracking 8. Ship devices directly to users

Docs: https://learn.microsoft.com/en-us/autopilot/windows-autopilot https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-packages https://learn.microsoft.com/en-us/mem/intune/configuration/provisioning-packages

Explanation

Windows deployment scenarios define the approach and tools used to install or upgrade Windows across devices based on organizational needs. The four primary scenarios are: bare-metal (new device), in-place upgrade (keep apps/data), refresh (wipe and load), and replace (old to new device migration). Each scenario impacts user data preservation, application compatibility, and IT effort required.

Think of it as: In-place = Remodeling your kitchen without moving out Refresh = Moving out, gutting, and moving back in Replace = Selling the house and buying a new one Bare-metal = Building on an empty lot

Key Mechanics: - In-place upgrade: Uses Windows Setup, keeps user data, apps, settings - Refresh: Wipes device, reinstalls Windows, migrates user data (USMT or OneDrive) - Replace: Old device retired, new device deployed (Autopilot ideal) - Bare-metal: First-time OS installation on new hardware - Deployment tools: Autopilot, MDT, Configuration Manager, Provisioning Packages

Examples

Example 1 — [Success] In-place upgrade preserves user data A company upgrades 500 compatible Windows 10 laptops to Windows 11 via an in-place upgrade deployed through Windows Update for Business rings. Users keep all their apps, files, and settings. The process completes overnight and employees arrive to Windows 11 with everything intact.

Example 2 — [Blocked] In-place upgrade fails due to incompatible hardware An IT team attempts to in-place upgrade 100 older laptops to Windows 11. The upgrade fails on devices without TPM 2.0 or Secure Boot. Root cause: Windows 11 hardware requirements (TPM 2.0, Secure Boot, 64-bit CPU) must be met for in-place upgrade. Incompatible devices require a Replace scenario (new hardware + Autopilot) or must remain on Windows 10 until end of support.

Key Mechanisms

- Core function: Windows deployment scenarios define the approach and tools used to install or upgrade Windows across devices based on organizational needs. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] In-place upgrade preserves user data - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Assess current devices using Update Compliance or Endpoint Analytics 2. Choose scenario based on hardware age and compatibility: - Hardware < 3 years old → In-place upgrade - Hardware incompatible → Refresh or Replace - New hardware → Bare-metal or Autopilot 3. For in-place: Configure Windows Update for Business rings 4. For refresh: Create provisioning package with clean install option 5. For replace: Register new devices in Autopilot, configure data migration 6. Ensure OneDrive Known Folder Move enabled for data backup 7. Test each scenario in pilot before full rollout

Docs: https://learn.microsoft.com/en-us/windows/deployment/windows-10-deployment-scenarios https://learn.microsoft.com/en-us/mem/autopilot/windows-autopilot-scenarios https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-overview

Explanation

Windows Autopilot offers two primary deployment modes: User-Driven (UD) and Self-Deploying (SD), with a third White Glove mode (now called Pre-Provisioning) that combines both. User-Driven requires the user to complete setup with their credentials, while Self-Deploying provisions entirely without user interaction, ideal for kiosks or shared devices. Pre-Provisioning allows IT to pre-configure devices to a ready-to-use state before shipping.

Think of it as: User-Driven = User builds IKEA furniture with instructions Self-Deploying = Furniture arrives fully assembled Pre-Provisioning = Store assembles, you just place it

Key Mechanics: - User-Driven: User signs in, device joins Entra ID, applies policies, installs apps - Self-Deploying: No user sign-in required, uses device identity, for kiosks/shared devices - Pre-Provisioning: Technician runs setup to "pre-provision" device, then user completes - Deployment modes affect ESP behavior and available configuration options - Self-Deploying requires TPM 2.0 and Entra ID premium licensing

Examples

Example 1 — [Success] Self-Deploying mode for lobby kiosks A hospital deploys 20 patient check-in kiosks using Self-Deploying mode. Devices power on, contact the Autopilot service, join Entra ID using device identity (not user credentials), install the kiosk app, and lock into single-app mode — all without any user or technician interaction. TPM 2.0 is verified on all devices before deployment.

Example 2 — [Blocked] Self-Deploying mode fails — device lacks TPM 2.0 An IT admin selects Self-Deploying mode for 50 repurposed conference room laptops. During OOBE, every device fails at the "Device attestation" step with an error. Root cause: Self-Deploying mode requires TPM 2.0 for device identity attestation — devices without TPM 2.0 cannot complete this mode. Fix: Use User-Driven mode for those devices, or replace hardware with TPM 2.0-capable devices.

Key Mechanisms

- Core function: Windows Autopilot offers two primary deployment modes: User-Driven (UD) and Self-Deploying (SD), with a third White Glove mode (now called Pre-Provisioning) that combines both. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Self-Deploying mode for lobby kiosks - Decision clue: Industry: Retail

Review Path

Steps:

1. Go to Intune admin center → Devices → Windows → Windows enrollment 2. Select Autopilot deployment profile → Create profile 3. Choose deployment mode: - User-Driven: Select "User-driven" mode - Self-Deploying: Select "Self-deploying" mode 4. Configure additional settings: - Language/locale - Privacy settings - Skip EULA pages if applicable 5. For Pre-Provisioning: Enable "Allow pre-provisioned deployment" in profile 6. Assign profile to device groups 7. Verify TPM status for Self-Deploying devices 8. Test each mode in pilot

Docs: https://learn.microsoft.com/en-us/autopilot/self-deploying https://learn.microsoft.com/en-us/autopilot/user-driven https://learn.microsoft.com/en-us/autopilot/pre-provision

Explanation

Windows Autopilot provides multiple deployment scenarios tailored to different organizational needs: existing device reset, fresh start, and device replacement. Capabilities include automatic device naming, ESP tracking, and integration with Windows Update for Business. Autopilot also supports hybrid Entra join (with on-prem AD) and can be combined with co-management for Configuration Manager workloads.

Think of it as: Autopilot scenarios = Different paths to get to the same destination (managed device) Capabilities = Features that make each path smoother

Key Mechanics: - Existing device reset: Re-deploy devices already in use (keep in Intune) - Fresh start: Remove pre-installed OEM bloatware, reinstall Windows - Device replacement: Transfer device enrollment from old to new - Support for both Entra join and Hybrid Entra join - Device name templates (dynamic variables like %SERIAL%) - ESP ensures apps/policies before user desktop access

Examples

Example 1 — [Success] Autopilot reset redeploys returned device in hours A company receives a returned laptop from a departing employee. Instead of reimaging, IT triggers Autopilot Reset from Intune (Devices → [Device] → Autopilot Reset). The device wipes itself, reinstalls Windows, and provisions as a fresh Autopilot deployment — ready for a new employee within 2 hours without physical IT access.

Example 2 — [Blocked] Fresh Start removes all corporate apps including IME An IT admin runs Fresh Start on an employee's cluttered laptop to remove bloatware. After Fresh Start completes, none of the Intune-deployed Win32 apps reinstall. Root cause: Fresh Start removes all installed applications including the Intune Management Extension (IME). Without IME, Win32 app deployments cannot run. IME must re-download and reinstall from Intune before Win32 apps can deploy — this requires waiting for device check-in and the IME reinstall process.

Key Mechanisms

- Core function: Windows Autopilot provides multiple deployment scenarios tailored to different organizational needs: existing device reset, fresh start, and device replacement. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Autopilot reset redeploys returned device in hours - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. For existing device reset: From Intune → Devices → Select device → Autopilot Reset 2. For Fresh Start: Intune → Devices → Windows → Select device → Fresh Start 3. For Replace scenario: - Retire old device in Intune - Add new device to Autopilot - User signs in, provisions automatically 4. Configure naming template: Intune → Autopilot profiles → Device name template 5. Set Hybrid join: Enable in Autopilot profile + configure Entra Connect 6. Test ESP with required app assignments

Docs: https://learn.microsoft.com/en-us/autopilot/existing-devices https://learn.microsoft.com/en-us/autopilot/autopilot-fresh-start https://learn.microsoft.com/en-us/autopilot/replacement

Explanation

Device name templates in Autopilot automate computer naming conventions during deployment, ensuring consistent naming across the organization. Templates support variables like %SERIAL% (device serial), %RAND:x% (random alphanumeric), and %DSREG% (Entra device ID prefix). Names are limited to 15 characters and applied during Autopilot provisioning before policies are assigned.

Think of it as: A naming convention robot that names every computer before it wakes up

Key Mechanics: - Templates defined in Autopilot deployment profiles - Maximum 15 characters total (truncated if longer) - Variables available: %SERIAL%, %RAND:x%, %DSREG%, %USERNAME% - Names must be unique in the organization - Applied during device setup, visible in Intune/Entra ID - Cannot be changed after provisioning without re-enrollment

Examples

Example 1 — [Success] Serial-based naming applied at Autopilot enrollment A hospital configures the name template "HOSP-%SERIAL%" in the Autopilot deployment profile. When 200 new laptops are enrolled, each device receives a name like "HOSP-ABC1234" based on its serial number. The naming convention immediately identifies hardware by asset tag in both Entra ID and Intune without any manual steps.

Example 2 — [Blocked] Template changed — existing devices keep old names An admin realizes the name template "CORP-%RAND:5%" produces unclear names and changes it to "CORP-%SERIAL%" in the Autopilot profile. Existing enrolled devices keep their old random names — only newly enrolled devices receive the serial-based names. Root cause: The device name template applies only at enrollment time during OOBE — changing the template does NOT rename existing devices. To rename existing devices, they must be reset and re-enrolled through Autopilot.

Key Mechanisms

- Core function: Device name templates in Autopilot automate computer naming conventions during deployment, ensuring consistent naming across the organization. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Serial-based naming applied at Autopilot enrollment - Decision clue: Industry: Healthcare System

Review Path

Steps:

1. Navigate to Intune admin center → Devices → Windows → Windows enrollment 2. Select Autopilot deployment profiles → Choose profile or Create new 3. Under "Device name template", enable the setting 4. Enter template using available variables: - %SERIAL% for device serial number - %RAND:x% (x = number of characters, 1-14) - %DSREG% for Entra device ID prefix - %USERNAME% for user principal name prefix 5. Preview example name shown in portal 6. Verify total length ≤ 15 characters 7. Assign profile and test with pilot device

Docs: https://learn.microsoft.com/en-us/autopilot/autopilot-profile-settings#device-name-template https://learn.microsoft.com/en-us/mem/intune/configuration/device-profiles https://learn.microsoft.com/en-us/entra/identity/devices/device-management-naming-policy

Explanation

Autopilot profiles are configuration blueprints that define how Windows devices are deployed during OOBE. Profiles control deployment mode (user-driven/self-deploying), privacy settings, local admin rights, and which screens users see during setup. Multiple profiles can be created and assigned to different device groups based on department, location, or device type.

Think of it as: A GPS route for device setup—different paths for different vehicles

Key Mechanics: - Profiles assigned to Autopilot device groups, not users - Settings include: deployment mode, join type (Entra/Hybrid), language, privacy - "Convert all targeted devices to Autopilot" option for bulk conversion - Profile priority: most specific assignment wins - Can skip Cortana, OEM registration, and EULA screens - ESP settings linked to profile for app tracking

Examples

Example 1 — [Success] Multiple profiles match device types A company creates three Autopilot profiles: "Executive" (user-driven, skip all screens, local admin), "Standard" (user-driven, show privacy screens, standard user), and "Kiosk" (self-deploying, no user interaction). Each profile is assigned to a dedicated dynamic device group based on the GroupTag in the hardware hash CSV. Devices automatically receive the correct setup experience.

Example 2 — [Blocked] Profile assigned but device shows no profile at OOBE A new batch of laptops was purchased and registered in Autopilot, and a deployment profile was assigned to the "New Devices" group. But when devices are powered on, they go through standard OOBE without the Autopilot profile. Root cause: The devices were placed in the group AFTER the profile assignment — but the devices haven't been reset/gone through OOBE yet. An Autopilot profile assigned to a group applies on the NEXT OOBE. Devices already at desktop require an Autopilot Reset to pick up the profile on their next provisioning cycle.

Key Mechanisms

- Core function: Autopilot profiles are configuration blueprints that define how Windows devices are deployed during OOBE. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Multiple profiles match device types - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Go to Intune admin center → Devices → Windows → Windows enrollment 2. Select "Autopilot deployment profiles" → Create profile 3. Configure basics: Name, description, convert all targeted devices 4. Set deployment mode and join type 5. Configure OOBE settings: - Privacy settings (show/hide) - User role (standard/admin) - Terms of use (show/hide) - Language/locale settings 6. Enable and configure ESP settings 7. Assign profile to device groups 8. Monitor profile application in Intune

Docs: https://learn.microsoft.com/en-us/autopilot/profiles https://learn.microsoft.com/en-us/autopilot/autopilot-profile-settings https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-assign

Explanation

Implementing Windows Autopilot deployment means assembling all the prerequisite components — device registration, profile creation, group assignment, Enrollment Status Page (ESP) configuration, and required app targeting — into a coherent end-to-end workflow that transforms a factory-fresh Windows device into a fully managed, policy-compliant corporate endpoint without any IT technician involvement. The implementation sequence matters: devices must be registered before profiles can apply; profiles must be assigned to groups containing those devices; ESP must be configured to block desktop access until required apps install; and required apps must be marked as required (not available) so Intune pushes them during provisioning. A failed Autopilot implementation typically traces back to one of these steps being skipped or misconfigured. MD-102 tests your ability to design this end-to-end pipeline and diagnose where it breaks.

Examples

Example 1 — [Success] 300-device zero-touch office rollout An IT admin prepares for a new office opening: hardware hashes are imported from the OEM vendor portal, a "New Office" Entra ID group is created, the deployment profile is assigned to it, and ESP is configured to block the desktop until VPN and antivirus install. All 300 devices arrive at the office and self-configure when employees plug in and sign in — no IT travel required.

Example 2 — [Blocked] ESP timeout causes Autopilot failure before apps install After enabling ESP with a 60-minute timeout, devices fail during provisioning. Users see "Something went wrong" before the desktop appears. Root cause: A large required app (3 GB) is timing out during the ESP app installation phase. The default timeout is too short. Fix: Increase ESP timeout to 120+ minutes, optimize app size, or remove the oversized app from the ESP blocking list and deploy it post-enrollment instead.

Key Mechanisms

- Core function: Implementing Windows Autopilot deployment means assembling all the prerequisite components — device registration, profile creation, group assignment, Enrollment Status Page (ESP) configuration, and required app targeting — into a coherent end-to-end workflow that transforms a factory-fresh Windows device into a fully managed, policy-compliant corporate endpoint without any IT technician involvement. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] 300-device zero-touch office rollout - Decision clue: A fast-growing SaaS startup needs to onboard 50 new engineers every month with zero IT overhead.

Review Path

Implement end-to-end Autopilot deployment:

1. Register devices: Intune admin center → Devices → Windows enrollment → Devices → Import CSV with hardware hashes (or have OEM/reseller register via Partner Center using tenant ID) 2. Create Entra ID device group with dynamic membership rule targeting GroupTag or OrderID from the CSV 3. Create Autopilot deployment profile (Devices → Deployment profiles → Create) with correct mode + OOBE settings 4. Assign the profile to the device group from step 2 5. Configure Enrollment Status Page: Devices → Windows enrollment → Enrollment Status Page → Create - Enable: Show app and profile configuration progress → Yes - Block device use until all apps and profiles are installed → Yes - Add required apps to "Block access until these apps are installed" 6. Assign ESP profile to same device group 7. Assign required apps to the device group as Required 8. Ship device to user — they plug in, sign in, wait for ESP to complete 9. Verify: Intune admin center → Devices → Monitor → Autopilot deployments → check each device

Learn more: https://learn.microsoft.com/en-us/autopilot/tutorial/autopilot-scenarios

Explanation

Adding devices to Windows Autopilot requires registering their hardware hashes (unique device identifiers) into Intune. Devices can be added manually via CSV upload, automatically from OEM partners (Microsoft Partner Center), or using a script to extract hashes from existing devices. Once registered, devices are assigned deployment profiles and appear in the Autopilot devices list.

Think of it as: Adding license plates to your fleet management system before cars are delivered

Key Mechanics: - Hardware hash = 4KB file containing device unique identifiers - CSV upload requires: Device Serial Number, Windows Product ID, Hardware Hash - OEM integration: Dell, HP, Lenovo can register during manufacturing - PowerShell script (Get-WindowsAutoPilotInfo) collects hashes from existing devices - Devices in "Not assigned" state until profile assigned - Duplicate detection prevents multiple registrations

Examples

Example 1 — [Success] OEM auto-registers devices before delivery A company places a Dell order and provides their Microsoft Partner Center tenant ID. Dell registers the hardware hashes directly into the company's Intune tenant before shipping. When laptops arrive, they are already in the Autopilot device list, assigned to the correct profile — ready to provision with zero IT action.

Example 2 — [Blocked] Hardware hash CSV format incorrect — import fails An IT admin exports hardware hashes from existing devices using Get-WindowsAutoPilotInfo.ps1 but the CSV includes extra columns. The Intune import fails with a format error. Root cause: The Autopilot CSV must contain exactly three columns: "Device Serial Number," "Windows Product ID," and "Hardware Hash." Extra columns or wrong headers cause import failure. Fix: Review the CSV structure and remove extra columns before re-importing.

Key Mechanisms

- Core function: Adding devices to Windows Autopilot requires registering their hardware hashes (unique device identifiers) into Intune. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] OEM auto-registers devices before delivery - Decision clue: Industry: Technology

Review Path

Steps:

1. Collect hardware hashes: - On existing Windows device, run PowerShell as admin - Install script: Install-Script Get-WindowsAutoPilotInfo - Run: Get-WindowsAutoPilotInfo.ps1 -OutputFile C:Devices.csv 2. For OEM registration: Provide Microsoft Partner Center ID to hardware vendor 3. Upload CSV: - Go to Intune → Devices → Windows → Windows enrollment → Devices - Click "Import" and select CSV file 4. Verify upload success in device list 5. Assign Autopilot profile to devices 6. For bulk uploads, use "Convert all targeted devices to Autopilot" in profile

Docs: https://learn.microsoft.com/en-us/autopilot/add-devices https://learn.microsoft.com/en-us/autopilot/registration-overview https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo

Explanation

Autopilot troubleshooting involves diagnosing failures during the provisioning process, from OOBE network connectivity to ESP timeouts and policy application. Common issues include TPM attestation failures (for self-deploying), network proxy blocks, incorrect profile assignment, and Azure AD join delays. The Autopilot diagnostics log (MDM Diagnostics) and TPM diagnostics tools are primary investigation methods.

Think of it as: Flight data recorder for device deployment—finding where the takeoff failed

Key Mechanics: - TPM required for self-deploying; check TPM version and health - Network: Autopilot requires internet access to *.msa.akadns.net, *.azurewebsites.net - ESP timeout occurs if apps exceed 60-minute default - Profile assignment: Device must be in Intune with profile assigned before OOBE - Hybrid join: Check Entra Connect sync and OU permissions - Diagnostics: Collect MDM diagnostic log from failed device

Examples

Example 1 — [Success] ESP timeout increased to resolve deployment failures A company's Autopilot deployments are timing out at the ESP app installation phase. The IT team identifies a 2 GB app package as the culprit and increases the ESP timeout from 60 to 120 minutes for the affected device group. Subsequent deployments complete successfully.

Example 2 — [Blocked] Hybrid Entra join Autopilot fails — Entra Connect not synced An organization deploys hybrid join Autopilot profiles. Devices fail at the "Join domain" phase with error 0x801c001d. Root cause: Hybrid Entra join requires the device to contact a domain controller during OOBE AND requires the Entra Connect Hybrid Join configuration to be set up. The admin had configured the Autopilot profile for Hybrid join but never configured the Entra Connect sync with hybrid join enabled. Fix: Set up Hybrid Entra join in Entra Connect and ensure DCs are reachable during OOBE.

Key Mechanisms

- Core function: Autopilot troubleshooting involves diagnosing failures during the provisioning process, from OOBE network connectivity to ESP timeouts and policy application. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] ESP timeout increased to resolve deployment failures - Decision clue: Industry: Enterprise

Review Path

Steps:

1. Identify failure phase (OOBE vs ESP vs Post-provisioning) 2. For TPM issues: - Run tpm.msc to verify TPM presence and version (2.0 required) - Clear TPM if corrupted (caution: test first) 3. For network issues: - Verify device can reach: login.live.com, aadcdn.msauth.net, manage.microsoft.com - Check proxy authentication requirements 4. For ESP timeouts: - Increase timeout in ESP profile (max 120 minutes) - Break large apps into required vs available 5. Collect diagnostics: - On device: Settings → Accounts → Access work or school → Export logs - Or: C:ProgramDataMicrosoftDiagnosticLogsAutoPilot 6. Review logs in CMTrace or Notepad 7. Check profile assignment in Intune portal

Docs: https://learn.microsoft.com/en-us/autopilot/troubleshooting https://learn.microsoft.com/en-us/autopilot/esp-troubleshooting https://learn.microsoft.com/en-us/mem/intune/configuration/troubleshoot-policies-in-microsoft-intune

Explanation

The Enrollment Status Page (ESP) is an Intune configuration object that controls what happens between a user signing in during OOBE and when they are allowed to reach the Windows desktop. An ESP profile defines which apps and policies must be installed before the desktop is accessible, the timeout duration, error behavior (allow retry, reset, or block), and whether a custom error message is shown. There are two ESP phases: Device Setup (runs before user sign-in, installs device-targeted apps and policies) and Account Setup (runs after user sign-in, installs user-targeted apps and policies). Organizations create custom ESP profiles targeting specific device groups to enforce security requirements — for example, blocking desktop access until endpoint protection, VPN, and compliance policies are fully applied. MD-102 tests ESP configuration including which apps can be tracked and timeout settings.

Examples

Example 1 — [Success] ESP blocks desktop until Defender fully onboards A security team creates an ESP profile that requires Microsoft Defender for Endpoint to install and report health before the desktop unlocks. During Autopilot, users see the progress screen with "Installing: Microsoft Defender for Endpoint." The desktop only appears after Defender is running — zero devices reach users without active threat protection.

Example 2 — [Blocked] ESP timeout too low — Autopilot fails before apps install An IT admin sets ESP timeout to the default 60 minutes for a remote device group on slow home internet. Large app packages (VPN client + AV + M365 Apps) regularly exceed the 60-minute window. Devices show "Something went wrong" and users cannot proceed. Root cause: The timeout fired before all required apps finished installing. Fix: Increase ESP timeout to 120+ minutes for slow-internet groups, and consider removing non-critical apps from the ESP blocking list.

Key Mechanisms

- Core function: The Enrollment Status Page (ESP) is an Intune configuration object that controls what happens between a user signing in during OOBE and when they are allowed to reach the Windows desktop. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] ESP blocks desktop until Defender fully onboards - Decision clue: A financial services firm has a compliance requirement that all endpoints must have full-disk encryption active and endpoint detection running before any user accesses the desktop.

Review Path

Create and configure an Enrollment Status Page profile:

1. Intune admin center → Devices → Windows enrollment → Enrollment Status Page 2. Click Create profile → name it (e.g., "Corporate ESP - Block Until Secure") 3. Settings tab: - Show app and profile configuration progress: Yes - Show error when installation takes longer than specified minutes: Yes → set 60–120 min - Show custom message when time limit or error occurs: Yes → add helpdesk contact - Turn on log collection and diagnostics page for end users: Yes (helps with troubleshooting) - Only fail selected blocking apps in technician phase: Yes → add specific critical apps - Block device use until these required apps are installed: Add → select apps (Win32 or LOB) - Allow users to reset device if installation error occurs: Yes/No per policy 4. Assignments tab: assign to Entra ID device group (same group as Autopilot profile) 5. Review + Create 6. Test with a factory-reset or new Autopilot device — observe both ESP phases

Learn more: https://learn.microsoft.com/en-us/autopilot/enrollment-status-page

Explanation

The Enrollment Status Page (ESP) displays provisioning progress during Autopilot deployment, showing users exactly what's happening (device prep, account setup, app installation) and preventing desktop access until defined requirements are met. ESP can be configured with custom messages, timeouts, and block options to ensure devices are fully compliant before user productivity begins.

Think of it as: A "please wait while your device is prepared" screen with transparency and accountability

Key Mechanics: - Three phases: Device preparation, Device setup, Account setup - Can block device use until all required apps/policies install - Timeout settings: Installation timeout (default 60 min) and error timeout - Show app installation progress to users - Track specific apps (Win32, LOB, MS Store) as "required" - ESP profile linked to Autopilot deployment profile

Examples

Example 1 — [Success] Bank compliance ESP blocks until all security apps install A bank configures an ESP profile with "Block device use until all apps installed" and adds Defender for Endpoint, BitLocker policy, and VPN client to the required app list. New employees cannot reach the desktop until all three are fully deployed — confirmed compliant before any productivity begins.

Example 2 — [Blocked] ESP timeout fires at 60 minutes — VPN client not installed Remote users' Autopilot deployments consistently fail at 60 minutes. The VPN client package (1.5 GB) doesn't finish downloading over home internet in time. Root cause: The default 60-minute ESP timeout is too short for large apps over slow connections. Fix: Increase ESP timeout to 90–120 minutes for the remote deployment group, or distribute the VPN client as "Available" (post-enrollment) instead of a required blocking app.

Key Mechanisms

- Core function: The Enrollment Status Page (ESP) displays provisioning progress during Autopilot deployment, showing users exactly what's happening (device prep, account setup, app installation) and preventing desktop access until defined requirements are met. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Bank compliance ESP blocks until all security apps install - Decision clue: Industry: Government Agency

Review Path

Steps:

1. Go to Intune admin center → Devices → Windows → Windows enrollment 2. Under "Enrollment Status Page", click "Create profile" 3. Configure basics: Name, description 4. Set settings: - Show app and profile installation progress - Block device use until all apps/profiles installed (or time selected) - Allow users to reset device if installation error 5. Configure timeout settings: - Installation timeout (minutes) - Error timeout (minutes) 6. Select which apps to track (must be assigned as required) 7. Assign ESP profile to device groups 8. Link to Autopilot profile or assign separately

Docs: https://learn.microsoft.com/en-us/autopilot/enrollment-status https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status https://learn.microsoft.com/en-us/autopilot/esp-troubleshooting

Explanation

Provisioning packages (.ppkg files) are self-contained configuration packages created with Windows Configuration Designer that can apply settings, install apps, and join devices to Entra ID or Active Directory without network connectivity during initial setup. Planning requires identifying which settings must be applied offline vs. those better handled by Intune post-enrollment.

Think of it as: A USB-based setup wizard that works anywhere, even in a basement with no internet

Key Mechanics: - Packages work during OOBE or on already-configured Windows devices - Can include: certificates, Wi-Fi profiles, VPN, bulk tokens for Entra join - Package signing ensures integrity and prevents tampering - Packages can be applied via USB, email, NFC, or network share - Settings priority: Intune > Provisioning Package > Local settings - Maximum package size: 250MB for runtime processing

Examples

Example 1 — [Success] Offline deployment with USB provisioning package A construction company deploys laptops at remote sites with no internet. IT creates a provisioning package in Windows Configuration Designer containing Wi-Fi credentials, bulk Entra join token, and a certificate. Technicians insert the USB during OOBE — the device configures itself in 2 minutes and enrolls in Intune when connectivity is restored.

Example 2 — [Blocked] Provisioning package rejected — unsigned package on locked device A technician creates a provisioning package but forgets to sign it. On the target device (which has a policy requiring signed packages), the device rejects the PPKG during OOBE with an error. Root cause: When the organization enforces signed provisioning packages, unsigned PPKGs are blocked. Fix: Re-create the package in Windows Configuration Designer and sign it with the organization's code-signing certificate before export.

Key Mechanisms

- Core function: Provisioning packages (.ppkg files) are self-contained configuration packages created with Windows Configuration Designer that can apply settings, install apps, and join devices to Entra ID or Active Directory without network connectivity during initial setup. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Offline deployment with USB provisioning package - Decision clue: Industry: Non-profit

Review Path

Steps:

1. Install Windows Configuration Designer from Microsoft Store 2. Choose scenario: "Provision desktop devices" or "Advanced provisioning" 3. Configure settings: - Device name pattern - Network credentials - Entra join (using bulk token) - Certificates - Applications (limited to MSI-based) 4. Export package as .ppkg (signed or unsigned) 5. Test package on reference device 6. Distribute via chosen method 7. Apply during OOBE by inserting USB when prompted

Docs: https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-packages https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-create-package https://learn.microsoft.com/en-us/mem/intune/configuration/provisioning-packages

Explanation

A provisioning package is a configuration bundle created using Windows Configuration Designer to quickly configure Windows devices. It can apply Wi-Fi settings, enroll devices into Intune, join Microsoft Entra ID, and install certificates. Unlike imaging, it modifies existing installations without reinstalling Windows. MD-102 requires understanding when provisioning is faster than reimaging or Autopilot, especially in bulk staging scenarios.

Examples

Example 1 — [Success] Bulk staging with provisioning package An IT team stages 200 devices in a warehouse using a USB provisioning package. The PPKG configures corporate Wi-Fi, locale, and applies a bulk Intune enrollment token. Each device is staged in under 2 minutes — no technician account or internet required. Devices auto-enroll in Intune when connected to the network.

Example 2 — [Blocked] Provisioning package cannot install EXE apps An admin builds a provisioning package intending to include a custom EXE installer. The package is created successfully but the EXE application silently fails to install on target devices. Root cause: Provisioning packages only support MSI-format applications — EXE installers are not supported in PPKG. Fix: Convert the application to MSI format, or deploy it post-enrollment via Intune as a Win32 app.

Key Mechanisms

- Core function: A provisioning package is a configuration bundle created using Windows Configuration Designer to quickly configure Windows devices. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Bulk staging with provisioning package - Decision clue: A logistics company receives 150 barcode-scanner tablets that need identical configurations before deployment to warehouse staff.

Review Path

Use provisioning package:

1. Install Windows Configuration Designer 2. Create new project 3. Configure settings 4. Export .ppkg file 5. Apply to device 6. Confirm configuration

Learn more: https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-packages-overview

Explanation

The Windows Configuration Designer desktop wizard simplifies creating provisioning packages through a step-by-step interface. It guides administrators through common scenarios: device enrollment, certificate installation, Wi-Fi configuration, and bulk Entra ID token generation for offline join. The wizard outputs a .ppkg file ready for distribution.

Think of it as: A recipe book where you check ingredients you want, and it generates the complete meal package

Key Mechanics: - Wizard steps: Device setup, Settings, Applications, Accounts - Bulk Entra token: Generated in wizard, valid for 30-180 days - Can configure multiple Wi-Fi profiles with priorities - Package must be signed if applied to locked-down devices - Runtime settings allow post-setup configuration - Preview feature shows estimated package size

Examples

Example 1 — [Success] Conference kiosk deployment via PPKG wizard A company creates a provisioning package for 50 conference registration kiosks. Using the Windows Configuration Designer wizard, they set the device name pattern, event Wi-Fi credentials, and include a bulk Entra join token. Technicians insert USB drives during OOBE at the venue — all 50 kiosks are configured in 90 minutes.

Example 2 — [Blocked] Bulk Entra token expired during event deployment A technician arrives at a venue to deploy devices using a provisioning package created 35 days ago. The bulk Entra join token inside the package was set to a 30-day validity and has expired. Devices fail to join Entra ID during OOBE. Root cause: Bulk tokens have a configurable validity (maximum 180 days) — once expired, the PPKG cannot perform Entra ID join. Fix: Regenerate the package with a new bulk token before deployment.

Key Mechanisms

- Core function: The Windows Configuration Designer desktop wizard simplifies creating provisioning packages through a step-by-step interface. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Conference kiosk deployment via PPKG wizard - Decision clue: Industry: Event Management

Review Path

Steps:

1. Launch Windows Configuration Designer (install from Microsoft Store) 2. Select "Provision desktop devices" (simple wizard) 3. Device setup: - Enter device name pattern - Configure product key if needed - Set time zone 4. Settings: - Add Wi-Fi profiles (SSID, security type, password) - Import certificates (.cer or .pfx) - Configure privacy settings 5. Applications: - Add MSI, APPX, or EXE installers - Set installation order 6. Accounts: - Generate bulk Entra token (sign in with Entra ID global admin) - Create local admin account if needed 7. Finish: - Choose package security (signing recommended) - Export to USB or local folder - Test on reference device

Docs: https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-create-package https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-command-line https://learn.microsoft.com/en-us/mem/intune/configuration/provisioning-packages

Explanation

Upgrading to Windows 11 requires careful planning around hardware compatibility, application readiness, and user communication. The upgrade can be deployed via Windows Update for Business rings, Intune feature updates, or traditional tools like Configuration Manager. Microsoft provides readiness assessments through Update Compliance and Endpoint Analytics to identify devices that meet Windows 11 minimum requirements.

Think of it as: Renovating your house—check if structure supports new features before starting

Key Mechanics: - Windows 11 minimum requirements: TPM 2.0, Secure Boot, 4GB RAM, 64GB storage - Readiness assessment via Update Compliance or Windows Analytics - Feature updates deployed as policies in Intune (update rings for feature updates) - 10-day rollback period after upgrade - App compatibility testing using Test Base or App Assure - Gradual rollout using deployment rings (Preview, Pilot, Broad, Critical)

Examples

Example 1 — [Success] Phased Windows 11 rollout via deployment rings A company creates three Intune feature update rings: Ring 1 (IT, 5% of devices, no deferral), Ring 2 (early adopters, 30-day deferral), Ring 3 (all remaining, 60-day deferral). IT validates Windows 11 compatibility and app behavior in Ring 1 before each subsequent ring releases. All 500 compatible devices upgraded with zero data loss over 3 months.

Example 2 — [Blocked] Windows 11 upgrade fails on device without TPM 2.0 During a broad Windows 11 rollout, 12% of devices fail the upgrade with error "This device doesn't meet requirements." Root cause: Those devices lack TPM 2.0 or have Secure Boot disabled in BIOS. Intune's Windows 11 readiness report (Reports → Endpoint Analytics) should have been run first to identify incompatible devices. Fix: Enable TPM/Secure Boot in BIOS where supported, or plan hardware replacement for non-upgradeable devices.

Key Mechanisms

- Core function: Upgrading to Windows 11 requires careful planning around hardware compatibility, application readiness, and user communication. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Phased Windows 11 rollout via deployment rings - Decision clue: Industry: Legal Services

Review Path

Steps:

1. Assess readiness: - Go to Intune admin center → Reports → Endpoint analytics - View "Windows 11 readiness" report - Identify devices failing requirements 2. Address incompatible devices: - Plan hardware refresh for TPM 1.2 devices - Enable TPM/Secure Boot in BIOS where disabled 3. Create deployment rings: - Devices → Update rings for Windows 10 and later → Create profile - Set "Feature update deferral" in days (0, 30, 60, 90) 4. For targeted Windows 11 upgrade: - Devices → Windows 10/11 updates → Feature updates - Create policy targeting Windows 11 (22H2, 23H2) - Assign to rings progressively 5. Configure rollback: - Enable "Uninstall" option in update settings - Educate help desk on rollback procedure 6. Monitor via Update Compliance in Azure portal

Docs: https://learn.microsoft.com/en-us/windows/deployment/planning/windows-11-overview https://learn.microsoft.com/en-us/mem/intune/protect/windows-10-feature-updates https://learn.microsoft.com/en-us/windows/deployment/update/deployment-rings

Explanation

Windows upgrade vs. migration decisions impact user data, applications, and IT effort. Upgrade preserves user data, settings, and apps (in-place), while migration (refresh or replace) moves user data to a clean OS installation. Considerations include hardware age, app compatibility, user state management tools, and rollback complexity.

Think of it as: Upgrade = Remodeling your current house Migration = Moving to a new house (with movers)

Key Mechanics: - In-place upgrade: Fastest, preserves everything, requires compatible hardware - Refresh: Clean install, retains user data via USMT or OneDrive, removes bloatware - Replace: New hardware, migrate data from old device - User State Migration Tool (USMT) for on-premises migrations - OneDrive Known Folder Move for cloud-based data preservation - App compatibility: Native vs. virtualization (App-V, MSIX)

Examples

Example 1 — [Success] In-place upgrade preserves all apps and data A law firm upgrades 300 compatible Windows 10 laptops to Windows 11 via in-place upgrade through Intune feature update policies. All apps, files, and user settings are preserved automatically. The upgrade completes in under 2 hours per device. Users arrive the next morning to Windows 11 with everything intact.

Example 2 — [Blocked] In-place upgrade rollback window missed A user upgrades to Windows 11 and reports their legacy time-tracking app no longer works. They wait 12 days before contacting IT. Root cause: In-place upgrades include a 10-day rollback window (accessible via Settings → Recovery → Go back). After 10 days, the previous Windows version files are automatically deleted and rollback is no longer possible. Fix: Ensure users are aware of the 10-day window and that IT is notified immediately of app compatibility issues post-upgrade.

Key Mechanisms

- Core function: Windows upgrade vs. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] In-place upgrade preserves all apps and data - Decision clue: Industry: Education

Review Path

Steps:

1. Assess devices and choose path: - Windows 11 ready & <3 years → In-place upgrade - Windows 11 ready but >3 years → Refresh - Not Windows 11 ready → Replace 2. For in-place: - Deploy via Intune feature updates - Ensure 10GB free space 3. For refresh: - Capture data (USMT or OneDrive) - Deploy Provisioning Package with clean install - Restore data post-install 4. For replace: - Register new devices in Autopilot - Configure OneDrive for data sync - Retire old device in Intune 5. Test each method with pilot group

Docs: https://learn.microsoft.com/en-us/windows/deployment/windows-10-deployment-scenarios https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-overview https://learn.microsoft.com/en-us/onedrive/known-folder-move

Explanation

Windows 365 delivers Cloud PCs—personalized Windows desktops streamed from Azure to any device. Deployment involves provisioning licenses, creating provisioning policies, and assigning users. Cloud PCs run in Microsoft's Azure infrastructure, with user profiles and data persisted between sessions. Organizations choose between Enterprise (full control) and Business (simplified) editions.

Think of it as: A Windows desktop in the cloud that follows you to any device

Key Mechanics: - Provisioning policies define: Azure region, virtual machine size, image type - Gallery images: Windows 10/11 Enterprise pre-built by Microsoft - Custom images: Upload your own generalized VM images - Network: Microsoft-hosted (Business) or your Azure network (Enterprise) - User data persists on Cloud PC OS disk - Access via Remote Desktop client or browser

Examples

Example 1 — [Success] Cloud PCs for contractors on personal Macs A consulting firm provides 50 contractors with Windows 365 Cloud PCs. Contractors access a full Windows 11 desktop from their personal MacBooks via the Remote Desktop app. Corporate data never leaves Azure, and when contracts end, the Windows 365 license is removed — the Cloud PC and all data are deprovisioned automatically.

Example 2 — [Blocked] Cloud PC provisioning fails — Azure Network Connection error An IT admin creates a Windows 365 Enterprise provisioning policy pointing to an Azure Network Connection (ANC). When users try to access their Cloud PCs, provisioning fails with an ANC error. Root cause: The ANC requires correct permissions on the Azure subscription and VNet — the service principal for Windows 365 must have "Network Contributor" role on the VNet. Fix: Verify ANC health in Intune → Devices → Windows 365 → Azure network connections → [connection name] → Check.

Key Mechanisms

- Core function: Windows 365 delivers Cloud PCs—personalized Windows desktops streamed from Azure to any device. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Cloud PCs for contractors on personal Macs - Decision clue: Industry: Consulting

Review Path

Steps:

1. Purchase Windows 365 licenses in Microsoft 365 admin center 2. For Windows 365 Enterprise: - Create Azure Network Connection (ANC) in Intune - Point to Azure subscription, region, VNet 3. Create provisioning policy: - Intune → Devices → Windows 365 → Provisioning policies - Choose: Enterprise or Business - Select image (gallery or custom) - Choose VM size (based on user needs) - Assign to Entra ID group 4. Assign licenses to users 5. Users access via https://windows365.microsoft.com or Remote Desktop app 6. Monitor Cloud PCs in Intune → Devices → Windows 365

Docs: https://learn.microsoft.com/en-us/windows-365/overview https://learn.microsoft.com/en-us/windows-365/enterprise/provisioning https://learn.microsoft.com/en-us/windows-365/enterprise/deployment-planning

Explanation

Windows 365 is a cloud service that provides each licensed user with a persistent, personal Windows 11 desktop hosted in Microsoft's Azure infrastructure — a "Cloud PC" — that streams to any device via a web browser or client app. Unlike Azure Virtual Desktop (AVD), which requires complex infrastructure setup (host pools, session hosts, FSLogix), Windows 365 is a managed service with no Azure subscription required for the basic Microsoft-hosted network option, provisioning is handled automatically through a simple provisioning policy in Intune, and each user gets dedicated (not shared) resources. The two licensing tiers are Windows 365 Business (for SMBs, simplified admin, no Intune required) and Windows 365 Enterprise (full Intune management, provisioning policies, compliance, custom images, Azure Network Connection for on-premises access). For MD-102, focus on the Enterprise tier: how Cloud PCs appear in Intune as managed devices, the difference from AVD, and why Cloud PCs are a modern desktop deployment option for flexible and remote workforces.

Examples

Example 1 — [Success] Developer uses Cloud PC across multiple devices A developer uses a Windows 365 Enterprise 4vCPU/16GB Cloud PC as their primary workstation. They switch from their home laptop to an office desktop to a company iPad across the day — the Cloud PC state is persistent, open tabs and running processes are always available. Corporate code and data never touch any personal device.

Example 2 — [Blocked] Business-tier Cloud PC cannot connect to Azure VNet A company purchases Windows 365 Business licenses for developers who need access to Azure-hosted development resources via a corporate VNet. The developers cannot reach the Azure VNet from their Cloud PCs. Root cause: Windows 365 Business uses Microsoft-hosted networking only — Azure Network Connection (ANC) to a custom VNet requires Windows 365 Enterprise. Fix: Upgrade to Enterprise licenses and configure an ANC in Intune.

Key Mechanisms

- Core function: Windows 365 is a cloud service that provides each licensed user with a persistent, personal Windows 11 desktop hosted in Microsoft's Azure infrastructure — a "Cloud PC" — that streams to any device via a web browser or client app. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Developer uses Cloud PC across multiple devices - Decision clue: A global consulting firm employs 300 consultants who work on-site at client locations using client-provided hardware that may be locked down, outdated, or on restrictive networks.

Review Path

Get started with Windows 365 Enterprise:

1. Licensing: Microsoft 365 admin center → Billing → Licenses → ensure Windows 365 Enterprise licenses are purchased 2. Review Intune requirements: Windows 365 Enterprise requires Microsoft Intune and Entra ID P1 (included in M365 E3+) 3. Access Windows 365 admin experience: Intune admin center → Windows 365 (left navigation) 4. Review: All Cloud PCs, Provisioning policies, Azure network connections, User settings 5. Assign license to a test user: M365 admin center → Users → select user → Licenses → assign Windows 365 Enterprise SKU 6. Create provisioning policy → assign to test user's group → wait 30–90 min for Cloud PC to provision 7. Test access: sign in as the licensed user at windows365.microsoft.com 8. Manage Cloud PC in Intune: Devices → All devices → filter Type = Cloud PC → apply policies

Learn more: https://learn.microsoft.com/en-us/windows-365/enterprise/overview

Explanation

Windows 365 offers two primary deployment options: Windows 365 Business (simplified, no Azure infrastructure required) and Windows 365 Enterprise (full control with Azure network integration). Frontline provides temporary Cloud PCs for shift workers. Each option targets different organizational needs, compliance requirements, and IT control preferences.

Think of it as: Business = Cloud PC apartment (everything included, limited customization) Enterprise = Cloud PC house (you build the foundation, full control)

Key Mechanics: - Business: Microsoft-hosted network, automatic updates, simple provisioning - Enterprise: Your Azure VNet, custom images, advanced networking, full Intune integration - Frontline: Shared license pool, auto-provision on sign-in, deprovision on sign-out - Government: GCC and GCC High for public sector compliance - VM sizes range from 1 vCPU/2GB to 8 vCPU/32GB - Storage: 128GB to 512GB OS disk options

Examples

Example 1 — [Success] Role-matched Windows 365 deployment A bank uses Windows 365 Business for 20 tellers (simple web banking apps, Microsoft-hosted), Enterprise for 50 financial advisors (custom compliance image + Azure VNet access to on-premises data), and Frontline for 100 call center shift workers (20 licenses shared across 100 users — provisions on login, deprovisions on logout).

Example 2 — [Blocked] Frontline users share Cloud PC data — data not preserved A call center manager expects each shift worker's Frontline Cloud PC to retain their work between shifts. After a shift ends, the next worker logs in and finds no prior data. Root cause: Windows 365 Frontline deprovisions the Cloud PC when a user signs out — user data is NOT persisted between sessions by default. For persistent data, Frontline users need OneDrive or a shared storage path configured; the Cloud PC itself resets on each session.

Key Mechanisms

- Core function: Windows 365 offers two primary deployment options: Windows 365 Business (simplified, no Azure infrastructure required) and Windows 365 Enterprise (full control with Azure network integration). - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Role-matched Windows 365 deployment - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Assess requirements: - Need Azure network access? → Enterprise - Simple deployment, no Azure? → Business - Shift workers? → Frontline 2. For Business: - Microsoft 365 admin center → Billing → Purchase services - Assign licenses to users - Users activate at windows365.microsoft.com 3. For Enterprise: - Set up Azure subscription and VNet - Create Azure Network Connection in Intune - Upload custom images (if needed) - Create provisioning policies with specific VM sizes 4. For Frontline: - Purchase Frontline licenses (e.g., 20 for 100 users) - Configure in Intune with auto-provisioning - Assign to shift worker groups

Docs: https://learn.microsoft.com/en-us/windows-365/business/ https://learn.microsoft.com/en-us/windows-365/enterprise/ https://learn.microsoft.com/en-us/windows-365/frontline/

Explanation

Device configuration profiles in Intune define settings and features for Windows devices, from simple wallpaper preferences to complex security configurations. Profiles can configure administrative templates (ADMX-backed settings), device restrictions, PowerShell scripts, and custom OMA-URI settings. Profiles are assigned to Entra ID groups and can be filtered by device attributes.

Think of it as: A recipe card for how each Windows device should look and behave

Key Mechanics: - Profile types: Settings catalog, Templates, Administrative templates - Settings catalog centralizes thousands of Windows policy settings - ADMX templates import on-premises Group Policy settings - OMA-URI for custom configurations not in UI - Profile priority: Multiple profiles merge, conflicts resolved by most restrictive - Filters target profiles based on device properties (OS version, manufacturer)

Examples

Example 1 — [Success] Role-specific configuration profiles A company creates separate Windows configuration profiles: Sales devices receive a company wallpaper and Teams performance settings; Engineering laptops receive developer mode enabled and PowerShell execution permissions; Kiosk devices receive single-app assigned access. Each profile is scoped to the appropriate device group via dynamic group rules.

Example 2 — [Blocked] OMA-URI setting has no effect — format wrong An admin creates a custom OMA-URI configuration profile to set a registry key for a legacy app. The profile deploys successfully (no errors in Intune) but the setting has no effect on devices. Root cause: The OMA-URI path or data type is incorrect — Intune accepts the profile but the Windows CSP ignores malformed values. Fix: Validate the correct OMA-URI path in the Windows MDM CSP documentation before deploying.

Key Mechanisms

- Core function: Device configuration profiles in Intune define settings and features for Windows devices, from simple wallpaper preferences to complex security configurations. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Role-specific configuration profiles - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Go to Intune admin center → Devices → Configuration profiles 2. Select "Create profile" → Platform: Windows 10 and later 3. Choose profile type: - Settings catalog (most common) - Templates (Administrative templates) - Custom (OMA-URI) 4. Configure settings: - For Settings catalog: Add settings by category (Security, Update, etc.) - For Administrative templates: Browse ADMX-like structure 5. Set assignment: - Target Entra ID groups - Add filters (OS edition, manufacturer, etc.) 6. Review and create 7. Monitor deployment in profile overview

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/device-profiles https://learn.microsoft.com/en-us/mem/intune/configuration/settings-catalog https://learn.microsoft.com/en-us/mem/intune/configuration/administrative-templates-windows

Explanation

Policy sets in Intune bundle related management objects—apps, policies, and configurations—into a single deployable package. Instead of assigning multiple individual items to a group, you create a policy set containing everything a specific device or user type needs. This simplifies management and ensures consistent application of related configurations.

Think of it as: A deployment bundle or care package for specific user types

Key Mechanics: - Policy sets can include: apps, configuration profiles, compliance policies, scripts - Objects maintain their individual settings but deploy as a group - Updates to individual objects automatically apply to policy set - Assignment is to groups, just like individual policies - Policy set status shows overall deployment health - Useful for scenarios like "New hire setup" or "Kiosk configuration"

Examples

Example 1 — [Success] New hire onboarding policy set A company creates an "Engineer Onboarding" policy set containing: VS Code (required app), Git for Windows (required app), security baseline profile, and a VPN configuration profile. When a new engineer is added to the "Engineering" group, all four objects deploy simultaneously from a single policy set without the admin touching each item individually.

Example 2 — [Blocked] Policy set object removed but still deployed An admin removes a deprecated app from a policy set, expecting it to be uninstalled from devices. The app remains installed. Root cause: Removing an object from a policy set does not uninstall already-deployed items — the app must be explicitly assigned as "Uninstall" or removed individually from its own assignment to remove it from devices. Policy sets control deployment, not removal.

Key Mechanisms

- Core function: Policy sets in Intune bundle related management objects—apps, policies, and configurations—into a single deployable package. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] New hire onboarding policy set - Decision clue: Industry: Retail

Review Path

Steps:

1. Go to Intune admin center → Devices → Policy sets 2. Select "Create policy set" 3. Enter name and description (e.g., "Executive Device Bundle") 4. Add resources: - Apps: Select from deployed apps - Configuration profiles: Choose relevant profiles - Compliance policies: Add security requirements - Scripts: Add PowerShell scripts - (Continue adding all relevant objects) 5. Assign to groups: - Select "Next: Assignments" - Add Entra ID groups (e.g., "Executive Users") 6. Review and create 7. Monitor deployment status in policy set overview

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/policy-sets https://learn.microsoft.com/en-us/mem/intune/configuration/policy-sets-create https://learn.microsoft.com/en-us/mem/intune/configuration/policy-sets-monitor

Explanation

When multiple policies assign different values for the same setting, Intune uses conflict resolution rules to determine which value applies. For most settings, the most restrictive or secure value wins. For configuration profiles, the last modified profile takes precedence for non-conflicting settings, but conflicts are resolved based on setting type (restrictions, compliance, etc.) and assignment priority.

Think of it as: Multiple chefs adding ingredients—the strictest dietary restriction wins

Key Mechanics: - Compliance policies: Most restrictive applies (if one requires BitLocker and another doesn't, BitLocker required wins) - Configuration profiles: For same setting, profile with most specific assignment wins - Resource access (WiFi/VPN): Profiles merge unless conflicting - Settings catalog: Conflicts show in reporting, last write wins - Filters can prevent conflicts by narrowing scope - PowerShell scripts: All run, but order not guaranteed

Examples

Example 1 — [Success] Most-restrictive compliance wins in conflict Two compliance policies assign conflicting password requirements to the same user: Policy A requires 6-character passwords (company baseline), Policy B requires 10-character passwords (finance group). Intune evaluates both and applies the most restrictive: the user must set a 10-character password before being marked compliant.

Example 2 — [Blocked] Conflicting configuration profiles — setting shows "Error" not "Most Restrictive" Two Settings Catalog profiles assign different values for the same setting (screen timeout: 5 minutes in one, 15 minutes in the other). The admin expects the 5-minute (more restrictive) setting to apply. Instead, the device status shows "Error" for the setting and neither value is applied. Root cause: Configuration profile conflicts do NOT auto-resolve to most restrictive — they result in an "Error" or "Not Applicable" state. The admin must remove the conflicting setting from one profile to resolve the conflict.

Key Mechanisms

- Core function: When multiple policies assign different values for the same setting, Intune uses conflict resolution rules to determine which value applies. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Most-restrictive compliance wins in conflict - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Identify conflicts: - Go to Intune → Devices → Monitor → Assignment failures - Check device-specific troubleshooting 2. Review policy precedence: - Compliance > Configuration for security settings - User-assigned > Device-assigned for profiles 3. Use filters to narrow scope: - Create filters to prevent overlapping assignments 4. Test in pilot before broad deployment 5. Document conflict resolution rules for help desk 6. For critical settings, use Settings catalog with targeted assignments

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-troubleshoot https://learn.microsoft.com/en-us/mem/intune/configuration/filters-general

Explanation

Intune can deploy PowerShell scripts to Windows devices for configurations beyond built-in profiles. Scripts run in system context (or user context) and can perform complex tasks like registry edits, file operations, or custom application configurations. Scripts are assigned to users or devices and can run once or on every policy refresh.

Think of it as: A custom mechanic for your devices—when standard tools aren't enough

Key Mechanics: - Scripts run as 64-bit PowerShell (default) or 32-bit if specified - Execution policy: Bypass (scripts run regardless of device policy) - Run as logged-on user or system account - Detection scripts: Determine if script should run again - Output logged to Intune management extension logs - Max script size: 200KB (uncompressed)

Examples

Example 1 — [Success] PowerShell script sets legacy app registry key A legal app requires a specific registry key that's unavailable in the Intune Settings Catalog. IT writes a 10-line PowerShell script that creates the key and sets the required value. The script runs in system context at next device check-in — the app works correctly on all managed devices without manual IT intervention.

Example 2 — [Blocked] Script runs but produces no output — IME not installed An admin uploads a PowerShell script and assigns it to a device group. After 24 hours, the script shows "Pending" on all devices. Root cause: PowerShell scripts in Intune require the Intune Management Extension (IME) — IME is automatically installed on Entra joined devices that have at least one Win32 app or script assigned. If the device is very new or recently reset, IME may not have installed yet. Fix: Assign a Win32 app to trigger IME installation, then the script will run.

Key Mechanisms

- Core function: Intune can deploy PowerShell scripts to Windows devices for configurations beyond built-in profiles. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] PowerShell script sets legacy app registry key - Decision clue: Industry: Legal Services

Review Path

Steps:

Prepare PowerShell script (.ps1 file)

Go to Intune admin center → Devices → Scripts and remediations

Select "Add" → Windows PowerShell script

Upload script file

Configure settings:

Run this script using the logged on credentials (or system)

Run script in 64-bit PowerShell

Enforce script signature check (optional)

Run script once or every check-in

Add detection script (optional) to determine if rerun needed

Assign to Entra ID groups

Monitor execution in script overview

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/intune-management-extension https://learn.microsoft.com/en-us/mem/intune/apps/powershell-scripts https://learn.microsoft.com/en-us/mem/intune/configuration/powershell-scripts-troubleshoot

Explanation

Kiosk configuration transforms Windows devices into single-purpose or multi-app locked-down experiences. Intune supports two kiosk modes: single-app (assigned access) for public-facing devices, and multi-app for shared scenarios with limited application sets. Preparation includes choosing account type (local, domain, Auto-logon) and selecting allowed applications.

Think of it as: Turning a full computer into a focused appliance—like an ATM or library catalog station

Key Mechanics: - Single-app kiosk: One UWP or Win32 app runs full screen - Multi-app kiosk: Start menu shows only allowed apps - Auto-logon: Device boots directly to kiosk app without user interaction - Kiosk user: Can be local, domain, or Auto-logon (no password required) - Browser kiosk: Microsoft Edge configured for public browsing - Accessibility: On-screen keyboard, narrator can be enabled

Examples

Example 1 — [Success] Museum interactive kiosk deployment A museum creates touch-screen kiosks running a single interactive exhibit app using Intune's single-app kiosk profile. They configure auto-logon with a local kiosk account, disable the taskbar and settings access, and enable the on-screen keyboard. After assigning the profile to the "Kiosk-Devices" group, visitors can interact with the exhibit app and nothing else — no access to Edge, Start menu, or system settings.

Example 2 — [Blocked] Win32 app kiosk fails at AUMID entry An admin configures a single-app kiosk for a lobby check-in app (Win32 executable), but enters the app's AUMID instead of the executable path. The kiosk profile applies but the device boots to a blank screen with no app loaded. Root cause: UWP apps use AUMID; Win32 apps require the full executable path — these are not interchangeable in the kiosk configuration.

Key Mechanisms

- Core function: Kiosk configuration transforms Windows devices into single-purpose or multi-app locked-down experiences. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Museum interactive kiosk deployment - Decision clue: Industry: Hospitality

Review Path

Steps:

1. Go to Intune admin center → Devices → Configuration profiles 2. Create new profile → Platform: Windows 10 and later → Profile: Kiosk 3. Choose kiosk mode: - Single-app, full-screen kiosk - Multi-app kiosk 4. Configure user account: - Local user (created on device) - Auto-logon (no password) - Entra ID user (if domain joined) 5. Select application(s): - For UWP apps: Add by AUMID - For Win32: Add by executable path 6. For multi-app: Configure Start menu layout 7. Configure additional settings: - Enable on-screen keyboard (touch devices) - Set browser kiosk settings if using Edge 8. Assign to device group 9. Test on pilot kiosk device

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/kiosk-settings https://learn.microsoft.com/en-us/windows/configuration/kiosk-methods https://learn.microsoft.com/en-us/mem/intune/configuration/kiosk-settings-windows

Explanation

Kiosk settings in Intune configure Windows and HoloLens devices for dedicated, locked-down experiences. For Windows, settings control single/multi-app behavior, user accounts, and Edge browsing modes. For HoloLens, kiosk settings restrict the device to specific immersive apps, ideal for training or guided work scenarios in mixed reality environments.

Think of it as: A device straightjacket—keeps users focused on exactly what they need

Key Mechanics: - Windows kiosk: Supports UWP, Win32, and Edge in kiosk mode - Edge kiosk modes: InPrivate public browsing, digital signage, or full-screen single app - HoloLens kiosk: Restricts to one or more immersive apps (2D or 3D) - Auto-logon: Device boots directly to kiosk experience - Custom Start layout: Only allowed apps appear (multi-app mode) - Accessibility: Enable narrator, magnifier, on-screen keyboard for touch

Examples

Example 1 — [Success] HoloLens kiosk for assembly training A manufacturing company configures HoloLens 2 devices in single-app kiosk mode using Intune. The kiosk profile restricts the device to the "Assembly Guide" immersive app, blocks the Settings gesture, disables calibration access, and configures auto-connect to factory Wi-Fi. Workers put on the headset and immediately see the training app — no way to exit to the shell or access other features.

Example 2 — [Blocked] Multi-app kiosk exceeds HoloLens app limit An admin tries to add 8 apps to a HoloLens multi-app kiosk profile. The profile saves but the device only shows 5 apps and the others are silently omitted. Root cause: HoloLens multi-app kiosk mode supports a maximum of 5 apps — exceeding this causes apps to be dropped without an explicit error in the Intune portal.

Key Mechanisms

- Core function: Kiosk settings in Intune configure Windows and HoloLens devices for dedicated, locked-down experiences. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] HoloLens kiosk for assembly training - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Go to Intune admin center → Devices → Configuration profiles 2. Create profile → Platform: Windows 10 and later → Profile: Kiosk 3. For Windows devices: - Select kiosk mode (single/multi-app) - Configure user account (local, AD, auto-logon) - Add apps by AUMID (UWP) or path (Win32) - For Edge kiosk: Choose kiosk mode type 4. For HoloLens: - Select kiosk mode (single/multi-app) - Add immersive apps by package family name - Configure allowed gestures/system access 5. Assign to device groups 6. Test on reference hardware

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/kiosk-settings-windows https://learn.microsoft.com/en-us/hololens/hololens-kiosk https://learn.microsoft.com/en-us/mem/intune/configuration/kiosk-settings-hololens

Explanation

Android device configuration profiles in Intune manage settings for Android Enterprise (recommended) and Android device administrator (legacy) devices. Android Enterprise offers work profile (BYOD), fully managed (corporate), and dedicated (kiosk) enrollment types. Profiles configure Wi-Fi, VPN, email, restrictions, and compliance settings based on enrollment type.

Think of it as: A remote control for Android devices—tuning them for work without taking over personal space

Key Mechanics: - Android Enterprise work profile: Separate personal/work containers on BYOD - Fully managed: Complete corporate control, no personal apps - Dedicated devices: Kiosk/multi-app mode for shared devices - Configuration types: Restrictions, Wi-Fi, VPN, Email (Exchange ActiveSync) - App configuration policies: Configure managed apps (Gmail, Edge, Teams) - OEMConfig: Vendor-specific settings for Samsung, Zebra, etc.

Examples

Example 1 — [Success] Mixed Android enrollment for logistics A shipping company enrolls drivers' personal phones as Android Enterprise work profile (BYOD), corporate handheld scanners as fully managed, and dispatch tablets as dedicated (kiosk) devices. Each enrollment type gets a tailored configuration profile: work profile restricts corporate app data, fully managed locks down the OS, and dedicated kiosks the dispatch app. All three co-exist in Intune with separate compliance and configuration policies per group.

Example 2 — [Blocked] Restrictions policy fails on work profile device An admin applies a "Fully Managed Restrictions" configuration profile to a group that includes both fully managed and work profile devices. The profile applies to fully managed devices correctly, but on work profile devices, corporate restrictions meant for fully managed mode are either ignored or cause a policy conflict. Root cause: Restriction profile types are enrollment-mode specific — fully managed and work profile require separate profiles with settings scoped to their enrollment type.

Key Mechanisms

- Core function: Android device configuration profiles in Intune manage settings for Android Enterprise (recommended) and Android device administrator (legacy) devices. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Mixed Android enrollment for logistics - Decision clue: Industry: Logistics

Review Path

Steps:

1. Connect managed Google Play: - Intune → Tenant administration → Connectors and tokens → Managed Google Play - Sign in with Google account, accept terms 2. Enroll devices based on type: - Work profile: Send enrollment email with QR code - Fully managed: Use QR code or NFC provisioning - Dedicated: Use QR code during setup 3. Create configuration profiles: - Go to Devices → Configuration profiles → Create profile - Platform: Android Enterprise - Choose profile type (Restrictions, Wi-Fi, etc.) 4. Configure settings per enrollment type 5. Deploy apps from Managed Google Play 6. Assign profiles to appropriate groups

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/android-enterprise-overview https://learn.microsoft.com/en-us/mem/intune/enrollment/android-enterprise-enroll https://learn.microsoft.com/en-us/mem/intune/configuration/device-restrictions-android-enterprise

Explanation

iOS device configuration profiles in Intune manage settings for iPhones and iPads enrolled via Apple Business Manager (corporate) or user enrollment (BYOD). Profiles configure restrictions (passcode, camera, AirDrop), Wi-Fi, VPN, email, and compliance settings. iOS requires Apple Push Notification Service (APNs) certificate for management.

Think of it as: A blueprint for Apple devices—defining what they can and can't do in the enterprise

Key Mechanics: - Device enrollment (corporate): Full control, supervised mode - User enrollment (BYOD): Limited management, personal data protected - APNs certificate required for all iOS management - Configuration profiles can be: Restrictions, Wi-Fi, VPN, Email, Custom - Settings can be: Required (supervised) or optional - App configuration policies configure managed apps (Outlook, Teams)

Examples

Example 1 — [Success] Supervised iPads for patient check-in A hospital deploys supervised iPads for patient check-in using Apple Business Manager and Intune. The configuration profile enables single-app kiosk mode (Guided Access), disables the camera and AirDrop, configures hospital Wi-Fi via certificate, and pushes the check-in app automatically. Nurses' personal iPhones are enrolled via user enrollment — corporate apps are managed but personal data stays private.

Example 2 — [Blocked] Supervised-only setting fails on user-enrolled device An admin creates a restrictions profile that includes a supervised-only setting (disabling App Store) and assigns it to a group containing both supervised iPads and user-enrolled iPhones. The setting applies to supervised devices but silently fails on user-enrolled iPhones. Root cause: Many iOS restrictions require supervised mode — they are ignored (not errored) on user-enrolled devices, giving a false impression of compliance.

Key Mechanisms

- Core function: iOS device configuration profiles in Intune manage settings for iPhones and iPads enrolled via Apple Business Manager (corporate) or user enrollment (BYOD). - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Supervised iPads for patient check-in - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Set up iOS management: - Get Apple Push Notification certificate (Intune → Devices → iOS enrollment) - Connect Apple Business Manager (for corporate devices) 2. Create enrollment profiles: - Corporate: Devices → iOS enrollment → Enrollment program tokens - BYOD: Configure user enrollment settings 3. Create configuration profiles: - Devices → Configuration profiles → Create → Platform: iOS/iPadOS - Choose profile type (Restrictions, Wi-Fi, VPN, etc.) 4. Configure settings based on enrollment type: - Supervised-only settings available for corporate devices 5. Assign to groups 6. Monitor compliance and deployment

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/ios-device-restrictions https://learn.microsoft.com/en-us/mem/intune/enrollment/ios-enroll https://learn.microsoft.com/en-us/mem/intune/configuration/ios-ipados-to-configure

Explanation

Intune provides unified profile creation for Apple devices (iOS, iPadOS, macOS) with platform-specific settings. Profiles manage device features, security settings, and app configurations. While the console separates platforms, many settings are conceptually similar but implemented differently based on Apple's platform capabilities and restrictions.

Think of it as: Apple device tailor—fitting the same suit to different body types

Key Mechanics: - Shared settings across Apple platforms: Passcode, restrictions, Wi-Fi, VPN - iOS/iPadOS-specific: Home screen layout, app store controls, cellular settings - macOS-specific: FileVault encryption, Gatekeeper settings, printer configuration - Platform-specific restrictions: Different capabilities per OS - User vs device profiles: Some settings apply to user, others to device - Apple Configurator: Import custom .mobileconfig files

Examples

Example 1 — [Success] Unified Apple platform baseline A creative agency manages both macOS workstations and iOS/iPadOS devices from Intune. They create separate profiles per platform: macOS gets FileVault enforcement, Gatekeeper policy, and network printer configuration; iOS/iPadOS gets passcode requirements, AirDrop restrictions, and VPN. Both profiles are assigned to platform-specific Entra ID device groups. IT manages the entire Apple fleet from a single console with consistent security baselines.

Example 2 — [Blocked] macOS FileVault profile assigned to iOS group An admin creates a macOS-only profile with FileVault encryption settings and accidentally assigns it to a group containing both macOS and iOS/iPadOS devices. The profile applies to macOS devices correctly but generates "Not Applicable" status on all iOS devices. Root cause: macOS profiles are platform-specific — FileVault and Gatekeeper settings only exist on macOS; they cannot be applied to iOS/iPadOS and Intune will not attempt to apply them.

Key Mechanisms

- Core function: Intune provides unified profile creation for Apple devices (iOS, iPadOS, macOS) with platform-specific settings. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Unified Apple platform baseline - Decision clue: Industry: Creative Agency

Review Path

Steps:

1. Go to Intune admin center → Devices → Configuration profiles 2. Select "Create profile" → Choose platform: - iOS/iPadOS - macOS 3. Select profile type: - Templates (Restrictions, Wi-Fi, VPN, etc.) - Settings catalog (newer, more settings) 4. Configure settings per platform: - iOS/iPadOS: Home screen, app store, cellular - macOS: FileVault, firewall, printer 5. For custom settings: - Import .mobileconfig file from Apple Configurator 6. Assign to user or device groups 7. Monitor deployment

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-create https://learn.microsoft.com/en-us/mem/intune/configuration/ios-device-restrictions https://learn.microsoft.com/en-us/mem/intune/configuration/macos-device-restrictions

Explanation

macOS configuration profiles in Intune manage Apple computers in enterprise environments. Profiles configure system preferences, security settings (FileVault, firewall), app restrictions, and network configurations. macOS management requires user-approved MDM enrollment and can integrate with Apple Business Manager for automated device enrollment (DEP).

Think of it as: Group Policy for Macs—bringing Windows-like management to Apple devices

Key Mechanics: - User-approved MDM: Required for full management capabilities - FileVault: Full disk encryption management and recovery key escrow - Gatekeeper: Control which apps can run (App Store vs anywhere) - Firewall: Configure application firewall and stealth mode - Kernel extensions: Allowlist required legacy extensions - Privacy Preferences Policy Control (PPPC): Grant app permissions (accessibility, camera, etc.) - System extensions: Modern replacement for kernel extensions

Examples

Example 1 — [Success] Developer MacBook standardization A software company enrolls developer MacBooks via Apple Business Manager and deploys Intune configuration profiles: FileVault is required with recovery keys escrowed to Intune, Gatekeeper allows identified developers, and PPPC grants terminal and VS Code accessibility permissions. IT confirms FileVault compliance from the Intune device view and can rotate the recovery key remotely if needed.

Example 2 — [Blocked] macOS kernel extension blocked by SIP An admin creates a kernel extension allowlist profile to permit a legacy VPN driver, but the policy is assigned before the devices are user-approved for MDM. On new MacBooks with SIP enabled and no MDM approval, the kernel extension is blocked. Root cause: macOS requires explicit user approval for MDM to manage kernel extensions — if the device is not user-approved MDM, kernel extension policies cannot take effect.

Key Mechanisms

- Core function: macOS configuration profiles in Intune manage Apple computers in enterprise environments. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Developer MacBook standardization - Decision clue: Industry: Software Development

Review Path

Steps:

1. Ensure devices are user-approved MDM: - Enroll via Company Portal or Apple Business Manager 2. Go to Intune admin center → Devices → Configuration profiles 3. Create profile → Platform: macOS 4. Choose profile type: - Templates: Restrictions, FileVault, Firewall, PPPC, etc. - Settings catalog: Browse all settings 5. Configure specific settings: - FileVault: Enable, choose recovery key escrow - Firewall: Enable, configure stealth mode, app blocks - PPPC: Add apps and grant permissions (accessibility, camera, etc.) - Kernel extensions: Add team IDs or bundle IDs 6. Assign to user or device groups 7. Monitor compliance in profile overview

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/macos-device-restrictions https://learn.microsoft.com/en-us/mem/intune/configuration/filevault-settings-macos https://learn.microsoft.com/en-us/mem/intune/configuration/device-restrictions-macos

Explanation

Enterprise multi-session devices, like Windows 365 Enterprise multi-session or Windows 10/11 multi-session for Azure Virtual Desktop, support multiple concurrent user sessions. Configuration profiles for these devices must account for shared environments, optimizing settings for performance, user personalization (FSLogix), and security across sessions.

Think of it as: A hotel room config—same room, different guests, each with their own belongings

Key Mechanics: - Multi-session OS: Multiple users simultaneously on one VM - FSLogix: Profiles and Office containers for user data roaming - Profile types: Restrict user-installed apps, shared settings apply to all - Performance settings: Optimize for multi-user workload (background apps, visual effects) - User Experience: Configure Start layout, taskbar for all users - Security: Settings apply to all sessions; user-specific policies via FSLogix

Examples

Example 1 — [Success] Call center VDI standardization A call center deploys Windows 365 Enterprise multi-session VMs and uses Intune to push configuration profiles: performance settings disable visual effects for faster rendering, a common Start layout shows only call app and Teams, and FSLogix is deployed as a Win32 app with registry settings pointing to Azure Files profile containers. Each agent gets a consistent, fast experience regardless of which VM session they connect to.

Example 2 — [Blocked] User-specific settings overwrite shared configuration An admin applies a user-targeted configuration profile to the same group receiving the machine-targeted multi-session profile. Some user-specific settings (like desktop wallpaper) conflict with the machine settings and are overwritten each login. Root cause: Multi-session environments require careful scoping — user-context profiles apply per session and can conflict with device-context profiles; use FSLogix user policies rather than Intune user profiles for session personalization.

Key Mechanisms

- Core function: Enterprise multi-session devices, like Windows 365 Enterprise multi-session or Windows 10/11 multi-session for Azure Virtual Desktop, support multiple concurrent user sessions. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Call center VDI standardization - Decision clue: Industry: Call Center

Review Path

Steps:

1. Deploy multi-session OS (Azure Virtual Desktop or Windows 365 Enterprise) 2. Configure FSLogix: - Download FSLogix from Microsoft - Deploy via Intune as Win32 app - Configure registry settings for profile container path 3. Create configuration profiles for multi-session: - Go to Intune → Devices → Configuration profiles - Platform: Windows 10 and later - Settings catalog: - System → Power Management → Optimize for performance - User Experience → Start layout (apply to all users) - Security → BitLocker, Defender - Administrative templates: - Terminal Services → Sessions, time limits 4. Test with multiple concurrent users 5. Monitor performance and user experience

Docs: https://learn.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq https://learn.microsoft.com/en-us/fslogix/overview https://learn.microsoft.com/en-us/mem/intune/configuration/windows-10-multi-session

Explanation

Shared Windows devices (shared PCs, multi-session VMs, or kiosks) require specific configurations to manage multiple users. Windows 10/11 includes "Shared PC mode" that optimizes for shared use: automatic guest account sign-in, disk cleanup between users, and power management. Settings control user accounts, disk space, and sign-in behavior.

Think of it as: A public library computer—ready for the next person as soon as you leave

Key Mechanics: - Shared PC mode: Enables guest-like accounts, automatic deletion of profiles - Account management: Local accounts only (no Microsoft account sign-in) - Disk leveling: Delete profiles when disk space low - Power settings: Configure sleep, wake timers for shared environment - Sign-in: Fast switching, auto-logon options - Guest favorite apps: Pre-installed apps available to all - Education-specific: "Set up shared PC" for classroom scenarios

Examples

Example 1 — [Success] University computer lab shared PC setup A university configures 100 Windows workstations in Shared PC mode via Intune: guest account auto-logon is enabled, profile deletion triggers when disk usage exceeds 80%, and power settings wake the device automatically at 7am. Students sit down, log in as guest, use Office and Edge, and leave — the next student gets a clean session.

Example 2 — [Blocked] Domain user data persists on shared PC A library enables Shared PC mode but staff log in with their domain accounts. Their profiles accumulate on the shared PC and disk space fills up over time. Root cause: Shared PC mode's automatic profile deletion works for local/guest accounts but domain-joined accounts may retain profiles depending on configuration. For true profile isolation, combine Shared PC mode with "delete profiles older than X days" setting and restrict domain sign-in on shared devices.

Key Mechanisms

- Core function: Shared Windows devices (shared PCs, multi-session VMs, or kiosks) require specific configurations to manage multiple users. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] University computer lab shared PC setup - Decision clue: Industry: Education

Review Path

Steps:

1. Go to Intune admin center → Devices → Configuration profiles 2. Create new profile → Platform: Windows 10 and later 3. Select "Settings catalog" 4. Search for "Shared PC" and configure: - Enable Shared PC Mode - Set account model (Guest, Domain-joined, or both) - Configure disk level deletion settings - Set inactive threshold (days before profile deletion) 5. Add additional settings: - Power management (sleep timers) - Start layout (User Experience → Start layout) - Education policies (disable Cortana, consumer features) 6. Assign to device groups (labs, libraries, etc.) 7. Test on reference device

Docs: https://learn.microsoft.com/en-us/windows/configuration/shared-pc https://learn.microsoft.com/en-us/mem/intune/configuration/shared-multi-user-device-settings https://learn.microsoft.com/en-us/education/windows/set-up-school-pcs-shared-pc-mode

Explanation

Filters in Intune allow granular targeting of configuration profiles, compliance policies, and apps based on device properties (OS version, manufacturer, model) or enrollment attributes. Filters narrow policy application within assigned groups, enabling scenarios like "Apply this profile to all Windows 11 devices in the Sales group" without creating multiple groups.

Think of it as: A bouncer at the policy door—only letting in devices that meet specific criteria

Key Mechanics: - Filters evaluate device properties at policy application time - Rule syntax: (device.manufacturer -eq "Microsoft") or (device.osVersion -startsWith "10.0.22000") - Properties available: manufacturer, model, OS version, enrollment profile, etc. - Filters can be included (apply to matching) or excluded (skip matching) - Multiple rules combined with AND/OR - Evaluated per device during policy check-in

Examples

Example 1 — [Success] Model-specific Wi-Fi targeting A company has one global "All Windows Devices" group but needs different Wi-Fi SSIDs for Surface devices vs. Dell laptops. They create two filters — "Surface Devices" using (device.manufacturer -eq "Microsoft Corporation") and "Dell Devices" using (device.manufacturer -eq "Dell") — and apply each to a separate Wi-Fi configuration profile assigned to the same group. Surfaces get "Surface-WiFi" and Dell laptops get "Dell-Corp" without creating separate device groups.

Example 2 — [Blocked] Filter used to restrict user permissions fails An admin creates a filter to try to restrict users from accessing certain apps based on device model. After assigning the policy with the filter, the app restriction does not apply as expected. Root cause: Filters scope policy deployment to matching devices — they do NOT grant or restrict user permissions. To control user access, use Conditional Access, app protection policies, or assignment groups, not filters.

Key Mechanisms

- Core function: Filters in Intune allow granular targeting of configuration profiles, compliance policies, and apps based on device properties (OS version, manufacturer, model) or enrollment attributes. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Model-specific Wi-Fi targeting - Decision clue: Industry: Multi-National Corporation

Review Path

Steps:

1. Go to Intune admin center → Tenant administration → Filters 2. Select "Create" → Enter name and description 3. Choose platform (Windows, iOS, etc.) 4. Define rules using device properties: - device.manufacturer - device.model - device.operatingSystemVersion - device.enrollmentProfileName - device.ownership (corporate/personal) 5. Use operators to build expression 6. Validate rule syntax 7. Save filter 8. When assigning profile, under "Filter", select "Include filtered devices in assignment" or "Exclude" 9. Choose the created filter

Docs: https://learn.microsoft.com/en-us/mem/intune/fundamentals/filters https://learn.microsoft.com/en-us/mem/intune/configuration/filters-general https://learn.microsoft.com/en-us/mem/intune/configuration/filters-device-properties

Explanation

Creating filters in Intune involves defining rules based on device properties to control policy application. Filters use a simple expression language to evaluate device attributes like manufacturer, OS version, or enrollment profile. Well-designed filters reduce the need for multiple groups and enable precise targeting of configurations.

Think of it as: Writing a smart rule that sorts devices automatically

Key Mechanics: - Filter creation in Tenant administration section - Rule syntax: [property] [operator] [value] - Available properties: manufacturer, model, osVersion, enrollmentProfileName, ownership, etc. - String operators: -eq, -ne, -contains, -startsWith - Numeric operators: -eq, -ne, -ge, -le, -gt, -lt - Combine rules with -and, -or - Test filter before saving to validate logic

Examples

Example 1 — [Success] Surface-only BitLocker filter An IT admin creates a filter named "Surface Devices" with rule: (device.manufacturer -eq "Microsoft Corporation"). They then assign a BitLocker configuration profile to the "All Windows Corporate" group using this filter in "Include" mode. The profile applies only to Surface devices — other Windows devices in the same group are unaffected. When new Surface devices enroll, the filter auto-targets them at next check-in.

Example 2 — [Blocked] Admin mistakes filter for permission control An admin creates a filter for "Contractor Devices" and assigns it to a compliance policy hoping it will also prevent contractors from accessing sensitive SharePoint sites. The compliance policy deploys correctly but SharePoint access is not blocked. Root cause: Filters control policy deployment scope — they do NOT grant or restrict user permissions or content access. Blocking SharePoint for contractors requires Conditional Access policies with the relevant user group, not a filter.

Key Mechanisms

- Core function: Creating filters in Intune involves defining rules based on device properties to control policy application. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Surface-only BitLocker filter - Decision clue: Industry: IT Department

Review Path

Steps:

1. Navigate to Intune admin center → Tenant administration → Filters 2. Click "Create" to start new filter 3. Enter name and description 4. Select platform (Windows, iOS, Android, etc.) 5. In rule builder: - Choose property from dropdown - Select operator - Enter value - Add multiple rules with AND/OR 6. Review rule syntax in text view 7. Click "Preview" to see how many devices match 8. Validate logic with test values 9. Save filter 10. Use in profile assignments under "Filter" option

Docs: https://learn.microsoft.com/en-us/mem/intune/fundamentals/filters-create https://learn.microsoft.com/en-us/mem/intune/configuration/filters-create https://learn.microsoft.com/en-us/mem/intune/configuration/filters-troubleshoot

Explanation

Endpoint Privilege Management (EPM) is an Intune Suite add-on that allows organizations to run specific applications with elevated privileges without granting users permanent admin rights. EPM enables standard users to perform approved privileged tasks (like installing approved apps or running specific executables) while maintaining least-privilege security.

Think of it as: A valet key for admin rights—users get temporary, limited access only when needed

Key Mechanics: - Elevation rules: Define which files/users get temporary admin rights - Support for: EXE, MSI, scripts, Control Panel items - Elevation types: Automatic (silent) or just-in-time (user requests) - Child process handling: Control if elevated app can launch other elevated processes - Reporting: Track all elevation requests and usage - Windows 10/11 required (no Windows Server support) - Works with existing policies: No change to user account type

Examples

Example 1 — [Success] Standard users install approved VPN client A financial services company deploys EPM with an automatic elevation rule for the approved VPN client installer (verified by file hash and certificate). Standard-user financial advisors can install the VPN without admin rights — EPM silently elevates the installer, logs the event to Intune, and the installation completes. Helpdesk admin elevation tickets drop significantly.

Example 2 — [Blocked] Just-in-time request denied at child process A user triggers a JIT elevation for an approved app installer, provides a business justification, and the installer runs elevated. However, the installer tries to launch a child process (post-install config tool) that is NOT in the elevation rules. The child process is blocked by EPM's child process handling setting. Root cause: Elevation rules apply to the specific file only — by default, child processes launched by an elevated app do NOT inherit the elevation unless explicitly configured in the EPM rule.

Key Mechanisms

- Core function: Endpoint Privilege Management (EPM) is an Intune Suite add-on that allows organizations to run specific applications with elevated privileges without granting users permanent admin rights. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Standard users install approved VPN client - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Verify Intune Suite license (add-on required) 2. Go to Intune admin center → Endpoint security → Endpoint Privilege Management 3. Enable EPM for Windows devices (tenant-wide setting) 4. Create elevation rules: - Click "Create" → "Elevation rule" - Upload file or specify path - Choose detection method (hash, certificate, path) - Select elevation type (automatic or just-in-time) - Configure child process behavior - Set validation options (publisher, product name) 5. Assign rule to device groups 6. Configure reporting settings 7. Monitor elevation activity in EPM reports

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/epm-overview https://learn.microsoft.com/en-us/mem/intune/protect/epm-policies https://learn.microsoft.com/en-us/mem/intune/protect/epm-troubleshoot

Explanation

EPM policies in Intune define elevation rules and settings for managed devices. These policies include elevation rules (file-specific) and global settings (reporting, user notifications). EPM uses a client component installed on Windows devices that intercepts elevation requests and applies configured rules before allowing privileged access.

Think of it as: A smart gatekeeper that knows which visitors (apps) get VIP access

Key Mechanics: - Policy types: Elevation rules (per app) and general settings - Client component: Automatically installed when EPM enabled - Rule precedence: More specific rules (file hash) override generic (path) - Reporting: Events sent to Intune/Defender for monitoring - User notifications: Customizable messages for JIT elevation - Support for: EXE, MSI, scripts, COM objects - Block rules: Explicitly deny elevation for specific files

Examples

Example 1 — [Success] Tiered EPM policies by department A hospital creates two EPM policies: a "Nursing" policy with automatic elevation for the medical records app (hash + certificate validated) and JIT elevation for printer drivers requiring justification; an "IT Staff" policy with automatic elevation for Microsoft-signed installers. Each is assigned to the corresponding department device group. Security team reviews elevation events in Defender for Endpoint.

Example 2 — [Blocked] File path rule elevated the wrong executable An admin creates a JIT elevation rule scoped to "C:\LOBApps\*.exe" instead of using the specific file hash. A threat actor places a malicious .exe in that directory, and the user accidentally triggers a JIT elevation for it. The EPM policy allows it because the path matches. Root cause: Path-based rules are less secure than hash or certificate-based validation — always prefer hash or certificate as the detection method for trusted elevation to avoid unintended elevation of arbitrary executables.

Key Mechanisms

- Core function: EPM policies in Intune define elevation rules and settings for managed devices. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Tiered EPM policies by department - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Navigate to Intune admin center → Endpoint security → Endpoint Privilege Management 2. Select "Policies" tab → Create new policy 3. Configure general settings: - Enable/disable EPM client - Set reporting level - Configure user notification preferences 4. Add elevation rules: - Click "Add" → Choose rule type (automatic, JIT, block) - Specify target file (upload or path) - Configure validation method - Set child process handling 5. For JIT rules: Configure justification requirements 6. Add multiple rules as needed 7. Assign policy to device groups 8. Monitor policy application in EPM reports

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/epm-policies-create https://learn.microsoft.com/en-us/mem/intune/protect/epm-settings https://learn.microsoft.com/en-us/mem/intune/protect/epm-rules

Explanation

The Enterprise App Catalog in Intune is a centralized repository of prepackaged, validated third-party applications (like Adobe Reader, Zoom, Java) that IT can deploy without manual packaging. Microsoft maintains the catalog, ensuring apps are tested, dependency-free, and updated with the latest versions.

Think of it as: An app store for IT—curated, ready-to-deploy applications

Key Mechanics: - Catalog apps: Third-party apps pre-configured for Intune deployment - Microsoft-validated: Tested for compatibility and silent installation - Automatic updates: Catalog apps can be set to auto-update - Available as: Win32 apps (in Intune format) - Dependency handling: App dependencies automatically included - Reporting: Native Intune deployment reporting - Languages: Multiple language versions available

Examples

Example 1 — [Success] Deploying Adobe Reader via Enterprise App Catalog An IT admin needs to deploy Adobe Acrobat Reader to 5,000 Windows devices. Instead of packaging, they open Intune admin center → Apps → All apps → Add → Enterprise App Catalog, search for "Adobe Acrobat Reader," select the latest version, configure auto-update, and assign as Required to the "All Windows Devices" group. All 5,000 devices install the app silently within the next check-in cycle.

Example 2 — [Blocked] Specific app version not available in catalog An IT team needs a specific legacy version of Java (v8u251) locked to a particular LOB app. They search the Enterprise App Catalog but only the latest Java LTS version is available. The specific patch version they need is not in the catalog. Root cause: The Enterprise App Catalog only offers Microsoft-validated versions — organizations that require specific older patch versions must fall back to custom Win32 app packaging using the Win32 Content Prep Tool.

Key Mechanisms

- Core function: The Enterprise App Catalog in Intune is a centralized repository of prepackaged, validated third-party applications (like Adobe Reader, Zoom, Java) that IT can deploy without manual packaging. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Deploying Adobe Reader via Enterprise App Catalog - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Go to Intune admin center → Apps → All apps 2. Click "Add" → Select "Enterprise App Catalog" 3. Browse or search for desired application 4. Select application and version 5. Configure app information: - Name, description - Language selection - Install behavior (system/user) 6. Configure assignments: - Required (auto-install) - Available (Company Portal) - Uninstall 7. Set update options: - Automatic updates (latest version) - Specific version (lock version) 8. Review and create 9. Monitor deployment in app overview

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-enterprise-app-catalog https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-enterprise-app-catalog https://learn.microsoft.com/en-us/mem/intune/apps/apps-enterprise-app-catalog-faq

Explanation

Enterprise Application Management (EAM) in Intune provides comprehensive capabilities for managing the entire application lifecycle across Windows devices. EAM includes the Enterprise App Catalog, advanced app packaging, dependency management, and update controls for third-party applications, reducing the need for manual packaging and external tools.

Think of it as: A full-service app department—from packaging to updates, all in one place

Key Mechanics: - App packaging: Pre-packaged apps or import your own - Dependency management: Apps can require other apps (e.g., Java for specific apps) - Supersedence: Replace old app versions automatically - Detection rules: Verify app installation status - Update rings: Control update rollout speed - Reporting: Detailed installation status and errors - Integration: Works with existing Intune app policies

Examples

Example 1 — [Success] App supersedence for PDF viewer migration A company is replacing Legacy PDF Viewer v2 with Adobe Acrobat Reader. In Intune, they add Adobe Acrobat Reader and configure supersedence targeting Legacy PDF Viewer v2 with "Uninstall" selected. When the Adobe Reader assignment deploys, Intune automatically uninstalls the old app and installs the new one in a single operation — no separate uninstall policy needed.

Example 2 — [Blocked] Dependency app fails silently — main app never installs An admin deploys App A (an LOB tool) with .NET Framework 4.8 configured as a dependency. On several devices, .NET Framework 4.8 fails to install silently due to a pending Windows Update restart. App A's installation is blocked but the Intune report shows App A as "Pending install" with no clear error. Root cause: Dependency failures block the primary app but may not surface detailed errors in the console — always check the dependency app's individual deployment status in Intune device reports.

Key Mechanisms

- Core function: Enterprise Application Management (EAM) in Intune provides comprehensive capabilities for managing the entire application lifecycle across Windows devices. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] App supersedence for PDF viewer migration - Decision clue: Industry: Enterprise IT

Review Path

Steps:

1. Add applications: - From Enterprise App Catalog (recommended) - Upload custom Win32 apps (using Win32 Content Prep Tool) - Add store apps (Microsoft Store, Google Play, Apple) 2. Configure app settings: - Set detection rules (file, registry, MSI code) - Add dependencies (required apps) - Configure supersedence (replaces old versions) 3. Assign to groups: - Required (auto-install) - Available (Company Portal) - Uninstall (remove) 4. Create update rings: - Groups → Update rings for Windows - Control deferral periods 5. Monitor deployment: - App install status - Device installation reports - Troubleshoot failures

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-windows-enterprise https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-add https://learn.microsoft.com/en-us/mem/intune/apps/apps-lifecycle

Explanation

Intune Advanced Analytics provides deep insights into device performance, application reliability, and user experience. It includes Endpoint Analytics (boot performance, app crashes), custom queries, and proactive remediation. Advanced Analytics helps IT identify issues before users report them and optimize device performance.

Think of it as: A health monitor for your devices—predicting problems before they happen

Key Mechanics: - Endpoint Analytics: Boot time, app reliability, sign-in duration - Proactive remediations: Scripts that detect and fix common issues - Custom queries: KQL-based queries against device data - Work from home: VPN and Wi-Fi performance insights - Battery health: Track battery capacity and charging patterns - Reporting: Historical trends and device-level details

Examples

Example 1 — [Success] Proactive POS remediation prevents store downtime A retail chain's IT team uses Intune Advanced Analytics to monitor 500 POS terminals. Analytics shows 60 terminals with boot scores below 50. IT creates a proactive remediation script that detects unnecessary startup services and disables them. The remediation runs every 6 hours, boot scores rise above 75 within two weeks, and store opening delays due to slow POS startup drop to zero.

Example 2 — [Blocked] Advanced Analytics custom queries not available on Basic license An IT admin wants to run KQL-based custom device queries from Intune's device query blade. After enabling Endpoint Analytics, the custom query option is grayed out. Root cause: Intune Advanced Analytics custom queries and proactive remediations require the Intune Suite add-on license (or the Advanced Analytics add-on separately) — the standard Intune license only provides basic Endpoint Analytics scores without custom query capability.

Key Mechanisms

- Core function: Intune Advanced Analytics provides deep insights into device performance, application reliability, and user experience. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Proactive POS remediation prevents store downtime - Decision clue: Industry: Retail

Review Path

Steps:

1. Enable Endpoint Analytics: - Intune admin center → Reports → Endpoint analytics - Click "Start" to enable - Configure data collection settings 2. View baseline scores: - Startup performance - App reliability - Work from home insights 3. Create proactive remediations: - Go to Apps → Proactive remediations → Create - Upload detection script - Upload remediation script - Set schedule and scope 4. Run custom queries: - Go to Reports → Device query - Write KQL queries - Run and export results 5. Set up alerts and notifications 6. Monitor trends over time

Docs: https://learn.microsoft.com/en-us/mem/analytics/overview https://learn.microsoft.com/en-us/mem/analytics/proactive-remediations https://learn.microsoft.com/en-us/mem/analytics/device-query

Explanation

Endpoint Analytics is a cloud-based service in Microsoft Intune that provides insights into endpoint performance, user experience, and IT efficiency. It analyzes startup performance, application reliability, and sign-in times to help IT optimize devices and reduce helpdesk tickets. Scores (0-100) rate performance and highlight areas for improvement.

Think of it as: A report card for your devices—showing how well they're serving users

Key Mechanics: - Startup performance: Boot time, login duration, background processes - App reliability: Crash frequency for key applications - Work from home: VPN connectivity, WiFi performance - Battery health: Charge capacity, discharge rates - Scores: Excellent (80-100), Needs improvement (60-79), Poor (0-59) - Recommendations: Actionable insights to improve scores - Historical trending: Track improvements over time

Examples

Example 1 — [Success] Lab startup score improvement A university's Endpoint Analytics shows lab computers averaging a startup score of 72. Drilling into the report reveals Adobe Updater and Teams are the top startup delay causes on 150 devices. IT creates a configuration profile to remove both from startup and redeploys Teams with a policy disabling auto-start at login. After 30 days the startup score rises to 85 and student complaints about slow lab boot times drop significantly.

Example 2 — [Blocked] Endpoint Analytics scores not populating after opt-in An admin enables Endpoint Analytics for all devices but after two weeks, 40% of devices show no data in the startup performance report. Root cause: Endpoint Analytics data collection requires the Intune Management Extension (IME) to be installed and active on each device — devices that are not regularly checking in or that have IME missing will not submit telemetry data, causing gaps in reporting.

Key Mechanisms

- Core function: Endpoint Analytics is a cloud-based service in Microsoft Intune that provides insights into endpoint performance, user experience, and IT efficiency. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Lab startup score improvement - Decision clue: Industry: Education

Review Path

Steps:

1. Enable Endpoint Analytics: - Intune admin center → Reports → Endpoint analytics - Click "Enable" (requires Intune license) - Configure data collection (opt-in for all devices) 2. View scores: - Overall score - Startup performance - App reliability - Work from home insights 3. Drill down into issues: - Click on any metric for details - View device-level data 4. Review recommendations: - Suggested actions to improve scores - Export recommendations to CSV 5. Track progress: - Historical charts show trends - Compare current vs. previous periods 6. Take action: - Create configuration profiles based on findings - Deploy app updates - Communicate with users

Docs: https://learn.microsoft.com/en-us/mem/analytics/overview https://learn.microsoft.com/en-us/mem/analytics/startup-performance https://learn.microsoft.com/en-us/mem/analytics/app-reliability

Explanation

Remote Help is an Intune Suite add-on that enables IT support to remotely connect to users' Windows devices for assisted troubleshooting. It provides secure, session-based remote control with consent, chat, and elevation capabilities. Remote Help integrates with Intune roles and permissions for access control.

Think of it as: A secure, managed version of remote desktop for helpdesk—with audit trails

Key Mechanics: - Remote assistance: Full control with user consent - Chat: In-session communication - Elevation: Request admin rights during session (if user approves) - Session recording: Optional audit trail (compliance) - Role-based access: Control who can initiate sessions - Reporting: Session history, duration, participants - Works with: Windows 10/11 devices managed by Intune - No VPN required: Uses Microsoft's secure relay service

Examples

Example 1 — [Success] Remote printer driver installation for remote worker A remote employee reports their Intune-managed laptop cannot detect the company printer. A helpdesk Tier 2 agent initiates a Remote Help session from Intune admin center → Devices → [Device] → Remote Help. The user receives a consent dialog, approves, and the agent takes full control. The agent requests elevation, installs the missing driver, and confirms the printer appears. The session is logged with participant names and duration for compliance review.

Example 2 — [Blocked] Remote Help session blocked — Intune Suite license missing A helpdesk agent tries to initiate a Remote Help session but the button is grayed out in the Intune device view. Root cause: Remote Help requires the Intune Suite add-on license (or standalone Remote Help license) — a standard Microsoft 365 E3/Intune P1 license does NOT include Remote Help. The tenant admin must assign the add-on before the feature is available.

Key Mechanisms

- Core function: Remote Help is an Intune Suite add-on that enables IT support to remotely connect to users' Windows devices for assisted troubleshooting. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Remote printer driver installation for remote worker - Decision clue: Industry: Global Enterprise

Review Path

Steps:

1. Verify Intune Suite license (add-on required) 2. Enable Remote Help: - Go to Intune admin center → Tenant administration → Remote Help - Toggle "Enable Remote Help" to On - Configure session settings: - Allow remote control - Allow elevation - Enable session recording (optional) 3. Configure permissions: - Assign users to "Helpdesk Operator" role in Entra ID - Or create custom role with Remote Help permissions 4. Train helpdesk agents: - Access via Intune → Devices → Select device → Remote Help - Or via Microsoft 365 admin center 5. Monitor usage: - View reports in Remote Help dashboard - Export session logs for compliance 6. Test with pilot users before full rollout

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-help/remote-help-overview https://learn.microsoft.com/en-us/mem/intune/remote-help/remote-help-configure https://learn.microsoft.com/en-us/mem/intune/remote-help/remote-help-report

Explanation

Cloud PKI is an Intune Suite add-on that provides a cloud-hosted public key infrastructure for issuing and managing certificates. It eliminates the need for on-premises certificate authorities (CAs) and supports common use cases: Wi-Fi authentication (802.1x), VPN access, email signing/encryption (S/MIME), and device authentication. Cloud PKI integrates directly with Intune certificate profiles.

Think of it as: A certificate authority in the cloud—no servers, no complex infrastructure

Key Mechanics: - Root CA: Microsoft-hosted, automatically renewed - Issuing CA: Scoped to your tenant, issues end-entity certificates - Certificate templates: Predefined or custom for different use cases - Integration: Works with Intune SCEP and PKCS certificate profiles - Lifecycle: Automatic renewal, revocation support - Compliance: FIPS 140-2 compliant, private keys in HSM

Examples

Example 1 — [Success] Hospital certificate rollout with Cloud PKI A hospital deploys Cloud PKI to replace their on-premises CA. IT creates a root CA (Microsoft-managed, HSM-protected) and an issuing CA in Intune's Cloud PKI blade. They then create SCEP certificate profiles for 802.1x Wi-Fi authentication and PKCS profiles for S/MIME email signing for physicians. Certificates are deployed automatically to all enrolled devices — no on-premises server maintenance required and certificates auto-renew before expiry.

Example 2 — [Blocked] Certificate profile fails on devices without Intune MDM enrollment An admin creates a Cloud PKI SCEP certificate profile for 802.1x Wi-Fi but assigns it to a group that includes unmanaged contractor laptops. The enrolled corporate devices receive certificates, but contractor laptops (not MDM-enrolled) show no certificate deployment. Root cause: Cloud PKI certificate profiles require full Intune MDM enrollment — they cannot deploy to devices managed only via MAM or unmanaged devices. Contractors need a separate certificate delivery method.

Key Mechanisms

- Core function: Cloud PKI is an Intune Suite add-on that provides a cloud-hosted public key infrastructure for issuing and managing certificates. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hospital certificate rollout with Cloud PKI - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Verify Intune Suite license (add-on required) 2. Set up Cloud PKI: - Go to Intune admin center → Tenant administration → Cloud PKI - Create Root CA (Microsoft managed) - Create Issuing CA (configure validity, enrollment restrictions) 3. Create certificate profiles for each use case: - Devices → Configuration profiles → Create → SCEP certificate - Choose template (User, Device, or custom) - Configure subject name, key usage, extended key usage - Point to Cloud PKI issuing CA 4. Deploy profiles to appropriate groups 5. For VPN/Wi-Fi: Create corresponding profiles referencing the certificate 6. Monitor certificate issuance in reports

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/cloud-pki-overview https://learn.microsoft.com/en-us/mem/intune/protect/cloud-pki-configure https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep

Explanation

Microsoft Cloud PKI is a fully managed certificate authority service within Intune that issues and manages certificates without on-premises infrastructure. It provides a complete PKI solution including root and issuing CAs, certificate templates, and integration with Intune certificate profiles. Cloud PKI supports SCEP and PKCS enrollment for Windows, iOS, Android, and macOS devices.

Think of it as: PKI as a service—certificates without the complexity

Key Mechanics: - Two-tier hierarchy: Root CA (Microsoft managed) + Issuing CA (tenant configurable) - Certificate templates: Predefined (user, device, email) or custom - Key storage: Private keys in FIPS 140-2 Level 3 HSMs - Revocation: CRL and OCSP support - Validity periods: Configurable up to 2 years for end-entity certs - Auto-renewal: Intune handles certificate renewal before expiry - Reporting: Certificate inventory, expiring certificates alerts

Examples

Example 1 — [Success] Legacy CA migration to Cloud PKI A bank decommissions their 15-year-old on-premises Microsoft CA and migrates to Cloud PKI. IT creates a tenant issuing CA in Intune admin center → Tenant administration → Cloud PKI, configures user authentication and device authentication templates, creates SCEP profiles for Windows and PKCS profiles for iOS devices, and assigns to all device groups. Certificate renewal is now automatic — no expired certificate incidents since migration.

Example 2 — [Blocked] SCEP certificate profile shows "Pending" indefinitely A company sets up Cloud PKI and creates a SCEP certificate profile for Windows devices but 30% of devices show the profile status as "Pending" for weeks. Root cause: SCEP certificate delivery requires the Intune Certificate Connector to be installed on at least one on-premises Windows Server for NDES communication, OR devices must be able to reach the Cloud PKI SCEP URL directly. Devices without the connector configured or network path to the SCEP endpoint cannot receive certificates.

Key Mechanisms

- Core function: Microsoft Cloud PKI is a fully managed certificate authority service within Intune that issues and manages certificates without on-premises infrastructure. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Legacy CA migration to Cloud PKI - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Enable Cloud PKI: - Intune admin center → Tenant administration → Cloud PKI - Click "Set up" and accept terms 2. Create issuing CA: - Name, description - Validity period - Enrollment restrictions (optional) 3. Configure certificate templates: - Built-in templates (User, Device, Email) - Or create custom template - Set key usage, extended key usage 4. Create certificate profiles: - Devices → Configuration profiles → Create - Platform: Choose (Windows, iOS, etc.) - Profile: SCEP or PKCS certificate - Point to Cloud PKI issuing CA - Select template 5. Assign profiles to groups 6. Monitor in Cloud PKI dashboard

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/cloud-pki-overview https://learn.microsoft.com/en-us/mem/intune/protect/cloud-pki-configure-issuing-ca https://learn.microsoft.com/en-us/mem/intune/protect/cloud-pki-certificate-profiles

Explanation

Microsoft Tunnel for MAM extends Microsoft Tunnel VPN capabilities to unmanaged devices (BYOD) using app-layer tunneling. It provides secure access to on-premises apps from mobile devices without full device enrollment. Tunnel for MAM integrates with Conditional Access and App Protection Policies to ensure only managed and compliant apps can access corporate resources.

Think of it as: A secure tunnel just for your work apps—not the whole device

Key Mechanics: - App-layer VPN: Only traffic from managed apps goes through tunnel - No device enrollment required: Works with MAM-only protection - Integration: Works with Edge, Outlook, and third-party apps via SDK - Conditional Access: Require approved apps and app protection - Per-app VPN: Different apps can have different access rules - Split tunneling: Corporate traffic via tunnel, internet direct - Zero Trust: Verify user, device health, app protection

Examples

Example 1 — [Success] Hospital doctors accessing on-premises records from personal iPhones A hospital enables Microsoft Tunnel for MAM so doctors can access on-premises patient records from personal iPhones without enrolling the device. Edge browser on the personal iPhone is registered with MAM, and Tunnel for MAM routes all Edge traffic to the on-premises web portal through the Tunnel gateway. Doctors never see a traditional VPN client — the tunnel is transparent within Edge. Personal apps on the phone go directly to the internet.

Example 2 — [Blocked] Tunnel for MAM fails — Defender for Endpoint license missing An admin sets up the Microsoft Tunnel gateway and enables Tunnel for MAM in the Intune console. When users open the managed Edge app, the connection to on-premises resources fails with a tunnel initialization error. Root cause: Microsoft Tunnel for MAM mode requires Microsoft Defender for Endpoint (Plan 1 or Plan 2) to be licensed for the tenant — Intune license alone is insufficient. The Intune Suite does NOT automatically include Defender for Endpoint.

Key Mechanisms

- Core function: Microsoft Tunnel for MAM extends Microsoft Tunnel VPN capabilities to unmanaged devices (BYOD) using app-layer tunneling. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hospital doctors accessing on-premises records from personal iPhones - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Deploy Microsoft Tunnel gateway servers: - Prepare Linux servers (Ubuntu 20.04/22.04) - Install Microsoft Tunnel using deployment script - Configure DNS, certificates - Set up high availability (minimum 2 servers) 2. Configure in Intune: - Go to Tenant administration → Microsoft Tunnel - Add site and servers - Enable "Tunnel for MAM" setting 3. Create server configuration profile: - Assign to apps using per-app VPN 4. Configure app protection policies: - Require managed apps for corporate data - Set data protection settings 5. Configure Conditional Access: - Require approved client app - Require app protection policy - Grant access, block legacy auth 6. Test with pilot users

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-overview https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-mam https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-configure

Explanation

Microsoft Tunnel is a VPN gateway solution that runs on Linux servers in your infrastructure, enabling secure connectivity from Intune-managed devices to on-premises resources. It supports two scenarios: full device tunnel (for managed devices) and app-layer tunnel (MAM) for unmanaged devices. Tunnel integrates with Intune for configuration, Conditional Access, and reporting.

Think of it as: Your own secure on-ramp from the cloud to your internal network

Key Mechanics: - Gateway servers: Linux (Ubuntu) running Tunnel software - High availability: Multiple servers in a site - Protocols: TLS-based VPN (not IPsec) - Authentication: Entra ID + device compliance - Split tunneling: Route only internal traffic through tunnel - Integration: Works with Conditional Access, compliance policies - Monitoring: Tunnel health, connected devices in Intune - MAM support: App-layer VPN for unmanaged devices

Examples

Example 1 — [Success] Replacing legacy VPN with Microsoft Tunnel A manufacturing company deploys two Ubuntu 22.04 servers in their primary data center as a Microsoft Tunnel HA pair. They register the servers in Intune admin center → Tenant administration → Microsoft Tunnel, configure split tunneling to route only 10.1.0.0/16 traffic through the tunnel, and assign a VPN configuration profile to the "Managed Windows Devices" group. Engineers working remotely connect automatically — no VPN client installation required, compliance is verified at connection time via Conditional Access.

Example 2 — [Blocked] Tunnel server health check fails after Linux OS update A company's Tunnel gateway servers stop accepting connections after a routine Ubuntu kernel update. The Intune Tunnel dashboard shows servers as unhealthy. Root cause: Microsoft Tunnel is sensitive to specific Linux kernel versions and some updates can break the Tunnel software. Always validate Tunnel compatibility before applying OS updates — Microsoft publishes a supported Linux distributions list and kernel version requirements.

Key Mechanisms

- Core function: Microsoft Tunnel is a VPN gateway solution that runs on Linux servers in your infrastructure, enabling secure connectivity from Intune-managed devices to on-premises resources. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Replacing legacy VPN with Microsoft Tunnel - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Plan infrastructure: - Minimum 2 Linux servers for HA - Network connectivity to internal resources - Firewall rules for Tunnel communication 2. Deploy servers: - Install Ubuntu 20.04/22.04 LTS - Download and run Tunnel deployment script - Configure certificates 3. Configure in Intune: - Go to Tenant administration → Microsoft Tunnel - Create site (e.g., "Primary Data Center") - Add servers to site 4. Create VPN profiles: - Devices → Configuration profiles → Create - Platform: Windows 10 and later - Profile: VPN - Select "Microsoft Tunnel" as connection type 5. Configure Conditional Access: - Require compliant devices - Require MFA 6. Test connectivity 7. Monitor via Tunnel dashboard

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-overview https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-prerequisites https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-monitor

Explanation

The sync device action forces a managed device to check in with Intune immediately, rather than waiting for its next scheduled check-in (typically every 8 hours). This ensures policy changes, app deployments, or compliance updates are applied urgently when needed, such as before a user travels or after a security incident.

Think of it as: Pushing the "refresh" button on a device's connection to IT

Key Mechanics: - Triggers device to check for new policies, apps, profiles - Works on all platforms: Windows, iOS, Android, macOS - Device must be online and reachable - Sync happens asynchronously—device may take several minutes - Status shows "Sync pending" until completed - Limited to 15 sync requests per device per day - Requires Intune license for the user/device

Examples

Example 1 — [Success] Emergency policy push before executive travel Before an executive departs internationally, IT issues an updated VPN configuration profile. The helpdesk immediately syncs the executive's device from Intune admin center → Devices → [Device] → Sync. Within five minutes the device checks in, downloads the new VPN profile, and the executive confirms the VPN connects from the airport lounge — hours before the normal 8-hour check-in cycle would have delivered it.

Example 2 — [Blocked] Sync completes but policy still not applied An admin triggers sync on a device after assigning an emergency compliance policy. The sync status shows "Sync completed," but the device still shows non-compliant in Intune. Root cause: Sync triggers a check-in but policy evaluation and reporting can take additional time after check-in completes — "Sync completed" means the device checked in, not that all policies have been evaluated and applied. Wait 5–15 minutes after sync before assuming the policy failed.

Key Mechanisms

- Core function: The sync device action forces a managed device to check in with Intune immediately, rather than waiting for its next scheduled check-in (typically every 8 hours). - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Emergency policy push before executive travel - Decision clue: Industry: IT Helpdesk

Review Path

Steps:

1. Go to Intune admin center → Devices → All devices 2. Select device(s) to sync (single or bulk) 3. Click "More" → "Sync" remote action 4. Confirm action in popup 5. Monitor status: - Device overview shows "Sync pending" - Refresh to see "Last check-in" time update 6. For bulk sync: - Select up to 100 devices - Use filters to select specific group 7. Verify completion: - Check device properties - Review policy application status 8. Use Graph API for automated syncs: POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{deviceId}/syncDevice Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-sync https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-management https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-syncdevice

Explanation

The restart device action remotely reboots a managed Windows device. This is useful for applying updates that require a restart, troubleshooting performance issues, or enforcing compliance after security patches. The action can be scheduled with a configurable grace period and notification message to minimize user disruption.

Think of it as: Remote-controlled reboot—like asking someone to restart their computer, but doing it for them

Key Mechanics: - Works on Windows devices only (Intune managed) - Configurable grace period: 0-120 minutes - Custom notification message to user - Device must be online and reachable - User can postpone (if grace period > 0) - Requires device to be enrolled and active - Logs restart event in device history

Examples

Example 1 — [Success] Post-patch restart with user grace period After deploying critical security updates on Patch Tuesday, IT uses Intune to remotely restart all Windows devices that haven't rebooted in 48 hours. They select the "Needs Restart" filter, choose all devices, and issue a restart action with a 60-minute grace period and the message: "Critical updates require a restart in 60 minutes. Please save your work." Most devices restart within the grace period and the fleet reaches compliance before the next business day.

Example 2 — [Blocked] Restart action has no effect on offline device An admin issues a restart action on a device that hasn't checked in for 3 days. The Intune portal shows the action as "Pending" indefinitely. Root cause: Remote restart requires the device to be online and reachable — the command is queued but cannot execute until the device connects. For devices offline for extended periods, investigate why the device hasn't checked in rather than repeatedly issuing actions.

Key Mechanisms

- Core function: The restart device action remotely reboots a managed Windows device. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Post-patch restart with user grace period - Decision clue: Industry: Retail

Review Path

Steps:

1. Navigate to Intune admin center → Devices → All devices 2. Select Windows device(s) to restart 3. Click "More" → "Restart" remote action 4. Configure options: - Grace period (minutes) - Custom message to user (optional) 5. Click "Restart" to confirm 6. Monitor status: - Device overview shows restart status - Check device history for restart events 7. For scheduled restarts: - Use device groups and filters - Combine with maintenance windows 8. Verify restart: - Check last reboot time in device properties - Confirm updates applied

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-restart https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-management https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-restart-troubleshoot

Explanation

The retire action removes a device from Intune management, wiping all corporate data, apps, and policies while optionally preserving personal data (on BYOD devices). For corporate devices, it can optionally perform a full wipe. Retired devices are removed from Intune inventory and lose access to corporate resources protected by Conditional Access.

Think of it as: Checking out of a hotel—you return the keys and leave, but personal belongings stay

Key Mechanics: - Removes Intune management profile - Uninstalls all company apps and data - Removes device from Entra ID (optional) - For BYOD: Preserves personal data (work profile removed) - For corporate: Option to perform full factory reset - Device becomes unmanaged, loses Conditional Access - User can no longer access corporate resources - Action is irreversible—device must re-enroll to regain access

Examples

Example 1 — [Success] Secure offboarding across device types When an employee leaves, HR notifies IT. The helpdesk issues a Wipe action on the corporate-owned laptop (factory reset for redeployment) and a Retire action on the employee's personal Android phone (removes work profile and corporate apps, preserves personal data). Both actions complete within 30 minutes. The user can no longer access corporate email, SharePoint, or other Conditional Access-protected resources.

Example 2 — [Blocked] Retire action does not remove corporate data on unmanaged device An employee used their personal phone to access corporate email via the Outlook app but never fully enrolled in Intune MDM (MAM-only). IT issues a Retire action but the device isn't in the Intune MDM device list. Root cause: Retire only removes corporate data from MDM-enrolled devices. MAM-only devices must have their corporate data removed via an app-level selective wipe from Intune apps blade (Apps → App selective wipe), not from the device list.

Key Mechanisms

- Core function: The retire action removes a device from Intune management, wiping all corporate data, apps, and policies while optionally preserving personal data (on BYOD devices). - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Secure offboarding across device types - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Navigate to Intune admin center → Devices → All devices 2. Select device(s) to retire 3. Click "Retire" (or "Wipe" if corporate device and full reset needed) 4. Confirm action: - For BYOD: "Retire" (keep personal data) - For corporate: Choose "Wipe" for factory reset 5. Monitor status: - Device shows "Retire pending" then removed from list - Check device history for completion 6. For automated offboarding: - Use Microsoft Graph API - Integrate with HR systems 7. Verify: - Device no longer appears in Intune - User can't access corporate resources

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/devices-wipe https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-retire https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-management

Explanation

The wipe action performs a factory reset on a device, removing all data and restoring it to out-of-box state. This is used for corporate devices being repurposed, lost/stolen devices, or when a device needs complete cleanup. Wipe can be configured to retain enrollment data for quick redeployment or perform a full clean wipe.

Think of it as: Demolition and rebuild—starting completely fresh

Key Mechanics: - Factory reset: Removes all data, apps, settings - Two options: - Wipe device, but keep enrollment for quick re-enrollment - Full wipe (complete reset, no enrollment data) - Works on: Windows, iOS, Android, macOS - Device must be online to receive command - Lost/stolen: Can wipe even if device offline (next check-in) - After wipe: Device removed from Intune - Corporate devices only recommended (not for BYOD)

Examples

Example 1 — [Success] Semester-end laptop redeployment A university collects 200 loaner laptops at semester end and issues a Wipe with "Retain enrollment" action from Intune. Each device factory-resets, auto-re-enrolls via Autopilot, receives the student laptop profile, and is ready for next-semester distribution within a few hours — no manual re-imaging required.

Example 2 — [Blocked] Full wipe sent to personal BYOD device An admin accidentally selects a BYOD personal iPhone when issuing a bulk wipe action and confirms without checking the ownership filter. The personal device is completely wiped including personal photos, contacts, and apps. Root cause: Wipe on personal/BYOD devices should use Retire (not Wipe) — Retire removes only the work profile and corporate data while preserving personal data. Always filter by "Corporate" ownership before issuing Wipe actions.

Key Mechanisms

- Core function: The wipe action performs a factory reset on a device, removing all data and restoring it to out-of-box state. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Semester-end laptop redeployment - Decision clue: Industry: Education

Review Path

Steps:

1. Go to Intune admin center → Devices → All devices 2. Select device(s) to wipe (corporate devices only) 3. Click "Wipe" remote action 4. Configure options: - "Wipe device, but keep enrollment" → Check for quick redeployment - Leave unchecked for full wipe (remove enrollment) 5. For lost/stolen devices: - Choose full wipe - Device will wipe when next online 6. Confirm action 7. Monitor status: - Device shows "Wipe pending" - Removed from inventory after completion 8. For redeployment: - After standard wipe, device re-appears in Intune - Ready for Autopilot or new assignment

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/devices-wipe https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-retire https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-management

Explanation

Bulk device actions allow administrators to perform remote operations on multiple devices simultaneously, saving time and ensuring consistency. Actions include sync, restart, retire, wipe, and custom script execution. Bulk actions can target up to 100 devices per operation and use filters for precise targeting.

Think of it as: One command, many devices—like conducting an orchestra instead of individual instruments

Key Mechanics: - Max devices per bulk action: 100 - Supported actions: Sync, Restart, Retire, Wipe, Custom scripts - Filter support: Target devices by group, OS, ownership - Asynchronous processing: Actions queue and execute over time - Status tracking: Overall progress per action - Error handling: Failed actions reported individually - Audit logs: All bulk actions logged for compliance

Examples

Example 1 — [Success] Bulk restart for Patch Tuesday compliance After deploying critical security updates on Patch Tuesday, IT uses bulk device actions to restart all Windows devices pending reboot. They filter by "Pending restart" status, select 100 devices at a time, configure a 30-minute grace period with a user message, and execute the bulk restart action in 5 batches to cover 500 devices. Compliance reporting shows 95% of devices rebooted and applied updates within 2 hours.

Example 2 — [Blocked] Bulk wipe exceeds 100-device limit An admin tries to bulk wipe 350 devices returned from a site closure by selecting all 350 devices at once. The Intune portal shows an error that bulk actions are limited to 100 devices. Root cause: Intune bulk device actions are capped at 100 devices per operation — for larger operations, the admin must run multiple batches of up to 100 devices each, or use the Microsoft Graph API to script the operation across all devices.

Key Mechanisms

- Core function: Bulk device actions allow administrators to perform remote operations on multiple devices simultaneously, saving time and ensuring consistency. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Bulk restart for Patch Tuesday compliance - Decision clue: Industry: Large Enterprise

Review Path

Steps:

1. Navigate to Intune admin center → Devices → All devices 2. Click "Bulk device action" (top menu) 3. Select action type: - Sync - Restart - Retire - Wipe 4. Choose devices: - Use filters to target specific devices - Or browse and select manually (max 100) 5. Configure action-specific settings: - Restart: Grace period, message - Wipe: Retain enrollment option 6. Review and start action 7. Monitor progress: - Notification area shows action ID - Click to view detailed status 8. Export results for reporting 9. For larger sets, repeat in batches of 100

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/bulk-device-actions https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-management https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-bulkaction

Explanation

Security intelligence updates (also called signature updates) keep Microsoft Defender Antivirus current with the latest threat definitions. Intune can force an immediate update of security intelligence on managed devices, ensuring protection against newly discovered malware without waiting for automatic updates.

Think of it as: Giving your antivirus a booster shot of the latest threat knowledge

Key Mechanics: - Security intelligence: Definitions of known malware, viruses, threats - Update frequency: Normally daily automatic updates - Manual update: Force immediate definition refresh - Works on: Windows devices with Defender Antivirus - No restart required: Updates apply immediately - Update source: Microsoft Update, WSUS, or file share - Reporting: View security intelligence version per device

Examples

Example 1 — [Success] Zero-day threat response A new zero-day vulnerability is disclosed. Microsoft releases updated Defender definitions within hours. The security team immediately issues a bulk "Update Defender security intelligence" action across all 2,000 Windows devices in Intune — running 20 batches of 100 devices. No restarts required — definitions apply immediately. Within 2 hours, Intune's antivirus report confirms 98% of devices are running the updated definitions.

Example 2 — [Blocked] Manual update action has no effect — third-party AV installed An admin issues "Update Defender security intelligence" for 50 devices but the action shows "Not applicable" on 20 of them. Root cause: The "Update Defender security intelligence" action only works on devices running Microsoft Defender Antivirus as the active antivirus. Devices where a third-party antivirus (e.g., Symantec, McAfee) has taken over the active AV role disable Defender's real-time protection — the update action has no effect on these devices.

Key Mechanisms

- Core function: Security intelligence updates (also called signature updates) keep Microsoft Defender Antivirus current with the latest threat definitions. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Zero-day threat response - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Verify devices use Microsoft Defender Antivirus 2. For single device: - Intune → Devices → Select device - Click "Update Defender security intelligence" 3. For bulk update: - Intune → Devices → All devices → "Bulk device action" - Select "Update Defender security intelligence" - Choose devices (up to 100) or use filters - Execute action 4. Monitor progress: - Check action status in notifications - View device properties for definition version 5. Verify using reports: - Intune → Reports → Antivirus status - Filter by definition age 6. For automation: - Use Graph API to trigger updates - Schedule during high-alert periods

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/update-defender-security-intelligence https://learn.microsoft.com/en-us/mem/intune/protect/antivirus-microsoft-defender-settings-windows https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-antivirus-updates

Explanation

BitLocker key rotation allows administrators to remotely regenerate recovery keys for encrypted Windows devices. This enhances security when keys may be compromised (e.g., departing employee, suspected breach) or as a routine security practice. The new key is escrowed to Entra ID or Intune for secure recovery.

Think of it as: Changing the locks on a device without ever touching it

Key Mechanics: - Rotates recovery key while keeping data encrypted - Device must be online and running Windows 10/11 - New key escrowed to Entra ID/Intune automatically - Old key invalidated after rotation - User may need to restart to complete process - Supported on: Windows devices with BitLocker enabled - Requires TPM 2.0 for best experience

Examples

Example 1 — [Success] Post-contractor key rotation After a contractor with access to sensitive devices departs, IT issues a bulk "Rotate BitLocker recovery keys" action on all devices they were assigned access to. Each device generates a new recovery key, escrows it to Entra ID, and invalidates the old key. The contractor's knowledge of any previous recovery key is now useless — the device data remains encrypted and only the new key (stored in Entra ID) can recover it.

Example 2 — [Blocked] Key rotation fails on device without TPM An admin issues BitLocker key rotation on a fleet that includes a few legacy devices without TPM chips. The rotation action returns "Failed" for those devices in the Intune action report. Root cause: BitLocker recovery key rotation requires the device to have a TPM — devices using the "Allow BitLocker without compatible TPM" exception use a password-based protector and cannot perform automated key rotation via Intune. These devices require manual key rotation.

Key Mechanisms

- Core function: BitLocker key rotation allows administrators to remotely regenerate recovery keys for encrypted Windows devices. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Post-contractor key rotation - Decision clue: Industry: Government Agency

Review Path

Steps:

1. Verify BitLocker is enabled and keys escrowed: - Check device configuration - Confirm keys in Entra ID (devices → BitLocker keys) 2. For single device: - Intune → Devices → Select Windows device - Click "Rotate BitLocker recovery keys" 3. For bulk rotation: - Intune → Devices → All devices → "Bulk device action" - Select "Rotate BitLocker recovery keys" - Choose up to 100 devices - Execute 4. Monitor rotation: - Check device status for completion - Verify new key in Entra ID 5. For offline devices: - Rotation occurs when device next checks in - Monitor for 7 days, then follow up 6. Document rotation in audit logs

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/encrypt-devices#rotate-bitlocker-recovery-keys https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-rotate-bitlocker-keys https://learn.microsoft.com/en-us/entra/identity/devices/bitlocker-recovery-key-view

Explanation

BitLocker key rotation is the process of generating new recovery keys for encrypted devices while maintaining data encryption. This security best practice ensures that compromised or exposed recovery keys become invalid, preventing unauthorized access. Rotation can be manual (admin-initiated) or automatic based on policy.

Think of it as: Changing the emergency spare key for your house without changing the locks

Key Mechanics: - Recovery key ≠ encryption key: Encryption key stays same - New recovery key escrowed to Entra ID/Intune - Old key immediately invalidated - Device must be online with TPM 2.0 - Can be triggered per device or bulk - Automatic rotation: Configurable via policy (e.g., every 90 days) - No user impact during rotation (background process) - Recovery process unchanged for users

Examples

Example 1 — [Success] Automatic 90-day key rotation policy A hospital creates a BitLocker configuration profile in Intune with the "Rotate recovery passwords" setting configured to rotate every 90 days. All enrolled Windows devices automatically rotate their recovery keys on schedule — the new keys are escrowed to Entra ID. The HIPAA compliance audit shows 100% of devices with current (< 90 day) recovery keys without any manual IT intervention.

Example 2 — [Blocked] Automatic rotation stops after helpdesk views key A helpdesk agent views a device's BitLocker recovery key in Entra ID to help a locked-out user. Several days later the IT team notices the key shown in Entra ID is the same as before — they expected it to auto-rotate after key access. Root cause: Automatic post-access rotation requires the "Rotate BitLocker recovery passwords (Windows)" policy setting to be configured to rotate "After key retrieval" — this setting is NOT enabled by default. Without it, viewing the key does NOT trigger automatic rotation.

Key Mechanisms

- Core function: BitLocker key rotation is the process of generating new recovery keys for encrypted devices while maintaining data encryption. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Automatic 90-day key rotation policy - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Configure automatic rotation: - Intune → Devices → Configuration profiles → Create - Platform: Windows 10 and later - Settings catalog → Administrative Templates → BitLocker - Find "Rotate BitLocker recovery keys on every boot" or similar - Set to Enabled - Assign to device groups 2. For scheduled rotation: - Use PowerShell or Graph API to schedule quarterly - Or configure via custom OMA-URI 3. Monitor rotation status: - Check device properties for last rotation - Use Graph API to query key age 4. For manual rotation: - Follow steps in previous concept 5. Document rotation policy and schedule

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/encrypt-devices#bitlocker-recovery-key-rotation https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/key-rotation https://learn.microsoft.com/en-us/mem/intune/protect/bitlocker-policy

Explanation

Device query in Intune allows administrators to run Kusto Query Language (KQL) queries against live device data to quickly find specific information across their managed fleet. Queries can check installed applications, running processes, registry keys, file system, and more without needing to access each device individually.

Think of it as: Google for your devices—ask a question, get instant answers across all managed endpoints

Key Mechanics: - Real-time queries: Executes on devices at query time - KQL syntax: Similar to Azure Data Explorer - Supported data: Registry, files, processes, services, event logs, network, security - Results: Returned in seconds to minutes depending on scope - Scope: Single device, group, or all devices - Permissions: Requires specific Intune role permissions - Data retention: Results not stored, query must be re-run - Max results: 10,000 rows per query

Examples

Example 1 — [Success] Finding vulnerable software across the fleet A security team learns of a critical vulnerability in Adobe Reader v23.x. They run a KQL device query in Intune: DeviceFile | where FileName contains "AcroRd32.exe" | project DeviceName, FolderPath. The query returns 147 devices still running the vulnerable version. IT immediately creates a targeted deployment to update Adobe Reader on those exact devices — all remediated within hours of the disclosure.

Example 2 — [Blocked] Device query returns no data — IME missing An IT admin runs a KQL device query to check for a specific registry key across all devices. The query runs but returns 0 results even for devices they know have the configuration. Root cause: KQL device queries require the Intune Management Extension (IME) to be installed and active on each Windows device. Devices without IME (or with IME not reporting) do not respond to device queries — always check IME status on devices that return no query results.

Key Mechanisms

- Core function: Device query in Intune allows administrators to run Kusto Query Language (KQL) queries against live device data to quickly find specific information across their managed fleet. - Category fit: This concept belongs to device management and security and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Finding vulnerable software across the fleet - Decision clue: Industry: IT Operations

Review Path

Steps:

1. Navigate to Intune admin center → Devices → All devices 2. Select a device or group (optional) 3. Click "Device query" in top menu 4. Write KQL query: - Start with table name (DeviceInfo, DeviceFile, etc.) - Use where, project, extend, summarize operators - Example: DeviceInfo | where OSVersion contains "10.0.19044" | project DeviceName, Manufacturer, LastCheckIn 5. Select scope: - Current device (if started from device) - All devices - Specific group 6. Click "Run query" 7. View results in grid 8. Export to CSV or copy results 9. Save query for reuse (copy to notepad) 10. Schedule recurring queries via Graph API/PowerShell

Docs: https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-query https://learn.microsoft.com/en-us/mem/intune/remote-actions/device-query-kql-reference https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

Explanation

Adding a Win32 app to Intune enables deployment of traditional Windows applications (EXE, MSI, PowerShell scripts) to managed devices through the Microsoft Intune admin center. Win32 apps support complex installation commands, detection rules, dependencies, and supersedence—making them the preferred method for deploying enterprise line-of-business applications. The app must first be packaged using the Microsoft Win32 Content Prep Tool before upload.

Think of it as: Adding a Win32 app is like uploading a software package to a cloud delivery service—you specify how to install it, how to detect if it's already there, and who should receive it.

Key Mechanics: - Win32 apps packaged as .intunewin files (contains source files and metadata) - Installation commands support switches like /quiet, /norestart, /install - Detection rules verify installation using file, registry, MSI, or script checks - Dependencies ensure required apps install first - Supersedence replaces older app versions automatically

Examples

Example 1 — [Success] Legacy ERP deployment with SQL Express dependency A manufacturing company deploys a legacy ERP system (Win32 app) with SQL Express configured as a dependency. Intune installs SQL Express first, then the ERP installer runs with /VERYSILENT /NORESTART flags. A registry detection rule confirms installation. All 200 factory devices receive the app silently during the maintenance window.

Example 2 — [Blocked] Win32 app never installs — IME missing on device An admin deploys a Win32 app as Required to a device group. After 24 hours, 30 devices still show "Not installed" status with no error. Investigation reveals those devices are missing the Intune Management Extension (IME). Root cause: Win32 apps require the Intune Management Extension to be installed on each Windows device — without IME, the app package is never downloaded or executed. IME installs automatically when Intune first detects a PowerShell script, Win32 app, or proactive remediation, but can be absent on older enrolled devices.

Key Mechanisms

- Core function: Adding a Win32 app to Intune enables deployment of traditional Windows applications (EXE, MSI, PowerShell scripts) to managed devices through the Microsoft Intune admin center. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Legacy ERP deployment with SQL Express dependency - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Run Microsoft Win32 Content Prep Tool on source folder to create .intunewin 2. Sign in to Microsoft Intune admin center (https://intune.microsoft.com) 3. Navigate to Apps → All apps → Add 4. Select "Windows app (Win32)" from the App type list 5. Click "Select app package file" and upload your .intunewin 6. Fill app information: Name, Description, Publisher, Category, Icon 7. On Program tab: enter Install command (e.g., setup.exe /quiet) and Uninstall command 8. Configure Detection rules (choose manual or use rules) 9. Add Dependencies and Supersedence if needed 10. Assign to groups and review + create

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-add https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-app-management https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-prepare

Explanation

Adding apps to Intune is the process of uploading application packages and metadata to the Intune cloud so they become available for deployment. Intune supports multiple app types: Store apps (Microsoft Store, Apple App Store, Google Play), line-of-business (LOB) apps (custom .msi, .appx, .ipa), built-in apps (Office, Edge), and Win32 apps. Each app type requires different preparation and configuration before it can be assigned to users or devices.

Think of it as: Adding apps to Intune is like stocking shelves in a warehouse—you bring in products from different suppliers (stores, developers), tag them with information, and organize them for later distribution.

Key Mechanics: - Store apps require synchronization with app stores (Microsoft Store for Business, Apple Business Manager) - LOB apps need code signing and proper file formats - Web apps are created as links to internal or external URLs - Built-in apps are pre-configured and ready to assign - iOS/iPadOS LOB apps require .ipa files with valid provisioning profiles

Examples

Example 1 — [Success] Multi-platform app onboarding A healthcare organization adds EpicHaiku (iOS App Store app via Apple Business Manager), a custom Android patient portal (.apk LOB app), and Microsoft Edge (built-in app) to Intune in a single afternoon. Each app type follows the appropriate upload path — iOS requires VPP token sync, Android LOB uploads the APK directly, and Edge is selected from the built-in apps catalog. All three are assigned to their respective platform device groups.

Example 2 — [Blocked] iOS LOB app rejected — invalid provisioning profile An admin uploads an iOS LOB .ipa file to Intune. The app appears in the console but when it deploys to devices, installation fails with a certificate/provisioning error. Root cause: iOS LOB apps require a valid Apple development or enterprise distribution certificate and an active provisioning profile in the .ipa — if the provisioning profile has expired or the certificate is untrusted by Apple, Intune can upload the file but the device will reject installation.

Key Mechanisms

- Core function: Adding apps to Intune is the process of uploading application packages and metadata to the Intune cloud so they become available for deployment. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Multi-platform app onboarding - Decision clue: Industry: Retail

Review Path

Steps:

1. Sign in to Microsoft Intune admin center 2. Go to Apps → All apps → Add 3. Select app type based on platform and source: - Microsoft Store app (Windows) - iOS store app / Android store app - Windows app (Win32) or Windows app (MSI) - iOS/iPadOS LOB app / Android LOB app - Web link - Built-in app (Microsoft 365 Apps, Edge) 4. Follow platform-specific wizard to upload or select app 5. Configure app information: name, description, icon, category 6. Set platform-specific settings (install commands, detection rules, minimum OS) 7. Click Create to add app to inventory

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-add https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-microsoft https://learn.microsoft.com/en-us/mem/intune/apps/lob-apps-windows

Explanation

Deploying Microsoft 365 Apps (formerly Office 365 ProPlus) through Intune enables centralized management of Word, Excel, PowerPoint, and other Office applications across Windows devices. Intune provides a built-in app type specifically for Microsoft 365 Apps, allowing administrators to configure installation options, update channels, and exclusion of specific apps (like Access or Publisher). Deployment can target users or devices with streamlined XML-based configuration or the simplified Intune UI.

Think of it as: Microsoft 365 Apps deployment is like setting up a standardized office suite package—you choose which apps to include, how they update, and who gets them.

Key Mechanics: - Built-in Microsoft 365 Apps app type simplifies configuration - Update channels control feature delivery pace (Current, Monthly Enterprise, Semi-Annual) - Apps can be excluded individually (e.g., remove Skype for Business) - Architecture selection (32-bit vs 64-bit) based on device compatibility - Installation can be user-based (follows user) or device-based (machine-wide) - Supports shared computer activation for RDS or multi-user scenarios

Examples

Example 1 — [Success] Department-specific Office suites A consulting firm creates two Intune M365 Apps deployments: "Consultant Suite" (all apps, Monthly Enterprise Channel, 64-bit) and "Staff Suite" (Word, Excel, Outlook only, Semi-Annual Channel). Both deployments exclude Skype for Business. Consultants get latest features monthly; staff receive stable twice-yearly updates. IT controls the rollout entirely through Intune.

Example 2 — [Blocked] Intune deployment removes update channel pinning from ODT A company previously managed Microsoft 365 Apps with the Office Deployment Tool (ODT), pinning all devices to Monthly Enterprise Channel v2308. After switching to Intune for M365 Apps deployment, the Intune deployment overrides the ODT channel configuration, and devices start pulling updates from the channel Intune specifies. Root cause: M365 Apps deployment via Intune removes Click-to-Run source control previously set by ODT — if channel pinning to a specific build version is required, use ODT with a servicing profile or set the channel explicitly in the Intune deployment configuration.

Key Mechanisms

- Core function: Deploying Microsoft 365 Apps (formerly Office 365 ProPlus) through Intune enables centralized management of Word, Excel, PowerPoint, and other Office applications across Windows devices. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Department-specific Office suites - Decision clue: Industry: Consulting

Review Path

Steps:

1. In Intune admin center, go to Apps → All apps → Add 2. Select "Microsoft 365 Apps (Windows)" from app type 3. Choose deployment method: "Configure using Intune" (simplified) or "Upload configuration XML" 4. If simplified: select Suite (Microsoft 365 Apps for enterprise), apps to include/exclude 5. Configure architecture (32-bit recommended for compatibility, 64-bit for large datasets) 6. Choose update channel (Current, Monthly Enterprise, Semi-Annual) 7. Set other options: remove MSI versions, shared computer activation, installation source 8. Complete app information (name, description, category) 9. Add assignments (Required or Available groups) 10. Review and create

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-office365 https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-office365-windows https://learn.microsoft.com/en-us/deployoffice/overview-office-deployment-tool

Explanation

Adding Microsoft 365 Apps to Windows devices through Intune involves configuring and deploying the Office suite as a managed application. Intune provides a dedicated Microsoft 365 Apps app type that simplifies the process compared to traditional MSI-based deployment. Administrators can specify which Office applications are installed, the update channel, and installation preferences—all without managing complex XML files manually, though advanced users can still upload custom XML configurations.

Think of it as: Adding Microsoft 365 Apps is like ordering a customized office supply kit—you choose which tools go in the box, how often you get new supplies, and who delivers them.

Key Mechanics: - Built-in wizard eliminates need for manual Office Deployment Tool XML creation - Apps can be toggled on/off individually (Word, Excel, PowerPoint, Outlook, Access, etc.) - Update channels determine how frequently feature updates arrive - Version pruning removes older installer files to save space - Language packs can be included during initial deployment - Integration with Microsoft 365 Apps admin center for advanced management

Examples

Example 1 — [Success] Remote workforce standardization via Autopilot A company adds Microsoft 365 Apps (Word, Excel, Outlook, Teams) as a Required app in Intune and includes it in the Enrollment Status Page app list. New laptops provisioned via Autopilot automatically install the full suite during ESP before the user reaches the desktop. Every employee has consistent Office tools on first login regardless of their location.

Example 2 — [Blocked] Microsoft 365 Apps deployment fails after ODT previously configured channels A company migrated from ODT to Intune for Microsoft 365 Apps management. After the Intune deployment runs, some devices start showing the wrong update channel. Root cause: When Intune takes over M365 Apps management, it overrides ODT-configured channels. If ODT set a specific channel build, Intune's deployment configuration must explicitly specify the same channel — if left at default, Intune will use the channel defined in the Intune policy, not the ODT channel.

Key Mechanisms

- Core function: Adding Microsoft 365 Apps to Windows devices through Intune involves configuring and deploying the Office suite as a managed application. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Remote workforce standardization via Autopilot - Decision clue: Industry: Nonprofit

Review Path

Steps:

1. Sign in to Microsoft Intune admin center 2. Navigate to Apps → All apps → Add 3. Select "Microsoft 365 Apps (Windows)" from app type list 4. On Suite Configuration page, select "Microsoft 365 Apps for enterprise" 5. Under Apps, check the boxes for applications to install (Word, Excel, PowerPoint, Outlook, etc.) 6. Uncheck any apps to exclude from installation 7. Set Architecture to 32-bit (default) or 64-bit based on organizational needs 8. Choose Update Channel from dropdown (Monthly Enterprise recommended for most organizations) 9. Configure Additional settings: remove existing Office MSI, auto-accept EULA, etc. 10. Complete app information (name, description) and assign to groups

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-office365-windows https://learn.microsoft.com/en-us/deployoffice/overview-update-channels https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-office365

Explanation

Configuring policies for Office apps in Intune allows administrators to enforce security settings, feature controls, and user preferences across Word, Excel, PowerPoint, Outlook, and other Microsoft 365 applications. These policies are delivered through Administrative Templates (ADMX) and the Office Cloud Policy Service, enabling consistent configuration regardless of where users access Office—managed devices or unmanaged personal devices. Policies control everything from macro security and file save locations to privacy settings and default font styles.

Think of it as: Office policies are like workplace rules for a shared office—they set boundaries (security), provide defaults (templates), and ensure everyone follows the same procedures (compliance).

Key Mechanics: - Administrative Templates in Intune deliver ADMX-backed policies to Windows devices - Office Cloud Policy Service applies settings to Office on any device (Windows, Mac, mobile, web) - Policies can target users (follows identity) or devices (machine-wide) - Settings include security (macro protection, ActiveX controls), privacy (telemetry), and features (default file save locations) - Policy conflicts resolved by most restrictive or last write depending on setting type

Examples

Example 1 — [Success] Government macro security enforcement A state government agency creates an Administrative Templates policy in Intune disabling all unsigned macros in Office documents and setting OneDrive for Business as the default save location. The policy is assigned to all employees. When users try to run an unsigned macro, Office blocks it silently. Documents save to OneDrive automatically — compliance audit confirms all settings applied.

Example 2 — [Blocked] Office Cloud Policy doesn't apply to unmanaged device An admin configures an Office Cloud Policy to enforce macro restrictions and assigns it to a user group. Managed Intune devices correctly receive the policy. A contractor's personal laptop (not Intune-enrolled) continues to allow macros. Root cause: Administrative Templates in Intune only apply to Intune-managed Windows devices. To extend Office policy to unmanaged devices (any device where the user signs into Office), use the Office Cloud Policy Service (config.office.com) — it applies policies based on user identity, not device management state.

Key Mechanisms

- Core function: Configuring policies for Office apps in Intune allows administrators to enforce security settings, feature controls, and user preferences across Word, Excel, PowerPoint, Outlook, and other Microsoft 365 applications. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Government macro security enforcement - Decision clue: Industry: Government Agency

Review Path

Steps:

1. For Administrative Templates (managed Windows devices): - In Intune admin center, go to Devices → Configuration profiles → Create profile - Platform: Windows 10 and later, Profile type: Templates → Administrative Templates - Configure settings (e.g., File Save location, Macro security) - Assign to user or device groups

2. For Office Cloud Policy Service (all devices): - Go to Microsoft 365 Apps admin center (config.office.com) - Navigate to Customization → Policy Management - Create new policy configuration with desired settings - Assign to Azure AD groups - Policies apply to Office on any device where user signs in

3. Verify policy application using Office apps → Account → About → View policies

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/administrative-templates-windows https://learn.microsoft.com/en-us/deployoffice/admincenter/overview-office-cloud-policy-service https://learn.microsoft.com/en-us/deployoffice/security-overview-microsoft-365-apps

Explanation

Changing the Office update channel with Group Policy allows administrators to control how frequently Microsoft 365 Apps receive feature updates across the organization. The update channel determines the cadence of new features—Current Channel (monthly), Monthly Enterprise Channel (monthly with predictable release), or Semi-Annual Enterprise Channel (twice yearly). Group Policy provides centralized control for domain-joined devices, while Intune policies achieve the same for cloud-managed devices.

Think of it as: Update channels are like magazine subscriptions—some want monthly issues (Current), some want quarterly (Monthly Enterprise), and some want only twice-yearly summaries (Semi-Annual).

Key Mechanics: - Group Policy setting located under Computer Configuration → Administrative Templates → Microsoft Office 2016 → Updates - Policy "Update Channel" accepts channel IDs (e.g., Current, MonthlyEnterprise, SemiAnnual) - Changes take effect after gpupdate and Office restarts - Device must have internet access to Microsoft CDN for updates - Office version determines which channels are available (Microsoft 365 Apps vs perpetual) - Policy overrides user-configured update settings

Examples

Example 1 — [Success] Staged rollout for trading floor stability A bank creates two GPOs: one setting Semi-Annual Enterprise Channel for trading floor OUs and another setting Monthly Enterprise Channel for marketing. After running gpupdate /force on client devices, Office updates shift to the configured cadence. Trading floor stays stable with twice-yearly updates; marketing gets new features monthly.

Example 2 — [Blocked] Update channel setting ignored after Intune conflict An admin uses Group Policy to set Semi-Annual Channel for a device. The device is also Intune-enrolled with an Intune configuration profile setting a different update channel. The Intune policy wins and the GPO setting is overridden. Root cause: When a device is co-managed (both GPO and Intune), Intune policies take precedence for Office update channel settings on cloud-managed workloads. Resolve by removing the conflicting Intune channel setting or adjusting co-management workload assignments.

Key Mechanisms

- Core function: Changing the Office update channel with Group Policy allows administrators to control how frequently Microsoft 365 Apps receive feature updates across the organization. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Staged rollout for trading floor stability - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Open Group Policy Management Console on domain controller or management workstation 2. Create new GPO or edit existing one linked to target OUs 3. Navigate to: Computer Configuration → Policies → Administrative Templates → Microsoft Office 2016 → Updates 4. Find policy named "Update Channel" 5. Set to "Enabled" 6. In Options, select desired channel from dropdown: - Current Channel - Monthly Enterprise Channel - Semi-Annual Enterprise Channel - (Other channels available depending on Office version) 7. Click OK and close Group Policy Editor 8. Link GPO to appropriate Organizational Units 9. On client devices, run gpupdate /force and restart Office applications

Docs: https://learn.microsoft.com/en-us/deployoffice/admincenter/configure-update-settings https://learn.microsoft.com/en-us/deployoffice/updates/overview-update-channels https://learn.microsoft.com/en-us/deployoffice/updates/change-update-channels

Explanation

Administrative Template files (ADMX/ADML) for Microsoft 365 Apps are policy definition files that enable centralized management of Office settings through Group Policy. ADMX files contain the policy definitions in a language-neutral format, while ADML files provide language-specific user interface text. These templates allow administrators to configure hundreds of Office settings—security, privacy, feature availability, file save locations, and more—across domain-joined Windows devices. The templates are regularly updated by Microsoft to support new Office features.

Think of it as: ADMX/ADML files are like instruction manuals for Group Policy—they tell Group Policy what settings exist for Office and how to display them in the editor.

Key Mechanics: - ADMX files stored in PolicyDefinitions folder (SYSVOL for central store) - ADML files provide localized text for each supported language - Templates cover Word, Excel, PowerPoint, Outlook, Access, Publisher, and shared Office components - New templates released with major Office updates (download from Microsoft Download Center) - Central Store in SYSVOL ensures all domain controllers use same template versions - Intune also supports ADMX-backed policies for cloud-managed devices

Examples

Example 1 — [Success] Central Store update for new Office policy settings After Microsoft releases new ADMX templates for Microsoft 365 Apps v2308, an admin downloads the latest ADMX/ADML files and copies them to the SYSVOL PolicyDefinitions Central Store, overwriting the previous versions. All IT admins opening Group Policy Editor across the domain now see the new Office policy options for macro security and privacy settings — no changes needed on individual machines.

Example 2 — [Blocked] Policy settings missing from Group Policy Editor An IT admin tries to configure an Office security setting in Group Policy but cannot find the Microsoft Office 2016 node under Administrative Templates. Root cause: The ADMX templates for Microsoft 365 Apps have not been copied to the Central Store (or the local PolicyDefinitions folder on the editing machine). Group Policy Editor only shows settings for templates that have been added — without the Office ADMX files, Office policies are invisible to the editor.

Key Mechanisms

- Core function: Administrative Template files (ADMX/ADML) for Microsoft 365 Apps are policy definition files that enable centralized management of Office settings through Group Policy. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Central Store update for new Office policy settings - Decision clue: Industry: Enterprise Manufacturing

Review Path

Steps:

1. Download latest Administrative Template files (ADMX/ADML) for Microsoft 365 Apps from Microsoft Download Center 2. On a domain controller, create Central Store if not exists: - Navigate to \domainSYSVOLdomainPolicies - Create folder named "PolicyDefinitions" 3. Copy all downloaded ADMX files to PolicyDefinitions folder 4. For each language needed, create subfolder in PolicyDefinitions (e.g., en-US, fr-FR) 5. Copy corresponding ADML files to language subfolders 6. Verify by opening Group Policy Management Console → Edit any GPO → Administrative Templates → Microsoft Office 2016 7. To update templates later, repeat process with newer versions, overwriting existing files 8. For Intune-based ADMX management, upload custom ADMX files to Intune Settings Catalog

Docs: https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-central-store-domain https://www.microsoft.com/en-us/download/details.aspx?id=49030 https://learn.microsoft.com/en-us/mem/intune/configuration/administrative-templates-windows

Explanation

Deploying Microsoft 365 Apps as part of a Windows Autopilot deployment integrates Office installation into the out-of-box experience (OOBE), ensuring new devices arrive fully configured with the productivity suite ready for users. This is achieved by adding Microsoft 365 Apps as a required app in Intune, which then installs during the Enrollment Status Page (ESP) phase of Autopilot. Organizations can combine Intune's Microsoft 365 Apps deployment with the Office Deployment Tool (ODT) or Office Customization Tool (OCT) for advanced configuration requirements.

Think of it as: Autopilot with Office is like buying a pre-furnished apartment—the device arrives with all the essential software (Office) already set up and waiting for the user.

Key Mechanics: - Microsoft 365 Apps added as Intune app, assigned to Autopilot device group - Installation occurs during ESP if assigned as Required with device context - ODT/XML configuration enables advanced settings (languages, update paths, exclusion) - Office Customization Tool (OCT) provides web-based XML generation - Installation source can be Microsoft CDN or local network share - Device must have internet connectivity during Autopilot for CDN-based install

Examples

Example 1 — [Success] Zero-touch Office deployment for remote employees A startup shipping 500 laptops to remote employees includes Microsoft 365 Apps as a Required app (device context) in their Autopilot Enrollment Status Page configuration. Employees power on, join Wi-Fi, and Autopilot installs Windows, apps, and M365 Apps automatically. Employees reach the desktop with Office installed and activated — no IT touchpoints required.

Example 2 — [Blocked] Autopilot times out before Office finishes installing A company configures M365 Apps as Required during ESP. For devices on slow internet connections, the Office download (3–4 GB) exceeds the ESP timeout. Autopilot fails with "Something went wrong" and the device rolls back. Root cause: ESP timeouts (default 60 minutes, configurable up to 90) may not be long enough for M365 Apps on slow connections. Increase the ESP timeout to 90+ minutes or pre-stage Office via PPKG. Alternatively, switch M365 Apps to "Available" (not blocking ESP) and let it install post-OOBE.

Key Mechanisms

- Core function: Deploying Microsoft 365 Apps as part of a Windows Autopilot deployment integrates Office installation into the out-of-box experience (OOBE), ensuring new devices arrive fully configured with the productivity suite ready for users. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Zero-touch Office deployment for remote employees - Decision clue: Industry: Technology Startup

Review Path

Steps:

1. Generate Office configuration XML using Office Customization Tool (https://config.office.com) or Office Deployment Tool 2. In Intune admin center, go to Apps → All apps → Add 3. Select "Microsoft 365 Apps (Windows)" as app type 4. Choose "Upload configuration XML" option 5. Upload your XML file from OCT/ODT 6. Complete app information (name, description) 7. Assign app as "Required" to the device group used for Autopilot deployment 8. Ensure Enrollment Status Page profile is configured to track app installation 9. Verify in Autopilot deployment profile that "Allow users to enroll in Intune" is enabled 10. Test deployment with a pilot device before broad rollout

Docs: https://learn.microsoft.com/en-us/mem/autopilot/windows-autopilot-scenarios https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-office365 https://learn.microsoft.com/en-us/deployoffice/overview-office-deployment-tool

Explanation

The Office Customization Tool (OCT) is a web-based GUI at config.office.com that enables administrators to visually construct Office Deployment Tool XML configuration files without manually writing XML schema. The OCT interface exposes the full Office Deployment Tool XML schema through visual controls: product selection (Microsoft 365 Apps for Enterprise, Business, or individual apps like Project and Visio), excluded applications (deselect Access, Publisher), update channel (Current, Monthly Enterprise, Semi-Annual), architecture (32-bit or 64-bit), languages and language proofing packs, and advanced options including display level (full, basic, or none for silent install), logging verbosity, whether to remove MSI-based Office versions, EULA acceptance, shared computer activation, and PIN and product key settings. The OCT also supports generating configurations for the /customize operation to modify existing Office installations. Understanding the XML structure that OCT generates is important for MD-102 because some questions test knowledge of specific XML attributes: SourcePath (local network share), UpdatePath (update source), Channel (update channel identifier), and the Product ID (O365ProPlusRetail, O365BusinessRetail). Priority logic when multiple configuration files are involved follows ODT processing order — the last-specified value for any duplicate attribute wins. The generated XML is the input for the Office Deployment Tool (setup.exe /configure configuration.xml), creating a clear two-tool workflow: OCT generates, ODT executes.

Examples

Example 1 — [Success] Generating custom Office XML with OCT An IT admin needs to deploy Microsoft 365 Apps with 64-bit, Monthly Enterprise Channel, French language pack, no Access or Publisher, and removal of existing Office 2019 MSI. They open config.office.com, use the OCT visual interface to configure all these settings, and export the configuration.xml in minutes without writing any XML manually. They upload the XML to the Intune Microsoft 365 Apps deployment wizard for deployment.

Example 2 — [Blocked] Wrong Product ID causes activation failure An admin manually edits an OCT-generated XML and changes the Product ID to "O365BusinessRetail" but the organization's licenses are Microsoft 365 Apps for Enterprise. The Office installation completes but activation fails. Root cause: The Product ID in the XML must match the actual license type — "O365ProPlusRetail" for Microsoft 365 Apps for Enterprise, "O365BusinessRetail" for Microsoft 365 Apps for Business. Mismatched Product IDs cause installation to complete but licensing to fail.

Key Mechanisms

- Core function: The Office Customization Tool (OCT) is a web-based GUI at config.office.com that enables administrators to visually construct Office Deployment Tool XML configuration files without manually writing XML schema. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Generating custom Office XML with OCT - Decision clue: An IT administrator needs to deploy Microsoft 365 Apps with specific settings to 1,000 devices: 64-bit, Monthly Enterprise channel, no Access or Publisher, remove old MSI Office.

Review Path

Use the Office Customization Tool:

1. Open browser and navigate to https://config.office.com 2. Click Office Customization Tool 3. Select products to install (Microsoft 365 Apps suite) 4. Choose included apps and deselect unwanted ones 5. Select update channel, architecture (64-bit), and languages 6. Configure advanced settings (remove MSI, accept EULA, etc.) 7. Export configuration file → downloads configuration.xml 8. Use with Office Deployment Tool: setup.exe /configure configuration.xml

Learn more: https://learn.microsoft.com/en-us/deployoffice/admincenter/overview-office-customization-tool

Explanation

The Office Deployment Tool (ODT) is a command-line tool that downloads and deploys Microsoft 365 Apps to client computers. It provides granular control over Office installations—specifying which products and languages to install, update settings, and installation sources. The ODT uses an XML configuration file to define all installation parameters, making it ideal for large-scale deployments, offline installations, and integration with management tools like Intune or Configuration Manager.

Think of it as: The Office Deployment Tool is like a custom installer builder—you write a recipe (XML), and ODT follows it exactly to prepare and serve Office to your devices.

Key Mechanics: - ODT downloads Office source files to a local network share (for offline deployment) - XML configuration controls products, languages, updates, and installation behavior - Supports 32-bit and 64-bit architecture selection - Can remove existing Office versions before installing - Works with setup.exe command-line parameters for silent deployment - Integrated with Intune via XML upload option for Microsoft 365 Apps app type

Examples

Example 1 — [Success] Offline Office deployment for school district A school district with limited bandwidth uses ODT to download Microsoft 365 Apps once to a central server (setup.exe /download configuration.xml), creating a local source. During summer break, IT deploys Office to 1,000 lab computers using the local source — all installs complete quickly without saturating internet links.

Example 2 — [Blocked] ODT /download fails — SourcePath points to CD-ROM location An admin runs ODT with /download but accidentally sets the SourcePath in the XML to a mapped drive that doesn't exist on the download machine. ODT reports an error and downloads nothing. Root cause: During /download mode, the SourcePath in the XML is the destination where ODT writes the installation files — it must be a writable local or UNC path that the running user has access to. A mapped drive letter that doesn't exist or lacks write permissions causes the download to fail.

Key Mechanisms

- Core function: The Office Deployment Tool (ODT) is a command-line tool that downloads and deploys Microsoft 365 Apps to client computers. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Offline Office deployment for school district - Decision clue: Industry: Education (K-12)

Review Path

Steps:

1. Download Office Deployment Tool from Microsoft Download Center 2. Extract setup.exe and sample XML files to a folder 3. Create or edit configuration.xml: - Use sample as template or generate via Office Customization Tool - Specify <Add> section with OfficeClientEdition, products, languages - Define <Updates> with update channel and path - Include <RemoveMSI> if removing old Office versions 4. For offline source: Run setup.exe /download configuration.xml 5. For deployment: Run setup.exe /configure configuration.xml 6. For Intune integration: Package ODT + XML as Win32 app 7. Test deployment on pilot devices before mass rollout

Docs: https://learn.microsoft.com/en-us/deployoffice/overview-office-deployment-tool https://learn.microsoft.com/en-us/deployoffice/office-deployment-tool-configuration-options https://www.microsoft.com/en-us/download/details.aspx?id=49117

Explanation

Deploying Microsoft 365 Apps from a local source means installing Office using installation files stored on a local network share rather than downloading from Microsoft's content delivery network (CDN) during installation. This approach conserves internet bandwidth, speeds up deployments, and ensures consistency when internet connectivity is limited. The Office Deployment Tool (ODT) is used to download the source files once to a network location, then clients install from that location using an XML configuration pointing to the local path.

Think of it as: Local source deployment is like having a library branch in your neighborhood instead of always ordering books from the central library—faster access and saves on shipping (bandwidth).

Key Mechanics: - ODT /download mode retrieves all Office installation files to specified network share - XML configuration points to local source path using <Add SourcePath="\\server\share"> - Clients must have network access to the source location during installation - Updates can also be served from local source using <Updates UpdatePath="\\server\updates"> - Supports multiple languages and product combinations in single source - Ideal for remote sites with limited internet or during large-scale rollouts

Examples

Example 1 — [Success] Remote site local source deployment An oil company ships an external drive with the ODT-downloaded Office source files to a remote drilling site. IT copies the source to a local server and creates an XML with SourcePath pointing to the local UNC path. All 200 field laptops install Office from the local server — the satellite internet link is never used for the install.

Example 2 — [Blocked] Local source deployment fails after Office source files expire An admin downloads Office source files to a local server in March for a June deployment. When IT finally runs the deployment in June, it fails with a "version not available" error. Root cause: Office Click-to-Run source files include version-specific builds — Microsoft eventually removes old builds from CDN validation. Additionally, if the local source folder is incomplete or the source version is incompatible with the client's OS, installation fails. Always use a fresh download close to the deployment date.

Key Mechanisms

- Core function: Deploying Microsoft 365 Apps from a local source means installing Office using installation files stored on a local network share rather than downloading from Microsoft's content delivery network (CDN) during installation. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Remote site local source deployment - Decision clue: Industry: Oil & Gas (Remote Sites)

Review Path

Steps:

1. Create configuration.xml for /download mode: <Configuration> <Add OfficeClientEdition="64" Channel="MonthlyEnterprise"> <Product ID="O365ProPlusRetail"> <Language ID="en-us" /> </Product> </Add> <Downloads Path="\\server\share\office_source" /> </Configuration>

2. Run ODT: setup.exe /download download-config.xml to populate source

3. Create deployment configuration.xml for clients: <Configuration> <Add OfficeClientEdition="64" Channel="MonthlyEnterprise" SourcePath="\\localserver\office_source"> <Product ID="O365ProPlusRetail"> <Language ID="en-us" /> </Product> </Add> <Updates Enabled="TRUE" UpdatePath="\\localserver\office_updates" /> <RemoveMSI /> </Configuration>

4. Deploy to clients: - Manual: setup.exe /configure deploy-config.xml - Intune: Package ODT + deploy-config.xml as Win32 app - ConfigMgr: Create application package with ODT command line

5. For updates: Periodically refresh source from CDN and replicate to local servers

Docs: https://learn.microsoft.com/en-us/deployoffice/deploy-from-a-local-source https://learn.microsoft.com/en-us/deployoffice/overview-office-deployment-tool https://learn.microsoft.com/en-us/deployoffice/update-office-from-local-source

Explanation

The Microsoft 365 Apps admin center (config.office.com) is a cloud-based portal for managing Microsoft 365 Apps across an organization. It provides centralized tools for inventory visibility, policy management (via Office Cloud Policy Service), customization (Office Customization Tool), update management, and health monitoring. Unlike Intune or Group Policy which focus on managed devices, the admin center can apply settings to Office on any device—corporate-managed, BYOD, Mac, mobile, or web—as long as the user signs in with their work account.

Think of it as: The Microsoft 365 Apps admin center is mission control for Office—you can see everything, configure everything, and troubleshoot issues from one dashboard, regardless of where Office is running.

Key Mechanics: - Inventory dashboard shows Office versions, channels, and add-ins across organization - Office Cloud Policy Service applies user-based policies to any device - Office Customization Tool generates XML for ODT-based deployments - Update management controls rollout pace and deadlines - Health dashboard monitors service incidents and client issues - Security recommendations highlight misconfigurations and risks

Examples

Example 1 — [Success] Add-in crash monitoring and remediation An admin notices in the Microsoft 365 Apps admin center (config.office.com) health dashboard that a critical Excel add-in has a 12% crash rate on the Monthly Enterprise Channel. They block the add-in organization-wide from the admin center while contacting the vendor. Once the vendor releases a fix, they re-enable the add-in. All this is done without touching individual devices.

Example 2 — [Blocked] OCPS policies not applying to office-only devices An admin creates an Office Cloud Policy Service policy to enforce macro restrictions, assigns it to a user group, and tests on corporate Windows laptops. The policies apply correctly. However, when the same users sign into Office on a shared, unmanaged kiosk device with no Microsoft account sign-in prompt, the policies don't apply. Root cause: OCPS policies require the user to be signed into Office with their Microsoft 365 work account on each session — if Office is configured for offline/shared use without sign-in, OCPS has no user identity to apply policies against.

Key Mechanisms

- Core function: The Microsoft 365 Apps admin center (config.office.com) is a cloud-based portal for managing Microsoft 365 Apps across an organization. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Add-in crash monitoring and remediation - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Go to https://config.office.com and sign in with admin credentials 2. Explore Inventory to see Office versions, add-ins, and devices 3. Set up Office Cloud Policy Service: - Go to Customization → Policy Management - Create new policy configuration - Add settings (e.g., macro security, file save locations) - Assign to Azure AD groups 4. Configure update management: - Go to Update → Update rings - Create rings with different channels and deadlines - Assign to user groups 5. Monitor Health dashboard for service issues 6. Review Security recommendations for potential improvements 7. Use Office Customization Tool under Deployment to generate XML for ODT

Docs: https://learn.microsoft.com/en-us/deployoffice/admincenter/office-365-admin-center https://learn.microsoft.com/en-us/deployoffice/admincenter/inventory https://learn.microsoft.com/en-us/deployoffice/admincenter/overview-office-cloud-policy-service

Explanation

The Office Cloud Policy Service (OCPS) is a component of the Microsoft 365 Apps admin center that enables administrators to apply policies to Microsoft 365 Apps across any device—corporate-managed, personal, Mac, mobile, or web—based on user identity rather than device management. Policies defined in OCPS roam with the user, ensuring consistent Office behavior regardless of where they sign in. This complements traditional device-based policies from Intune or Group Policy.

Think of it as: Office Cloud Policy Service is like a personal assistant that follows you—your Office settings (macro security, default save locations) are applied whether you're on your work PC, home Mac, or iPad.

Key Mechanics: - Policies applied based on Azure AD user or group membership - Works on Windows, Mac, iOS, Android, and Office for the web - Policies stored in the cloud, applied when user launches Office - Over 1,300 policy settings available (security, privacy, features, UI) - Can coexist with device-based policies (most restrictive or last applied wins) - No device enrollment required—works on BYOD and unmanaged devices

Examples

Example 1 — [Success] Cross-platform security policy for legal staff A law firm applies an Office Cloud Policy Service policy blocking internet-sourced macros and setting OneDrive for Business as the default save location. The policy is assigned to "All Attorneys" and "All Paralegals" Entra ID groups. Partners on iPads, associates on Windows laptops, and paralegals on personal Macs all receive the same macro restrictions when they sign into Office — no device enrollment required.

Example 2 — [Blocked] OCPS policy conflicts with Intune Administrative Templates policy An admin has both an OCPS policy and an Intune Administrative Templates policy that configure the same macro security setting — but with different values. The device-based Intune policy sets macros to "Block all," while the OCPS user policy sets macros to "Enable trusted publishers only." The effective setting on the enrolled device is unexpected. Root cause: When OCPS and device-based policies (GPO or Intune Administrative Templates) conflict on the same device, the most restrictive setting wins for security settings — but the evaluation order matters. Always document and test when both policy mechanisms are in use to avoid unpredictable results.

Key Mechanisms

- Core function: The Office Cloud Policy Service (OCPS) is a component of the Microsoft 365 Apps admin center that enables administrators to apply policies to Microsoft 365 Apps across any device—corporate-managed, personal, Mac, mobile, or web—based on user identity rather than device management. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Cross-platform security policy for legal staff - Decision clue: Industry: Legal Services

Review Path

Steps:

1. Go to https://config.office.com and sign in 2. Navigate to Customization → Policy Management 3. Click "Create" to start new policy configuration 4. Give policy a name (e.g., "Security Baseline") 5. Add settings: - Use search to find specific policies - Configure each setting as desired (Enabled/Disabled with options) 6. Review and save policy 7. Assign policy to Azure AD user groups 8. (Optional) Set precedence if multiple policies assigned 9. Users will receive policies within hours (faster if they restart Office) 10. Verify policy application via Office apps → Account → About → View policies

Docs: https://learn.microsoft.com/en-us/deployoffice/admincenter/overview-office-cloud-policy-service https://learn.microsoft.com/en-us/deployoffice/admincenter/office-cloud-policy-service https://learn.microsoft.com/en-us/deployoffice/admincenter/policy-configuration

Explanation

Deploying apps from platform-specific app stores through Intune enables organizations to distribute public applications from Microsoft Store, Apple App Store, and Google Play to managed devices. Intune synchronizes with these stores, allowing administrators to browse, approve, and assign store apps just like custom applications. Volume purchase programs (Microsoft Store for Business, Apple Business Manager, Managed Google Play) enable license management and silent installation on corporate devices.

Think of it as: Store app deployment is like having a company credit card for app stores—IT approves purchases and assigns apps to employees, who get them automatically without reimbursement requests.

Key Mechanics: - Intune integrates with store portals via connectors or APIs - Microsoft Store apps sync from Microsoft Store for Business (soon to be Windows Package Manager) - iOS store apps require Apple Business Manager or Volume Purchase Program - Android store apps use Managed Google Play for approval and distribution - Store apps can be assigned as Required (silent install) or Available (Company Portal) - License tracking ensures volume license counts aren't exceeded

Examples

Example 1 — [Success] Self-service medical apps via Company Portal A hospital connects Managed Google Play to Intune and approves "Nursing Drug Handbook" and "Medical Calculator." Both apps are assigned as Available to nurse device groups. Nurses open the Company Portal app on their Android tablets, find the approved apps, and install them on demand — no personal Google account or admin action required per device.

Example 2 — [Blocked] New Microsoft Store app unavailable in Intune — publisher not listed An admin tries to deploy a niche line-of-business app from the new Microsoft Store to Windows devices but the app doesn't appear in the Intune app list. Root cause: The new Microsoft Store (powered by winget) only surfaces apps that publishers have listed in the store — app availability depends entirely on the publisher's decision to list their app. Unlike Win32 or LOB apps that you package yourself, Store apps cannot be added if the publisher has not listed them in the Microsoft Store catalog.

Key Mechanisms

- Core function: Deploying apps from platform-specific app stores through Intune enables organizations to distribute public applications from Microsoft Store, Apple App Store, and Google Play to managed devices. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Self-service medical apps via Company Portal - Decision clue: Industry: Healthcare

Review Path

Steps:

For Microsoft Store apps: 1. In Intune admin center, go to Tenant administration → Connectors and tokens → Microsoft Store for Business 2. Enable sync with Microsoft Store for Business 3. In Microsoft Store for Business portal, purchase and manage apps 4. Apps sync to Intune automatically; assign as needed

For iOS store apps: 1. Configure Apple Business Manager integration in Intune (upload token) 2. Purchase volume licenses in Apple Business Manager 3. Sync apps to Intune, then assign

For Android store apps: 1. In Intune admin center, go to Apps → Android → Managed Google Play 2. Connect to Managed Google Play 3. Browse and approve apps in the Managed Google Play store 4. Approved apps appear in Intune for assignment

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-microsoft https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-ios https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-android

Explanation

Getting Android apps for Intune deployment involves connecting Intune to Managed Google Play, the enterprise app store for Android. This connection allows administrators to browse, approve, and sync public Android apps from Google Play, as well as publish private line-of-business (LOB) apps for internal use. Managed Google Play provides a curated experience where only approved apps are visible to users, preventing installation of unauthorized applications on corporate devices.

Think of it as: Managed Google Play is like a corporate app catalog—IT chooses which apps are available, and users can only see and install those approved selections.

Key Mechanics: - Intune binds to a Managed Google Play account via enrollment token - Public apps are searched and approved in the Managed Google Play web interface - Private LOB apps are published using Google Play Console or managed Google Play iframe - Web apps can be added as shortcuts on Android devices - System apps (built-in) can be enabled/disabled via configuration profiles - Apps sync to Intune within minutes after approval

Examples

Example 1 — [Success] Warehouse scanner app deployment via Managed Google Play A logistics company approves "Warehouse Inventory Pro" in Managed Google Play and uploads their custom barcode scanner APK as a private app. Both appear in Intune within minutes. IT assigns both as Required to the "All Scanner Devices" group — the apps install silently during Android Enterprise device enrollment with no user interaction needed.

Example 2 — [Blocked] Managed Google Play approval expires — app stops deploying An admin approved an Android app in Managed Google Play six months ago. After a Google Play policy update, the app's permissions changed and required re-approval. New devices enrolling no longer receive the app. Root cause: When an app in Managed Google Play updates its requested permissions, the approval lapses and must be renewed by the admin. Until re-approved, the app cannot be deployed to new devices. Admins should configure Managed Google Play to notify them when approvals need renewal.

Key Mechanisms

- Core function: Getting Android apps for Intune deployment involves connecting Intune to Managed Google Play, the enterprise app store for Android. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Warehouse scanner app deployment via Managed Google Play - Decision clue: Industry: Logistics

Review Path

Steps:

1. In Intune admin center, go to Tenant administration → Connectors and tokens → Android 2. Under "Managed Google Play", click "Manage Google Play for Work" 3. Sign in with Google account and accept terms to bind Intune to your organization 4. After binding, access Managed Google Play: - Directly at play.google.com/work, or - Through Intune: Apps → Android → Managed Google Play → Launch 5. To add public apps: Search for app, click "Approve", select permissions, confirm 6. To add private LOB apps: Click "Add private app", upload APK, fill details 7. To add web apps: Click "Add web app", provide URL and name 8. Approved apps automatically appear in Intune (refresh if needed) 9. In Intune, assign apps to groups as Required or Available

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-android-managed-google-play https://learn.microsoft.com/en-us/mem/intune/apps/apps-android-overview https://support.google.com/work/android/answer/9339567

Explanation

Getting iOS/iPadOS apps for Intune deployment requires integrating Intune with Apple Business Manager (or Apple School Manager). This connection enables volume purchasing, license management, and silent deployment of apps from the Apple App Store. Organizations can purchase apps in bulk through Apple Business Manager, assign licenses to users or devices, and sync them to Intune for deployment. For custom line-of-business (LOB) apps, organizations can upload .ipa files directly to Intune.

Think of it as: Apple Business Manager is the company app store for iOS—IT buys apps in volume, assigns them to employees, and they install automatically without users needing Apple IDs or payment methods.

Key Mechanics: - Intune connects to Apple Business Manager using a token (renewed annually) - Apps are purchased and assigned licenses in Apple Business Manager portal - Intune syncs purchased apps and license information - Apps can be assigned as Required (silent install) or Available (Company Portal) - Device-based or user-based license assignment supported - Custom LOB apps (.ipa) uploaded directly to Intune with provisioning profiles

Examples

Example 1 — [Success] Silent iOS app deployment via Apple Business Manager A hospital purchases 500 volume licenses for "EpicHaiku" in Apple Business Manager and syncs them to Intune. IT assigns the app as Required to the "Doctor iPhones" device group with device-based licensing. The app installs silently during device enrollment — doctors never see an App Store prompt or need a personal Apple ID.

Example 2 — [Blocked] iOS app sync fails after ABM token expiration An admin assigned iOS apps to devices months ago. Suddenly new devices stop receiving the apps and the Intune console shows a sync error. Root cause: Apple Business Manager integration uses a token that must be renewed annually. When the token expires, Intune loses the ability to sync apps and license assignments from ABM. The admin must download a new token from Apple Business Manager and re-upload it in Intune admin center → Tenant administration → Connectors → Apple volume purchase program tokens.

Key Mechanisms

- Core function: Getting iOS/iPadOS apps for Intune deployment requires integrating Intune with Apple Business Manager (or Apple School Manager). - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Silent iOS app deployment via Apple Business Manager - Decision clue: Industry: Retail

Review Path

Steps:

1. Enroll in Apple Business Manager (business.apple.com) if not already 2. In Apple Business Manager: - Add MDM server (Intune) and download token - Purchase volume licenses for required public apps - Upload private LOB apps (.ipa) if needed 3. In Intune admin center: - Go to Tenant administration → Connectors and tokens → Apple MDM - Upload the token downloaded from ABM 4. Sync apps: Apps → iOS → All apps → Sync 5. After sync, apps appear in Intune 6. Assign apps to groups: - Required: Installs automatically without user interaction - Available: Users install via Company Portal 7. Monitor license usage in ABM or Intune

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/apps-add-ios https://learn.microsoft.com/en-us/mem/intune/apps/vpp-apps-ios https://learn.microsoft.com/en-us/mem/intune/apps/lob-apps-ios

Explanation

Deploying Microsoft Store apps through Intune enables organizations to distribute Universal Windows Platform (UWP) apps from the Microsoft Store to managed Windows devices. Integration with Microsoft Store for Business (soon to be Windows Package Manager) allows admins to browse, acquire, and manage store apps centrally. These apps can be assigned as Required (silent installation) or Available (via Company Portal) to users or devices, with license tracking to ensure compliance.

Think of it as: Microsoft Store for Business is a corporate app storefront—IT picks the apps, buys licenses in bulk, and pushes them to company devices without users needing to search or pay.

Key Mechanics: - Intune syncs with Microsoft Store for Business (MSfB) via connector - Apps acquired in MSfB appear in Intune for assignment - Offline licensed apps can be deployed without requiring users to sign in - Online licensed apps require users to sign in with Azure AD account - Store apps support required, available, and uninstall assignments - Microsoft Store for Business is transitioning to Windows Package Manager integration

Examples

Example 1 — [Success] Silent offline app deployment via Microsoft Store A school district acquires "Microsoft Whiteboard" (offline license) from Microsoft Store for Business, syncs it to Intune, and assigns as Required to the "Classroom Devices" group. The app installs silently on all 1,000 classroom PCs without requiring students to sign in with a personal Microsoft account — offline licensing means Intune manages the license directly.

Example 2 — [Blocked] Required app not available from new Microsoft Store An admin wants to deploy a specific utility app using the new Microsoft Store integration in Intune (winget-based). The app was previously distributed by the vendor through other channels but the vendor never listed it in the Microsoft Store. It cannot be found in the Intune Store search. Root cause: The new Microsoft Store uses winget and app availability depends entirely on the publisher listing their app in the store catalog — admins cannot add apps the publisher hasn't listed. For apps not in the Store, use Win32 packaging (Win32 Content Prep Tool) instead.

Key Mechanisms

- Core function: Deploying Microsoft Store apps through Intune enables organizations to distribute Universal Windows Platform (UWP) apps from the Microsoft Store to managed Windows devices. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Silent offline app deployment via Microsoft Store - Decision clue: Industry: Nonprofit Organization

Review Path

Steps:

1. Sign in to Microsoft Store for Business (businessstore.microsoft.com) with admin account 2. Browse and acquire apps needed for organization 3. For each app, select license type: - Online: User must sign in, license roams with user - Offline: App can be installed without user sign-in, managed by Intune 4. In Intune admin center: - Go to Tenant administration → Connectors and tokens → Microsoft Store for Business - Enable synchronization 5. Wait for sync to complete (or manually sync) 6. Go to Apps → All apps, verify store apps appear 7. Select an app, click Properties, configure assignments 8. Choose Required or Available groups 9. For offline apps, configure deployment settings (device context recommended) 10. Save assignment

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-microsoft https://learn.microsoft.com/en-us/microsoft-store/ https://learn.microsoft.com/en-us/mem/intune/apps/windows-store-for-business

Explanation

App Protection Policies (APP) in Intune, also known as MAM policies, are rules that protect organization data within applications on both managed and unmanaged devices. Unlike device compliance policies that manage the entire device, APP focuses on protecting data at the app level—controlling how users can access, share, and save corporate data in mobile apps like Outlook, Teams, and SharePoint. These policies work without requiring device enrollment, making them ideal for BYOD scenarios.

Think of it as: App Protection Policies are like security guards inside each app—they don't care what building (device) you're in, but they enforce rules about what you can do with the documents (data) inside.

Key Mechanics: - Policies apply to apps, not devices (works on enrolled and unmanaged devices) - Data protection controls: prevent copy/paste, restrict save-as, block screenshots - Access requirements: PIN or biometrics to open app, block on jailbroken devices - Conditional launch: wipe data after multiple failed attempts, require minimum app version - Policies target user groups, not device groups - Integrates with Conditional Access to require approved apps

Examples

Example 1 — [Success] BYOD email protection without device enrollment A bank allows employees to use personal iPhones for corporate email. An App Protection Policy requires a 6-digit PIN to open Outlook, prevents saving attachments to iCloud or personal apps, blocks copy/paste to unmanaged apps, and wipes corporate data after 5 failed PIN attempts. The policy applies without enrolling the personal device in Intune MDM — the employee's personal photos and apps are untouched.

Example 2 — [Blocked] App Protection Policy applied to managed device — enrollment NOT required, policy still applies A new admin assumes App Protection Policies (MAM-WE) only apply to enrolled devices. They assign an APP to an "All Users" group but don't realize it will also protect apps on unenrolled BYOD devices. A BYOD user calls helpdesk confused why Outlook now requires a PIN on their personal phone. Root cause: App Protection Policies (MAM without enrollment) apply to unmanaged devices — enrollment is NOT required. This is the key exam trap: APP applies to any device where the user signs into an APP-protected app, regardless of MDM enrollment status.

Key Mechanisms

- Core function: App Protection Policies (APP) in Intune, also known as MAM policies, are rules that protect organization data within applications on both managed and unmanaged devices. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] BYOD email protection without device enrollment - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Sign in to Microsoft Intune admin center 2. Go to Apps → App protection policies → Create policy 3. Choose platform (iOS/iPadOS or Android) 4. Provide name and description 5. Under "Apps", select which apps the policy applies to (e.g., Outlook, Teams, Word) 6. Configure Data protection settings: - Transfer, copy/paste restrictions - Save-as restrictions - Encryption requirements 7. Configure Access requirements: - PIN or biometrics - Block rooted/jailbroken devices 8. Configure Conditional launch: - Max PIN attempts - Offline grace period - Min app version requirements 9. Assign policy to user groups 10. Review and create

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policy https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policies-overview https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policies-access-actions

Explanation

App Protection Policies on Android interact with Android Enterprise work profiles to provide layered data protection. The work profile creates a separate, encrypted container on the device where corporate apps and data reside, isolated from personal apps. App Protection Policies then add additional controls within those managed apps—requiring PIN, restricting copy/paste between work and personal, and wiping corporate data if conditions aren't met. This combination provides defense-in-depth for corporate data on Android devices.

Think of it as: Work profile is a secure office within your phone; App Protection Policies are the security guards inside that office enforcing specific rules about handling documents.

Key Mechanics: - Work profile separates corporate apps/data from personal space - APP policies apply to apps within the work profile (and can apply to unmanaged devices too) - Multi-identity apps (Outlook, Teams) distinguish work vs personal within same app - APP can prevent copy/paste from work apps to personal apps - Selective wipe removes only work profile data without affecting personal data - Work profile required for some APP features on fully managed devices

Examples

Example 1 — [Success] Dual-purpose phone with work profile and APP A consultant uses a personal Android phone enrolled with work profile. Corporate apps (Outlook, Teams, CRM) appear in the work profile with a briefcase badge — PIN required to launch, copy/paste blocked between work and personal apps. The consultant's personal photos, contacts, and games remain completely untouched. If the device is reported lost, IT can selectively wipe only the work profile.

Example 2 — [Blocked] APP policy configured but copy/paste still works between profiles An admin creates an App Protection Policy blocking copy/paste "to other apps" for Android but assigns it to only iOS devices. Android work profile users can still copy data from Outlook to personal apps. Root cause: App Protection Policies are platform-specific — an iOS policy does NOT apply to Android. The admin must create a separate APP for Android Enterprise (work profile) and ensure the platform is set to Android in the policy configuration.

Key Mechanisms

- Core function: App Protection Policies on Android interact with Android Enterprise work profiles to provide layered data protection. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Dual-purpose phone with work profile and APP - Decision clue: Industry: Consulting

Review Path

Steps:

1. In Intune admin center, go to Devices → Android → Enrollment 2. Configure enrollment profile for "Personally-owned work profile" 3. Users enroll devices, creating work profile 4. Create App Protection Policy: - Apps → App protection policies → Create policy → Android - Name and description - Select apps (Outlook, Teams, Office apps) 5. Configure Data protection settings: - Transfer data to other apps: Block (or policy managed apps) - Save copies: Block - Cut/copy/paste: Block with other apps 6. Configure Access requirements: - PIN: Require (separate from device PIN) - Block rooted devices: Yes 7. Assign policy to user group 8. Policy applies to apps within work profile

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/app-protection-policies-android https://learn.microsoft.com/en-us/mem/intune/apps/android-deployment-scenarios-app-protection-work-profiles https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment-android

Explanation

App Configuration Policies in Intune allow administrators to provide configuration settings to apps when they launch, eliminating the need for manual setup by users. These policies can supply server URLs, account settings, branding information, and feature toggles to managed apps on iOS and Android. For managed devices, configuration can be delivered via device channel; for unmanaged devices with App Protection Policies, the user channel delivers settings based on user identity.

Think of it as: App Configuration Policies are like pre-filling a form for users—when they open an app, all the required settings (server, account, theme) are already filled in correctly.

Key Mechanics: - Two delivery channels: Managed Devices (device context) and Managed Apps (user context) - Supports iOS and Android apps that are designed to accept managed configuration - Configuration data sent as key-value pairs or XML/JSON - Can configure Outlook account setup, Teams meeting settings, VPN app profiles - Policies can target users or devices based on deployment scenario - Integrates with App Protection Policies for layered management

Examples

Example 1 — [Success] Outlook auto-configuration for field staff A company deploys Outlook mobile to field technicians' Android tablets via Intune. An App Configuration Policy pre-fills the Exchange server URL, account name, and disables the ability to add personal email accounts. Technicians open Outlook, see their corporate email already configured, and never need to enter server details manually.

Example 2 — [Blocked] App configuration policy doesn't apply on unmanaged BYOD device An admin creates an App Configuration Policy using the "Managed Devices" channel to pre-configure Outlook settings. A BYOD employee (unmanaged device) opens Outlook but the app configuration doesn't apply — Outlook launches with a blank setup wizard. Root cause: Managed Devices channel requires the device to be MDM-enrolled in Intune. For BYOD devices without enrollment, use the "Managed Apps" (user context) channel instead — this delivers configuration based on user identity without requiring device enrollment.

Key Mechanisms

- Core function: App Configuration Policies in Intune allow administrators to provide configuration settings to apps when they launch, eliminating the need for manual setup by users. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Outlook auto-configuration for field staff - Decision clue: Industry: Energy

Review Path

Steps:

For Managed Devices (enrolled devices): 1. In Intune admin center, go to Apps → App configuration policies → Add → Managed devices 2. Provide name and platform (Android or iOS) 3. Select targeted app from list 4. Choose configuration settings format: - Configuration designer (simple key-value) - JSON/XML editor (advanced) 5. Add settings (e.g., server_url = https://corp.outlook.com) 6. Assign policy to device groups 7. Review and create

For Managed Apps (unmanaged devices with APP): 1. Go to Apps → App configuration policies → Add → Managed apps 2. Provide name 3. Select targeted apps 4. Choose configuration settings format 5. Add settings (may include both general and app-specific) 6. Assign policy to user groups (requires App Protection Policy also assigned) 7. Review and create

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-overview https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-ios https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-android

Explanation

Implementing Conditional Access for App Protection Policies combines Azure AD Conditional Access with Intune App Protection to ensure that corporate data can only be accessed through approved, protected client apps. This configuration requires users to use specific mobile apps (like Outlook, Teams, SharePoint) that have Intune App Protection Policies applied, blocking access from unmanaged or vulnerable native clients. It's a key control for securing data on mobile devices, especially in BYOD scenarios.

Think of it as: Conditional Access with app protection is like requiring employees to use company-approved briefcases (protected apps) to carry documents, rather than allowing any bag (unmanaged app) they bring from home.

Key Mechanics: - Conditional Access policy targets "Require approved client app" or "Require app protection policy" - Approved apps are those that support Intune SDK and can receive APP policies - Policy blocks native mail clients, browser access to Exchange/SharePoint - Works alongside App Protection Policies (APP must be assigned to user) - Applies to Exchange Online, SharePoint Online, and other cloud apps - Users prompted to download approved app if not already installed

Examples

Example 1 — [Success] Blocking native mail clients with app-based CA An insurance company creates a Conditional Access policy targeting Exchange Online and SharePoint Online for iOS and Android devices. The Grant control requires "Require app protection policy." Users who try to access corporate email via iOS Mail or Android Gmail are blocked with a message to use Outlook. Users who open Outlook (which has an App Protection Policy assigned) can access email after providing their PIN.

Example 2 — [Blocked] App-based CA blocks all access — APP policy not assigned An admin creates a Conditional Access policy that requires "Require app protection policy" for mobile device access. After enabling the policy, all mobile users are blocked from Exchange — even those using Outlook. Root cause: App-based CA requires BOTH the CA policy AND an active Intune App Protection Policy assigned to the user. CA alone with "Require app protection policy" grant will block all users for whom no APP has been assigned — the CA grant checks for an active APP assignment, not just the presence of the Outlook app.

Key Mechanisms

- Core function: Implementing Conditional Access for App Protection Policies combines Azure AD Conditional Access with Intune App Protection to ensure that corporate data can only be accessed through approved, protected client apps. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Blocking native mail clients with app-based CA - Decision clue: Industry: Insurance

Review Path

Steps:

1. Ensure App Protection Policies are created and assigned to target users 2. Sign in to Azure portal (https://portal.azure.com) 3. Go to Azure Active Directory → Security → Conditional Access 4. Click "New policy" 5. Name policy (e.g., "Require Approved Apps - Mobile") 6. Assign to user groups (the same groups that have App Protection Policies) 7. Under Cloud apps, select Office 365 Exchange Online and SharePoint Online 8. Under Conditions, select Device platforms → Include → iOS and Android 9. Under Grant, select "Require approved client app" AND "Require app protection policy" 10. Enable policy and click Create

Docs: https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-grant https://learn.microsoft.com/en-us/mem/intune/apps/app-based-conditional-access-intune https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-approved-app

Explanation

App-based Conditional Access is a specific Conditional Access policy type that restricts access to cloud apps (like Exchange Online and SharePoint Online) to approved client applications that support Intune app protection policies. Unlike device-based Conditional Access which checks device compliance, app-based Conditional Access focuses on the application itself—ensuring users connect through apps like Outlook, Teams, or SharePoint that can enforce data protection at the app level.

Think of it as: App-based Conditional Access is like a VIP list for a club—only certain approved apps (the VIPs) are allowed in, regardless of what the user is wearing or driving (their device).

Key Mechanics: - Uses "Require approved client app" grant control in Conditional Access - Approved apps list includes Microsoft apps (Outlook, Teams, Word, etc.) and third-party apps that integrate with Intune SDK - Blocks access from basic authentication clients, legacy apps, and mobile browsers - Often combined with "Require app protection policy" for layered security - Does not require device enrollment (ideal for BYOD) - Works with Exchange Online, SharePoint Online, and other integrated cloud apps

Examples

Example 1 — [Success] Blocking browser access for contractors A marketing agency requires contractors to use the SharePoint mobile app (not Safari) for accessing collaboration sites. A Conditional Access policy with "Require approved client app" blocks browser-based SharePoint access on iOS and Android. Contractors see a message prompting them to use the app — once they do, access is granted and App Protection Policies (already assigned) enforce data protection controls.

Example 2 — [Blocked] App-based CA blocks all users — APP policy missing An admin enables a Conditional Access policy requiring "Require app protection policy" for mobile access to Exchange Online. Within minutes, all mobile users lose access to email — even those using Outlook. Root cause: "Require app protection policy" in CA checks that an Intune App Protection Policy is assigned AND applied to the user. If no APP has been assigned to a user, the CA check fails and blocks access completely. The APP must be configured and assigned to the same users BEFORE enabling the CA policy, not after.

Key Mechanisms

- Core function: App-based Conditional Access is a specific Conditional Access policy type that restricts access to cloud apps (like Exchange Online and SharePoint Online) to approved client applications that support Intune app protection policies. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Blocking browser access for contractors - Decision clue: Industry: Marketing Agency

Review Path

Steps:

1. Create App Protection Policies for target users (required for approved app experience) 2. Go to Azure AD Conditional Access in Azure portal 3. Create new policy 4. Name: "App-Based Access for Mobile" 5. Assign to user groups (contractors, specific departments) 6. Select Cloud apps: Choose Exchange Online, SharePoint Online, Teams, etc. 7. Under Conditions: Device platforms → Select iOS and Android 8. Under Grant: - Select "Require approved client app" - Choose specific apps or "All approved apps" - Also consider "Require app protection policy" for stronger security 9. Enable policy in Report-only mode first, then switch to On after validation 10. Monitor sign-in logs for blocked attempts

Docs: https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-approved-app https://learn.microsoft.com/en-us/mem/intune/apps/app-based-conditional-access-intune https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/app-based-conditional-access

Explanation

App Configuration Policies for managed devices deliver app-specific settings to enrolled devices through Intune. These policies apply when the app is installed from Intune (as required or available) and provide configuration at the device level. This approach is ideal for corporate-owned devices where IT has full management control and wants to pre-configure apps with organization-specific settings like server URLs, account information, or feature toggles without relying on user identity.

Think of it as: Managed device app configuration is like setting up software on company computers before handing them to employees—all the settings are already correct, and employees don't need to configure anything.

Key Mechanics: - Policies target device groups (not user groups) - Configuration delivered during app installation or at next device sync - Supports iOS and Android apps that accept managed configuration - Configuration format: XML (iOS) or JSON (Android) or key-value pairs - Can configure Outlook, Teams, Edge, VPN apps, and custom LOB apps - Settings apply to all users of the device (shared devices scenario)

Examples

Example 1 — [Success] Shared iPad app pre-configuration for nurses A hospital deploys shared iPads for nurses using managed device app configuration policy. The EpicHaiku app is pre-configured with the hospital's EMR server URL and the "enable_personal_mode" key set to false. Nurses pick up any shared iPad, open EpicHaiku, and are immediately connected to the correct EMR system — no server address required.

Example 2 — [Blocked] Managed device config policy shows "Not applicable" on BYOD phone An admin creates a managed device app configuration policy for Outlook and assigns it to a user group that includes both enrolled corporate phones and BYOD personal phones. The policy correctly configures Outlook on corporate devices but shows "Not applicable" on BYOD phones. Root cause: Managed device app configuration policies require MDM enrollment — they apply at the device context level. For BYOD/unmanaged devices, use the Managed Apps (user channel) app configuration policy instead.

Key Mechanisms

- Core function: App Configuration Policies for managed devices deliver app-specific settings to enrolled devices through Intune. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Shared iPad app pre-configuration for nurses - Decision clue: Industry: Hospitality

Review Path

Steps:

1. In Intune admin center, go to Apps → App configuration policies 2. Click "Add" and select "Managed devices" 3. Provide a name (e.g., "Outlook Config - Corporate Devices") 4. Choose platform (iOS/iPadOS or Android) 5. Click "Select app" and choose the target app 6. Under Configuration settings format, choose: - Configuration designer (for simple key-value pairs) - JSON/XML data (for complex configurations) 7. Add settings (e.g., for Outlook: "EmailAddress" = "username@domain.com") 8. Assign policy to device groups 9. Review and create

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-overview https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-ios https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-android

Explanation

App configuration for iOS managed devices involves delivering settings to apps on enrolled iPhones and iPads using Intune. iOS apps that support managed configuration can receive settings via XML property lists (PLIST) or key-value pairs, allowing administrators to pre-configure server URLs, account settings, feature toggles, and security policies. This is particularly powerful for corporate-owned iOS devices where IT needs to ensure apps are properly configured before users receive them.

Think of it as: iOS managed app configuration is like preparing iPhones with all apps pre-set before handing them to employees—the VPN app already knows the corporate gateway, the email app has the account configured, and security settings are already enforced.

Key Mechanics: - Configuration delivered as XML property lists (.plist) or through Intune's configuration designer - Apps must support managed app configuration (respond to open with configuration) - Works on supervised and unsupervised iOS devices (supervision enables more settings) - Configuration can be delivered via device channel (enrolled devices) or user channel (with APP) - Settings can be required (user cannot change) or configurable by user - Supports both native iOS apps and third-party apps from Apple Business Manager

Examples

Example 1 — [Success] Hospital iOS apps pre-configured by department A hospital creates separate app configuration policies for ER and Cardiology iPhones. Each policy sets the EpicHaiku server URL and department-specific keys. Doctors pick up their assigned iPhone, open EpicHaiku, and immediately see the correct department portal — no server address or department code needed.

Example 2 — [Blocked] iOS PLIST configuration rejected — malformed XML An admin uploads a custom PLIST XML for an iOS app configuration policy. The policy saves but the app doesn't receive the configuration — Intune shows a "Configuration not applied" error. Root cause: iOS managed configuration PLIST files must be valid XML with proper plist schema — missing closing tags, incorrect value types, or unsupported key names result in the configuration being silently rejected. Always validate PLIST XML with a linter before uploading.

Key Mechanisms

- Core function: App configuration for iOS managed devices involves delivering settings to apps on enrolled iPhones and iPads using Intune. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hospital iOS apps pre-configured by department - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Ensure iOS apps are added to Intune (from Apple Business Manager or as LOB apps) 2. In Intune admin center, go to Apps → App configuration policies 3. Click "Add" and select "Managed devices" 4. Enter a name (e.g., "EpicHaiku - ER Configuration") 5. For Platform, select "iOS/iPadOS" 6. Click "Select app" and choose the target iOS app 7. Under Configuration settings format, choose: - "Configuration designer" for simple key-value pairs, OR - "Property list (PLIST) XML" for complex configurations 8. Add configuration keys and values: - Use configuration designer to add key-value pairs - Or paste PLIST XML directly (refer to app developer documentation) 9. For each setting, choose the value type (string, integer, boolean, etc.) 10. Assign policy to device groups (e.g., "ER iPhone Devices") 11. Review and create 12. Deploy the app as Required to the same device groups 13. Test on pilot devices to verify configuration applies correctly

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-ios https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-overview https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf https://learn.microsoft.com/en-us/mem/intune/configuration/ios-device-features-settings

Explanation

App configuration for Android managed devices delivers app-specific settings to enrolled Android Enterprise devices through Intune. Android apps that support managed configuration can receive settings via JSON key-value pairs, allowing administrators to pre-configure server URLs, account details, feature toggles, and security settings. This works on all Android Enterprise deployment scenarios—fully managed devices, dedicated devices (COSU), and work profiles on corporate-owned devices.

Think of it as: Android managed app configuration is like setting up a company phone with all apps pre-configured—the CRM app already knows the server address, the email app already has the account settings, and employees just pick up and work.

Key Mechanics: - Configuration delivered through JSON key-value pairs or configuration designer - Apps must support Android Enterprise managed configurations (read docs at run time) - Works on fully managed, dedicated, and corporate-owned work profile devices - Settings can be required (user cannot change) or optional (user can override) - Policies target device groups (device context) for corporate devices - Supports both system apps and third-party apps from Managed Google Play

Examples

Example 1 — [Success] Regional scanner pre-configuration A shipping company creates separate managed device app configuration policies for West and East region warehouse scanners — each with a different server_url key value pointing to the regional API endpoint. Devices automatically receive the correct endpoint based on their group assignment. Warehouse staff open the scanner app and are immediately connected to the right server without any manual input.

Example 2 — [Blocked] Configuration designer keys not recognized by app An admin uses Intune's configuration designer to add keys to an Android app config policy. The policy applies successfully (no errors) but the app doesn't behave as expected. Root cause: For Android managed configurations, the key names must exactly match the app's declared managed configuration schema. If the admin uses incorrect key names or value types, the app silently ignores the unrecognized keys. Always check the app's documentation or managed configuration schema (available in Managed Google Play) for the correct key names and value types.

Key Mechanisms

- Core function: App configuration for Android managed devices delivers app-specific settings to enrolled Android Enterprise devices through Intune. - Category fit: This concept belongs to application deployment and endpoint configuration and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Regional scanner pre-configuration - Decision clue: Industry: Transportation & Logistics

Review Path

Steps:

1. Ensure Android apps are added to Intune (via Managed Google Play) 2. In Intune admin center, go to Apps → App configuration policies 3. Click "Add" and select "Managed devices" 4. Enter a name (e.g., "Scanner App - West Warehouse") 5. For Platform, select "Android" 6. Click "Select app" and choose the target Android app 7. Under Configuration settings format, choose: - "Configuration designer" for simple key-value pairs, OR - "JSON data" for complex configurations 8. Add configuration keys and values: - Refer to app developer documentation for supported keys - Common examples: server_url, api_endpoint, sync_interval, region 9. For each setting, choose if user can modify (if app supports it) 10. Assign policy to device groups (not user groups) 11. Review and create 12. Test on a pilot device before broad deployment

Docs: https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-android https://developer.android.com/work/managed-configurations https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-overview https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment-android

Explanation

Microsoft Defender Antivirus policies in Intune define how endpoint protection scans and responds to threats across managed devices. These policies configure real-time protection, scheduled scans, signature updates, and remediation actions when malware is detected. Defender Antivirus serves as the primary antimalware component built into Windows 10/11 and is managed through Intune endpoint security policies.

Think of it as: A security guard schedule and rulebook that tells Defender exactly when to patrol (scan), what to look for (detection types), and how to handle intruders (remediation actions).

Key Mechanics: - Real-time protection continuously monitors file activity and processes - Cloud-delivered protection uses Microsoft's vast threat intelligence network - Scheduled scans run at defined times with configurable scan types (quick/full) - Remediation actions determine quarantine, removal, or user notification - Exclusions can be defined to prevent performance impacts on critical apps

Examples

Example 1 — [Success] Nightly full scan for financial services A financial services firm creates an Intune Endpoint Security → Antivirus policy with full scans scheduled nightly at 2 AM, real-time protection enabled, and threat remediation set to quarantine automatically. The policy deploys to all Windows 11 workstations — helpdesk sees malware reports through the Intune antivirus report rather than user calls.

Example 2 — [Blocked] Antivirus policy not applying — third-party AV active An admin creates a Defender Antivirus policy but 30% of devices show "Not applicable" in the Intune report. Root cause: When a third-party antivirus (like Symantec or McAfee) is the active AV provider, Windows disables Microsoft Defender Antivirus's active protection. Intune's Defender Antivirus policies cannot configure real-time protection settings on devices where Defender is in passive mode. Remove or disable the third-party AV to restore Defender as the active provider.

Key Mechanisms

- Core function: Microsoft Defender Antivirus policies in Intune define how endpoint protection scans and responds to threats across managed devices. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Nightly full scan for financial services - Decision clue: Industry: Education

Review Path

Steps:

1. Navigate to Microsoft Intune admin center → Endpoint security → Antivirus 2. Click "Create Policy" and select platform (Windows 10/11, macOS, or Windows 10/11/Server) 3. Choose profile type: "Microsoft Defender Antivirus" 4. Configure basic settings: - Enable real-time monitoring - Configure cloud-delivered protection level - Set file and folder exclusions if needed 5. Configure scan settings: - Schedule scan type (quick/full) and timing - Set scan parameters (CPU usage, catch-up scans) 6. Define remediation actions for each threat level 7. Assign policy to device groups and review 8. Monitor compliance in Endpoint security → Antivirus

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/antivirus-microsoft-defender-settings-windows https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-antivirus-policy https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-antivirus-windows

Explanation

Always-on protection refers to continuous, real-time monitoring of device activity by Microsoft Defender for Endpoint to detect and respond to threats immediately. This includes file system monitoring, process inspection, network activity analysis, and behavior-based detection that operates constantly without user intervention. The monitoring feeds into the Defender security console for centralized visibility.

Think of it as: A 24/7 security camera system that watches every corner of your device, recording everything suspicious and alerting security guards immediately.

Key Mechanics: - Real-time protection monitors file writes, process creations, and DLL loading - Behavior monitoring uses machine learning to detect suspicious patterns - Network protection inspects inbound/outbound traffic for malicious domains/IPs - Cloud-delivered protection checks files against up-to-the-minute threat intelligence - Tamper protection prevents malware from disabling security features

Examples

Example 1 — [Success] Ransomware blocked before execution A user at a law firm downloads a malicious macro-enabled document. Always-on protection detects suspicious file activity within milliseconds, blocks the file, terminates the spawned process, and sends an alert to the security operations center. The encryption never begins — the only evidence is a threat notification in the Defender portal.

Example 2 — [Blocked] Tamper protection prevents Defender from being disabled An IT admin attempts to disable Defender real-time protection on a device through PowerShell (Set-MpPreference -DisableRealtimeMonitoring $true) to perform a performance test. The command returns no error but real-time protection remains active. Root cause: Tamper protection, when enabled via Intune, prevents any local changes to Defender security settings — including PowerShell, registry edits, and local Group Policy. To temporarily disable for testing, tamper protection must first be disabled in the Microsoft Defender portal or Intune.

Key Mechanisms

- Core function: Always-on protection refers to continuous, real-time monitoring of device activity by Microsoft Defender for Endpoint to detect and respond to threats immediately. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Ransomware blocked before execution - Decision clue: Industry: Legal

Review Path

Steps:

1. Go to Microsoft Intune admin center → Endpoint security → Antivirus 2. Create or edit an existing antivirus policy 3. Under "Real-time protection" settings: - Set "Enable real-time protection" to Yes - Set "Enable on access protection" to Yes - Configure "Monitor file and program activity" to monitor all files 4. Configure cloud protection: - Set "Enable cloud-delivered protection" to Yes - Set "Cloud protection level" to High or High + - Set "Cloud timeout extension" to 50 seconds 5. Enable behavior monitoring: - Set "Enable behavior monitoring" to Yes 6. Configure tamper protection in Microsoft 365 Defender 7. Deploy policy and verify in Endpoint security reports

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/antivirus-microsoft-defender-settings-windows#real-time-protection https://learn.microsoft.com/en-us/defender-endpoint/configure-real-time-protection-microsoft-defender-antivirus https://learn.microsoft.com/en-us/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection

Explanation

Disk encryption policies in Intune enforce BitLocker Drive Encryption on Windows devices to protect data at rest. These policies configure encryption strength, protection methods (TPM, PIN, recovery key), and recovery options to ensure that if a device is lost or stolen, data remains inaccessible. BitLocker encrypts the entire operating system drive and fixed data drives.

Think of it as: A digital safe that automatically locks when the device is turned off, requiring the correct key (TPM, PIN, or recovery key) to unlock and access the contents.

Key Mechanics: - TPM (Trusted Platform Module) provides hardware-based security for encryption keys - Recovery keys are automatically escrowed to Entra ID/Intune for retrieval - Encryption strength options include XTS-AES 128-bit or 256-bit - Silent encryption occurs in the background during device provisioning - Pre-provisioning can encrypt used space only for faster deployment

Examples

Example 1 — [Success] HIPAA compliance via silent BitLocker encryption A hospital enforces BitLocker on all clinical workstations via an Intune Endpoint Security → Disk Encryption policy. TPM is required, recovery keys are escrowed to Entra ID, and silent encryption runs during provisioning. When a tablet is lost, IT confirms via Intune that the device was encrypted and the thief cannot access patient data without the recovery key stored in Entra ID.

Example 2 — [Blocked] BitLocker policy fails on legacy device without TPM An admin deploys a BitLocker policy requiring TPM to a device fleet that includes some older laptops without TPM chips. Those devices show BitLocker as "Not applicable" or "Error" in the Intune compliance report. Root cause: BitLocker with TPM requires a physical TPM chip — devices without TPM cannot use the default TPM protection method. To enable BitLocker on non-TPM devices, the admin must explicitly enable the "Allow BitLocker without compatible TPM" setting in the policy. Without this toggle, BitLocker simply won't activate on TPM-less devices.

Key Mechanisms

- Core function: Disk encryption policies in Intune enforce BitLocker Drive Encryption on Windows devices to protect data at rest. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] HIPAA compliance via silent BitLocker encryption - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Navigate to Microsoft Intune admin center → Endpoint security → Disk encryption 2. Click "Create Policy" → Platform: Windows 10/11 → Profile: BitLocker 3. Configure BitLocker base settings: - Enable BitLocker on OS drives: Yes - Configure encryption method: XTS-AES 256-bit 4. Configure OS drive settings: - Require TPM startup: Require TPM - Configure TPM startup PIN: Not required 5. Configure fixed drive encryption: - Enable BitLocker on fixed drives: Yes - Auto-unlock on OS drive mount: Yes 6. Set recovery options: - Recovery key escrow: Store to Entra ID - Recovery password rotation: Enabled 7. Assign to device groups and deploy 8. Monitor encryption status in Endpoint security → Disk encryption

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/bitlocker-policies https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/ https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-disk-encryption-profile-settings

Explanation

Firewall policies in Intune control inbound and outbound network traffic on managed Windows devices based on rules you define. These policies configure Windows Defender Firewall with Advanced Security settings, including profile-specific rules (Domain, Private, Public) and advanced filtering based on ports, protocols, applications, and IP addresses.

Think of it as: A border control checkpoint that examines every network packet trying to enter or leave your device, allowing or blocking based on your custom rulebook.

Key Mechanics: - Firewall profiles (Domain, Private, Public) apply different rules based on network location - Inbound rules control traffic attempting to connect to the device - Outbound rules control traffic originating from the device - Rules can be based on program path, port number, protocol, or IP address - Stateful filtering tracks connection states for intelligent blocking

Examples

Example 1 — [Success] RDP restricted to corporate VPN range A company creates an Intune Firewall policy with an inbound allow rule for port 3389 (RDP) scoped to the corporate VPN IP range (10.0.0.0/8) and an inbound block rule for all other RDP traffic. All other inbound connections remain blocked. IT can reach devices via RDP through VPN; internet-facing RDP brute-force attacks are blocked.

Example 2 — [Blocked] Firewall policy overrides critical application traffic An admin deploys a firewall policy setting the Public profile to "Block all outbound" to prevent data exfiltration. Several devices lose access to a cloud-based LOB application that communicates over HTTPS port 443. Root cause: "Block all outbound" in the Public profile blocks ALL outbound traffic unless an explicit allow rule exists. The admin must add an outbound allow rule for the LOB application (by path or destination IP) before setting the default outbound action to Block.

Key Mechanisms

- Core function: Firewall policies in Intune control inbound and outbound network traffic on managed Windows devices based on rules you define. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] RDP restricted to corporate VPN range - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Navigate to Microsoft Intune admin center → Endpoint security → Firewall 2. Click "Create Policy" → Platform: Windows 10/11 → Profile: Microsoft Defender Firewall 3. Configure basic firewall settings: - Enable firewall for Domain, Private, Public profiles - Set default inbound action: Block - Set default outbound action: Allow 4. Configure advanced settings: - Enable stateful inspection - Enable stealth mode for public networks 5. Add custom rules: - Click "Add" under firewall rules - Define rule name, direction (inbound/outbound) - Specify protocol, local/remote ports, IP ranges 6. Assign to appropriate device groups 7. Deploy and monitor rule effectiveness

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-firewall-policy https://learn.microsoft.com/en-us/mem/intune/protect/firewall-policy-create https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/

Explanation

Managing firewall settings through endpoint security policies provides centralized control over Windows Defender Firewall configurations across all managed devices. This approach enables consistent rule enforcement, real-time monitoring, and streamlined updates without requiring local administrator access on endpoints.

Think of it as: A central air traffic control tower that manages flight patterns (network traffic) for all aircraft (devices) from one location, ensuring consistent safety rules everywhere.

Key Mechanics: - Centralized policy management in Intune replaces local GPO or manual configuration - Rule merging controls whether local firewall rules can coexist with managed rules - Connection security rules configure IPsec authentication and encryption - Monitoring provides visibility into firewall state and rule effectiveness - Policy precedence determines which rules apply when multiple policies target a device

Examples

Example 1 — [Success] Emergency port block deployed across 10,000 devices A critical vulnerability is disclosed exploiting TCP port 8888. The security team adds a block rule to the existing Intune Firewall policy in the Endpoint Security blade and saves it. All 10,000 managed endpoints receive the updated rule on next check-in — no local admin access or user interaction needed. The new rule is enforced within hours.

Example 2 — [Blocked] Local firewall exceptions overriding managed policy An admin deploys a firewall policy blocking all RDP inbound traffic. However, some help-desk-managed devices have local firewall exceptions added through the Windows Firewall advanced settings panel that allow RDP from any source. These local exceptions override the managed policy. Root cause: By default, Intune firewall policies allow rule merging — locally created rules coexist with managed rules. To prevent this, set "Allow local firewall rules" to "No" in the policy to block all locally created rules from being merged.

Key Mechanisms

- Core function: Managing firewall settings through endpoint security policies provides centralized control over Windows Defender Firewall configurations across all managed devices. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Emergency port block deployed across 10,000 devices - Decision clue: Industry: Retail

Review Path

Steps:

1. Access Microsoft Intune admin center → Endpoint security → Firewall 2. Review existing firewall policies and identify gaps 3. Create new policy or modify existing: - Configure profile-specific settings - Set rule merge behavior (prevent local exceptions if needed) 4. Add connection security rules for sensitive traffic: - Require authentication for specific IP ranges - Configure IPsec encryption requirements 5. Deploy policies to targeted device groups 6. Monitor firewall status: - Go to Endpoint security → Firewall → Monitor - View devices with firewall disabled or misconfigured 7. Use reports to identify devices requiring remediation

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-firewall-policy https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure https://learn.microsoft.com/en-us/mem/intune/protect/monitor-firewall-policy

Explanation

Attack Surface Reduction (ASR) rules are intelligent policies that prevent common malware attack vectors by blocking suspicious behaviors and file executions. These rules target specific behaviors used by malware, such as scripting, macro execution, and process injection, significantly reducing the attack surface of Windows devices.

Think of it as: A bouncer at an exclusive club who knows all the tricks troublemakers use to sneak in and blocks them before they can cause problems.

Key Mechanics: - ASR rules target specific attack behaviors, not just known malware signatures - Rules can be configured in Audit mode (log only) or Block mode - Exclusions can be defined for trusted applications or files - Rules are managed through Intune endpoint security policies - Integration with Defender for Endpoint provides detailed alerts on ASR blocks

Examples

Example 1 — [Success] Phishing attack blocked by ASR rule An attacker sends a phishing email with a macro-enabled Office attachment. The "Block Office applications from creating child processes" ASR rule is in Block mode. When the victim opens the document and the macro attempts to spawn cmd.exe, the process creation is blocked and an alert fires in Microsoft Defender. The attack chain is broken before any payload executes.

Example 2 — [Blocked] ASR rule blocks legitimate business application An admin enables the "Block Office from creating child processes" rule in Block mode. A critical HR application that integrates with Word via COM automation immediately stops working — the COM child process is blocked. Root cause: ASR rules in Block mode have no awareness of business context — they block ALL matching behavior, including legitimate use cases. Always run new ASR rules in Audit mode for 30 days first to identify and add exclusions for trusted applications before switching to Block mode.

Key Mechanisms

- Core function: Attack Surface Reduction (ASR) rules are intelligent policies that prevent common malware attack vectors by blocking suspicious behaviors and file executions. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Phishing attack blocked by ASR rule - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Navigate to Microsoft Intune admin center → Endpoint security → Attack surface reduction 2. Click "Create Policy" → Platform: Windows 10/11 → Profile: Attack Surface Reduction Rules 3. Configure ASR rules: - Select from 15+ available rules - Set each rule to: - Block: Prevent action and log - Audit: Log only (for testing) - Warn: Prompt user (Windows 11) - Disable: Rule off 4. Add exclusions for trusted files/folders 5. Configure additional protections: - Controlled folder access - Exploit protection 6. Assign to device groups 7. Monitor rule activity: - Microsoft 365 Defender portal → Reports - Event Viewer: Microsoft-Windows-Windows Defender/Operational

Docs: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-asr-policy https://learn.microsoft.com/en-us/defender-endpoint/enable-attack-surface-reduction

Explanation

Windows Defender Application Control (WDAC) is a code integrity (CI) policy that restricts which applications and drivers can run on Windows devices. Unlike traditional antivirus that looks for known bad files, WDAC only allows trusted applications to execute, creating a zero-trust approach to application management. Policies can be configured in audit mode before enforcement.

Think of it as: An airport security system that only allows pre-approved passengers (trusted apps) to board planes (run on devices), rather than just checking for known terrorists (malware).

Key Mechanics: - WDAC policies are XML-based and can be deployed via Intune or Group Policy - Policies can be signed or unsigned, with signed policies providing tamper protection - Trust can be based on publisher certificates, file hashes, or file paths - Multiple policies can be applied simultaneously with cumulative restrictions - UMCI (User Mode Code Integrity) controls applications; KMCI controls drivers

Examples

Example 1 — [Success] Trading floor lockdown via WDAC A high-frequency trading firm deploys WDAC in audit mode for 60 days on trading workstations, collects all application execution logs, creates a base policy trusting all verified trading app publishers, and deploys enforcement mode via Intune. Only approved trading apps and Windows components execute — unauthorized apps are blocked before trading hours begin.

Example 2 — [Blocked] WDAC enforcement breaks legacy LOB application An admin deploys WDAC enforcement policy to lock down workstations. An old line-of-business app that installs to a non-standard path without a code signing certificate is immediately blocked on every device. Dozens of users call helpdesk. Root cause: WDAC blocks ALL unsigned applications — including legacy LOB apps with no publisher certificate. Before enforcing WDAC, every trusted application (including unsigned legacy apps) must be added to the allowlist via file hash or path rules. Deploying enforcement without a complete allowlist will break legitimate software.

Key Mechanisms

- Core function: Windows Defender Application Control (WDAC) is a code integrity (CI) policy that restricts which applications and drivers can run on Windows devices. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Trading floor lockdown via WDAC - Decision clue: Industry: Financial Trading

Review Path

Steps:

1. Plan WDAC strategy: - Determine trust model (publisher hash, path) - Identify required applications - Decide on signed vs. unsigned policies 2. Create audit policy: - Use PowerShell: New-CIPolicy - Deploy in audit mode via Intune - Collect application usage logs for 30+ days 3. Build enforcement policy: - Merge audit logs into base policy - Add trusted publisher rules - Convert to enforcement mode - Sign policy if using signed policies 4. Deploy via Intune: - Go to Devices → Configuration profiles - Create profile for WDAC - Upload policy XML file - Deploy to pilot group first 5. Monitor and maintain: - Check Event ID 3076 for blocks - Update policy for new applications

Docs: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/ https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-asr-policy#application-control https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-design-guide

Explanation

Exploit Protection applies mitigation techniques to applications and system processes to prevent common exploit techniques used by malware. These mitigations include protections against memory corruption, code execution, and other attack vectors, and can be applied system-wide or to specific applications.

Think of it as: Reinforced armor plating for your applications that makes them resistant to specific attack techniques like buffer overflows and memory corruption attempts.

Key Mechanics: - System-level settings apply mitigations to all processes - Program-specific settings target individual applications - Mitigations include DEP, ASLR, CFG, and other exploit-hardening techniques - Can be configured in audit mode to test compatibility - Integrates with Event Viewer for monitoring and troubleshooting

Examples

Example 1 — [Success] Legacy app hardened with per-process mitigations A government agency has a legacy application that cannot be updated. They add per-process exploit protection settings in Intune (Export Address Filtering, Import Address Filtering, Force Randomization) targeting the app's executable. The app continues to function while receiving modern exploit mitigations that weren't available when it was originally developed.

Example 2 — [Blocked] Mandatory ASLR breaks critical database application An admin enables Mandatory ASLR as a system-level exploit protection setting via Intune. A critical database application that relies on fixed memory addresses starts crashing on all devices. Root cause: Mandatory ASLR forces all DLLs to relocate even if they weren't compiled with ASLR support — applications with non-ASLR-compatible DLLs will crash. Run exploit protection in Audit mode first to identify compatibility issues before enabling enforcement.

Key Mechanisms

- Core function: Exploit Protection applies mitigation techniques to applications and system processes to prevent common exploit techniques used by malware. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Legacy app hardened with per-process mitigations - Decision clue: Industry: Government

Review Path

Steps:

1. Navigate to Microsoft Intune admin center → Endpoint security → Attack surface reduction 2. Click "Create Policy" → Platform: Windows 10/11 → Profile: Exploit Protection 3. Configure exploit protection settings: - Upload an existing XML configuration file - Or create settings manually via template 4. For manual configuration: - Set system-level mitigations (DEP, ASLR, CFG) - Add program-specific rules as needed 5. Set configuration mode: - Audit (recommended for initial deployment) - Enforcement (after compatibility testing) 6. Deploy to pilot device group first 7. Monitor via Event Viewer: - Applications and Services Logs → Microsoft → Windows → Security-Mitigations → Kernel Mode

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/endpoint-security-asr-policy#exploit-protection https://learn.microsoft.com/en-us/defender-endpoint/enable-exploit-protection https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/exploit-protection/exploit-protection-reference

Explanation

Microsoft Defender Application Guard (MDAG) uses hardware-based virtualization to isolate untrusted browsing sessions and documents in a secure container separate from the host operating system. If a user visits a malicious site or opens a dangerous attachment, the attack is contained within the isolated environment, preventing compromise of the actual device.

Think of it as: A protective glass box where you open suspicious mail—even if it explodes, you're safe because the box contains everything and the real environment remains untouched.

Key Mechanics: - Hardware-based isolation uses Hyper-V virtualization technology - Separate container has no access to host files, processes, or memory - Edge browser runs in isolated container when visiting untrusted sites - Office documents can be opened in isolated containers - Container is discarded after each session, removing any malware

Examples

Example 1 — [Success] Malicious link isolated from host OS An employee in a law firm clicks a link in a phishing email. Because the firm has enabled MDAG with Edge, the browser opens the link in an isolated Hyper-V container. The page attempts to run a drive-by exploit, but the container has no access to the host OS, local files, or corporate network. After the session ends, the container is discarded with all malware remnants. The employee's device and data are completely unaffected.

Example 2 — [Blocked] MDAG fails due to missing Hyper-V virtualization support An admin deploys an Application Guard configuration profile to 200 Windows 10 Pro devices. MDAG silently does not activate on most of them. Root cause: MDAG requires Windows 10/11 Enterprise or Education edition and 64-bit CPU with Hyper-V virtualization extensions enabled. Windows 10 Pro devices do not support MDAG — check edition requirements before deploying.

Key Mechanisms

- Core function: Microsoft Defender Application Guard (MDAG) uses hardware-based virtualization to isolate untrusted browsing sessions and documents in a secure container separate from the host operating system. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Malicious link isolated from host OS - Decision clue: Industry: Legal Services

Review Path

Steps:

1. Verify hardware requirements: - Windows 10/11 Enterprise or Education - 64-bit CPU with virtualization extensions - 8GB RAM minimum 2. Navigate to Intune → Devices → Configuration profiles 3. Create new profile → Platform: Windows 10/11 → Profile: Microsoft Defender Application Guard 4. Configure Application Guard settings: - Set "Enable Application Guard" to Enabled - Configure clipboard behavior - Set file download behavior - Configure network isolation 5. Define trusted sites: - Add corporate domains to trusted list - All others automatically isolated 6. Enable Office Application Guard if needed 7. Deploy to appropriate device groups 8. Verify functionality via System Information or task manager

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/windows-defender-application-guard https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-application-guard/mdag-overview https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-windows-defender-application-guard

Explanation

Credential Guard uses virtualization-based security to protect domain credentials and derived credentials from theft and reuse attacks like Pass-the-Hash or Pass-the-Ticket. It isolates secrets in a protected environment that even the operating system cannot access directly, preventing malware from stealing credentials from LSASS memory.

Think of it as: A vault inside your computer where credentials are stored behind a glass wall—even if someone breaks into the building (compromises the OS), they can't reach the vault's contents.

Key Mechanics: - Virtualization-based security (VBS) creates isolated memory region - LSASS runs in protected mode, credentials stored in isolated environment - NTLM and Kerberos derived credentials are protected - Prevents credential dumping tools like Mimikatz from accessing secrets - Requires UEFI lock and secure boot to prevent disabling

Examples

Example 1 — [Success] Credential dump blocked on compromised workstation An attacker gains local admin on a hospital workstation and runs Mimikatz to dump LSASS credentials. With Credential Guard enabled (UEFI lock), LSASS runs in isolated VBS mode — Mimikatz returns empty hashes. The attacker cannot extract NTLM hashes or Kerberos tickets for lateral movement. The breach is contained to that single device.

Example 2 — [Blocked] Credential Guard disabled remotely without UEFI lock An admin enables Credential Guard via Intune but forgets to set the UEFI lock option. An attacker with admin access on a compromised device uses PowerShell to disable Credential Guard, disabling VBS protection, then reboots and successfully dumps credentials from the now-unprotected LSASS. Root cause: Without UEFI lock, Credential Guard can be disabled from within the OS — always enable UEFI lock to prevent runtime disabling.

Key Mechanisms

- Core function: Credential Guard uses virtualization-based security to protect domain credentials and derived credentials from theft and reuse attacks like Pass-the-Hash or Pass-the-Ticket. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Credential dump blocked on compromised workstation - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Verify hardware readiness: - Check UEFI/Secure Boot enabled - Confirm TPM 2.0 present - Virtualization enabled in BIOS 2. Navigate to Intune → Devices → Configuration profiles 3. Create profile → Platform: Windows 10/11 → Profile: Device Guard/Credential Guard 4. Configure settings: - Set "Credential Guard Configuration" to Enabled with UEFI lock - Enable "Virtualization Based Security" - Configure Secure Launch Configuration as needed 5. Deploy to pilot group first 6. Verify via System Information: - Run msinfo32.exe - Check "Credential Guard" status 7. Monitor event logs for issues (Event ID 9797, 9798)

Docs: https://learn.microsoft.com/en-mem/intune/protect/credential-guard https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/manage-windows-credential-protection https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/credential-guard/configure

Explanation

Security baselines in Intune are pre-configured groups of Windows settings that represent Microsoft's recommended security configurations for different versions of Windows. These baselines provide a consistent, expert-recommended starting point for device security, implementing settings that align with industry best practices and compliance requirements.

Think of it as: A pre-built security blueprint from master architects—you can use it as-is or modify it, but you know it's built on expert knowledge and tested patterns.

Key Mechanics: - Baselines include settings for Defender, Edge, BitLocker, firewall, and more - Multiple baseline versions exist for different Windows releases - Settings can be customized while maintaining baseline structure - Baselines are updated as new threats emerge and Windows evolves - Compliance reporting shows devices matching baseline requirements

Examples

Example 1 — [Success] New deployment secured with Windows 11 baseline A financial institution deploying 500 new Windows 11 devices applies the Microsoft Security Baseline for Windows 11 in Intune before users ever log in. Every device gets consistent hardening: BitLocker enabled, Defender real-time protection on, SMBv1 disabled, and Edge configured with safe browsing. The first audit review shows 97% baseline compliance across the fleet with no manual configuration.

Example 2 — [Blocked] Baseline update doesn't apply to existing assigned groups A security admin updates their Windows 11 Security Baseline from version 22H2 to 23H2 in Intune. They expect the updated settings to automatically push to all devices in the existing assignment group. A week later, devices still show the old baseline version. Root cause: Security baseline updates do NOT auto-apply — after updating, you must re-create or update the baseline assignment to push the new version to assigned groups.

Key Mechanisms

- Core function: Security baselines in Intune are pre-configured groups of Windows settings that represent Microsoft's recommended security configurations for different versions of Windows. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] New deployment secured with Windows 11 baseline - Decision clue: Industry: Finance

Review Path

Steps:

1. Navigate to Microsoft Intune admin center → Endpoint security → Security baselines 2. Review available baseline types: - Windows 10/11 Security Baseline - Microsoft Defender for Endpoint Baseline - Microsoft Edge Baseline 3. Select appropriate baseline for your Windows version 4. Review default settings: - Each setting shows recommendation rationale - Note settings requiring business review 5. Customize if necessary: - Modify only settings conflicting with critical apps - Document all changes with business justification 6. Create baseline assignment: - Name and describe the baseline instance - Assign to pilot device group first 7. Deploy to production after successful pilot 8. Monitor compliance in Endpoint security → Security baselines

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines-settings-windows-11 https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines-settings-defender-atp

Explanation

Managing security baselines involves maintaining, updating, and monitoring baseline configurations across your environment. This includes handling baseline version updates, tracking compliance, remediating non-compliant devices, and adapting baselines as business needs or threat landscapes change.

Think of it as: Maintaining a building's security system—you need to update access codes, check that all doors are properly secured, and upgrade components as better technology becomes available.

Key Mechanics: - Baseline versions update with new Windows features and threats - Compliance reporting shows percentage of devices meeting baseline - Version migration requires testing before production rollout - Multiple baseline instances can exist for different device groups - Remediation occurs automatically for devices falling out of compliance

Examples

Example 1 — [Success] Baseline version migration with phased rollout Microsoft releases Windows 11 Security Baseline version 23H2 with updated Defender and BitLocker settings. The security team creates a new baseline instance in Intune using the new version, assigns it to a 30-device pilot group, monitors compliance for 3 weeks, then migrates the production assignment. All 1,200 production devices receive the updated settings within the next check-in cycle.

Example 2 — [Blocked] Multiple baseline instances conflict on the same device An admin creates two security baseline instances — one for "standard" settings and one for "high security" users. Both are assigned to the same device group. One baseline sets BitLocker encryption strength to AES-128; the other sets AES-256. Intune reports the device as in conflict and applies neither setting. Root cause: When two baseline instances configure the same setting for the same device, Intune marks the setting as "Conflict" — consolidate overlapping assignments or use separate device groups.

Key Mechanisms

- Core function: Managing security baselines involves maintaining, updating, and monitoring baseline configurations across your environment. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Baseline version migration with phased rollout - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Establish baseline monitoring: - Navigate to Endpoint security → Security baselines - View compliance by baseline type - Export reports for regular review 2. Manage non-compliant devices: - Identify root causes (settings overwritten, manual changes) - Use Intune remediation actions - Consider user education for intentional changes 3. Handle baseline version updates: - Review new version settings in Intune - Create new baseline instance with updated version - Test on pilot group (30+ days) - Migrate production assignments gradually 4. Maintain baseline documentation: - Record version history for each baseline - Document customizations and exceptions - Track deployment dates and success rates 5. Regular review cycle: - Quarterly baseline effectiveness review - Annual exception revalidation - Continuous monitoring for emerging threats

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines-monitor https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines-manage-updates https://learn.microsoft.com/en-us/mem/intune/protect/security-baselines-troubleshoot

Explanation

Integrating Intune with Microsoft Defender for Endpoint creates a unified endpoint security solution combining management (Intune) with advanced threat protection (Defender). This integration enables device risk-based conditional access, deep security configuration, and consolidated visibility across managed endpoints.

Think of it as: Connecting your building's management system with its security system—now security events can trigger automatic lockdowns, and facility managers have full visibility into security status.

Key Mechanics: - Integration requires both Intune and Defender for Endpoint licenses - Device risk scores from Defender feed into Conditional Access policies - Defender for Endpoint telemetry visible in Intune reporting - Security configurations can be deployed via Intune to Defender - Unified device inventory across both portals

Examples

Example 1 — [Success] High-risk device automatically blocked from corporate apps A SaaS developer's laptop receives a high-severity Defender for Endpoint alert indicating active malware execution. Defender updates the device risk score to "High." Intune receives the risk signal, marks the device as non-compliant, and Conditional Access immediately blocks the device from accessing Microsoft 365 apps. The developer sees an "Access Blocked - Device Not Compliant" error. After the IT team remediates the threat, compliance status restores and access returns automatically.

Example 2 — [Blocked] Defender onboarding ≠ Defender Antivirus policy configured An admin connects Intune to Defender for Endpoint and deploys the onboarding package to all devices. They assume Defender Antivirus is now fully configured. A week later, Defender reports show many devices with real-time protection disabled. Root cause: Defender for Endpoint onboarding (sensor connectivity) and Defender Antivirus configuration (policies, exclusions, scan schedules) are two separate configurations — onboarding the sensor does NOT configure AV policies; a separate Intune Antivirus policy is required.

Key Mechanisms

- Core function: Integrating Intune with Microsoft Defender for Endpoint creates a unified endpoint security solution combining management (Intune) with advanced threat protection (Defender). - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] High-risk device automatically blocked from corporate apps - Decision clue: Industry: Technology

Review Path

Steps:

1. Verify licensing: - Microsoft 365 E5 or E5 Security - Standalone Defender for Endpoint P1/P2 2. Configure Intune connection: - Go to Intune admin center → Tenant administration → Connectors and tokens - Select Microsoft Defender for Endpoint - Set "Allow Intune to receive Defender data" to On 3. Configure Defender connection: - Go to Microsoft 365 Defender portal → Settings - Select Endpoints → Advanced features - Enable Microsoft Intune connection 4. Verify connection status: - Both portals should show connected status - Device risk data appears in Intune within 24 hours 5. Create Conditional Access policies using risk: - Require compliant device for access - Optionally require device risk score below medium 6. Monitor integration health regularly

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/advanced-threat-protection https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-endpoint https://learn.microsoft.com/en-us/mem/intune/protect/conditional-access-integrate-jamf

Explanation

Onboarding devices to Microsoft Defender for Endpoint via Intune involves deploying configuration packages that connect endpoints to the Defender service. This enables advanced threat detection, response capabilities, and security telemetry collection from managed devices through the unified Intune management channel.

Think of it as: Installing security cameras and sensors throughout a building (devices) and connecting them to a central monitoring station (Defender) all through the existing maintenance team (Intune).

Key Mechanics: - Onboarding packages are unique to each tenant - Packages configure Defender client to connect to correct workspace - Multiple deployment methods: Intune, GPO, local script - Devices appear in Defender portal after successful onboarding - Offboarding packages remove devices from Defender service

Examples

Example 1 — [Success] Bulk onboarding 5,000 devices via Intune policy An organization creates an Intune configuration profile using the Defender for Endpoint onboarding .xml package and assigns it to all Windows device groups. Within 24 hours, all 5,000 devices appear in the Defender portal with active sensors, telemetry flowing, and threat detection enabled — zero manual intervention per device.

Example 2 — [Blocked] Onboarding package from wrong tenant deployed An IT admin downloads the onboarding package from a test tenant's Defender portal instead of the production tenant. They deploy it via Intune to 200 production devices. Devices check in but never appear in the production Defender portal. Root cause: Each onboarding package is unique to a specific tenant workspace ID — always download the package from the correct production Defender portal before deploying.

Key Mechanisms

- Core function: Onboarding devices to Microsoft Defender for Endpoint via Intune involves deploying configuration packages that connect endpoints to the Defender service. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Bulk onboarding 5,000 devices via Intune policy - Decision clue: Industry: Education

Review Path

Steps:

1. Access Microsoft 365 Defender portal: - Go to Settings → Endpoints → Onboarding 2. Select operating system (Windows 10/11) 3. Choose deployment method: "Microsoft Intune" 4. Download onboarding package (ZIP file containing .xml) 5. Navigate to Intune admin center: - Devices → Configuration profiles → Create profile 6. Select platform: Windows 10/11 - Profile type: "Microsoft Defender for Endpoint (Windows 10/11)" 7. Upload the onboarding .xml file 8. Configure additional settings: - Sample sharing - Telemetry reporting frequency 9. Assign to device groups and deploy 10. Verify onboarding in Defender portal

Docs: https://learn.microsoft.com/en-us/defender-endpoint/onboarding-endpoint-manager https://learn.microsoft.com/en-us/mem/intune/protect/advanced-threat-protection-configure#onboard-devices https://learn.microsoft.com/en-us/defender-endpoint/configure-endpoints-intune

Explanation

Onboarding devices to Microsoft Defender for Endpoint establishes the connection between endpoints and the Defender security service, enabling full advanced threat protection capabilities. The process installs the Defender sensor, configures communication with the cloud service, and begins collecting security telemetry for analysis and response.

Think of it as: Enrolling devices in a premium security monitoring service—once enrolled, every device contributes to threat intelligence and receives real-time protection updates.

Key Mechanics: - Onboarding installs the Defender for Endpoint sensor on devices - Multiple onboarding methods support different scenarios (Intune, GPO, local) - Devices must meet minimum OS requirements (Windows 10/11, Server) - Non-persistent VDI requires special onboarding configuration - Offboarding properly removes devices and stops data collection

Examples

Example 1 — [Success] Unified onboarding across diverse environments A multinational company uses three onboarding methods: Intune configuration profiles for 15,000 cloud-managed laptops, Group Policy ADMX templates for 8,000 on-premises desktops, and local PowerShell scripts for 500 air-gapped development systems. All devices appear in the unified Defender portal within 48 hours, providing centralized threat visibility across all environments.

Example 2 — [Blocked] Server onboarded via workstation method fails An admin downloads the Windows 10/11 onboarding package and deploys it to Windows Server 2019 machines via a local script. The servers appear briefly in Defender, then drop off. Root cause: Server onboarding uses a different package and method — Windows Server 2019 requires the dedicated Server onboarding script from the Defender portal's Server section, not the workstation package.

Key Mechanisms

- Core function: Onboarding devices to Microsoft Defender for Endpoint establishes the connection between endpoints and the Defender security service, enabling full advanced threat protection capabilities. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Unified onboarding across diverse environments - Decision clue: Industry: Multi-National Corporation

Review Path

Steps:

1. Plan onboarding strategy: - Inventory all devices requiring onboarding - Determine management method for each group - Verify OS version compatibility 2. For Intune-managed devices: - Follow Intune-specific onboarding steps - Deploy via configuration profile 3. For GPO-managed devices: - Download onboarding package from Defender portal - Create ADMX policy for Defender configuration - Deploy via Group Policy Management Console 4. For local/manual onboarding: - Download local script package - Run as Administrator on target device - Verify connectivity to Defender service 5. For servers: - Use Configuration Manager if available - Or deploy via preferred server management tool 6. Verify onboarding: - Check devices appear in Defender portal - Confirm telemetry is flowing - Test alert generation

Docs: https://learn.microsoft.com/en-us/defender-endpoint/onboarding https://learn.microsoft.com/en-us/defender-endpoint/configure-endpoints https://learn.microsoft.com/en-us/defender-endpoint/onboarding-endpoint-manager

Explanation

Endpoint Detection and Response (EDR) in Microsoft Defender for Endpoint provides continuous monitoring, behavioral analysis, and automated response to sophisticated threats. EDR captures detailed telemetry from endpoints, identifies suspicious patterns, and enables security teams to investigate and respond to incidents with deep visibility into attack timelines.

Think of it as: A forensic investigation team that never sleeps—constantly recording everything that happens, analyzing for suspicious patterns, and providing detectives with complete evidence when incidents occur.

Key Mechanics: - Continuous recording of process, network, and file activities - Behavioral detection identifies attack patterns, not just signatures - Automated investigation and remediation for common threats - Investigation timeline shows complete attack sequence - Deep analysis tools for hunting and threat research

Examples

Example 1 — [Success] Full attack chain reconstructed from EDR timeline A suspicious PowerShell script executes on a finance workstation. The security team opens the EDR incident timeline: they see the parent process (Outlook), the malicious attachment that spawned it, network connections to a C2 server, file writes to %AppData%, and a persistence registry key. The complete attack chain from phishing email to data staging is visible in one view, enabling full remediation within 2 hours.

Example 2 — [Blocked] EDR data unavailable — device not onboarded A security analyst receives an alert for a high-severity incident on a manufacturing floor PC. When they try to view the investigation timeline and device telemetry, the Defender portal shows "No data available." Root cause: The manufacturing PC was never onboarded to Defender for Endpoint — EDR capabilities require the Defender sensor to be installed and the device onboarded; without onboarding, no telemetry is collected.

Key Mechanisms

- Core function: Endpoint Detection and Response (EDR) in Microsoft Defender for Endpoint provides continuous monitoring, behavioral analysis, and automated response to sophisticated threats. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Full attack chain reconstructed from EDR timeline - Decision clue: Industry: Financial Services

Review Path

Steps:

1. Ensure proper licensing: - Defender for Endpoint Plan 2 (includes EDR) - Verify all devices have appropriate license 2. Confirm EDR is enabled: - Default configuration enables EDR on onboarding - Verify in Defender portal → Settings → Endpoints → Advanced features 3. Access EDR capabilities: - Microsoft 365 Defender portal → Incidents & alerts - View active incidents requiring investigation 4. Use investigation timeline: - Select affected device - Review complete activity timeline - Expand process trees for full context 5. Perform advanced hunting: - Use Kusto Query Language (KQL) - Query across all endpoint data - Create custom detection rules 6. Respond to incidents: - Use response actions (isolate, contain) - Collect investigation packages - Remediate confirmed threats

Docs: https://learn.microsoft.com/en-us/defender-endpoint/overview-endpoint-detection-response https://learn.microsoft.com/en-us/defender-endpoint/incidents-queue https://learn.microsoft.com/en-us/defender-endpoint/advanced-hunting-overview

Explanation

The Security Operations Dashboard in Microsoft 365 Defender provides a centralized view of threat landscape, alert status, and device health across all onboarded endpoints. It enables security teams to prioritize incidents, track response progress, and monitor overall security posture through interactive visualizations and real-time data.

Think of it as: A mission control center where security analysts can see every alert, incident, and system health metric at a glance, helping them focus on the most critical threats first.

Key Mechanics: - Dashboard shows active incidents, alerts, and affected devices - Severity-based prioritization helps focus on critical threats - Automated investigation status tracks remediation progress - Time-series views show threat trends over time - Drill-down capabilities provide detailed incident context

Examples

Example 1 — [Success] Overnight incidents triaged before business hours A security analyst starts their 7am shift and opens the Security Operations Dashboard. Three critical incidents are visible at the top, all generated overnight. The dashboard shows automated investigation results for two of them (threat remediated, no action needed), leaving only one requiring manual review. The analyst drills into the active incident, reviews the attack timeline, and isolates the device — all before the first user logs in at 9am.

Example 2 — [Blocked] Dashboard shows no incidents — permissions misconfigured A newly hired security analyst is told to monitor the dashboard but reports seeing zero incidents even though the security team knows there are active alerts. Root cause: The analyst was assigned the "Security Reader" role in Entra ID, but NOT the "Security Reader" role in the Microsoft 365 Defender portal — the two role systems are separate. Full dashboard visibility requires the correct role assignment in the Defender portal, not just Entra ID.

Key Mechanisms

- Core function: The Security Operations Dashboard in Microsoft 365 Defender provides a centralized view of threat landscape, alert status, and device health across all onboarded endpoints. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Overnight incidents triaged before business hours - Decision clue: Industry: Managed Security Provider

Review Path

Steps:

1. Access Microsoft 365 Defender portal: - Navigate to security.microsoft.com - Ensure appropriate permissions (Security Reader/Analyst/Admin) 2. Review dashboard components: - Incidents by severity - Active alerts count - Affected assets - Automated investigation status 3. Customize view: - Click "Edit" on dashboard - Add/remove widgets as needed - Set default time range 4. Use filtering: - Filter by date range - Filter by severity or status - Filter by device group or tag 5. Drill down into incidents: - Click any incident for details - View investigation timeline - Access response options 6. Create saved views for common monitoring tasks

Docs: https://learn.microsoft.com/en-us/defender-endpoint/security-operations-dashboard https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/microsoft-defender-security-center https://learn.microsoft.com/en-us/defender-endpoint/incidents-queue

Explanation

Threat protection reports in Microsoft Defender for Endpoint provide detailed analytics on detected threats, device health, and protection effectiveness across your organization. These reports help security teams understand threat trends, measure security posture improvements, and demonstrate compliance to stakeholders through data-driven insights.

Think of it as: A health report card for your organization's security—showing what threats you've faced, how well you've protected against them, and where you need to improve.

Key Mechanics: - Reports include threat detection trends, alert volumes, and severity distribution - Device health reports show onboarding status and sensor health - Protection updates show antivirus and signature update status - Reports can be scheduled for regular delivery - Data supports trend analysis and security metric reporting

Examples

Example 1 — [Success] Board report shows 40% reduction in successful infections A CISO exports a 90-day threat protection report from the Defender portal, showing detection trends before and after Defender for Endpoint deployment. The report shows a 40% reduction in successful malware infections, MTTD of 2.4 minutes, and 98.7% of threats blocked automatically. The board approves continued security investment based on the data.

Example 2 — [Blocked] Report shows 30% of devices with outdated sensor signatures A monthly device health report reveals 350 of 1,200 devices have Defender signatures more than 7 days old, leaving them vulnerable to recent threats. Root cause: Those devices are not reaching Windows Update due to network segmentation — they need a WSUS or update ring configuration to receive signature updates on the isolated network segment.

Key Mechanisms

- Core function: Threat protection reports in Microsoft Defender for Endpoint provide detailed analytics on detected threats, device health, and protection effectiveness across your organization. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Board report shows 40% reduction in successful infections - Decision clue: Industry: Retail

Review Path

Steps:

1. Navigate to Microsoft 365 Defender portal → Reports 2. Review available reports: - Threat protection report - Device health and compliance - Web protection - Vulnerability management 3. Customize report parameters: - Set date range (last 7, 30, 90 days) - Filter by device groups - Filter by severity 4. Generate threat protection report: - View detection trends - Analyze alert categories - Review automated investigation results 5. Export reports: - Export as PDF or CSV - Schedule recurring exports 6. Create advanced hunting queries for custom reporting: - Use KQL to extract specific metrics - Save and share queries with team

Docs: https://learn.microsoft.com/en-us/defender-endpoint/threat-protection-reports https://learn.microsoft.com/en-us/defender-endpoint/device-health-reports https://learn.microsoft.com/en-us/defender-endpoint/advanced-hunting-overview

Explanation

Planning for device updates involves developing a comprehensive strategy for managing Windows updates across your organization, considering business needs, compliance requirements, and operational impact. Effective update planning balances security needs with stability requirements, ensuring devices remain protected without disrupting productivity.

Think of it as: Planning a city-wide infrastructure maintenance schedule—you need to fix roads (security updates) without gridlocking traffic (user productivity), and you need different schedules for different neighborhoods (device groups).

Key Mechanics: - Update rings group devices with similar update requirements - Deployment schedules account for testing, pilot, and production phases - Maintenance windows define when updates can install - Ring progression allows graduated deployment to reduce risk - Rollback planning prepares for update-related issues

Examples

Example 1 — [Success] Phased rollout catches incompatible driver update A global company creates four update rings: Ring 0 (IT test, 5 devices, immediate), Ring 1 (pilot, 50 early adopters, 3-day deferral), Ring 2 (general staff, 7-day deferral), Ring 3 (critical systems, 14-day deferral). A January quality update causes crashes on a specific Dell laptop model. Ring 0 catches the issue before Ring 2 deploys — IT pauses the update ring, waits for Microsoft's driver fix, then resumes deployment. 2,000 devices are protected from the bad update.

Example 2 — [Blocked] No rollback plan — bad update reaches all devices simultaneously An admin deploys a quality update to all 800 devices at once with no ring structure. The update introduces a Bluetooth driver conflict affecting all devices in one meeting room simultaneously during a client presentation. With no ring structure and no rollback procedure documented, IT must manually revert each device. Root cause: Without update rings and a tested rollback plan, a single bad update can simultaneously affect all devices with no automated mitigation.

Key Mechanisms

- Core function: Planning for device updates involves developing a comprehensive strategy for managing Windows updates across your organization, considering business needs, compliance requirements, and operational impact. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Phased rollout catches incompatible driver update - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Assess environment: - Inventory all Windows devices - Document device types and criticality - Identify update compatibility requirements 2. Define update rings: - Create ring structure (3-4 rings recommended) - Determine deferral periods for each ring - Document membership criteria 3. Establish maintenance windows: - Based on device usage patterns - Consider time zones for global organizations - Define exceptions for critical systems 4. Plan testing process: - Test updates in Ring 0 before broader rollout - Document test procedures - Establish pass/fail criteria 5. Create communication plan: - Notify users before update windows - Provide update schedules - Establish issue reporting channels 6. Document rollback procedures: - Steps to pause problematic updates - Process for reverting changes - Escalation contacts

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-for-business-plan https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wufb https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-rings

Explanation

Windows as a Service (WaaS) is Microsoft's modern servicing model for Windows 10/11, delivering continuous feature and quality updates rather than traditional major version releases. This model enables faster innovation, predictable update cadences, and reduced deployment complexity through cumulative updates and servicing channels.

Think of it as: A subscription to a continuously improving operating system rather than buying a new version every few years—your Windows gets better over time through regular, manageable updates.

Key Mechanics: - Feature updates (twice yearly) add new features and capabilities - Quality updates (monthly) provide security and reliability fixes - Servicing channels (General Availability, Long-Term Servicing) offer different update velocities - Cumulative updates include all previous fixes in one package - Update rings control when devices receive updates

Examples

Example 1 — [Success] Separating security cadence from feature cadence An organization configures two independent schedules: monthly quality updates deploy automatically within 7 days (security stays current) while feature updates are deferred 180 days for compatibility testing. When Windows 11 23H2 releases in October, the test group receives it immediately while production devices hold at 22H2 until April — providing 6 months of validation time without delaying security patches.

Example 2 — [Blocked] LTSC device receives no feature updates — by design, not a bug A new admin notices that manufacturing floor PCs running Windows 10 LTSC have not received any feature updates in 18 months and raises an urgent ticket. Root cause: Windows LTSC (Long-Term Servicing Channel) deliberately does not receive semi-annual feature updates — it only receives quality (security) updates. This is the intended behavior for specialized systems; if feature updates are needed, the device should be moved to the General Availability Channel.

Key Mechanisms

- Core function: Windows as a Service (WaaS) is Microsoft's modern servicing model for Windows 10/11, delivering continuous feature and quality updates rather than traditional major version releases. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Separating security cadence from feature cadence - Decision clue: Industry: Manufacturing

Review Path

Steps:

1. Understand WaaS fundamentals: - Review Microsoft documentation on servicing channels - Identify which Windows editions support which channels 2. Choose servicing strategy: - General Availability Channel for most devices - LTSC for specialized systems (medical, industrial) - Insider for testing/devices 3. Configure update rings in Intune: - Go to Devices → Update rings for Windows - Create rings with appropriate deferral periods 4. Set feature update deferral: - Determine deferral period (0-365 days) - Consider testing time in your decision 5. Configure quality update settings: - Set automatic update behavior - Define deadlines for installation 6. Monitor update compliance: - Use Windows Update reports - Track update success rates

Docs: https://learn.microsoft.com/en-us/windows/deployment/update/waas-overview https://learn.microsoft.com/en-us/windows/deployment/update/waas-quick-start https://learn.microsoft.com/en-us/windows/deployment/update/waas-options

Explanation

Preparing a servicing strategy involves designing a comprehensive approach to Windows client updates that addresses your organization's security, compliance, and operational needs. This strategy defines update classification, deployment rings, testing requirements, and rollback procedures to ensure reliable and secure update delivery.

Think of it as: Creating a detailed battle plan for keeping your army's equipment (devices) in top condition—when to service, who gets new gear first, how to test, and what to do if something breaks.

Key Mechanics: - Update classification differentiates feature, quality, and driver updates - Deployment rings provide graduated rollout with validation at each stage - Testing requirements define validation criteria before production rollout - Rollback procedures ensure quick recovery from update issues - Compliance monitoring tracks update status across all devices

Examples

Example 1 — [Success] Academic year and summer strategies differentiated A school district creates two distinct update strategies: during the academic year, only quality updates deploy (Sunday 2–6am, 7-day deferral) and feature updates are blocked; during summer break, feature updates deploy to all student devices over a 3-week period with Ring 0 (IT labs) validated before Ring 1 (classrooms). School year starts with all devices on the latest stable Windows version.

Example 2 — [Blocked] "Pause updates" used as permanent workaround An admin pauses Windows updates on 50 executive laptops to avoid a disruptive update. Months later, the pause expiration is forgotten, and the devices are now 8 months behind on security patches, flagged in a compliance audit. Root cause: Update pause is a temporary tool (35-day maximum), not a long-term management strategy — use a maintenance window or extended deferral ring instead for devices requiring delayed updates.

Key Mechanisms

- Core function: Preparing a servicing strategy involves designing a comprehensive approach to Windows client updates that addresses your organization's security, compliance, and operational needs. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Academic year and summer strategies differentiated - Decision clue: Industry: Education

Review Path

Steps:

1. Classify update types: - Feature updates: Major version changes - Quality updates: Monthly security fixes - Driver updates: Hardware compatibility 2. Define deployment rings: - Ring 0 (Test): IT team, immediate deployment - Ring 1 (Pilot): Volunteers, 7-day deferral - Ring 2 (Production): General staff, 14-day deferral - Ring 3 (Critical): Executives, 30-day deferral 3. Establish testing criteria: - Application compatibility validation - Performance baseline checks - Security feature verification 4. Create update windows: - Based on device usage patterns - Consider time zones - Define exceptions 5. Document rollback procedures: - Pause update ring in Intune - Uninstall problematic updates if possible - Restore from backup if needed 6. Set up monitoring: - Configure update compliance reports - Create alerts for failed updates

Docs: https://learn.microsoft.com/en-us/windows/deployment/update/plan-determine-strategy https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-rings https://learn.microsoft.com/en-us/windows/deployment/update/waas-optimize-update-delivery

Explanation

iOS/iPadOS software update policies in Intune allow organizations to manage how Apple devices receive OS updates. These policies can require devices to run minimum OS versions, defer updates, or enforce immediate installation, helping maintain security compliance across Apple devices.

Think of it as: A fleet manager for Apple devices that ensures all vehicles (iPhones/iPads) have the latest safety features (updates) installed according to company policy.

Key Mechanics: - Update policies require supervised devices (DEP or Apple Configurator) - Policies can require minimum OS version for compliance - Deferral options delay updates up to 90 days - Installation can be enforced during specified time windows - Compliance reporting shows devices requiring updates

Examples

Example 1 — [Success] Hospital iPads enforced to latest iOS within 30 days A hospital requires all supervised patient check-in iPads to run iOS 17 or later. An iOS update policy sets the minimum OS version and configures a 30-day enforcement window with 0-day deferral for security updates. When Apple releases iOS 17.3 with a critical security fix, all iPads download and install it overnight during the configured maintenance window. The compliance dashboard shows 100% devices on compliant iOS within 72 hours.

Example 2 — [Blocked] Update policy silently does nothing — devices not supervised An admin creates an iOS update policy with 0-day deferral and assigns it to all enrolled iPhones. A week later, half the devices are still on an outdated iOS version. Root cause: iOS update policies in Intune only apply to supervised devices enrolled via Apple Business Manager (DEP/ADE). Personally-enrolled (user-enrolled) devices cannot be forced to update — supervision is a prerequisite for enforced iOS updates.

Key Mechanisms

- Core function: iOS/iPadOS software update policies in Intune allow organizations to manage how Apple devices receive OS updates. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Hospital iPads enforced to latest iOS within 30 days - Decision clue: Industry: Healthcare

Review Path

Steps:

1. Verify prerequisites: - Devices must be supervised - Apple Business Manager enrollment recommended - Devices enrolled via DEP or Apple Configurator 2. Navigate to Intune admin center: - Devices → iOS/iPadOS → Update policies 3. Click "Create profile" → "iOS/iPadOS update policy" 4. Configure basic settings: - Name and description - Select supervised devices only 5. Set update requirements: - Minimum required OS version - Deferral period (0-90 days) - Installation type (Download and install only) 6. Configure installation window if desired: - Set start/end times for updates - Consider device usage patterns 7. Assign to device groups 8. Monitor compliance: - Check policy status in reports - Identify devices requiring updates

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/software-updates-ios https://learn.microsoft.com/en-us/mem/intune/protect/software-updates-ios-policy https://learn.microsoft.com/en-us/mem/intune/enrollment/ios-ipados-supervised-enrollment

Explanation

Update rings in Intune are policies that control how and when Windows devices receive updates from Windows Update for Business. They define update deferral periods, installation deadlines, and user experience settings, enabling graduated rollout of updates across different device groups.

Think of it as: Creating different lanes on a highway with different speed limits and merge points—some lanes (rings) get updates faster, some slower, but all ultimately reach the same destination.

Key Mechanics: - Update rings group devices with similar update requirements - Deferral periods delay feature and quality updates - Installation deadlines force updates after specified days - User experience settings control restart behavior and notifications - Multiple rings enable phased deployment strategies

Examples

Example 1 — [Success] Graduated ring deployment catches bad update in pilot An organization creates three update rings: Ring 0 (IT, 0-day deferral), Ring 1 (Pilot, 7-day deferral), Ring 2 (Production, 14-day deferral). When a January quality update breaks a line-of-business app, Ring 0's IT team identifies the issue after 2 days. The admin pauses Rings 1 and 2 in Intune before any non-IT devices receive the update, preventing 3,000 devices from hitting the breakage.

Example 2 — [Blocked] Deferral miscalculated — admin counts from enrollment, not release An admin sets a 14-day quality update deferral expecting devices enrolled on Feb 1 to receive January patches by Feb 15. Instead, devices receive nothing. Root cause: Update ring deferral periods count from Microsoft's public release date (Patch Tuesday), NOT from the device's enrollment date. A January update released Jan 10 with 14-day deferral becomes available Jan 24 to all devices regardless of when they enrolled.

Key Mechanisms

- Core function: Update rings in Intune are policies that control how and when Windows devices receive updates from Windows Update for Business. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Graduated ring deployment catches bad update in pilot - Decision clue: Industry: Retail

Review Path

Steps:

1. Navigate to Microsoft Intune admin center: - Devices → Update rings for Windows 10/11 2. Click "Create profile" to create new update ring 3. Configure basic settings: - Name and description - Servicing channel (General Availability, etc.) 4. Set update settings: - Feature update deferral (0-365 days) - Quality update deferral (0-30 days) - Installation deadline for feature updates - Installation deadline for quality updates 5. Configure user experience: - Automatic update behavior - Restart checks - Active hours for blocking restarts 6. Set deadline grace period: - Days before automatic restarts - End-of-support notifications 7. Assign to device groups 8. Create additional rings with different settings 9. Monitor ring compliance and adjust as needed

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/windows-10-update-rings https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-rings-create https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-for-business-configure

Explanation

Windows Update for Business (WUfB) is a service that enables IT administrators to manage Windows updates directly from Microsoft's update services, reducing management overhead while maintaining control over update deployment. It replaces traditional WSUS infrastructure with cloud-based update management through Intune policies.

Think of it as: Moving from running your own private post office (WSUS) to using a premium courier service (WUfB) that handles delivery logistics while you control the shipping schedule.

Key Mechanics: - WUfB connects devices directly to Microsoft's update servers - Update rings control deferral periods and deadlines - Delivery Optimization manages peer-to-peer update sharing - Update compliance reports provide visibility - No on-premises infrastructure required

Examples

Example 1 — [Success] WSUS decommissioned, remote workers now update reliably A consulting firm with 600 remote workers previously relied on WSUS — but devices off-VPN never received updates. After migrating to Windows Update for Business via Intune, all remote devices fetch updates directly from Microsoft's CDN with configured 14-day quality update deferral and 90-day feature update deferral. WSUS servers are decommissioned. Update compliance jumps from 68% to 97% within 30 days.

Example 2 — [Blocked] WUfB and WSUS conflict — devices receive no updates An admin enables WUfB update rings in Intune but doesn't remove the existing Group Policy that points devices to an internal WSUS server. Devices now receive conflicting update instructions and stop receiving any updates. Root cause: WSUS GPO settings override WUfB policies — you must remove or disable the WSUS-pointing GPO (WUSERVER and related keys) before WUfB policies take effect.

Key Mechanisms

- Core function: Windows Update for Business (WUfB) is a service that enables IT administrators to manage Windows updates directly from Microsoft's update services, reducing management overhead while maintaining control over update deployment. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] WSUS decommissioned, remote workers now update reliably - Decision clue: Industry: Professional Services

Review Path

Steps:

1. Prepare for WUfB: - Ensure devices running Windows 10/11 Pro/Enterprise - Remove conflicting update policies (WSUS, GPO) 2. Configure WUfB through Intune: - Create update rings with deferral settings - Set feature update deferral (0-365 days) - Set quality update deferral (0-30 days) 3. Enable Delivery Optimization: - Go to Devices → Configuration profiles - Create profile with Delivery Optimization settings - Configure peer-to-peer sharing options 4. Set installation deadlines: - Define days before automatic installation - Configure restart behavior 5. Configure update compliance: - Enroll in Microsoft 365 Defender - Access update reports in Defender portal 6. Test on pilot devices before full rollout 7. Monitor and adjust settings as needed

Docs: https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wufb https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-for-business-configure https://learn.microsoft.com/en-us/windows/deployment/update/waas-optimize-update-delivery

Explanation

Update policies for iOS and macOS in Intune control how Apple devices receive OS updates, ensuring security compliance across your Apple fleet. iOS policies manage supervised devices with minimum version requirements, while macOS policies can enforce updates through various mechanisms including compliance policies.

Think of it as: A maintenance schedule for both iPhones and Macs that ensures all Apple devices in your organization run approved, secure operating system versions.

Key Mechanics: - iOS policies require supervised devices for full control - Minimum OS version requirements enforce baseline security - macOS updates can be managed through compliance policies - Deferral options available for iOS updates (up to 90 days) - Compliance reporting shows devices requiring updates

Examples

Example 1 — [Success] Unified Apple update compliance across iPhones and Macs A creative agency requires all supervised iPhones to run iOS 17+ and all Macs to run macOS 14 (Sonoma) or newer. iOS update policies enforce the minimum version on supervised devices with 30-day deferral for non-security updates. macOS compliance policies mark devices as non-compliant if below macOS 14, prompting users to update. Within 45 days, 98% of the Apple fleet is on approved OS versions.

Example 2 — [Blocked] macOS update policy has no enforcement mechanism An admin creates a macOS "Software Update" configuration profile in Intune that sets automatic updates to enabled. Three months later, 40% of Macs still run an outdated macOS version. Root cause: macOS configuration profiles can enable automatic update checking, but unlike iOS, they cannot force installation of macOS major version upgrades on enrolled (but not supervised) Macs — a compliance policy with conditional access enforcement is required to block non-compliant devices.

Key Mechanisms

- Core function: Update policies for iOS and macOS in Intune control how Apple devices receive OS updates, ensuring security compliance across your Apple fleet. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Unified Apple update compliance across iPhones and Macs - Decision clue: Industry: Creative Agency

Review Path

Steps:

1. For iOS/iPadOS update policies: - Verify devices are supervised (ABM enrollment) - Go to Devices → iOS/iPadOS → Update policies - Create policy with minimum OS version - Set deferral period (if desired) - Assign to device groups 2. For iOS compliance: - Create compliance policy requiring OS version - Set actions for non-compliance (mark device, notify user) 3. For macOS update management: - Create compliance policy with minimum OS requirement - Create configuration profile for Software Update: - Automatic check for updates: Enable - Download available updates: Enable - Install macOS updates: Configure as needed 4. Use scripts for advanced scenarios: - Deploy PowerShell scripts to check/trigger updates - Use Jamf integration if available 5. Monitor compliance: - Check reports in Intune - Identify outdated devices - Follow up with users

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/software-updates-ios https://learn.microsoft.com/en-us/mem/intune/protect/software-updates-macos https://learn.microsoft.com/en-us/mem/intune/configuration/custom-settings-macos

Explanation

Managing Android updates involves using Firmware-Over-The-Air (FOTA) deployments through device manufacturers' update services or Android Enterprise system updates. FOTA enables centralized management of OS updates across Android devices, ensuring security patches and feature updates reach devices in a controlled manner.

Think of it as: A centralized air traffic control system for Android updates—ensuring every Android device in your fleet gets the right updates at the right time, regardless of manufacturer.

Key Mechanisms: - System update policies control when and how updates install - FOTA deployments come from device manufacturers' servers - Android Enterprise work profiles have separate update management - Update deferral available up to 90 days (depending on OEM) - Compliance policies enforce minimum OS versions

Examples

Example 1 — [Success] Logistics scanner fleet kept patched via Android Enterprise A logistics company enrolls all Android handheld scanners in Android Enterprise Dedicated device mode. An Intune system update policy uses "Windowed" mode, scheduling updates from 2am–5am nightly. Security patch levels across the scanner fleet stay within 30 days of the latest release, and a compliance policy blocks access to warehouse apps if any device exceeds 60 days without a patch.

Example 2 — [Blocked] Android Enterprise system update policy ignored by Samsung devices An admin creates an Intune system update policy for Samsung Galaxy devices expecting automatic overnight patching. After 3 months, many Samsungs still show outdated security patches. Root cause: Samsung devices on Android Enterprise may use Samsung Knox FOTA service instead of Android Enterprise system updates — Intune's system update policy may not override Knox FOTA on Samsung devices. Samsung-specific update management through Knox is required for granular control.

Key Mechanisms

- Core function: Managing Android updates involves using Firmware-Over-The-Air (FOTA) deployments through device manufacturers' update services or Android Enterprise system updates. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Logistics scanner fleet kept patched via Android Enterprise - Decision clue: Industry: Logistics

Review Path

Steps:

1. Identify Android devices and their management capabilities: - Samsung devices: Consider Samsung Knox Manage - Other devices: Use Android Enterprise system updates 2. For Android Enterprise managed devices: - Go to Devices → Android → Configuration profiles - Create profile → "System update" for Android Enterprise - Choose update type: Automatic, Windowed, or Postponed - Set maintenance window (if using Windowed) - Deploy to device groups 3. For Samsung devices with Knox: - Configure Knox Manage console - Set FOTA policies with update windows - Deploy through Knox to Samsung devices 4. Create compliance policies: - Go to Endpoint security → Device compliance - Create Android compliance policy - Set minimum security patch level requirement - Set minimum OS version 5. Configure actions for non-compliance: - Mark device non-compliant - Block access to corporate resources - Notify user 6. Monitor compliance regularly

Docs: https://learn.microsoft.com/en-us/mem/intune/protect/software-updates-android https://learn.microsoft.com/en-us/mem/intune/configuration/android-enterprise-settings#system-update https://learn.microsoft.com/en-us/mem/intune/protect/compliance-policy-create-android

Explanation

Delivery Optimization is Windows' peer-to-peer distribution technology that reduces bandwidth consumption for update and app downloads. It allows devices to obtain content from multiple sources—Microsoft servers, other devices on the same network, and devices on the internet—optimizing download speed and reducing WAN traffic.

Think of it as: A community library system where instead of everyone ordering books (updates) from the central library (Microsoft), neighbors share books they've already received, reducing the load on the central library.

Key Mechanics: - Peer-to-peer sharing occurs between devices on same network or internet - Download modes control sharing scope (LAN only, internet, group) - Bandwidth throttling limits network usage during business hours - Caching servers can be used for branch offices - Works with Windows Update, Microsoft Store, and Intune content

Examples

Example 1 — [Success] WAN bandwidth reduced 70% with LAN peer caching A retail chain with 100 POS devices at each store location configures Delivery Optimization in Intune with DODownloadMode=1 (LAN peers only). The first device at each store downloads a monthly quality update from Microsoft; the remaining 99 devices receive it via LAN peer sharing. WAN bandwidth usage drops by 70% per store, and all POS devices receive updates within the same maintenance window.

Example 2 — [Blocked] DODownloadMode=1 configured but peer cache never activates An admin sets Delivery Optimization to LAN mode (DODownloadMode=1) across 200 devices at a corporate campus. Monitoring shows all devices still downloading directly from Microsoft with no peer sharing. Root cause: DODownloadMode=1 (LAN peers) requires devices to be on the same subnet — if all 200 devices span different network segments or VLANs, Delivery Optimization cannot discover peers. Use DODownloadMode=2 (Group) or Microsoft Connected Cache for devices across subnets.

Key Mechanisms

- Core function: Delivery Optimization is Windows' peer-to-peer distribution technology that reduces bandwidth consumption for update and app downloads. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] WAN bandwidth reduced 70% with LAN peer caching - Decision clue: Industry: Retail

Review Path

Steps:

1. Navigate to Intune admin center → Devices → Configuration profiles 2. Click "Create profile" → Platform: Windows 10/11 → Profile: Delivery Optimization 3. Configure download mode: - HTTP only (0): No P2P, HTTP only - LAN (1): P2P on same NAT only - Group (2): Cross-subnet group sharing - Internet (3): Internet P2P with trusted groups - Simple (99): Simple download mode with no P2P 4. Set bandwidth optimization: - Enable background download throttling - Set percentage or absolute limits - Configure foreground download throttling 5. Configure cache settings: - Set maximum cache size (GB or percentage) - Define cache retention policy 6. For branch offices: - Consider Microsoft Connected Cache - Deploy cache server on-premises 7. Deploy policy to devices 8. Monitor effectiveness: - Check Delivery Optimization logs - Use performance monitor to track bandwidth savings

Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/delivery-optimization-windows https://learn.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization https://learn.microsoft.com/en-us/mem/intune/configuration/delivery-optimization-settings

Explanation

Monitoring updates involves tracking update deployment status, compliance, and issues across all managed devices. Windows Update reports in Microsoft 365 Defender provide comprehensive visibility into update adoption, failure rates, and devices requiring attention, enabling proactive management of the update process.

Think of it as: A mission control dashboard for your update program, showing real-time status of every device's update journey and highlighting any vehicles (devices) that have broken down or fallen behind.

Key Mechanics: - Update compliance shows devices with latest updates installed - Failure reports identify devices with update errors - Deployment progress tracks rollout across update rings - Device health indicators show update-related issues - Historical data enables trend analysis

Examples

Example 1 — [Success] 50 failed-update devices identified and remediated A security admin reviews the Windows Update compliance report in Microsoft 365 Defender after Patch Tuesday. The report shows 50 devices with update failure error 0x800f0922 (insufficient disk space). The admin creates a dynamic group targeting those devices, runs a remediation script to clear Windows Update cache and temp files, then re-triggers the update. All 50 devices show compliant within 48 hours. The finance audit team receives the weekly export showing 99.1% compliance.

Example 2 — [Blocked] Update compliance report shows 0 devices — diagnostic data not enabled An admin generates a Windows Update compliance report but sees no data for any device. Root cause: Windows Update compliance reporting requires devices to send Windows diagnostic data — if the "Allow Telemetry" or "Diagnostic Data" setting is set to "Off" (Security level) in Intune, no update telemetry is collected and the report is empty. Set diagnostic data to at least "Required" to enable update compliance reporting.

Key Mechanisms

- Core function: Monitoring updates involves tracking update deployment status, compliance, and issues across all managed devices. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] 50 failed-update devices identified and remediated - Decision clue: Industry: Finance

Review Path

Steps:

1. Enable Windows Update reporting: - Ensure devices are onboarded to Microsoft 365 Defender - Configure diagnostic data settings to "Optional" - Allow up to 24 hours for data to populate 2. Access reports: - Go to Microsoft 365 Defender portal → Reports - Select "Windows Update" under Endpoints 3. Review key reports: - Update compliance: Percentage of devices current - Deployment status: Progress by update ring - Driver updates: Driver deployment status - Failure analysis: Common error codes 4. Create custom queries: - Use advanced hunting for specific insights - Query devices with particular error codes - Track devices missing specific updates 5. Set up alerts: - Configure alert rules for update failures - Set notification thresholds 6. Export and share reports: - Schedule regular report exports - Share with stakeholders

Docs: https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-reports https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-reports https://learn.microsoft.com/en-us/defender-endpoint/tvm-windows-update-report

Explanation

Windows Update Compliance Reports in Intune provide visibility into the update status of the Windows device fleet, showing which devices have received quality updates, feature updates, and drivers. Reports include overall compliance percentages, devices with pending or failed updates, and failure reason codes. These reports integrate with Update Rings and Feature Update policies, giving IT real-time insight into deployment progress. Data is available through the Intune admin center Reports section and can be exported for audit and compliance documentation. MD-102 requires understanding how to read, generate, and act on these reports for update management and security compliance.

Examples

Example 1 — [Success] Ring compliance validated before production rollout A bank's IT team generates a Windows Update Compliance Report after Ring 1 (pilot, 200 devices) receives February's Patch Tuesday update. The report shows 98% compliance with Ring 1, and 3 devices flagged for low disk space. IT remediates those 3 devices before approving Ring 2 (production, 3,000 devices) for deployment — preventing a known failure from reaching the production fleet.

Example 2 — [Blocked] Report data is 48 hours stale during an incident During a critical zero-day response, a security analyst generates a Windows Update Compliance Report to find which devices are still missing the emergency patch. The report shows data from 2 days ago. Root cause: Windows Update Compliance Reports are not real-time — they reflect diagnostic data uploaded on Windows telemetry schedules, which can lag 24–48 hours. For immediate status, use the Intune device list filtered by OS build version or run a live Device Query via Advanced Analytics.

Key Mechanisms

- Core function: Windows Update Compliance Reports in Intune provide visibility into the update status of the Windows device fleet, showing which devices have received quality updates, feature updates, and drivers. - Category fit: This concept belongs to monitoring, troubleshooting, and recovery and should be identified by purpose, not just by name recognition. - Real signal: Example 1 — [Success] Ring compliance validated before production rollout - Decision clue: A bank's compliance team requires weekly evidence that all endpoints have current security patches.

Review Path

Access Windows Update Compliance Reports:

1. Intune admin center → Reports → Windows updates 2. Click Reports tab 3. Select Windows Update Compliance Report 4. Configure filters: date range, device groups, update type 5. Click Generate report (may take a few minutes) 6. Review compliance metrics and drill into non-compliant devices 7. Select individual devices to see specific failure reasons 8. Export to CSV for audit documentation

Learn more: https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-compliance-reports