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.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.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!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.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.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.Registry Inventory in Microsoft Intune: Verifying What’s on Your Devices
By: Madison Cooks, Product Manager | Microsoft Intune IT admins need a reliable way to confirm how Windows devices are configured, especially when troubleshooting, validating compliance, or investigating security posture. Policy assignment alone doesn’t always show what’s present on the device and getting registry visibility at scale has often required custom discovery or remediation scripts that take time to build, test, and maintain. With Microsoft Intune’s July (2607) release, device inventory will include Windows registry data, helping IT admins verify a device’s actual configuration, not just the policy assigned. With a new Device inventory property for registry keys, you define the keys you care about in the properties catalog, and Intune collects them for you. There’s no collection logic to build or keep running. This makes registry-based configuration checks easier to operationalize across managed Windows devices, so teams can spend less time maintaining scripts and more time acting on the data. Figure 1: Microsoft Intune device inventory profile creation screen showing the Properties picker with the Registry category selected for inventory data collection. What registry data you collect Registry data collection is configured through the existing properties catalog. For each entry, provide a registry key path and, when needed, a value name. For every targeted device, the device agent attempts collection and reports: Registry key path Value name Value type Value data Microsoft Intune device inventory profile configuration page showing registry key collection settings, including registry path, collection pattern options, and value name fields. The initial release supports the following collection patterns designed for common admin scenarios that use HKEY_LOCAL_MACHINE (HKLM) paths. Single value Specify a registry path and value name to collect one value from that path. For example, collect Secure Boot certificate servicing status from HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot by using values such as UEFICA2023Status, UEFICA2023Error, or UEFICA2023ErrorEvent. All values under a path, non-recursive Specify a registry path to collect all values directly under that path. This pattern doesn't include subkeys. For example, collect values directly under a Windows Update configuration path to help validate expected settings. Same value across subkeys Specify a base registry key path and a value name to collect that value from each immediate subkey. For example, collect DHCP status across network interface subkeys under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. Where registry inventory data appears After collection, registry inventory data will be available in Device inventory at initial release. We’ll expand access to registry data in the coming months, including support in additional reporting and exploration experiences. Microsoft Intune Device Inventory page displaying collected Windows registry data for a device, including registry key paths, values, collection status, and timestamps. This makes registry data available alongside other inventory signals, so admins can use familiar tools to investigate configuration, validate device state, and support troubleshooting without building separate collection scripts. How admins use this You can collect registry data and view it per device in Device inventory - a verified record of each endpoint’s actual configuration and a key source of settings data on each endpoint. This helps answer questions like: Is a setting actually enabled on the device? Which app, version, or configuration is installed? Did a policy apply correctly? Why is this device behaving differently from the rest? Registry data collection in Device inventory is included with Microsoft Intune Plan 1. Collection results and limits If a registry value exists but doesn’t contain data, collection succeeds and the value appears as empty. If the registry path or value name doesn’t exist on a device, that device reports Not found for the collection result. Collection continues for all other devices, so one missing value won’t block results from devices where the value exists. Registry inventory includes safeguards to keep collection focused and manageable. Each collected registry value is capped at 6 KB, and each device can collect up to 100 registry keys. If a value or device exceeds these limits, collection skips the excess data and reports the applicable result for that device. These limits help manage data volume, maintain service performance, and reduce the risk of over-collection. Registry inventory is designed for configuration visibility and troubleshooting, not for collecting sensitive or confidential data. Built-in heuristic detection helps identify and prevent ingestion of values that may contain secrets, credentials, authentication tokens, certificates, private keys, connection strings, or other data that could grant access if exposed. If a value is flagged as potentially sensitive, it isn’t collected. Collection is limited to HKEY_LOCAL_MACHINE (HKLM) paths. This keeps inventory focused on device-level configuration and avoids user-specific registry contexts. Summary Registry inventory in Microsoft Intune helps admins collect Windows registry data in a native, declarative way. Instead of maintaining custom scripts for common inventory scenarios, admins can configure registry collection in the properties catalog and query the results through familiar Intune reporting experiences. Use registry inventory for configuration visibility and troubleshooting across managed Windows devices. As you plan your collection strategy, focus on device-level HKLM data, avoid sensitive values, and remember collection limits to keep inventory targeted and manageable. If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.
Rethinking “Allow my organization to manage my device” Why opt‑in enrollment works better for Intune
By: Ramya B Sharma – Senior Software Engineer | Microsoft Intune A new public preview feature in Microsoft Intune, we’ve introduced a toggle that allows admins to block automatic mobile device management (MDM) enrollment during the modern app sign-in flow on Windows. This enhancement directly responds to frequent customer requests for greater control over device enrollment, specifically the ability to prevent automatic MDM enrollment on Windows devices during app sign-in. While Microsoft Entra generally recommends automatic enrollment by default, most Intune customers - especially those supporting bring your own device (BYOD), mixed ownership, or multi-tenant access scenarios - benefit from an opt-in enrollment model instead. Recommended best practice Keep “MDM user scope” set to All so enrollment is available when needed, but configure the new toggle “Disable MDM enrollment when adding a work or school account on Windows” to Yes so MDM enrollment is not automatically selected by default during app sign in. This ensures devices are enrolled into Intune only through intentional enrollment flows, reducing accidental enrollments, support burden, and difficult recovery scenarios. Learn more: Automatic MDM enrollment in the Intune admin center. Why this matters For years, Windows users signing into work or school apps have been presented with: “Allow my organization to manage my device.” In most environments, this option was selected by default or clicked through without full understanding. That single action could result in: Microsoft Entra device registration Automatic Intune MDM enrollment Immediate policy application to the device For IT teams, this often led to: Unintended device enrollments Personal or BYOD devices becoming fully managed Difficult unenrollment and recovery experiences The new public preview toggle directly addresses these long‑standing issues. How the modern app sign in enrollment flow works When a user signs into a Microsoft work or school app on Windows, Windows may start a device registration flow. Historically, if: Automatic enrollment was enabled, and The user was in the MDM user scope Then registration could immediately turn into full MDM enrollment, even though the user only intended to sign into an app. What the new toggle changes The new setting“Disable MDM enrollment when adding a work or school account on Windows”: Allows account registration Stops the flow before MDM enrollment Removes the “Allow my organization to manage my device” screen from the app sign-in flow Preserves intentional enrollment paths Important: This setting applies to modern app sign in flows, not Windows settings–based enrollment. Allowing enrollment versus forcing enrollment This distinction is critical. Allowing enrollment: MDM user scope is configured to “All” or “Some” Enrollment is available when needed Devices enroll through deliberate flows Forcing enrollment Enrollment triggered implicitly App sign in becomes an enrollment decision Users may not realize the device is managed Recovery is harder later The new toggle lets organizations separate these behaviors. Impact across common Windows enrollment scenarios Scenario Default behavior Opt-in recommended behavior BYOD / personal devices High risk of accidental enrollment App access without device takeover Microsoft Office / Teams sign in May initiate MDM enrollment No MDM enrollment unless user chooses Microsoft Entra hybrid join (corporate) Microsoft Entra joined Microsoft Entra joined Windows settings enrollment MDM enrollment MDM enrollment Windows Autopilot / provisioning MDM enrollment MDM enrollment Security and governance benefits Opt-in enrollment supports: Least surprise Explicit consent Cleaner BYOD posture Safer break glass scenarios Reduced support escalations It also aligns well with Conditional Access and app level protection strategies. When to use the default behavior Default automatic enrollment may still be appropriate for: Fully corporate owned device fleets Locked down environments Dedicated provisioning scenarios The key is that it should be a conscious decision, not an accidental one. Summary In conclusion, for most organizations, the modern best practice is: Allow enrollment everywhere - require intent. Using the new Intune toggle to make enrollment opt-in during app sign in reduces risk, improves user trust, and simplifies the device lifecycle - without sacrificing Intune’s management capabilities. Recommended reading: For a concrete example of the end‑user experience with this model, see Step 6: Understand Microsoft Edge for Business End User Experience for Windows, which walks through how opt‑in enrollment and app‑level management are presented to users in Microsoft Edge for Business. Understand Microsoft Edge for Business End User Experience for Windows. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Configure Delivery Optimization for Windows to save bandwidth and speed up deployments
Delivery Optimization is built into Windows and can help reduce bandwidth usage during app and update deployments. Instead of downloading content from the internet every time, devices can download it from nearby devices or a local cache when available. Many organizations leave Delivery Optimization at its default settings or disable it entirely. As a result, they may miss opportunities to reduce network traffic, improve deployment performance, and make better use of existing network resources. This article focuses on the Delivery Optimization scenarios and the common configurations that Intune admins use most often: large-scale patching, Windows Autopilot provisioning, branch office bandwidth management, and Microsoft Connected Cache for scenarios where peer-to-peer sharing alone isn't enough. How Delivery Optimization works Delivery Optimization is an HTTP downloader with built-in peer-to-peer capabilities available in supported versions of Windows. It helps distribute Windows updates, Microsoft 365 Apps updates, Microsoft Defender definition updates, Microsoft Store apps, Intune Win32 apps package and other supported content. Delivery Optimization checks local sources before falling back to internet content caches. The most important Delivery Optimization policy setting is Download Mode, which determines how devices discover peers. Mode Description Mode 1 (LAN) Devices share content with peers behind the same IP/NAT boundary. Mode 2 (Group) Devices share content within a defined group, such as an Active Directory site, domain, or custom group ID. Recommended for environments with multiple VLANs or segmented networks. Mode 3 (Internet) Devices can share content with internet peers outside the organization. This mode is rarely used in enterprise environments. Delivery Optimization checks sources in this order: LAN or group peers and, if configured, Microsoft Connected Cache in parallel. Internet peers, if allowed in the Download Mode setting Internet content caches, which are always available as the final fallback Regardless of the mode you choose, the goal is to keep content download traffic local whenever possible. Common misconceptions Before configuring Delivery Optimization, it's worth addressing a few common misunderstandings we’ve heard from customers. "Does Delivery Optimization use my bandwidth to upload content to the internet?" In Mode 1 (LAN), peer sharing is restricted to your local subnet. Content is only shared with other devices on the same network segment, and no content leaves your LAN. Additionally, you have full control over upload usage through the Monthly upload data cap setting. "Is Delivery Optimization the same as BranchCache?" While both technologies help reduce bandwidth usage, they are built on different architectures and support different scenarios. BranchCache relies on BranchCache-enabled content servers to cache and distribute content, whereas Delivery Optimization is built directly into Windows and is designed to work natively with cloud-delivered content, including Windows updates, Microsoft Store apps, and Microsoft 365 Apps. "We disabled Delivery Optimization years ago. Is there any reason to revisit it?" Yes. Delivery Optimization has evolved significantly and now offers extensive management capabilities through the Intune Settings Catalog. Administrators can configure download modes, define group boundaries, control bandwidth usage, set cache sizes, and limit uploads. If Delivery Optimization was disabled in the past, it may be worth reevaluating your configuration. When properly configured, it can help reduce bandwidth consumption, improve content distribution efficiency, and accelerate update and application deployments. Essential policies The following settings, available in the settings catalog under Delivery Optimization, provide you a strong starting point: Setting Default Value* Recommended Value What It Does DODownloadMode 1 (LAN) 1 (LAN) Keeps peer-to-peer sharing within your subnet or Delivery Optimization group. DORestrictPeerSelectionBy 1 1 Devices discover and peer with others on the same subnet. DOMaxCacheSize 20% 20% to 30% Amount of local disk space allocated to the Delivery Optimization cache. DOMinFileSizeToCache 50 MB 5 MB Minimum file size eligible for caching and peer-to-peer distribution. DOMaxCacheAge 259,200 seconds (3 days) 1,209,600 seconds (14 days) Determines how long cached content remains available before cleanup. DOMonthlyUploadDataCap 20 GB 20 GB Limits the total amount of data a device can upload to peers each month. *The default values in this table are for Windows 11. The table above lists common Delivery Optimization settings, their default values, and recommended starting values. However, the best configuration depends on your network topology, device count, update cadence, and whether you’re using Microsoft Connected Cache. Use the scenario guidance below to tune from the baseline. for the full policy reference review: Configure Delivery Optimization (DO) for Windows. The defaults provide some immediate value, but organizations often achieve better results by: Defining peer groups Increasing cache size Increasing retention periods Lowering the minimum file-size threshold when appropriate When configuring Delivery Optimization, avoid managing the same setting from multiple locations, such as settings catalog and custom policy. Using the settings catalog as your primary management location can help reduce conflicts and simplify troubleshooting. Windows quality updates, feature updates, and Office updates are typically the largest bandwidth consuming events most organizations face. A 1 GB cumulative update pushed to 10,000 devices means 10 TB of traffic from the internet unless Delivery Optimization lets devices share locally. This is where properly configured Delivery Optimization pays for itself immediately. Coordinate Delivery Optimization with deployment rings. Start with a small seeder ring, typically 5 to 10 percent of devices, so those devices populate peer caches before broader rings begin hours or days later. If Microsoft Connected Cache is deployed, the same seeder ring also populates the cache node, creating a persistent local source for later rings. Scenario 1. Large-scale update deployments Large scale deployments vary greatly in complexity and challenges. Device count isn’t the only factor to consider. Network infrastructure and configuration can also play a role in your configuration and deployment of Delivery Optimization. How you tune Delivery Optimization for large-scale updates depends heavily on your WAN topology. The two most common designs call for different approaches: Star (hub-and-spoke) topology Branches connect to a central hub; internet traffic may be backhauled. Every update byte a branch device pulls from the internet crosses the internal link between the hub and spoke. Group boundaries: Identify local LAN configurations at branch locations. If all devices at a branch location are on a single subnet, use DODownloadMode = 1 with DORestrictPeerSelectionBy=1 to restrict peers to that subnet. If a branch site has multiple subnets, DODownloadMode = 2 with a branch-specific DOGroupID is more effective because devices can discover peers throughout the branch instead of being limited to their local subnet. Tip: Delivery Optimization Has Evolved Many organizations disabled Delivery Optimization during early Windows 10 deployments after experiencing unexpected WAN traffic. At that time, peer sharing controls were far less granular, making it difficult to limit content sharing to devices within the same network or site. As a result, some organizations chose to disable Delivery Optimization entirely and missed potential bandwidth savings from peer-to-peer content distribution. Today, modern Delivery Optimization policies provide significantly more control through features such as Group mode, Group IDs, subnet-based peer restrictions, bandwidth management settings, and integration with Microsoft Connected Cache. These capabilities help organizations realize the benefits of peer caching while maintaining tighter control over network traffic. Bandwidth throttling: Spoke links are often the bottleneck. Use DOPercentageMaxBackgroundBandwidth to limit Delivery Optimization background downloads to 10% to 25% of available bandwidth during business hours. Configure DOSetHoursToLimitBackgroundDownloadBandwidth to define the hours when those limits apply, then relax or remove the limits outside business hours. Cache retention: Set DOMaxCacheSize to 40% to 50% and DOMaxCacheAge to match your final deployment ring so cached content survives all ring phase days at branches. Branch peers are the only local sources. They need to hold content long enough for the full ring cycle. Hub site: Devices at the hub have direct internet access and also typically have more bandwidth available. Standard cache settings (20% to 30%, 3 days) are usually sufficient. Tip: Combine Peer Caching and Microsoft Connected Cache In star (hub-and-spoke) network topologies, Microsoft Connected Cache (MCC) can deliver the greatest bandwidth savings at central hubs and larger branch offices. By caching frequently requested updates and applications locally, MCC helps reduce the amount of content that must traverse upstream WAN links. You can configure an MCC server directly in your Delivery Optimization policy by specifying: DOCacheHost=<MCC FQDN> When configured, Delivery Optimization continues to prioritize content from nearby peers. If the requested content isn't available from peers, devices will attempt to download it from Microsoft Connected Cache. If the content isn't present in the cache, devices automatically fall back to Microsoft's internet content source. Think of the content retrieval process as a layered approach: Peers → Microsoft Connected Cache → Internet. This hierarchy helps optimize bandwidth usage while maintaining reliable access to updates and applications. Distributed topology With a distributed topology, all locations have their own local internet access. Each site reaches the internet directly, so the WAN penalty for a cache miss is lower. Group boundaries: Set DODownloadMode=2 and set a DOGroupID. The key is that each physical site is its own peer group. DORestrictPeerSelectionBy = 1 (Subnet) is still recommended but less critical because cross-site peer-to-peer traffic is less likely. Bandwidth limits: More relaxed than star. 25% to 50% during business hours is typical since each site has its own internet cache path. Tip: With local internet connectivity and Delivery Optimization Group mode, many locations achieve excellent bandwidth savings with no additional infrastructure. Microsoft Connected Cache adds value primarily at the largest locations (more than 100 devices). Scenario 2. Branch offices with limited WAN Branch offices often see the biggest Delivery Optimization savings. Instead of every device pulling the same update over the WAN, one device can download from the internet and share locally with peers on the subnet. Use DODownloadMode = 2 and assign a unique DOGroupID per branch location to keep peer-to-peer traffic within the branch. Set aggressive background limits (15% to 25% of link speed) to protect line-of-business applications. For very small branches with fewer than 10 devices, or locations where devices are frequently reimaged, consider adding a Microsoft Connected Cache node. A small cache server with a 100 GB drive provides a persistent local source that doesn't depend on any single peer being online. Scenario 3. Mass provisioning and Windows Autopilot During Windows Autopilot bulk provisioning or mass reimaging, many devices request identical content at the same time. Without Delivery Optimization, every device downloads independently from the internet cache, often saturating internet links and extending provisioning times. For environments with repeated content consumption, such as shared devices, labs, and kiosks that get reimaged frequently, peer-to-peer distribution has a structural limitation. After a mass reimage, no device has cached content available to share. This is where Microsoft Connected Cache provides the greatest value. Because the cache node retains content on-premises independent of device state, the first device after a wipe can download from the local cache rather than the internet cache. If you're using peer-to-peer alone, consider staggering reimage schedules so that some devices always have content available to share. Intune already uses Delivery Optimization to distribute Win32 and Microsoft Store apps, so no extra setup is needed beyond the core Delivery Optimization policies. The main tuning is around thresholds and retention. Lower DOMinFileSizeToCache from 10 MB to 5 MB so snaller app installers qualify for peer-to-peer sharing and extend DOMaxCacheAge to 7 days (604800 seconds) to accommodate app deployments that often span a full week. During large provisioning events, be generous with cache resources. Increase DOMaxCacheSize to 50 percent or higher to ensure early devices have room to cache and share content. Set DOMonthlyUploadDataCap to 0 (unlimited) so the first-wave of devices can serve a larger number of peers. Finally, provision devices in stages whenever possible. Even a 15-minute delay between groups gives Delivery Optimization time to build peer availability before the next wave starts. Scenario 4. Devices that move between locations In environments where employees frequently move between locations, isolating peer traffic can be challenging. For example, a device assigned to the Group ID for Branch A may be physically connected at Branch B, causing it to search for peers across the WAN. In this scenario, use DHCP to provide the appropriate DOGroupID and, when applicable, DOCacheHost source for the device’s current location. DOCacheHostSource=1 and set the DHCP Option 235 at the site to the FQDN of the Microsoft Connected Cache. DOGroupIdSource=3 and set the DHCP Option 234 to the GUID for the GroupID. Go further with Microsoft Connected Cache Microsoft Connected Cache is an optional on-premises content cache. It complements Delivery Optimization by providing a persistent local source when peers are unavailable. Tip: Start with Peer-to-Peer Caching First Before deploying Microsoft Connected Cache (MCC), consider optimizing Delivery Optimization peer-to-peer caching. Many organizations achieve substantial bandwidth savings through properly configured download modes, peer groups, cache settings, and deployment rings without introducing additional infrastructure. Peer-to-peer caching is often the simplest and most cost-effective first step because devices can share content directly with one another, reducing internet downloads and WAN utilization across the organization. Microsoft Connected Cache becomes particularly valuable when peer sharing alone cannot fully meet business requirements, such as locations with few devices, frequent device reimaging, limited peer availability, or a need for a persistent on-premises content source. In these scenarios, MCC can complement Delivery Optimization to further reduce bandwidth consumption and improve content availability. Microsoft Connected Cache is most valuable at small locations with few peers, in environments with frequent device resets, or anywhere large content volumes need a guaranteed local source. Devices can find the cache node in two ways: Static (Intune policy): Set DOCacheHost to the FQDN of your Microsoft Connected Cache server in the Intune Settings catalog. Simple, static, works well for single-site deployments. Dynamic (DHCP Option 235): Set DOCacheHostSource = 1 and configure DHCP Option 235 with the MCC server FQDN. Devices discover the correct cache node automatically based on network location. This is the preferred approach for multi-site deployments. When using Microsoft Connected Cache, configure DODelayForegroundDownloadFromHttp to 30 seconds and DODelayBackgroundDownloadFromHttp to 60 seconds. These timeouts control how long Delivery Optimization waits for a local source before falling back to the internet cache; they don’t control download speed. For setup details and hardware requirements, refer to: Release Notes for Microsoft Connected Cache for Enterprise and Education. Troubleshooting tips Slow downloads: The fallback timeout is the most misunderstood Delivery Optimization setting. It controls how long a device waits for a local source before requesting from the internet cache, not download speed. If downloads are slow, check network routing, DNS, and firewall rules. Cache misses: Internet cache Vary headers can prevent content from being cached on the first request. Microsoft Connected Cache respects these headers, which can cause initial cache misses. The product team is actively working on a fix. Diagnostics: Run the Delivery Optimization troubleshooter at aka.ms/DO-Fix for automated diagnostics. PowerShell: Use Get-DeliveryOptimizationStatus in PowerShell to see real-time download source, peer count, and bytes per source for each active download. Delivery Optimization reporting: Centralized reporting is available in the Windows Update for Business Delivery Optimization report or through PowerShell cmdlets. Monitor Delivery Optimization. Get started Delivery Optimization is already available on supported Windows devices you manage. The configurations in this post take minutes to deploy through the Intune settings catalog and can save significant bandwidth with every update cycle and application deployment. Start with the essential policies table, pilot the profile with a small device group, and review Windows Update for Business reports after a couple of patch cycles to measure the impact. Many organizations achieve their goals using Delivery Optimization peer-to-peer caching alone. For scenarios where peer caching is insufficient or a persistent local cache is required, Microsoft Connected Cache is available as an additional option. The product team is active in the Connected Cache Community at aka.ms/ConnectedCacheCommunity, and feature ideas can be submitted through the Intune feedback portal at aka.ms/IntuneFeedback. Resource Link Configure Delivery Optimization Configure Delivery Optimization Delivery Optimization Troubleshooter Run the Delivery Optimization Troubleshooter Microsoft Connected Cache Release Notes View MCC Release Notes Connected Cache Community Join the Community DO + MCC AMA Recording Watch the AMA Recording Intune Feedback Submit Product Feedback If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.
