Troubleshooting Windows Feature updates in Microsoft Intune
By: Luke Ramsdale – Sr Security Customer Escalation Engineer | Microsoft Intune Effectively managing feature updates for Windows devices is essential for maintaining system performance and security. This article focuses on the troubleshooting steps necessary to address common issues with feature update policies in Intune. The feature update policy in Intune allows you to choose the Windows feature update version that devices should stay on or update to. The process of managing feature updates on Windows 10 and 11 devices is done through a combination of update ring and feature update policies. Update ring policies utilize the Policy CSP - Update to configure the Windows devices with the desired settings. Note: The unified suite of Windows update tools is officially known as Windows Autopatch. For further details, please visit: Why Windows Autopatch is the smart update solution - Windows IT Pro Blog to learn more. Prerequisites The first step in troubleshooting feature updates is to ensure the prerequisites are in place. This is a crucial step to take to ensure a smooth feature update policy implementation; missing a prerequisite accounts for many feature update failures or undesirable behavior. Licenses The core functionality requires an Intune license, but it’s important to note that the cloud-based capabilities such as gradual rollout and optional feature updates require a license that includes access to the Windows Update for Business deployment service, for example: Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) Windows 10/11 Education A3 or A5 (included in Microsoft 365 A3 or A5) Windows Virtual Desktop Access E3 or E5 Microsoft 365 Business Premium For more information about gradual rollouts please refer to the following document: Configure schedules to gradually roll out Windows Updates in Intune Telemetry Ensure that a device restriction policy is deployed to all devices in scope for feature updates with reporting and telemetry configured. At minimum the Share usage data setting needs to be configured to “Required”. For more details on this setting, review: Device restriction settings for Windows 10/11 in Microsoft Intune Enable Windows diagnostic data collection Configuring diagnostic data collection is essential to ensure feature update reporting is accurate. This is a tenant wide setting and is configured in the Intune admin center under Tenant administration > Connectors and tokens > Windows data. For more information, review: Use Windows Update for Business reports for Windows Updates in Microsoft Intune Microsoft Account sign-in Assistant service Ensure the Microsoft Account sign-in Assistant service isn’t disabled, by default this is set to Manual. Connected User Experiences and Telemetry service Ensure the Connected User Experiences and Telemetry service is not disabled , by default this is set to Automatic. Supported version of Windows 10/11 The Windows operating system being updated must be either Professional, Enterprise or Education editions.editions. Network endpoints Ensure the devices can access the Intune and Windows update endpoints: Network endpoints for Microsoft Intune Connection endpoints for Windows 10, version 1809 - Windows Privacy Deploying feature update policies with update rings If you’re deploying update rings in parallel to feature update policies, then it is important to consider the implications of configuring certain settings in the update ring policy: Feature update deferral period (days) The recommendation is to configure this to ‘0’ but if you choose to change this it’ll delay the deployment of feature updates. Upgrade Windows 10 devices to Latest Windows 11 release If this option is configured to yes, then eligible Windows 10 devices will update to the latest Windows 11 feature update regardless of what is configured in any feature update policy. Note: It’s important to understand this update ring policy setting will overrule any Windows 10 feature update policy deployed. Paused feature updates If feature updates are paused in an update ring policy, then targeted devices won’t receive feature updates; ensure that feature updates are running for any update ring policies targeting users or devices that also have feature updates policies deployed. Conflicting feature update policies There are a couple of scenarios that are important to keep in mind when deploying feature update policies: Deploying multiple feature update policies to devices could target multiple versions of feature updates to a device at the same time. The latest feature update will always be offered to the device under these circumstances. An eligible Windows 10 device targeted with both Windows 10 and 11 feature update policies will update to Windows 11. Our recommendation is to target a single feature update policy per operating system version, in other words, one for Windows 10 and one for Windows 11 devices. We also recommended to deploy a new feature update policy per release, one policy for Windows 11 23H2 and a separate policy for Windows 11 24H2. In this scenario administrators remove the devices from the group targeted with Windows 11 23H2 and move them to a group targeted with the Windows 11 24H2 policy. Microsoft Entra hybrid joined devices When feature updates are failing to deploy to machines that are Microsoft Entra hybrid joined, it’s important to investigate whether there are any pre-existing group policy objects (GPOs) deployed via Active Directory Services. These can conflict with the settings configured in Intune in general and the feature updates specifically. There are a couple of ways to attempt to check and troubleshoot potential GPO conflicts: On a device you suspect has conflicts run the following at the command line as a local administrator: gpresult /v >c:\temp\gpo.txt Open the text file and examine the contents for group policies which are configuring Windows update settings or redirecting update scanning to WSUS servers. Consider configuring a scan source GPO to specify which sources should be used for each individual class of Windows update. For example, you can configure Feature Updates to use Windows Server Update Services (WSUS) and Quality Updates to use Windows Update as shown in the screenshot below. Configuring a scan source group policy can help ease the transition from an on premises managed environment and Intune. For more information about scan source group policy objects refer to Use Windows Update for Business and Windows Server Update Services (WSUS) together. Note: Using the GPO wins over the mobile device management (MDM) setting doesn’t work with Windows update policies. Safeguard holds A safeguard hold is a Windows function that prevents your device from receiving new feature updates. The Windows update service enforces a safeguard hold on a device when it determines that a feature update may have a negative impact on your device. Safeguard holds are applied when quality and compatibility data identify issues that might cause a Windows client feature update to fail or roll back. These holds can also be applied when a customer, partner, or internal validation finds an issue that would cause severe effects, such as data loss or loss of key functionality. The lifespan of a safeguard hold varies depending on the time required to investigate and fix the issue. Once a fix is found and verified, the safeguard hold is lifted, and Windows Update resumes offering new operating system versions to the affected devices It’s important to check the feature update failures report, which is mentioned in the next section. For more information on safeguard holds and Windows release health refer to: Safeguard holds for Windows Windows release health Troubleshooting Feature updates from the Intune admin center It’s important to enable the prerequisites for update reporting, there are two prerequisites which you must meet: Enable Windows diagnostic data collection from devices by configuring telemetry to be at least required. Configure the tenant level Windows data collection. Windows feature update report The Windows feature update report is a good starting point to get an overall status of the feature update deployment policy status. (Reports > Windows updates > Reports > Windows feature update report) This report runs on individual feature update policies and provides a summary and details of the feature update state. This report doesn’t automatically update and you need to generate it manually. The important data on this report is contained in the update state and update substate columns. If the update state is set to “Offering” and the update substate is set to “Offer ready”, then Windows update made the feature update available to the device. If the update state is “Pending” and update substate is “Scheduled”, then the update will be available for installation later. If it’s “Pending validation”, then there’s a problem validating the device by Windows update. Feature update failures report The first point of contact for troubleshooting feature updates should be the feature update failures report which is in the Intune admin center > Devices > Monitor > Feature update policies with alerts. This report shows you the reasons why individual devices have failed to install a feature update. Note: You need to configure the data collection pre-requisite discussed above before this report shows any data. This lists all the current feature update policies with an overview of the number of devices with errors. Clicking on the feature update policy will drill into the details and list the failures. This report should be the first place that an administrator checks to understand whether the feature update install has been attempted on a device and subsequently failed. For a full list of possible errors populated in this report and recommendations for remediation refer to:Use Windows Update for Business reports for Windows Updates in Microsoft Intune - Microsoft Intune. Checking the Windows update service using PowerShell It’s possible to interact with the Windows Autopatch service via graph explorer or via PowerShell cmdlets using Windows update APIs. The cmdlets are documented in Microsoft.Graph.Beta.WindowsUpdates Module and theGraph APIs are documented in Windows updates API overview. There is also a training course on how to manage updates using the SDK Manage Windows updates for cloud-connected devices by using the Microsoft Graph PowerShell SDK - Training. Administrators don’t need to use the SDK when deploying updates via Intune, but it can be used to investigate and troubleshoot deployment issues.deployment issues. The following is an example of how to request the properties of a Microsoft Entra device using the device identifier. You can view this record using a PowerShell cmdlet called: 'Get-MgBetaWindowsUpdatesUpdatableAsset' with the Microsoft Entra device id as a parameter, here is an example PowerShell script which gets the update information: Import-Module Microsoft.Graph.Beta.WindowsUpdates Connect-MgGraph $updateInfo = Get-MgBetaWindowsUpdatesUpdatableAsset -UpdatableAssetId '<insert Entra device id>' Write-Host "Update Information:`n$($updateInfo | ConvertTo-Json -Depth 10)" This is an example of the output where the feature update enrollment state is still “enrolling.” A Microsoft Entra ID device will need to be successfully enrolled into the Windows Autopatch service before it can start receiving the feature update policies. In this case the enrolling state could be caused if the feature update is paused in an update ring policy. Update Information: { "Id": "13315f1b-96b4-4a88-b453-342d984a6e05", "AdditionalProperties": { "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/updatableAssets/$entity", "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice", "errors": [], "enrollment": { "feature": { "enrollmentState": "enrolling", "lastModifiedDateTime": "2025-01-23T14:39:07.8854424Z" }, "quality": { "enrollmentState": "notEnrolled" }, "driver": { "enrollmentState": "enrolledWithPolicy", "lastModifiedDateTime": "2024-02-08T15:14:30.5073437Z" } } } } The ideal state is as follows; this shows the Microsoft Entra ID device is enrolled in the Windows Update for business service for feature updates. Note that the Entra ID enrollment into Windows Autopatch is distinct from enrolling a Windows device into Intune: Update Information: { "Id": "0dde8413-951b-4d95-b628-705881f4901b", "AdditionalProperties": { "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/updatableAssets/$entity", "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice", "errors": [ ], "enrollment": { "feature": { "enrollmentState": "enrolled", "lastModifiedDateTime": "2025-02-06T16:02:59.0065266Z" }, "quality": { "enrollmentState": "notEnrolled" }, "driver": { "enrollmentState": "enrolled", "lastModifiedDateTime": "2025-02-06T16:02:57.5209828Z" } } } } The enrollment state should equal enrolled if the device has a policy targeting one of the updates. Graph explorer The same principle can be used with graph explorer by navigating to https://developer.microsoft.com/graph/graph-explorer and querying the following: https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/<insert Microsoft Entra Device id> This returns the data associated with the asset in JSON format. In this example we see that the device is still enrolling for feature updates rather than enrolled. Note: When you create a feature update policy in Intune it will interact directly with Windows Update for Business using the documented Windows Autopatch APIs to configure the policies, however, these policies are not visible either though Graph or PowerShell. Troubleshooting Feature updates from the client side Device diagnostics The first step when troubleshooting feature updates from the client side is to get hold of the device side logs. Intune provides a way to gather logs from the device using the Intune admin center within device diagnostics. To ensure that device diagnostics is available in your tenant, navigate to Tenant admin > Device diagnostics and ensure that the options are enabled. Once enabled it’s possible to collect diagnostics from the device by navigating to the device overview page, Collect diagnostics. After a short period, the diagnostics will be available to download from the device diagnostics view on the device: For more information about device diagnostics please refer to Collect diagnostics from an Intune managed device - Microsoft Intune. Device diagnostic logs The device diagnostics feature in Intune gathers all the relevant MDM event logs along with other relevant data such as registry keys, log files, and commands. When troubleshooting feature updates, the key logs to investigate from the device diagnostics are the following: %windir%\logs\CBS\cbs.log The CBS, or component-based servicing, log gives detailed information on the installation of updates which relate to the component-based servicing system. This includes some aspects of the feature update install. If a feature update fails due to a missing or corrupted system component, the CBS.log may contain relevant errors. %windir%\logs\Panther\unattendgc\setupact.log Setupact.log contains detailed step by step records of the Windows setup process. This log contains the actions performed during a feature update installation and is useful for scenarios where the update is delivered to the device but has not installed correctly. SetupDiag is also available to download to help determine why upgrades fails for more information refer to: SetupDiag. %windir%\logs\WindowsUpdate\*.etl The Windows update log is useful for investigating issues with scanning, downloading, and installing updates. The etl files can be converted to a more friendly text log file using the PowerShell cmdlet Get-WindowsUpdateLog. For more information about troubleshooting via the Windows update logs refer to Windows Update log files. %temp%\MDMDiagnostics\mdmlogs-<Date/Time>.cab The mdmlogs cab is a diagnostic log package generated by the device diagnostics to capture all relevant MDM logs and compresses them into a cab file. The key logs and files for investigating feature updates are the MDM diagnostics report HTML file (which is discussed in detail below) and the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx. Checking the prerequisites via MDM diagnostics report Once the diagnostics are downloaded, the first step is to check that all the prerequisites for feature updates are satisfied. To do this unzip the DiagLogs zip file and search for a folder called: temp_MDMDiagnostics_mdmlogs, for example temp_MDMDiagnostics_mdmlogs-2025-01-28-16-51-20_cab, extract the files from the CAB file and search for the file MDMDiagHtmlReport.html. The MDM diagnostic information has a list of all the policies that are applied to the device from Intune, and in the case of feature updates, the following settings need to be deployed and configured on the device. Note that there are two columns for the values, the default Windows value and the current value which is configured by Intune. Here’s an example of how the policies look in the MDMDiagHtmlReport.html: Search this file for the CSP area, such as Update or DeviceHealthMonitoring as in the example below: These are the prerequisites areas, policies and settings that you should check: Area Policy Default Current Update DeferFeatureUpdatesPeriodInDays 0 0 Update ConfigureDeadlineForFeatureUpdates 7 10 Update PauseFeatureUpdates 0 0 DeviceHealthMonitoring AllowDeviceHealthMonitoring 0 1 DeviceHealthMonitoring ConfigDeviceHealthMonitoringScope BootPerformance, WindowsUpdates System AllowTelemetry 1 1 In this example the policy values equate to: Setting Value Description DeferFeatureUpdatesPeriodInDays 0 The number of days a feature update can be deferred, 0 days is recommended but this can be configured for up to 365 days. ConfigureDeadlineForFeatureUpdates 10 Number of days before the feature update is installed automatically, in this case 10 days. PauseFeatureUpdates 0 0 means that feature updates are not paused. 1 means that they are paused. AllowDeviceHealthMonitoring 1 1 means DeviceHealthMonitoring connection is enabled. ConfigDeviceHealthMonitoringScope BootPerformance and WindowsUpdates data are sent to Microsoft. AllowTelemetry 3 3 means that all telemetry data is being sent to help fix problems, 1 is basic. Basic is the minimum telemetry setting required for feature updates. If you want to understand these values further, refer to the CSP documentation: Policy CSP - Update Policy CSP - System Policy CSP - DeviceHealthMonitoring Verifying Intune policy is applied When a policy fails to apply on a device, the error returned from the CSP is reflected in the Intune admin center reports. For all CSPs, including the update, device health monitoring and system policy CSP, any errors that occur when applying the CSP settings appear in the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin event log. To access this event log, you can either request the device diagnostics from a device and extract it from the zip file or access the event log directly on the device. To access this on a device, open the event viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Here is an example of an error in the DeviceManagement-Enterprise-Diagnostics-Provider admin event log from the WiFi CSP: The error is as follows: MDM ConfigurationManager: Command failure status. Configuration Source ID: (773B7171-7CB3-41CE-9480-64439F370613), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (WiFi), Command Type: (Add: from Replace or Add), CSP URI: (./Vendor/MSFT/WiFi/Profile/Danger Zone/WlanXml), Result: (The service has not been started.). In the above error, a Wifi profile has failed to be applied via the Add/Replace command. The ‘Result’ is the important part. This can take the form of a hex code, such as 0x86000009, or can be more meaningful as in the example above: “The service has not been started”. In this case the device is a virtual machine which has no WiFi adapter, so the service is not running. Update, System, and Device health monitoring CSP errors are not common, but it is important to understand how to investigate potential CSP errors. Check the registry The best method for checking the device side settings is to review the MDM diagnostics report that can be collected using device diagnostics as described above. The diagnostics report reflects the settings configured in the registry. It’s also possible to check the prerequisites and the update settings in the registry. This helps verify the settings are configured as per the policies in Intune. Safeguard holds Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TargetVersionUpgradeExperienceIndicators This key specifically is related to Windows feature updates and tracks information about how a system is expected to behave during an upgrade to a newer Windows version. The GE24H2 subkey in the above screenshot refers to Windows 11 24H2 and the values in this subkey help assess whether the device is ready for the update. Telemetry settings Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection This location is where Windows stores telemetry specific settings, the value should either be 1 (Basic) or 3 (Full). In this screenshot, the AllowTelemetry_PolicyManager value shows 3 which means “Full”. Device health monitoring Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceHealthMonitoring The device health monitoring settings highlighted in red below are required for various update reports in the Intune admin center. Make sure the WindowsUpdates setting is present for ConfigDeviceHealthMonitoringScope and AllowDeviceHealthMonitoring is set to 1 (enabled). Reviewing these registry entries is useful for verifying the settings have applied successfully, editing the values directly in the registry has no impact on functionality. Note: If the administrator has configured the tenant wide Windows data settings in Tenant administration > Connectors and token > Windows data, the Windows update scope entry will not be present. This is only present when deploying the health monitoring settings via a device configuration profile: Use Windows Health Monitoring profile on Windows devices in Microsoft Intune. Update settings Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update This key contains all the update CSP settings which are configured by the update policies. This includes feature, quality, driver, and update ring settings. There are potentially many settings in this key and they vary depending on the settings configured in the policies configured in Intune. To understand what these settings mean refer to: Update Policy CSP. Microsoft Compatibility Appraiser The Microsoft Compatibility Appraiser is a built-in Windows telemetry component that evaluates the compatibility of installed software and hardware in Windows. It runs as part of the Windows Compatibility Telemetry process. Windows uses Microsoft Compatibility Appraiser for reporting and telemetry and is a key component for the Intune feature update reports. You configure Intune to leverage this tool using the Windows data tenant wide setting as described previously in the prerequisites section. In some circumstances where devices show up as unknown in the Intune update reports, it’s useful to attempt to trigger Microsoft Compatibility Appraiser manually to force the device to report back telemetry data. To do this you can either manually run a scheduled task on the device or execute it using PowerShell or the command line. Manually running the scheduled task Navigate to the start menu > type “task scheduler” and open the task scheduler > navigate to Microsoft > Windows > Application Experience > Microsoft Compatibility Appraiser Exp> right click > Run. Running the appraiser at the command line The task above runs a command which you can also execute manually or script it to run on many machines: Compattelrunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun Both methods will trigger Microsoft Compatibility Appraiser to report the required telemetry data and update the Windows update reports. Summary This blog covered many aspects of troubleshooting feature updates, here are the key points: Make sure the prerequisites are in place. It’s important to emphasize that implementing the prerequisites for feature updates is important to ensuring a smooth feature update deployment. Take time to ensure that these are configured correctly as this is especially important for reporting. In more complex environments with Microsoft Entra hybrid joined devices, it’s important to ensure that there are no conflicting settings deployed from multiple sources, for example, having GPO settings, Microsoft Configuration Manager update policies, and conflicting Intune update policies deployed. Try to ensure that update policies are deployed from only one source. If multiple sources must be used, consider using the scan source group policy. It’s possible to interact with Windows Autopatch using PowerShell cmdlets and Graph APIs. This provides insight into a tenant's configuration, but it’s not a requirement as Intune will configure this for you using feature update and update ring policies. Note: It’s also important to understand that the Intune configured Windows Update client policies will not be visible via the PowerShell cmdlets or Graph APIs. Take note of whether safeguard holds are applied to specific device models, checking the feature update failures report will assist with identifying these. The device side event logs, Windows update logs, MDM diagnostics report, and registry values are all important sources for trying to narrow down why a device isn’t installing a feature update, or if a feature update was unexpectedly not installed or installed. Collecting diagnostics from affected devices will gather the relevant logs and data required for troubleshooting, this is important to gather if a support request is opened. Hopefully these tips help you with troubleshooting feature updates! If you have any questions, leave a comment on this post or reach out on X @IntuneSuppTeam. Post update: 04/10/25: Added link to: Why Windows Autopatch is the smart update solution - Windows IT Pro Blog.Support tip: Understanding Microsoft Intune compliance policies reporting SyncML(500) errors
By: Brett Lock - Sr. Tech Support Engineer | Microsoft Intune When deploying Windows device compliance policies with Microsoft Intune, the compliance report may show the following error for the Firewall settings (as depicted in the screenshot below): “2016345612(Syncml(500): The recipient encountered an unexpected condition which prevented it from fulfilling the request.)” Example screenshot of a Windows device compliance policy displaying the SyncML(500) error. The Syncml(500) error for the Firewall setting typically occurs during device startup, if or when the mobile device management (MDM) agent service starts before the firewall or antivirus services have fully initialized. In this scenario, the MDM agent reports a “service not started state” back to Intune which appears as the Syncml(500) error in the report. This is normal and expected. This error is temporary and doesn’t affect the compliance state of the device, unless the device doesn’t synchronize with the Intune service. The compliance service provides a 7-day grace period for devices with this error, marking them non-compliant if no sync occurs within that timeframe. In most cases, the error is resolved within 10 minutes after the user has logged on however, manual synchronization may be needed. On the device, navigate to Settings > Accounts > Access work or school > Account > Info > Sync to clear the error or run a compliance check from the Intune Company Portal app. Alternatively, admins can remotely sync the device from the Intune admin center through the device actions to achieve this (Devices > Windows > select the device > Overview > Sync). We’ve recently improved how Intune reports compliance states which minimizes the occurence of the Syncml 500 error. However, this error can still occur, and it’s important to understand that the error is expected if the MDM service starts up before the firewall and antivirus services initialize. In summary, the Syncml(500) error won’t impact the device compliance status during the 7 day grace period. If the device is immediately switched off after the error occurs and left for seven days, then this will impact the device compliance state. To resolve a non-compliant device in this scenario simply turn the device back on and sync once the user is logged on. If you have any questions for the team, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn: aka.ms/IntuneLinked.From the frontlines: Empowering call center agents with Windows 365 Frontline
By: Tania Lima – Sr Product Manager | Windows 365 Editor’s Note - Updated 11/19/25: The new User Experience Sync for Windows 365 Frontline in shared mode, announced at Ignite, delivers a consistent and seamless experience for users who frequently switch between shared Cloud PCs. This feature ensures that user settings and application data persist across sessions and devices within the same provisioning policy. Included with the Frontline license at no extra cost, it provides fast, transparent sign-ins and allows IT admins to monitor storage quotas and clear user storage when needed to resolve issues. Learn more here: Windows 365 Frontline updates and Cloud Apps general availability. Call centers are dynamic environments where agents often work in shifts, handling customer inquiries around the clock. Providing these frontline employees with secure, consistent, and accessible computing environments is critical to maintaining productivity and excellent service. However, traditional desktop deployments, whether physical PCs or complex virtual desktop infrastructure (VDI), are often challenging to manage and scale for a shift-based workforce. Microsoft Windows 365 Frontline addresses this challenge by delivering Cloud PCs optimized for shift and part-time workers. With Windows 365 Frontline, organizations give call center agents full Windows desktop experiences from the cloud, while optimizing costs through a flexible licensing model that enables multiple employees to share Cloud PC resources during their respective shifts. This article explores the two modes of Windows 365 Frontline – dedicated and shared – and offers guidance on choosing the right approach for call centers, along with best practices for Microsoft Intune configuration and provisioning in these scenarios. Windows 365 Frontline overview Windows 365 is Microsoft's Cloud PC service that streams a full Windows desktop to any device. Windows 365 Frontline is a specialized offering within Windows 365 designed for organizations with frontline or shift-based workers – employees who don't need a Cloud PC 24/7, but rather only during working hours or on an intermittent basis. Instead of assigning a traditional one-to-one Cloud PC license per user, Frontline licenses are shared at the tenant level, allowing multiple users to utilize the same Cloud PC resources at different times. This model can significantly reduce costs for call centers and similar environments by ensuring you only pay for the maximum number of concurrent Cloud PC sessions needed, not for every employee in the directory. Windows 365 Frontline offers two modes of operation to accommodate different use cases: dedicated mode and shared mode. Both modes provide the same secure, high-performance Windows experience via the cloud, integrated with Microsoft Intune for management and Microsoft Entra ID for identity and security. The difference lies in how Cloud PCs are provisioned and used by multiple users. Dedicated mode: Personalized Cloud PCs for shift workers With Frontline Cloud PC in dedicated mode, each licensed user is provisioned their own personal Cloud PC, the same as a standard Windows 365 Enterprise scenario – with one crucial twist: a single Frontline license entitles up to three Cloud PCs, assigned to three different users, so long as only one Cloud PC is in use at any given time. In other words, one license is equivalent to 3 users (one active session at a time). This non-concurrent licensing is ideal for shift work. For example, if you have three call center agents covering morning, afternoon, and night shifts, you can assign each their own Cloud PC while consuming only one Frontline license. Each agent gets a dedicated, persistent Windows desktop with their apps, settings, and data, which remains available every time they log in. Because Frontline Cloud PC in dedicated mode is personal to each user, the user experience is consistent and tailored. Agents can customize their desktop, set up applications (or have them deployed via Intune), and retain files or settings from session to session. We recommend this mode or scenarios where employees require a prolonged and consistent desktop experience – for instance, full-time or regular part-time call center employees who work scheduled shifts on a daily basis. It ensures that each agent always returns to their own workspace in the cloud. To streamline shift handovers, Windows 365 Frontline Cloud PC in dedicated mode includes a built-in concurrency buffer that allows a temporary overlap of active sessions beyond the license limit. This is designed for those situations where one agent hasn't signed off yet and the next shift agent needs to sign in a few minutes early. The concurrency buffer permits exceeding the max concurrent user limit for short periods (up to 1 hour, a few times per day) to avoid blocking users during shift handovers. This means if one agent's session slightly overlaps with another's, both can be connected briefly without needing an extra license, and without being forced to log off. Once the time limit expires, users will be unable to log in until a Cloud PC is available. Shared mode: Ephemeral Cloud PCs for occasional use In Frontline Cloud PC in shared mode, a Cloud PC is not tied to any single user. Instead, you set up a collection of one or more Frontline Cloud PC in shared mode that a group of users can access one at a time. When someone in the group connects to a shared Cloud PC, they can receive either a persistent or a non-persistent session. Administrators can turn on the new User Experience Sync feature if they want users to enjoy a consistent experience—this ensures that applications storing user settings or app data will keep that information across sessions, including maintaining other Windows features like accessibility options. Alternatively, if preferred, a new user profile is created at each login, and once the user signs out, all session data is erased and the next user to sign in starts with a clean environment. This mode allows a Cloud PC to be truly shared among many users serially. Each Frontline license in shared mode allows you to provision one Cloud PC for the pool (thus one license = one Cloud PC accessible by many users, but still only one active user on that Cloud PC at a time). Shared mode is well-suited for scenarios where users need only occasional or brief access to a Windows environment rather than a daily dedicated workspace. For example, consider a training workstation in a call center or a kiosk-style PC for supervisors to quickly check reports. Another use case is for temporary staff or contractors who log in infrequently. In a call center context, shared mode could be used for a “floater” Cloud PC that any agent can use when extra capacity is needed, or for machines set aside for specific short tasks such as quality assurance checks by various team members. We don’t recommend shared mode for standard call center agents who have regular shifts, because those users benefit more from a persistent environment and dedicated mode can still provide cost savings in those cases. Instead, shared mode shines for truly ad-hoc access scenarios, where personalization isn't required. With Frontline Cloud PC in shared mode, since no user profile persists, it's important to ensure apps and configurations needed for the common tasks are pre-installed or available on demand. Users rely on cloud storage (OneDrive, SharePoint, web applications) for any data they need to save, because once they log off a shared Cloud PC, nothing is retained locally. The upside is that IT maintains a singular baseline configuration for all shared sessions and there's zero risk of one user’s data bleeding into the next session – the wipe on logoff provides a clean slate and extra security. Dedicated vs. shared mode comparison Feature Frontline Cloud PC in dedicated mode Frontline Cloud PC in shared mode Cloud PCs per license Up to 3 Cloud PCs per license (user-specific). Only 1 Cloud PC can be active at once (per license). 1 Cloud PC per license (pooled). Only 1 user session active at once (per Cloud PC). User experience Personalized persistent desktop for each user; data and settings saved between sessions. Non-persistent, generic desktop; user profile and data are reset on sign-out. Suitable use cases Shift workers who need their own space and apps (ex., daily call center agents with dedicated logins). Intermittent or short task usage (ex. shared training PC, occasional contractors or roaming supervisors). Provisioning method Cloud PCs are provisioned per user via Microsoft Entra ID group assignment. Each user gets their own Cloud PC instance. Cloud PCs are provisioned as a static pool (set number of identical Cloud PCs) and assigned to a group of users to share. Intune management Managed like any other individually assigned device. Supports user-targeted configurations. Managed as shared devices. Use device-targeted configs for apps/scripts (via device groups or Autopilot device prep) since users do not retain installs. Data storage Files and data persist on the Cloud PC (roam with user). Still recommended to use OneDrive/SharePoint for backup and mobility. Files and data do NOT persist locally. Must use OneDrive, SharePoint, or other cloud services for any data that needs to be retained. Intune configuration and recommendations for call centers Successfully deploying Windows 365 Frontline in a call center scenario requires optimal configuration of Microsoft Intune and adherence to best practices that maximize security and efficiency. Below are key recommendations. Provisioning policies Set up separate Windows 365 provisioning policies for your call center users depending on mode. In the Intune admin center, under Devices > Windows 365 > Provisioning policies, choose License type: Frontline, then specify the mode as dedicated or shared. For dedicated mode, assign the policy to a Microsoft Entra ID group containing your call center agents – Intune will automatically provision a Cloud PC for each user in the group (up to your license concurrency limits). For shared mode, assign the policy to a group of users and define the number of Cloud PC instances to create for that group. Name the shared Cloud PC pool descriptively (ex. "Call Center Training PC") so users recognize it. Use the Microsoft-hosted network unless integration with on-premises networks is needed and select a region close to your users for optimal performance. Image and applications Choose a base Cloud PC image that includes your core call center applications to speed up deployment. Microsoft provides gallery images (including options with Microsoft 365 Apps pre-installed). For Frontline Cloud PC in dedicated mode, each user gets this baseline image and can receive additional apps via Intune app deployment or Company Portal. For Frontline Cloud PC in shared mode, it's crucial to preload critical apps since users won't persist installs. Leverage the Windows Autopilot deployment preparation (preview) feature for shared mode provisioning policies. This feature lets you specify device-targeted apps and scripts that Intune should install on each Cloud PC during provisioning, ensuring that even the first user to sign in has all the required software ready. It helps avoid managing custom images while still delivering necessary apps on a clean shared PC each time. Microsoft Entra ID groups for access Manage which users can access Cloud PCs by controlling Microsoft Entra ID group membership. Since Frontline licenses are not assigned to individuals but pooled, any user in the provisioning policy’s assignment group will get access. For dedicated mode, ensure the group size aligns with available licenses (3 users per license). If the group has more users than license capacity, some users may not get a Cloud PC provisioned until additional licenses are added. Use the Connected Frontline Cloud PCs report in the Intune admin center to monitor how many Cloud PCs are active and if you’re hitting your license concurrency limit. Adjust group membership or purchase more licenses as needed to meet peak demand. Session time limits Configure automatic session timeouts to prevent a user from inadvertently locking a Cloud PC and blocking others. Use Intune to enforce idle session time limits and disconnected session sign-off for Windows 365 Frontline. For example, for a Frontline Cloud PC in shared mode that is idle for 15 minutes, disconnect the session, and for a session that has been disconnected for more than 5 or 10 minutes, sign the user out (ending the session).This ensures a Frontline Cloud PC in shared mode isn’t held by an inactive session, making it available to the next agent. For Frontline Cloud PC in dedicated mode, an idle timeout (e.g., 30 minutes) can free up the license concurrency slot without immediately logging the user off. You configure these settings in the Intune admin center using the settings catalog: Remote Desktop Session Host > Session Time Limits settings. Tuning these values helps balance user convenience with resource availability. OneDrive and user data Encourage or enforce the use of OneDrive Known Folder Move for Desktop, Documents, and Pictures so that user files are redirected to cloud storage. In dedicated mode, this ensures that if a user moves to a new Cloud PC or device, their files roam with them. In shared mode, this step is even more critical: when the user logs off, anything saved only on the local profile is erased. With Known Folder Move and cloud-based productivity apps, even a non-persistent session feels seamless as users access their files from OneDrive or SharePoint. Similarly, if users use Outlook, enable cached Exchange mode with cloud mailboxes so that email data isn't lost between sessions. Alternatively, direct users to access the new Outlook or Outlook on the web to avoid local data use. Security controls Treat Cloud PCs as you would any corporate device: apply Microsoft Defender for Endpoint monitoring and security baselines via Intune. One big advantage of Windows 365 for call centers is enhanced security – by default, Cloud PCs keep data off the local machine that the user is connecting from. Use Intune policies or Windows 365 settings to disable clipboard and drive redirection, prevent screenshots, and add watermarking if agents handle highly sensitive information (so data on the Cloud PC can't be easily copied out). Additionally, enforce multi-factor authentication (MFA) for Cloud PC access through Microsoft Entra ID Conditional Access, and limit Cloud PC access to only trusted networks or compliant endpoint devices for an extra layer of protection. Monitoring and scaling Continuously monitor usage patterns. Windows 365 usage reports help identify if your call center is reaching the concurrent connection limit. If agents frequently find Cloud PCs unavailable (shared mode) or get blocked due to concurrency (dedicated mode), you likely need more Frontline licenses or an adjusted strategy. Aim to have enough Cloud PCs to cover peak usage. Thankfully, adding capacity is straightforward – purchase additional Frontline licenses and update your provisioning policies. For shared mode, increase the Cloud PC count in the pool; for dedicated, new users in the group automatically get Cloud PCs if licenses are available. Likewise, if usage is consistently below capacity, consider reducing the number of provisioned Cloud PCs to optimize costs. Windows 365 provides the flexibility to scale up or down easily as your call center staffing changes, enabling organizations to efficiently adapt to operational fluctuations and changing demands. Endpoint devices When call center agents operate on-site with shared physical PCs or thin clients to connect to their Cloud PCs, configure these physical endpoints appropriately for shared usage. Windows PCs can be set up in Microsoft Entra ID Shared Device Mode or as kiosk devices that only allow launching the Windows App or a web browser for Cloud PC access. This ensures the local device doesn't store data between users and is locked down to its purpose. Intune can manage these Frontline Cloud PC in shared mode with policies to clear temp files on logout, enforce idle sign-out, and automatically launch the Windows App at login. By managing both the Cloud PC and the access device in Intune, IT creates a cohesive, secure experience for rotating call center shifts. Windows 365 Link devices in call centers Windows 365 Link devices offer a transformative solution for call centers by simplifying endpoint management and enhancing remote operability. These devices enable seamless access to Cloud PCs with high-fidelity Microsoft Teams support and multimedia redirection, which is critical for voice and video-heavy workflows. Windows 365 Link allows secure connections even to Cloud PCs that have never been signed into before, reducing onboarding friction for third-party agents. This is especially valuable for remote call centers, where maintaining client machines is challenging. Windows 365 Link can be shipped pre-configured, minimizing setup complexity and support overhead. Using Link devices supports scalable, secure, and efficient operations without compromising user experience or enterprise security policies. Windows 365 Link devices are intended to be managed in a manner consistent with other Windows endpoints within Intune; however, they operate on a streamlined Windows Cloud PC OS. This design reduces the range of management actions available, particularly with respect to enrollment and ongoing management actions. For more information visit Windows 365 Link documentation. Microsoft Teams If Microsoft Teams is part of the daily workflow for call center agents, we strongly recommend deploying the Microsoft Teams-optimized Windows App to access their Cloud PCs from Windows-based clients, in place of using the standard web-client. This approach ensures better performance, enhanced audio and video quality, and full support for Teams-specific optimizations such as offloading media traffic and reducing latency. Simple connection requirements for partners Many large organizations will work with third party call center partners to provide agents to support their customers, either as business as usual, or to provide out of hours and coverage for high call volume events. Ensuring these partner organizations can connect to your infrastructure, and connect to your applications, can be challenging and any changes can take time for your partners to roll out. By using Windows 365, you can deliver a defined list of software and network requirements (Windows App, with access to the Windows Cloud endpoints / Teams / Call Centre software), and minimize the number of changes required as your business evolves. Providing access to a new application, service, or resource is handled within the Cloud PCs that you control with no technical changes needed by the vendor or partner. Remote call center and BYOD scenarios Windows 365 empowers organizations to support remote call center agents through secure, scalable Cloud PC deployments that work seamlessly across bring your own device (BYOD) environments. Whether agents use personal laptops, tablets, or mobile phones, Windows 365 ensures secure access to corporate resources via the Windows app or browser-based clients, minimizing infrastructure overhead and simplifying endpoint management. This flexibility is especially valuable for outsourced or third-party call center partners, where device diversity and network variability are common. By centralizing application access within the Cloud PC, organizations enforce consistent security policies, reduce onboarding friction, and deliver reliable user experience, regardless of the agent’s physical location or device type. This model not only enhances operational agility but also strengthens data protection by isolating corporate workloads from unmanaged endpoints. Conclusion Windows 365 Frontline represents a transformative approach for call centers seeking to empower their agents with secure, flexible, and cost-effective computing environments. By offering both dedicated and shared modes, organizations can tailor Cloud PC deployments to match the unique needs of shift-based and occasional workers, optimizing resource utilization and reducing operational complexity. With robust integration into Microsoft Intune and Microsoft Entra ID, IT teams can streamline provisioning, enforce security best practices, and ensure seamless user experiences, whether agents are on-site, remote, or using their own devices. Ultimately, Windows 365 Frontline enables call centers to scale efficiently, enhance data protection, and deliver consistent service quality in today’s dynamic work landscape. This blog is part of the “From the Frontlines” series, where we explore different scenarios of how workers in field use devices and how IT admins can enable them. Check the other blog posts for more inspiration! As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam or @MSIntune! Post Updates: 11/19/25: Updates to the "Shared mode: Ephemeral Cloud PCs for occasional use" section highlighting new flexibility in shared Frontline Cloud PCs, including optional user experience persistence and simplified shared licensing.Debunking the myth: Cloud-native Windows devices and access to on-premises resources
By: Roger Southgate - Sr. Product Manager | Microsoft Intune Myth vs reality Myth: Cloud-native Windows devices can’t access on-premises resources such as file shares or legacy applications. Reality: With minimal or no configuration, cloud-native devices can seamlessly access on-premises resources using NTLM or Kerberos. Introduction Microsoft’s vision for secure, productive workplaces is clear: adopt cloud-first services, integrate Zero Trust throughout, and deploy Windows 11 devices as cloud-native endpoints to stay agile and future-ready. If you’re yet to begin this journey, review the Set up and configure a cloud-native Windows endpoint with Microsoft Intune tutorial. For context, a cloud-native device is a Windows device, joined to Microsoft Entra and managed by Intune. No domain join, no group policy, and no Microsoft Configuration Manager required. Leveraging complementary services such as Windows Autopilot and Windows Autopatch enables users to self-provision their devices, work remotely, and remain secure by applying the latest Windows Updates. But what about user’s data, files, and applications that they require to be productive? Moving to the cloud is a common goal for many organizations, though practical realities can make this a gradual process. Legacy technology, operational constraints, complexity, and other challenges can hinder adoption. While the goal might be to migrate all data to cloud-friendly repositories such as SharePoint Online and OneDrive, and transition applications to SaaS solutions, these migrations don’t happen overnight. In many cases, data may remain scattered across internal servers and on-premises repositories, creating scenarios where cloud-native devices still need to connect to these resources. Accessing on-premises resources What happens when you take a cloud-native device and try to access an on-premises resource such as a file share? Similarly, what about access to an application that is located on-premises? While these are just two examples, they can be used interchangeably in this scenario since the process of getting access is the same, regardless of apps or files. This is a topic that is raised (and often misunderstood) when discussing the transition of Windows devices to the cloud. Cloud-native devices were designed to take this scenario into account and have seamless access to on-premises resources. Note: This assumes you have line-of-sight to an Active Directory Domain Controller and that your on-premises resources, such as file shares and applications, use Windows authentication. Like a domain-joined device, a cloud-native device won’t have line of sight by default unless it’s physically on-site (for example, in a corporate office). If you require this functionality, you may need to use a VPN or Zero Trust Network Access (ZTNA) solution to provide this connectivity to on-premises resources. More on this later, when we touch on Microsoft Entra Global Secure Access. Legacy applications and authentication When people talk about legacy applications in this context, they typically mean apps that can only do legacy (NTLM or Kerberos) authentication with Active Directory. The good news is that for users synchronized using Microsoft Entra Connect Sync, cloud-native devices can seamlessly authenticate using NTLM and Kerberos just like domain-joined devices. When an on-premises domain account is synchronized to Microsoft Entra ID via Microsoft Entra Connect Sync, Windows uses details from Microsoft Entra ID, such as the source Active Directory domain name and the user’s User Principal Name (UPN), to locate a Domain Controller the same way an Active Directory domain-joined device does. If the user has signed into Windows using a password, Windows sends the on-premises domain information and user credentials to the Domain Controller to obtain a Kerberos Ticket-Granting Ticket (TGT) or NTLM token, based on the protocol the on-premises resource or application supports. From that point onwards, the TGT is used to get session keys that grant access to resources. Refer to How SSO to on-premises resources works on Microsoft Entra joined devices for additional details on how this process works. Note: Windows 11, version 24H2 and later releases have removed the NTLMv1 protocol as part of Microsoft's broader initiative to phase out NTLM. Refer to the Microsoft support article on Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 for additional details. Windows Hello for Business Passwordless authentication mechanisms such as FIDO2 and Windows Hello for Business are a cornerstone of Microsoft’s security vision. Adopting these authentication methods delivers stronger security and better, simpler user experiences. Windows Hello for Business provides phishing-resistant credentials as required by some security guidelines such as the Australian Cyber Security Centre ‘Essential Eight’. If you’re not already doing so, deploying cloud-native devices is a great opportunity to start using Windows Hello for Business, especially since it’s enabled by default on these devices. Windows Hello for Business is also a feature which results in a win-win scenario by enhancing security for IT, while also improving the user experience. While enabling Windows Hello for Business is a simple process, there’s some additional configuration required to enable single sign-on to on-premises Active Directory authenticated resources, and this is where we sometimes see customers running into issues. If username and password work successfully to access an on-premises resource, but Windows Hello for Business credentials don’t then ensure that you’ve setup Cloud Kerberos trust to enable single sign-on. Cloud Kerberos Trust removes much of the complexity once associated with configuring Windows Hello for Business, greatly simplifying the deployment process. When signing in with Windows Hello for Business, the device uses a partial Kerberos TGT issued by Microsoft Entra ID to obtain a full TGT from Active Directory, which in turn is used to get session keys to access resources. Refer to Microsoft Entra join authentication to Active Directory using cloud Kerberos trust for additional details. Zero Trust and modern connectivity On your Zero Trust journey, if you need to provide access to on-premises applications and services, consider replacing your traditional VPN with a modern solution, enabled by Microsoft Entra Private Access. Doing so will help you ensure secure, fine-grained access to private applications and resources, without exposing your full network - aligned with Microsoft’s three Zero Trust principles: verify explicitly, enforce least privilege, and assume breach. Review Zero Trust and Cloud-Native Windows for a deeper dive into this topic. On the subject of Zero Trust, did you know that Microsoft has developed a Zero Trust Workshop? By adopting Zero Trust, your organization can enhance its security posture and reduce risk and complexity while improving compliance and governance. Navigating the complexities of modern security is challenging and a Zero Trust strategy is the first step in providing clarity and direction. The Zero Trust Workshop is a guided framework to help you translate your Zero Trust strategy into actionable implementation steps which track your deployment progress and align with Microsoft recommendations. We’ve had many customers leverage the workshop to supercharge their Zero Trust journey and realize the full value of their existing security investments. The workshop can be run self-guided or in collaboration with your Microsoft account team or a partner and is vendor agnostic. Key takeaways If you aren’t already provisioning new Windows devices as cloud-native, check out Set up and configure a cloud-native Windows endpoint with Microsoft Intune and Cloud-native Windows endpoints: Begin by beginning to get started with a cloud-native Windows proof of concept today. Cloud-native doesn’t mean cloud only, these devices get the benefits of being cloud-first while maintaining the backward compatibility needed to access on-premises resources when necessary. Modern identity solutions such as Microsoft Entra ID, Windows Hello for Business, and Zero Trust Network Access can simultaneously enhance security and user experience. Be sure to check out our Zero Trust Workshop to help you plan and implement these and other technologies as part of your Zero Trust strategy. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Microsoft Intune Settings Catalog Updated to Support New Windows 11, version 25H2 Settings
By Mayur Jahdav, Product Manager | Microsoft Intune With the recent release of Windows 11, version 25H2, Microsoft Intune delivered support for 36 new 25H2 settings. IT admins can confidently manage devices running the latest Windows OS version from the moment they deploy it in their environment for testing or production use. We continue to invest in the settings catalog infrastructure to ensure timely support for new Windows policy settings. This enables organizations to adopt new OS versions and features without delay and maintain secure, compliant, and well-managed environments. New settings in the settings catalog As part of our day zero support for Windows 11, version 25H2, the settings catalog includes the newly released Windows 11, version 25H2 settings. The following table lists newly added settings that are now available for configuration using the settings catalog and are ready for use in device configuration profiles to manage Windows endpoints. Category Name Name Friendly Name Administrative Templates\Windows Components\App Package Deployment RemoveDefaultMicrosoftStorePackages Remove Default Microsoft Store packages from the system. Administrative Templates\Windows Components\Sync your settings EnableWindowsBackup Enable Windows Backup Auditing AccountLogonLogoff_AuditGroupMembership Account Logon Logoff Audit Group Membership Human Presence ForceOnlookerDetectionAction Force Onlooker Detection Action Human Presence ForceOnlookerDetection Force Onlooker Detection Microsoft App Store ConfigureMSIXAuthenticationAuthorizedDomains Configure MSIX Authentication Authorized Domains News And Interests DisableWidgetsBoard Disable Widgets Board News And Interests DisableWidgetsOnLockScreen Disable Widgets On Lock Screen Power EnableEnergySaver Enable Energy Saver Printers RequireIppsPolicy Require Ipps Policy Privacy LetAppsAccessSystemAIModels Let Apps Access System AI Models Start TurnOffAbbreviatedDateTimeFormat Turn Off Abbreviated Date Time Format (User) Start HideCategoryView Hide Category View (User) Start ConfigureStartPins Configure Start Pins (User) Start AlwaysShowNotificationIcon Always Show Notification Icon (User) Start ConfigureStartPins Configure Start Pins Start HideCategoryView Hide Category View System AllowOOBEUpdates Allow OOBE Updates Windows AI SetMaximumStorageSpaceForRecallSnapshots Set Maximum Storage Space For Recall Snapshots Windows AI DisableSettingsAgent Disable Settings Agent Windows AI AllowRecallEnablement Allow Recall Enablement Windows AI SetDenyAppListForRecall Set Deny App List For Recall (User) Windows AI DisableClickToDo Disable Click To Do (User) Windows AI SetCopilotHardwareKey Set Copilot Hardware Key (User) Windows AI SetDenyAppListForRecall Set Deny App List For Recall Windows AI DisableImageCreator Disable Image Creator Windows AI DisableCocreator Disable Cocreator Windows AI SetMaximumStorageSpaceForRecallSnapshots Set Maximum Storage Space For Recall Snapshots (User) Windows AI DisableClickToDo Disable Click To Do Windows AI SetDenyUriListForRecall Set Deny Uri List For Recall (User) Windows AI DisableGenerativeFill Disable Generative Fill Windows AI SetDenyUriListForRecall Set Deny Uri List For Recall Display ConfigureMultipleDisplayMode Configure Multiple Display Mode (User) Windows Backup And Restore EnableWindowsRestore Enable Windows Restore As Windows evolves and releases features through future feature updates as well as continuous innovation, we’ll continue to review newly added or updated settings to includ in the Intune settings catalog. These may include new controls for security, privacy, user experience, and device management. Be sure to check What's new in Microsoft Intune regularly for additional settings as we add them and check out Create a policy using settings catalog in Microsoft Intune for guidance on how to configure and assign settings to your managed devices. If you have questions or feedback, please leave a comment on this post or reach out to the Intune support team on X @IntuneSuppTeam. Post updates: 10/23/25: The Settings Catalog table has been updated. Settings that were previously limited to 'Windows Insider users' are now generally available.Configure the new Microsoft Intune connector for Active Directory with the least privilege principle
By: Arpit Sinha | Support Escalation Engineer – Microsoft Intune The purpose of the Microsoft Intune Connector for Active Directory, also known as the Offline Domain Join (ODJ) Connector, is to join computers to an on-premises domain during the Windows Autopilot process with the device ultimately becoming Microsoft Entra hybrid joined after the user logs into the device for the first time. The Intune Connector for Active Directory creates computer objects in a specified Organizational Unit (OU) in Active Directory during the domain join process. Important Note: Although fully supported, performing hybrid join during Windows Autopilot isn’t recommended as it can be difficult to configure, troubleshoot, and support over time. For additional information on this topic refer to Join your cloud-native endpoints to Microsoft Entra and the blog, Success with remote Windows Autopilot and hybrid Azure Active Directory join. Earlier this year, Intune released an updated Intune Connector for Active Directory that strengthens security and follows least privilege principles by using a Managed Service Account (MSA). As communicated in both the blog and Message Center, as started in July 2025, older versions of the connector will cease to operate successfully. Below are the useful steps you should follow while configuring the updated Intune Connector for Active Directory: Sign in to the Intune Connector for Active Directory Verify the Intune Connector for Active Directory is active Configure the MSA to allow creating objects in OUs (optional) Error when granting permissions to MSA account An issue that a small number of customers may experience during the connector installation is the inability for the installation process to grant the MSA account the necessary permissions on the default computers container or a specific organizational unit. The below screenshot shows the error message displayed when you encounter this error during installation. The installation log is named odjconnectorUI.txt, located in C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard, and shows the following when you encounter this error: Unknown error: System.DirectoryServices.DirectoryServicesCOMException (0x8007202F): A constraint violation occurred. Workaround and walk through To workaround the above issue, the following is a walkthrough for successfully installing the connector and the steps required to handle the MSA permission error. Follow the Install the Intune Connector for Active Directory on the server guidance to setup the new ODJ connector. You need to initiate the installation with an account that has the following rights: Create msDs-ManagedServiceAccount objects in the Managed Service Accounts container (domain rights) Local administrator on your Windows Server After successful installation and Microsoft Entra sign in (using an Intune Admin or Global Admin account), you’ll get the below confirmation screen in the Intune Connector for Active Directory showing that the connector is successfully enrolled and that an MSA account was successfully created. After selecting on ‘Ok’ in the above confirmation screen, wait a few seconds, and you might receive the error that mentions the MSA account 'could not be granted permission' and will show the MSA name which was created as highlighted in the below screenshot. Note the name of the MSA account as this is needed in a below step. Note: If setup is complete and successful, it won’t throw the above error. If the dialog is closed, go to location ‘C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard’ and relaunch ‘ODJConnectorEnrollmentWizard.exe’. Verify that the connector installation successfully created the MSA in Manager Service Account container in the Active Directory User and Computers console. Note that you must enable Advanced Features in the View menu to show this container. Validate that the 'Intune ODJ connector service' is Running with an Automatic Startup Type and with 'Log on As' use the MSA account configured during the connector’s installation only. As shown in the following example screenshot. Verify in the Intune admin center under Device > Enrollment > Intune Connector for Active Directory that the connector is Active. Note: Inactive connectors in the Intune Connector for Active Directory page will automatically be cleaned up after 30 days. Grant the Create Computer objects permission to the MSA account created by the connector installation on the organization unit or container that you configured the connector to use. This is best done using the Delegation of Control Wizard in the Active Directory User and Computers console. The following screenshot shows the end result. Note: Selecting ‘Configure Managed Service Account’ again will still result in the same permissions error. This is a known issue that can be ignored and will be addressed in the next released build of the connector.You can now proceed with provisioning devices using Autopilot. Look for the following event log events in Event Viewer on the server hosting the connector to validate correct functionality: Event Log Event Application and Services Logs > Microsoft > Intune > ODJConnectorService > Admin Event ID 30120 (successful Event) Application and Services Logs > Microsoft > Intune > ODJConnectorService > Operational Event ID 30130 and 30140 (successful Events) Summary Ensure that you’ve updated to the new connector as old versions will stop working. Additionally, ensure that the Managed Service Account has the correct permissions on the designated organizational unit. This is essential for the smooth operation of the Intune Connector for Active Directory. While you may encounter an error when selecting "Configure Managed Service Account", this can typically be safely ignored during initial setup. To confirm that the connector is functioning correctly and that devices can be provisioned through Autopilot without issues, monitor the event logs under the Intune ODJConnectorService. These logs provide critical insight into the provisioning process and helps validate successful connector enrollment and operation. Related information: Enrollment for Microsoft Entra hybrid joined devices Plan for Change: New Intune connector for deploying Microsoft Entra hybrid joined devices using Windows Autopilot Microsoft Intune Connector for Active Directory security update If you have any questions or want to share how you’re managing your Windows Autopilot devices with Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn.Deep dive into Windows Autopilot device preparation: How to deploy and when to use it
By: Maggie Dakeva - Sr. Product Manager | Microsoft Intune Provisioning devices at scale used to be complex and time-consuming, especially with today’s remote and hybrid work models. Windows Autopilot and Windows Autopilot device preparation simplify and secure the process, helping IT teams deliver ready-to-go devices with minimal touch. Understanding the differences between the two helps organizations choose the right approach for device lifecycle and deployment strategy. Understanding Windows Autopilot device preparation Windows Autopilot device preparation is a next-generation provisioning solution designed to simplify IT setup, improve reliability during device provisioning and provide better reporting and troubleshooting capabilities. While Windows Autopilot has long empowered organizations to automate device setup, Windows Autopilot device preparation introduces significant improvements in consistency, real-time visibility, and flexibility for device management. Key benefits of Windows Autopilot device preparation Simpler setup: Configure a single device provisioning policy that includes both Windows deployment configuration and out-of-box experience (OOBE) settings. Consistent and reliable provisioning experience: Windows Autopilot device preparation removes most of the complexity and unpredictability from device deployments, ensuring better workload coordination. Enrollment time grouping: Allows granular targeting of unregistered devices, reduces the complexity of dynamic group management and latency, and avoids conflicts due to group membership calculations during provisioning. Near real-time reporting: IT admins can review detailed status of each configured app and script in addition to overall status, speeding up issue resolution and unblocking user productivity. Windows Autopilot vs Windows Autopilot device preparation Many customers wonder when they should use Windows Autopilot and when to use Windows Autopilot device preparation. The key difference is in their supported provisioning modes and requirements: Windows Autopilot: Best suited for organizations needing advanced customization, multiple device type support, and hybrid join scenarios. Requires device registration and delivers configurations both during device and user phases. Windows Autopilot device preparation: Designed for rapid, Microsoft Entra joined deployments without the need for Windows Autopilot registration. Focuses on device-based targeting during OOBE and can deliver both apps and scripts, with enhanced troubleshooting and reporting capabilities. For a detailed comparison, review Compare Windows Autopilot solutions. Use Windows Autopilot device preparation if: You haven’t deployed Windows Autopilot before or are looking to simplify your deployment process. Your organization will use a user-driven flow where each user will set up their device. Your organization is transitioning to cloud-native (Microsoft Entra joined) devices or Windows 11. Your organization is deploying Windows 365 Frontline devices. You want to avoid managing Windows Autopilot registration and the complexities it brings during the device lifecycle and repairs. Your organization needs to deploy devices in sovereign clouds (GCCH, 21Vianet in China). You’d like better visibility into the provisioning experience with a more detailed report. Use Windows Autopilot if: Your organization requires pre-provisioning (device is prepared by technician) or self-deploying (shared device) flow. Your organization requires Windows Autopilot registration or the features it provides, such as hiding OOBE pages and renaming devices before enrollment, and device firmware configuration interface (DFCI). Device setup flow step-by-step Understanding the device preparation flow is key to leveraging this method effectively. Here’s an overview of the typical device journey: Overview of all steps of device preparation, described in detail below. Intune setup: You’d need to create a new device security group (steps) and a Device preparation policy in Intune where you include the group. Devices will receive configuration from that security group and will automatically be added to it during provisioning. Physical device setup: Windows Autopilot device preparation requires Windows 11 devices which are not registered for Windows Autopilot and supports only Microsoft Entra joined (cloud-native) deployments. You should always start with a clean image, pre-loaded with drivers. OOBE flow: User authenticates with their Microsoft Entra credentials. Enrollment: Device automatically Microsoft Entra-joins and enrolls in Intune. Windows backup (optional): If Windows Backup for organizations is configured for this user, they will see a page with options to restore user settings from previous device. Device preparation setup: Next, the Intune Management Extension is installed, then the bootstrapper agent which controls the provisioning process, and the device syncs with the mobile device management service (Intune).). Enrollment time grouping: After the device joins Microsoft Entra and enrolls in Intune, Windows Autopilot looks up the configuration assigned to the security group set for enrollment time grouping. Policy installation: Intune policies, line-of-business (LOB) apps, and Microsoft 365 apps are delivered to the device. If any LOB or Microsoft 365 apps are selected in the device preparation policy Windows Autopilot will ensure they deliver successfully before continuing to the next step. Script installation: PowerShell scripts selected in the device preparation policy are delivered. If successful, provisioning continues to the next step. Remediation and custom compliance scripts are not yet available. App installation: Win32, Microsoft Store, and Enterprise App Catalog apps selected in the device preparation policy are installed. If successful, provisioning continues. Apps must also be targeted to the device security group configured during step 1. Reboot: If needed, a coalesced reboot will be triggered prior to moving to the desktop. Device preparation completes: The device completes the Windows Autopilot device preparation setup, user is informed that Required setup is complete. After the device preparation setup is completed, the user may receive a cumulative Windows update at the end of OOBE (learn more) and then set up Windows Hello for Business. Desktop: The user proceeds to the desktop where additional Intune configuration which was not selected in the device preparation policy may be applied. Best practices for Windows Autopilot device preparation To maximize the benefits of Windows Autopilot device preparation, organizations should follow these best practices: Define clear security groups: Create a dedicated device security group in Microsoft Entra and assign the Intune Provisioning Client service principal as the group owner. This step is critical for profile assignment and app delivery. Use policies strategically: Windows Autopilot device preparation policies control the configuration of devices during OOBE. Carefully curate the list of critical apps and scripts, leaving additional configuration to deploy at the desktop. This will ensure an optimal user experience during OOBE. Use device-based apps: Assign apps to the device security group and configure them to install in the system context for successful deployment during OOBE. Manage timeout values: Review and adjust timeout settings in the device prep policy to ensure deployments don’t fail due to time constraints. Start troubleshooting by reviewing the report: Use the Windows Autopilot device preparation deployment report in Intune’s “Monitor” section for near real-time insights into deployment progress and to quickly spot any issues. Common issues and troubleshooting tips Even with the best planning, device preparation may encounter roadblocks. Here are some of the most frequently reported issues and strategies for addressing them: Device enrollment failures Blocked by enrollment restrictions: If corporate identifiers aren’t uploaded, devices may fail to enroll. Ensure these identifiers are added as required. Unsupported OS Version: Devices with incompatible OS versions will not appear in the device preparation deployment report and won’t display the device preparation page in OOBE. They may get the Enrollment status page, if configured for All users and all devices, or proceed straight to the Privacy settings page. Previously registered devices: If a device is already registered for Windows Autopilot, it can’t go through device preparation. Confirm that the registration is removed before deploying with Windows Autopilot device preparation. Application and script deployment issues App detection rules: Always review Win32 app detection rules and the Apps report in Intune. Inaccurate detection logic can cause apps to fail deployment. This is one of the most common issues causing deployment failures. Network constraints: Proxy settings, VPN clients, and Wi-Fi profile configurations may cause network instability if applied during the provisioning process. In addition, Delivery Optimization failures (often caused by network issues) can impede downloading app content. Review network setup and ensure reliable connectivity during the provisioning process. Script execution testing: Execute PowerShell scripts outside of Autopilot to ensure they work independently before inclusion in device preparation policies. Managed installer issues: If Managed Installer policy is enabled for your tenant, Win32 and Microsoft Store apps are skipped. This will be addressed in a future release. Monitor announcements on What's new in Windows Autopilot device preparation | Microsoft Learn. Targeting and context: Make sure apps are set to install in the system context and targeted to the device security group specified in the device preparation policy. Deployment timeout: If a device preparation deployment fails due to timeout, compare the timeout value in the device preparation policy with the actual deployment time reported and adjust as needed. Conclusion Windows Autopilot device preparation marks a significant evolution in Windows device provisioning, offering IT admins a predictable, flexible, and transparent deployment framework. By following the best practices outlined above and leveraging the robust troubleshooting features built in, organizations can minimize deployment headaches and ensure users can provision their devices and become productive as quickly as possible. FAQ Are corporate identifiers the new registration? Corporate identifiers aren’t a replacement for Windows Autopilot registration. They’re needed for organizations that block personal devices and to ensure only trusted devices can be enrolled in your tenant. How do I move from Windows Autopilot to Autopilot device preparation? You’d need to follow these steps: Create an assigned device security group and make sure all configurations are assigned to it. Create a new device preparation profile and assign it to your users. Deregister all devices from Windows Autopilot. Reset all devices. Note that some advanced scenarios aren’t yet available for Windows Autopilot device preparation but may be available in the future. Resources For more details, including updates and a full list of known policies or issues, review the Microsoft documentation below: Overview of Windows Autopilot device preparation Overview for Windows Autopilot device preparation user-driven Microsoft Entra join in Intune Compare Windows Autopilot device preparation and Windows Autopilot As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam or @MSIntune!Microsoft Intune Advanced Analytics in action: Real-world scenarios for IT teams
By: Janusz Gal – Sr Product Manager | Microsoft Intune Microsoft Intune Advanced Analytics empowers IT admins and enterprise users to gain deep insights into device health, user experience, and organizational trends. Building on the foundation of Microsoft Endpoint analytics, Advanced Analytics offers enhanced device timeline reporting, flexible query options, anomaly detection, battery health monitoring, and resource performance tracking. IT admins can use Advanced Analytics to proactively manage their user devices, by turning raw telemetry into actionable insights, and optimizing IT support processes with near real time device information. In this blog post, we’ll review the capabilities provided by Advanced Analytics with example scenarios for how they can be used. Getting started Getting started with Advanced Analytics is easy! Once your license is in place and Endpoint analytics is enabled, Advanced Analytics features will become available in your tenant. For more details on the licensing requirements, review the following: What is Microsoft Intune Advanced Analytics. For those who haven’t enabled Endpoint analytics, now is the time. In the Intune admin center, navigate to Reports > Endpoint analytics. Select All cloud-managed devices in the dropdown (or a subset) and select Start to enable Endpoint analytics for your tenant. Figure 1 Endpoint analytics introduction pane in the Microsoft Intune admin center (Reports > Endpoint analytics). Some capabilities may take up to 48 hours for data to populate for Advanced Analytics analysis, such as anomaly detection, battery health monitoring, and inventory data shown in Device Query for multiple devices. Review Planning Advanced Analytics for a full list of prerequisites, a planning checklist, FAQ and more. Let’s take a look at the new capabilities available when you enable Advanced Analytics in Microsoft Intune. Custom device scopes Think of a subset of the organization you’d like to better understand and compare to the rest of the tenant. Possible examples include executive devices, maybe a specific country or region with a different budget, or even Microsoft Entra hybrid joined and cloud-native devices. With custom device scopes you can recalculate the whole set of Endpoint analytics reports based on scope tags and get the comparisons you need to make informed decisions. Let’s consider a scenario where a subset of the organization has Microsoft Entra hybrid joined Windows devices with decades of group policy being applied and you want to make the business case to invest the time in reviewing and building new policy in Intune. You can create a scope tag, for this example we’ll name it “Hybrid joined devices”, that you apply to hybrid joined devices, and then add that to the device scopes capability within Endpoint analytics. The manage device scopes setting can be accessed by selecting on the device scope selector on any filterable Endpoint analytics pane: Figure 2. Endpoint analytics device scope selection (Reports > Endpoint analytics > Overview). Figure 3. Manage device scopes pane for selecting and creating new device scopes (Reports > Endpoint analytics > Overview > Device scope > Manage device scopes). Under Endpoint analytics reports, navigate to the Startup performance report which showcases Core boot time and Core sign-in time. By default, this report is scoped to All Devices but is filterable using any tag including the one you just created: “Hybrid joined devices”. Figure 4. Startup performance report (Reports > Endpoint analytics > Startup performance). While results will differ for each organization, in the tenant shown here when you set the scope to “Hybrid joined devices”, you’ll see that Group Policy contributes 8 seconds to your Core-sign in time, and overall devices report 9 seconds slower boot times and 30 second slower sign-ins: Figure 5. Startup performance report, recalculated with Device scope. Just like that, you know that users are losing time on each reboot. Depending on how large the fleet is for your organization, that could be a significant amount and worth what it would take to modernize and plan to implement new policies. Of course, you can also use a custom device scope across the rest of the Endpoint analytics reports such as application reliability and work from anywhere. And with Advanced Analytics you also get two additional reports that can be sliced with device scopes – Resource performance and Battery health. Resource performance The resource performance report provides an analysis and score of CPU, memory, and storage metrics over time to identify underperforming devices. Let’s take the same scenario from before – reviewing the hybrid joined devices in your organization. If you have existing hybrid joined devices that are expecting a future device refresh, would it make sense to schedule that sooner because of their performance? When you review the resource performance score, you see how All devices are performing based on their CPU and RAM spike time scores – effectively, how often they are hitting their resource limits. Figure 6. Endpoint analytics resource performance report (Reports > Endpoint analytics > Resource performance). In Endpoint analytics, higher scores indicate that devices are providing better user experiences. For example, in the Resource performance report, a higher score indicates that devices are seeing less CPU spikes. Figure 7. CPU spike time score details pane (Reports > Endpoint analytics > Resource performance > CPU spike time score). You can view performance by specific models or devices using the navigation tabs at the top of the report. Periodically reviewing these results is helpful to ensure your devices are performing well within their ownership or refresh cycles. Better yet, you can use Baselines, which capture a snapshot of the scores for your tenant and allow you to track progress over time: Figure 8. Baselines selection (Reports > Endpoint Analytics > Overview > Baseline). You could, for example, directly see how the overall baseline scores improve a few months after a hardware refresh by checking a previous baseline against the current scores. This can help further justify hardware spending by showing quantifiable improvements to the user experience. For this example, since you know the hybrid joined devices are older than your cloud-native ones, you can reuse your custom device scope here to filter the resource performance report and compare the scores: Figure 9. Resource performance report recalculated via Device scope (Reports > Endpoint Analytics > Resource performance > Device scope set). Now you can also easily identify that your hybrid joined devices are performing worse than average, as they have a significantly lower resource performance score than All devices. Battery health monitoring Advanced Analytics also gives us access to the Battery health report which details capacity and runtime scores across the organization. Figure 10. Battery health report (Reports > Endpoint Analytics > Battery health). The top level report shows a battery capacity score and a battery runtime score, both of which provide a flyout with granular details on how devices are performing: Figure 11. Battery capacity score detail (Reports > Endpoint Analytics > Battery health > Battery capacity score). Figure 12. Battery runtime score detail (Reports > Endpoint Analytics > Battery health > Battery runtime score). Using these reports, you can easily identify devices that need a battery replacement, such as older devices or laptops that have been plugged in for years. These are great candidates to replace sooner – as ever-changing home or office work locations shift, you can improve user confidence in their devices by ensuring a fully charged battery lasts for hours. On the flipside – you can use the Battery health report to assess whether existing devices can have their lifespan extended. Maybe they are five years old but the batteries are still reporting more than 5 hours of runtime on a charge and greater than 80% health. For example, in the hybrid joined device scenario, you were looking for budget to refresh those devices sooner – if you can find existing devices with healthy batteries, you could also check their resource performance results and decide to keep them an extra few years if they are performing well. Device query for multiple devices Suppose you have used the previous capabilities – custom device scopes, resource performance reporting, and battery health reporting – to determine a group of devices within your organization that you want to perform some action on. As mentioned before, this could be extending their lifespan, planning a refresh, or investing in a tooling migration. If you need additional details from devices before making that decision you can use Device query for multiple devices. Device query for multiple devices provides insights about the entire fleet of devices using previously collected inventory data. And since it leverages the flexible and powerful Kusto Query Language (KQL), you can mix and match inventory attributes to get the list of devices that meet your requirements. For Windows devices, before you can use Device query for multiple devices you’ll need to create a Properties Catalog policy. Add the properties you would like to collect and assign the profile to the intended devices. All available properties are automatically collected for Android Enterprise, iOS, iPadOS, and macOS devices, so no extra configuration is needed. Figure 13. Configure and deploy a Properties Catalog profile. You can view collected inventory information for a single device under the Device inventory pane. After a device syncs with Intune, it can take up to 24 hours for initial harvesting of inventory data. Once you have the inventory information collected across the fleet, navigate to Devices > Device query to start querying. Figure 14. Device query for multiple devices (Devices > Device query). Expanding on the scenarios from before, consider a requirement to replace devices with high battery cycle counts. With Device query for multiple devices, you could join battery and CPU data, and better target planned replacements: Figure 15. Running a query (Devices > Device Query). Of course, you can use any of the inventory categories to find applicable devices including storage space, TPM details, enrollment information, and so on. For organizations with Security Copilot licensed and enabled, you can leverage Query with Copilot to generate the KQL queries for you using natural language: Figure 16. Copilot query generation (Devices > Device query > Query with Copilot). Once you have the results, you can export to a .csv to use elsewhere like sharing to the team handling procurement and hardware lifecycle management. Figure 17. Export device query results (Devices > Device Query > Run query > Export). Now that you have your list of devices, what if you need even more detailed information? Granular details from enhanced device timeline and Device query With the results from Figure 15, you were able to find a device with high battery cycles and a relatively old processor. At first glance this is a great candidate for replacement. With Advanced Analytics, you can explore further by navigating to Devices > Windows select a device and leverage the enhanced device timeline and Device query capabilities. The enhanced device timeline shows a 30-day history of events that occurred on a specific device including details on app crashes, unresponsive apps, device boots, device logons, and anomaly detected events: Figure 18. Device timeline pane showing multiple app crashes over the past two days (Devices > Windows > select device > User experience > Device timeline). From here, you have a much better and direct understanding of how a user’s device is performing. If a user frequently sees unresponsive apps, you are now reasonably confident that you’ve found a device worthy of further troubleshooting or replacement. Device query for a single device, on the other hand, let’s you investigate even further and query the device for real-time data such as Windows Event Log Events, Registry configuration, or Bios details. For the full list of properties refer to Intune data platform schema. Figure 19. Device query for a single device, returning process details (Devices > Windows > select device > Device query). With Device query and the enhanced device timeline, you can get all of the granular information needed to make informed decisions about a device. Find additional scenarios with anomaly detection Don’t have a specific goal or unsure of what needs to be resolved? Want to proactively address issues before users start reporting them? Use the Anomalies tab to identify deviations from normal behavior across your environment, such as a spike in application crashes. Figure 20. Anomalies tab showing multiple high severity detections (Reports > Endpoint Analytics > Overview > Anomalies). With the other capabilities provided by Advanced Analytics, you can investigate anomalies in several ways. To start, each anomaly provides a list of affected devices. By clicking through each of these devices, you can use Device query or the enhanced device timeline to get detailed information needed to troubleshoot properly. Figure 21. Anomaly detection report detailing affected devices (Reports > Endpoint Analytics > Overview > Anomalies > select affected devices). Medium and high severity anomalies include device correlation groups based on one or more shared attributes such as app version, driver update, OS version, and device model. Figure 22. Anomaly detection report detailing behavior and impact (Reports > Endpoint Analytics > Overview > Anomalies > select anomaly title). To investigate further, you could create a new custom device scope to recalculate the Endpoint analytics reports for affected devices, use the Resource performance report, or even the Battery health report if that is seemingly causing issues. While a common approach for organizations is an internal initiative that drives an investigation into analytics reports, anomaly detection is certainly a great starting point as well for improving user experience. What’s next Advanced Analytics is continuing to evolve with new capabilities to give you the insights you need on the user device experience. Stay tuned for further blog posts around additional Advanced Analytics and Intune reporting capabilities. If you have any questions or want to share how you’re using Advanced Analytics in Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune!From the frontlines: Managing common kiosk scenarios in your business
By: Saurabh Sarkar – Product Manager 2 | Microsoft Intune I'm Saurabh Sarkar and I've had the opportunity to collaborate with several customers on effectively managing their Windows kiosk devices to enhance productivity with Microsoft Intune. This post covers some of my experience, recommendations, and additional takeaways from these collaborations. It’s a continuation of our From the frontlines series which focuses on frontline worker scenarios. In this post, we’ll explore how to effectively utilize Intune to enhance the productivity of frontline workers in two example sectors: the airline industry and the food and beverage sector (restaurants). Background Kiosk devices are integral to modern business operations, particularly in retail, manufacturing, and the airline industry. These devices serve as dedicated terminals for specific tasks, enhancing efficiency and productivity. In retail, kiosks are commonly used for customer service functions such as self-checkout, product information, and order placement. They provide a seamless and interactive experience for customers, reducing wait times and improving satisfaction. In manufacturing and factory settings, kiosk devices are utilized for various operational purposes including inventory management, allowing workers to quickly check stock levels and update records in real-time. Additionally, kiosks facilitate employee check-ins, shift scheduling, and access to important safety information, ensuring smooth and safe operations on the factory floor. From a technological standpoint, managing these kiosk devices is crucial to maintaining their functionality and security. As shared in the introduction to this series, Intune allows organizations to centrally control and manage their kiosk devices. With Intune, administrators can centrally manage and remotely configure settings, deploy applications, and enforce security policies, reducing the risk of data breaches and unauthorized access. Moreover, this centralized management approach using Intune not only enhances the reliability of kiosk devices but also ensures compliance with organizational policies and industry regulations. Self-service kiosks in airports and restaurants Self-service kiosks at airports offer numerous advantages that improve passenger experience and operational efficiency. They help reduce wait times by allowing passengers to check in, select seats, and print boarding passes quickly and conveniently which is especially beneficial during peak travel times. For airlines, self-service kiosks reduce the reliance on staffing resources and ticket agents resulting in cost savings and allowing airlines to reallocate staff to other critical areas, such as customer service and baggage handling. These kiosks can be activated as needed during busy periods, eliminating the need for temporary staffing solutions. Passengers benefit from the user-friendly interfaces of these kiosks, which are designed to be accessible to people of all ages and tech-savviness. Multilingual support further enhances accessibility for international travelers. Similarly self-ordering kiosks in restaurants reduces wait times and speeds up the ordering process. They also improve order accuracy, as customers input their selections directly, minimizing errors that can occur with verbal communication. The interface allows customers to browse the menu at their own pace, customize their orders, and make payments easily, leading to a more satisfying dining experience. Additionally, kiosks help restaurants save on labor costs by reducing the need for cashiers, allowing staff to focus on food preparation and customer service. Kiosk device provisioning scenario using Windows Autopilot Imagine a busy pizza delivery restaurant that strives to deliver a seamless ordering experience for its customers while streamlining staff operations. The restaurant equips its tables and waiting area with userless Windows devices, each configured to meet the below requirements: These devices are userless, eliminating the need for individual user logins before placing an order. They are configured to display the restaurant's website exclusively, with restrictions on accessing any other URLs or opening any other browser tabs or applications. If the device remains inactive during a session, the browser should automatically refresh and redirect to the homepage, ensuring it’s prepared for the next customer. The IT team leverages Windows Autopilot’s self-deploying mode to transform standard Windows hardware into dedicated ordering terminals. As soon as a device powers on and connects to the internet, it automatically joins Microsoft Entra ID, enrolls in Intune, and configures itself for kiosk use. Microsoft Edge launches in full-screen kiosk mode, locking the device to the restaurant’s website and preventing access to other URLs, tabs, or system applications. The kiosk profile set by Intune ensures that customers only see what they need for ordering, with no distractions or risk of tampering. The restaurant’s digital signage hides unnecessary browser controls, such as the home button, and disables features that could allow customers to exit the ordering environment. If a session remains inactive for 15 minutes, the browser refreshes and returns to the homepage, erasing any previous selections and preparing the device for the next guest. Meanwhile, secure Wi-Fi configurations - automatically deployed via Intune and authenticated using robust device-based certificates - keep each device connected to the network, regardless of user or shift changes. With this setup, the restaurant empowers customers to order efficiently and autonomously, eliminates the need for staff to manage devices, and ensures every kiosk remains secure and ready for use throughout the day. This scenario highlights how Windows Autopilot, Intune, and Microsoft Edge kiosk mode work together to support innovative ordering solutions in the food service industry. Considering the above scenario and requirements, you can deploy a Kiosk type device configuration policy to managed Windows devices as shown in Fig. 1 below. Fig. 1 – Setting up Kiosk configuration profile for Windows. The figure below illustrates the configuration settings that need to be applied in the kiosk profile to fulfill the specified requirements. This is the second page of the Kiosk device configuration profile wizard that is shown after the admin initiates the creation of the profile. Fig. 2 – Configuring settings in Single app Kiosk mode profile for Windows. The following are key points about the configuration: With the logon type set to “Auto logon”, users don’t need to manually sign in to use the device. Note: The auto logon process uses KioskUser0 account and cannot be changed. By configuring digital/interactive signage, you ensure that the home button isn’t visible and prevents users from opening additional tabs in the browser. By configuring the browser's idle time, you ensure that after 15 minutes of inactivity, the browser restarts and redirects to the restaurant's homepage. This process prepares the device for the next user and clears any cached data in the browser. You can also deploy a Wi-Fi profile from Intune that automatically connects the device to allowed SSIDs. You can further automate this connection by deploying and utilizing a device-based certificate using an organization provided PKI and the Certificate Connector for Microsoft Intune or using Microsoft Cloud PKI for Microsoft Intune. The below screenshot shows the user experience in a Windows device running with the Single app Kiosk mode. As we can see, the user doesn't have the home button visible in the browser and is restricted from opening any additional tabs. Fig. 3 – User experience in a Windows device configured with Single app mode Kiosk mode. This is one example of how Intune assists in the management of kiosk devices in various industries. Other examples include the use of kiosk devices in movie theatres for ticketing and information distribution or retail shops for self-checkout and gathering product information. Please refer to the documentation Microsoft Edge Browser Policy Documentation for additional settings that can be configured in Microsoft Edge when using Kiosk mode. This post is part of the “From the frontlines” series which aims to guide customers by exploring recommended practices for deploying, managing, and securing frontline devices using Intune and Windows Autopilot. We’ll publish additional posts on other healthcare scenarios and industries, such as retail and airlines, in the upcoming months so stay tuned and check back frequently! Resources: Please refer to the documentation here for more guidance: To learn about how to get started with kiosk device setup for Windows refer to Frontline worker for Windows devices in Microsoft Intune To learn about the various settings available in the kiosk profile for Windows in Intune refer to Windows 10/11 and newer device settings to run as a kiosk in Intune To learn about all the Windows kiosks configuration options, refer to aka.ms/kiosk To learn about the advances that have been made over the past 12 months for kiosk scenarios with Windows 11 please check our recording from technical Takeoff session Windows 11 kiosks: Cloud management for the win - Microsoft Technical Takeoff We’d love to hear how you're leveraging Intune in your frontline worker scenarios! Feel free to share your experiences or ask questions by leaving a comment below, or by reaching out to us on X (@IntuneSuppTeam or @MSIntune). You can also connect with us on LinkedIn.Support tip: Troubleshoot device cap reached when enrolling devices into Microsoft Intune
By: Premkumar N – Security Customer Experience Engineer | Microsoft Intune When Microsoft Entra or Intune device limits are reached, users will encounter an error when enrolling their device into Intune. While it can be difficult to understand the reason for the failure from the error message, this blog will explain the differences between Microsoft Entra device registration limit and the Intune device enrollment limit, along with the steps to resolve these issues. For an overview of Microsoft Entra and Intune device limit scenarios refer to: Understand Intune and Microsoft Entra device limit restrictions. Let’s look at the experiences on different platforms, followed by the resolution steps. Android Intune device limit reached When the Intune device limit is reached, an Android device enrollment will fail with the following error: To diagnose the issue, review the Intune Company Portal logs for the affected device. Capturing Company Portal logs: Users can select "Email Support" from the error screen to send the logs via email or Send logs from Company Portal. If the Company Portal logs display the “Device Cap Reached” error as shown in the example logs below, this indicates that the Intune device limit has been reached. 2025-07-16T15:07:39.8410000 VERB o.zzafi 13923 6035 sending event: EnrollmentFailureEvent( networkState=CONNECTED, enrollmentFlowType=Enrollment, enrollmentType=AfwProfileOwner, failureName=DeviceEnrollmentFailure, errorException=com.microsoft.windowsintune.companyportal.exceptions.EnrollmentException: Server error = <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Body> <s:Fault> <s:Code> <s:Value>s:Receiver</s:Value> <s:Subcode> <s:Value>s:Authorization</s:Value> </s:Subcode> </s:Code> <s:Reason> <s:Text xml:lang="en-US">Device Cap Reached</s:Text> </s:Reason> <s:Detail> <DeviceEnrollmentServiceError xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment"> <ErrorType>DeviceCapReached</ErrorType> <Message>Device Cap Reached</Message> <TraceId>xxx</TraceId> </DeviceEnrollmentServiceError> </s:Detail> </s:Fault> </s:Body> </s:Envelope>, errorMessage=, sessionGuid=xxx ) By default, Intune allows a maximum of 15 devices per user; exceeding this limit logs an error in the Company Portal. To address this issue, either remove inactive devices that have not checked in to Intune within a specified timeframe, or increase the device limit (up to 15) in the Intune settings. To remove stale devices: Navigate to the Microsoft Intune admin center > Devices > All Devices. Search using the affected user's UPN to view all enrolled devices. Remove any devices no longer in use. To increase the device limit: Navigate to the Microsoft Intune admin center > Devices > Enrollment > Device Limit Restrictions. Select the policy, go to Properties, then edit Device Limit, and adjust the limit (maximum 15). Note: If the Intune device limit is reached, errors are logged in the Microsoft Intune admin center under Devices > Monitor > Enrollment failures. Microsoft Entra device limit reached For Android, users will see the same error message when Microsoft Entra device limit has been reached. You can confirm the Microsoft Entra device limit has been reached by checking the Company Portal logs for the following error: com.microsoft.identity.broker4j.workplacejoin.exception.DrsErrorResponseException: { "code": "invalid_request", "subcode": "error_directory_quota_exceeded", "message": "User 'xxx' is not eligible to enroll a device of type 'Android'. Reason 'DeviceCapReached'.", "operation": "DeviceJoin", "requestid": "xxx", "time": "xxx" } Similar to the Intune device limit reached, to resolve this issue either increase the device limit in Microsoft Entra for Microsoft Entra registration or remove any stale devices associated with the user in the Microsoft Entra admin center. Stale devices are those that are no longer active and can be removed when they haven’t checked in for a specified period. One cause of stale devices is deleting or retiring an Intune device, which may leave behind a record in Microsoft Entra and contribute to reaching the Microsoft Entra device registration limit. To remove stale devices: Go to the Microsoft Entra admin center. Navigate to Microsoft Entra ID > Users. Search for the user using their UPN. Select Devices. This displays a list of registered devices for the user. Devices that are no longer in use can be removed. To increase the device limit for Microsoft Entra registration: Go to the Microsoft Entra admin center. Navigate to Microsoft Entra ID > Devices. Select Device Settings. Locate Maximum number of Devices Per User. Adjust the device limit as needed. iOS Intune device limit reached For iOS, device enrollment may fail with the following error if the device limit has been reached. To check the issue, select 'Report and Email logs' to collect Company Portal logs. If the logs show the below error, it confirms the Intune device limit has been reached. 2025-07-18 12:38:33.427 | utility | 31673 | AlertManager.swift:37 (push(alert:grouping:)) Pushing alert with: grouping = 0 title = Couldn't add your device. message = You have reached the limit of devices you can register. Please contact your company support to increase this number, or review and remove devices that are already registered with this account. into the AlertManager The resolution is the same as Android, refer to the earlier steps for Intune device limit reached on Android. Microsoft Entra device limit reached On iOS devices, Intune enrollment may successfully complete; however, device registration may still result in an error as shown below in the Company Portal app. To collect Intune Company Portal logs, select More > Send logs > Email Logs. When you see the following error message in the Company Portal logs: iOSunderlyingErrorMessage: { "ErrorType": "AuthorizationError", "Message": "User '00000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Ios'. Reason 'DeviceCapReached'.", "TraceId": "00000000-0000-0000-0000-000000000000", "Time": "2025-07-16 14:07:23Z" } To resolve, use the same steps as Android when Microsoft Entra device limit is reached. macOS Intune device limit reached For macOS, device enrollment will fail with the following error when the Intune device limit has been reached. To identify the issue, collect the Company Portal logs by selecting 'Report' and then email the logs. In the logs, when you see the following error, this confirms the Intune device limit has been reached. 2025-07-25 07:39:23.731 | utility | 14262 | AlertManager.swift:37 (push(alert:grouping:)) Pushing alert with: grouping = 0 title = Couldn't add your device. message = You have reached the limit of devices you can register. Please contact your company support to increase this number, or review and remove devices that are already registered with this account. into the AlertManager To resolve, use the same steps as Android when Intune device limit is reached. Microsoft Entra device limit reached For macOS when enrolling into Intune, if the Microsoft Entra device limit has been reached, you’ll notice the following error: In the Company Portal logs, when you see the following error, this confirms the Microsoft Entra device limit has been reached. Description: { "ErrorType": "AuthorizationError", "Message": "User '00000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Mac'. Reason 'DeviceCapReached'.", "TraceId": "00000000-0000-0000-0000-000000000000", "Time": "2025-05-27 05:24:52Z" } To resolve, use the same steps as Android when Microsoft Entra device limit is reached. Windows Intune device limit reached For Windows devices, enrollment will fail with the following error when Intune device limit has been reached: When you see this error, you can check the logs in the event viewer in this path: Source: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin Event ID: 71 MDM Enroll: Failed to receive or parse certificate enroll response. Result: The account has too many devices enrolled to Mobile Device Management (MDM). Delete or unenroll old devices to fix this error. To resolve, use the same steps as Android when Intune device limit is reached. Microsoft Entra device limit reached For Windows, when the Microsoft Entra device limit has been reached, you’ll notice the following error during Intune enrollment: When you see this error, you can check the logs in the event viewer in this path: Windows Device Source: Microsoft-Windows-User Device Registration/Admin Event ID: 304 The get join response operation callback failed with: exit code: Unknown HResult Error code: 0x801c000e Activity Id: a0a15e15-631a-46ab-b0a4-2f540778df7d The server returned: HTTP status: 400 Server response: { "code": "invalid_request", "subcode": "error_directory_quota_exceeded", "message": "User '8b000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Windows'. Reason 'DeviceCapReached'.", "operation": "DeviceJoin", "requestid": "a0000000-0000-0000-0000-000000000000", "time": "2025-05-30 15:33:09Z" } This is the result of the Microsoft Entra device limit reached for the user for Windows platform. To resolve, use the same steps as Android when Microsoft Entra device limit is reached. Device limit reached – Windows Autopilot hybrid join scenario The Microsoft Entra device limit reached error will also occur when changing the primary user in Intune for Windows Autopilot Microsoft Entra hybrid joined devices). In the Autopilot hybrid join scenario there will be two device records in Azure. The Microsoft Entra hybrid join record, and the standard Microsoft Entra join record. Changing the primary user only updates the hybrid joined record in Microsoft Entra, leaving the original user as the owner of the Microsoft Entra join record. The owner entries on the Microsoft Entra join record will impact the device registration limit. Rather than removing the Microsoft Entra join device, which deletes its join state and is not a recommended approach, remove the registered owner on that record. Note: Deploying new devices as Microsoft Entra hybrid join devices isn’t recommended, for more details refer to Microsoft Entra joined vs. Microsoft Entra hybrid joined in cloud-native endpoints: Which option is right for your organization. The following image shows the device state after the Microsoft Entra hybrid joined deployment is completed. User1 enrolled a Microsoft Entra hybrid join device with Intune and Windows Autopilot and the registered user for both the records is ‘user1’. After changing the primary user in Intune to user2, only the Microsoft Entra hybrid joined record is updated for user2. The Microsoft Entra device registration usage for user1 remains unchanged for the Microsoft Entra joined record, both before and after modifying the primary user of the Intune device. This counts toward the Microsoft Entra registration limit for user1. Resolution Before proceeding with the resolution steps for this scenario, it’s important to note the difference between a registered owner and a registered user: Registered owner: A registered owner is the user that cloud joined the device or registered their personal device. The registered owner is set at the time of registration. Registered user: For cloud joined devices and registered personal devices, registered users are set to the same value as registered owners at the time of registration. Remove the registered owner This action can be done using PowerShell and Graph Explorer. Step 1. Check the user's device count in Microsoft Entra ID using Graph Explorer or PowerShell. PowerShell: This query lists the registered devices for the user. Install-Module Microsoft.graph Connect-MGgraph Get-MgUserRegisteredDevice -UserId <userID> Get-MgUserRegisteredOwner -UserId <userId> Sample from PowerShell: Graph Explorer queries: Owned devices for the user GET https://graph.microsoft.com/v1.0/users/{user-id}/OwnedDevices Registered device for the user GET https://graph.microsoft.com/v1.0/users/{user-id}/registeredDevices Sample Graph Explorer output: Only the "ID" in the output is needed to remove the device in next step. { "@odata.context": "******", "@microsoft.graph.tips": "******", "id": "00000000-0000-0000-0000-00000000", "deletedDateTime": null, "accountEnabled": true, "approximateLastSignInDateTime": "******", "complianceExpirationDateTime": null, "createdDateTime": "******", "deviceCategory": null, "deviceId": "******", "deviceMetadata": null, "deviceOwnership": "Company", "deviceVersion": 2, "displayName": "******", "domainName": null, "enrollmentProfileName": null, "enrollmentType": "AzureDomainJoined", "externalSourceName": null, "isCompliant": false, "isManaged": true, "isRooted": false, "managementType": "MDM", "manufacturer": "******", "mdmAppId": "******", "model": "******", "onPremisesLastSyncDateTime": null, "onPremisesSyncEnabled": null, "operatingSystem": "******", "operatingSystemVersion": "******", "physicalIds": [ "******", "******", "******", "******" ], "profileType": "RegisteredDevice" } Step 2. After confirming the user association for the device, remove both the registered owner and user for the Microsoft Entra joined device record to clear the user count toward the pre-defined limit. Graph API query: Replace the 'deviceid' in the following query with the 'id' from the Graph Explorer output from the previous step. Delete Registered Owner DELETE https://graph.microsoft.com/v1.0/devices/{deviceid}/registeredowners/{user-id}/$ref Delete Registered User DELETE https://graph.microsoft.com/v1.0/devices/{deviceid}/registeredusers/{user-id}/$ref This can also be done with PowerShell as below. PowerShell commands In the below commands DeviceID = Microsoft Entra Device ID/ObjectID. It’s important to remove both the registered owner and registered user for the device. Remove registered owner: Remove-mgdeviceregisteredownerDirectoryObjectByRef –DeviceId <DeviceID> -DirectoryObjectId <userID> Sample PowerShell output: Remove registered user: Remove-mgdeviceregistereduserDirectoryObjectByRef –DeviceId <DeviceID> -DirectoryObjectId <userID> Sample PowerShell output: PowerShell or Graph Explorer can also be used to delete the device in other scenarios such as Intune device deletion and Microsoft Entra device ID deletion. Summary Device enrollment can fail when either Intune or Microsoft Entra device limits are reached. These errors can be confusing, however, understanding the difference between Microsoft Entra device registration limits and Intune device enrollment limits makes it easier to sort out and resolve the issue. These issues commonly stem from stale device records, or changing the primary user of a Microsoft Entra hybrid joined device. Resolving them involves removing inactive devices or adjusting device limit policies in the appropriate service. As a best practice, avoid changing the primary user of the Microsoft Entra hybrid joined device and deploy the Windows Autopilot device to new users with a fresh start. Additional information on this topic can be found in the Microsoft Learn docs below: Device limit - Understand Intune and Microsoft Entra device limit restrictions List RegisteredDevices for user - List registeredDevices - Microsoft Graph v1.0 ListOwnedDevices for user - List ownedDevices - Microsoft Graph v1.0 Remove the registered owners for the device - Delete registeredOwners - Microsoft Graph v1.0 Remove the registered user for the device - List registeredUsers - Microsoft Graph v1.0 If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam.
