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.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.Build a patch strategy for today’s threat pace with Microsoft
AI-accelerated vulnerability discovery and remediation are changing how organizations manage risk. As discussed in Pavan Davuluri’s recent blog, Microsoft is investing across the vulnerability lifecycle to help organizations identify, validate, and respond faster. For IT and security teams, one challenge lies downstream: deploying fixes quickly across endpoints to reduce exposure. Each update needs to be evaluated, piloted, monitored, and enforced across a mixed fleet of devices and apps. Some parts of the estate can move quickly; others cannot because of compliance requirements, approved change windows, and business-critical dependencies. As organizations adopt AI tools and agents across their environment, maintaining a current and hardened endpoint estate becomes increasingly important. In this context, patching becomes an ongoing operational discipline that combines OS, app, and driver updates with compliance enforcement, access control, and security baseline hardening. To keep pace, organizations need a patch strategy that helps in 3 stages: Mitigate: automate updates that can move quickly Assess: prioritize risk based on exposure and severity Contain: enforce compliance and limit exposure Operationalizing a patch strategy requires coordinated capabilities across endpoint management and security tools. Microsoft Intune brings these capabilities together in a single admin center, alongside the broader Microsoft security ecosystem, and is available with qualifying Microsoft 365 subscriptions 1 . In this post, we show how organizations can use these capabilities to build a patch strategy that helps reduce the time between update release and deployment across their endpoint estate. 1. Mitigate: automate updates that can move quickly A patch strategy is not about pushing every update everywhere at once. It’s about identifying the parts of your estate that can move quickly, then using automation, rings, monitoring, and enforcement to help those updates move with confidence. Regulations, approved change windows, validation needs, and business dependencies will shape what’s possible, but the strategy starts by separating repeatable update work from the exceptions that need deeper review. For OS, app, and driver updates that can move quickly, modern tools can help shorten the time between update release and deployment; without manual rollouts, ticket-driven packaging, or reboot disruption. Operationalize in Intune Windows Autopatch orchestrates ring-based update rollouts to reduce manual effort and keep Windows devices current. To help monitor risk, the Autopatch report visualizes how quickly devices apply updates based on the configured deployment cadence. In this report, devices are categorized as current within three days of update release, at risk between three and seven days, and at critical risk beyond seven days, based on the reporting model used by Windows Autopatch. Learn more about ring-based rollout updates or how to reassess Windows OS updates using this report. Hotpatch (enabled by default for 24H2+ in Intune) applies critical updates without requiring a reboot, helping reduce security gaps while keeping users productive. Figure 1: Watch the latest Microsoft Mechanics episode to see how Windows Autopatch and Hotpatch help organizations accelerate update deployment, reduce operational overhead, and keep devices secure. Intune Enterprise App Management (EAM) supports keeping Windows apps current through auto-updates, including the guided upgrade supersedence reporting, which surfaces outdated versions or version changes. EAM auto-updates are now generally available; details are included in the June Intune What’s new blog. Figure 2: Watch how Intune helps you move from update release to deployment to accelerate responses to vulnerabilities with Windows app management. The enhanced application inventory in the All apps page shows the app version installed on each managed Windows device, refreshed multiple times per day on most active devices, helping teams target app-specific vulnerabilities and confirming when fixes have been applied. The Vulnerability Remediation Agent in Security Copilot uses data from Defender Vulnerability Management to prioritize Common Vulnerabilities and Exposures (CVEs) across Intune-managed Windows devices and apps, and provides recommended remediation actions within Intune. The Vulnerability Remediation Agent is currently in public preview, read the blog to learn more. Figure 3: Watch this video to see how the Vulnerability Remediation Agent in Security Copilot, within Microsoft Intune, helps make agentic security easier to adopt and use. Extend across your endpoint estate Apple devices can be configured for automatic OS updates on managed devices, including enforcing updates to the latest version and deploying Background Security Improvement patches through the settings catalog. App updates can be managed by configuring volume-purchased App Store apps to update automatically and deploy updated app packages to keep apps current across macOS, iPhone, and iPad devices. Android devices can be managed using built-in update policies in Intune, including configuring install windows and freeze periods. For corporate Android fleets, Intune also integrates with OEM firmware management solutions - including Zebra LifeGuard Over-the-Air and Samsung E-FOTA - to enable more granular update control. Managed Google Play also supports configurable app auto-update modes, allowing admins to define whether updates install automatically, on Wi-Fi only, or manually. 2. Assess: prioritize risk based on exposure and severity The first step is reducing exposure across the parts of your estate that can move quickly. But not every system, application, or vulnerability can be addressed through broad update deployment. Teams also need a way to determine which risks require immediate action and which ones can be addressed over time. A calendar-based approach can treat every CVE equally. However, it doesn’t account for severity, exposure, or business impact. As AI accelerates vulnerability discovery, this can lead to effort being spent on lower-risk updates while higher-risk updates remain unaddressed. Risk-based service level objectives (SLOs) help bring prioritization to address this challenge. Instead of patching on a fixed schedule, IT and security teams can align response timeframes by severity, moving quickly on actively exploited or critical vulnerabilities, and applying a more measured approach where risk or impact is lower. This stage creates a clearer prioritization of remediation and helps bridge the view between the security teams that identify threats and the IT teams that act on them. Operationalize in Intune and Microsoft Defender The security update status dashboard in Intune provides an aggregated view of update compliance across Windows clients, Windows servers, and Microsoft 365 Apps. It shows overall counts of devices in different states across Intune-endpoints and helps teams identify where remediation should be focused. These status categories reflect how quickly devices apply updates based on a configured deployment cadence and internal SLOs. Figure 4: Security update dashboard showing patch status for Windows clients, servers, and Microsoft 365 apps. Microsoft Defender Vulnerability Management surfaces CVEs, affected devices, vulnerable software, and recommended remediation actions, offering a shared view of risk and progress across IT and security teams. Translate Defender recommendations into targeted Intune actions described in the mitigate section, such as updating software or moving devices through expedited remediation workflows so teams can focus on vulnerabilities that are actively exploited or most likely to affect an organization. Extend across your endpoint estate For Apple devices, use the Apple software update report in Intune to monitor update status across macOS, iOS, and iPadOS. For Android, compliance reporting surfaces devices that fall behind on OS version or security patch level. 3. Contain: enforce patch compliance and limit exposure Even with automated deployments and prioritized triage, gaps can remain. Some devices are unsupported, fall behind, operate on slower deployment rings, and others can’t be patched quickly. A patch strategy needs to focus on including containment for those surfaces. Compliance controls, conditional access, and device hardening act as an always-on safety net that limits risks that can fall through gaps. Compliance policies and Conditional Access can use a patch state as a signal for resource access, preventing non-compliant devices from accessing corporate resources. Security baselines reduce the attack surface by limiting risky defaults and common attack patterns. Together, these controls shift enforcement from a periodic activity to a continuous condition across a fleet. Operationalize in Intune and Defender Use compliance policies in Intune to define what "current" means, including minimum OS build, required update levels, risk status, and encryption state. Use Conditional Access (managed in Microsoft Entra, accessible from the Intune admin center) to control access to company resources based on user and device health. Combined with threat signals from Microsoft Defender, these policies help prevent non-compliant devices from accessing corporate resources. Use Microsoft Defender Vulnerability Management and Microsoft Security Exposure Management insights to identify exposed assets, prioritize remediation, and apply recommended protections where patching must move more slowly. Apply Intune security baselines to establish Microsoft-recommended configurations on Windows devices, such as disabling risky defaults, blocking common attack techniques, and reducing configuration drift. Watch this demo on security baselines being applied in the Zero Trust workshop. Use attack surface reduction policies in Intune to deploy Microsoft Defender for Endpoint protections, such as ASR rules and network protection, that help block common attack techniques on devices that can't be patched right away. Figure 5: Watch this Demo on how you can manage devices and implement Conditional Access with Intune. Extend across your endpoint estate Compliance policies and Conditional Access controls apply across Windows, macOS, iOS/iPadOS, and Android. Intune app protection policies extend compliance requirements and data protections to managed apps used for work on personal devices and add an additional layer of data protection on corporate devices. Use the settings catalog and configuration profiles to apply the same hardening intent on macOS, iOS/iPadOS, and Android, reducing configuration drift across platforms. Stay ahead with a patch strategy As vulnerability discovery and response continue to accelerate, organizations need an operational strategy that balances speed, risk, and resilience. By automating updates where possible, prioritizing remediation based on exposure, and limiting exposure through compliance and security controls, teams can reduce risk across their endpoint estate. Intune helps simplify this approach by bringing these capabilities together alongside the rest of your Microsoft security tools and ecosystem. Get started with Microsoft Secure Now to assess risk across your digital estate. Explore the new security update status dashboard in Intune. Harden the admin plane and review the best practices for securing Microsoft Intune. 1 Licensing and requirements Feature availability and included capabilities vary by Microsoft 365 subscription plan and feature. Some Microsoft capabilities referenced in this post may require specific licenses or additional enablement. Advanced Microsoft Intune capabilities are now included in Microsoft 365 E5, with select capabilities available in Microsoft 365 E3 as part of updates effective July 1, 2026. Existing customers will receive a 30-day notice in the Microsoft Admin Center prior to availability, with access beginning by August 2026. Microsoft Security Copilot and related AI capabilities may require separate licensing, learn more here. Stay up to date! Bookmark the Microsoft Intune Blog and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation.MDOP is out of support: What to do next with Microsoft Intune
By: Joe Lurie – Sr. Product Manager | Microsoft Intune On April 14, 2026, the Microsoft Desktop Optimization Pack (MDOP) reached the end of extended support. Microsoft no longer provides security updates, bug fixes, or technical support for MDOP components. For more information, refer to: Microsoft Desktop Optimization Pack (MDOP) support extended. If your organization still relies on parts of MDOP, it’s time to move to supported options. In most cases, including Windows desktop management, app virtualization, BitLocker administration, and Group Policy change control, you can handle the same workloads with capabilities in Microsoft Entra ID, Intune, Windows 11, and Configuration Manager. Moving these workloads to the cloud does more than keep you supported. It removes on-premises server infrastructure you have to stand up and patch, brings management of cross-platform devices into a unified console, and connects capabilities like encryption and recovery into a Zero Trust framework with Conditional Access. Quick start checklist Inventory what you actually use. Confirm whether Application Virtualization (App-V) server components, Microsoft BitLocker Administration and Monitoring (MBAM), Diagnostics and Recovery Toolset (DaRT), User Experience Virtualization (UE-V), or Advanced Group Policy Management (AGPM) are still in production. Prioritize BitLocker Management first. If you still rely on MBAM, plan your move to BitLocker management in Intune and confirm recovery key escrow is working as expected. Plan your App-V exit. Keep existing App-V packages running where needed but shift net-new packaging work to MSIX. Validate your PC recovery story. Document how you’ll handle common break/fix scenarios using Quick Machine Recovery, WinRE, bootable media, and Intune remote actions. Decide how you want to handle policy change management. For cloud policy, we recommend Multi Admin Approval for sensitive actions and policy-as-code practices for versioning and review. App-V App-V let you virtualize applications so they could run in isolated environments without a traditional install, which helped avoid app conflicts. It was especially useful for legacy line-of-business apps that were hard to install or update cleanly. Important The App-V server components (Management Server, Publishing Server, Reporting Server) reached end of extended support in April 2026. The App-V client and sequencer are still included with Windows Enterprise and Education editions. They will continue to receive security fixes for the support lifecycle of the Windows versions they ship with. If you are distributing App-V packages today via Configuration Manager, that can still work. The key change is that you should not plan on using the standalone App-V server infrastructure going forward. For more details refer to: App-V in Windows support policy. What to do instead: For new packaging work, we recommend moving to MSIX. MSIX is a modern packaging format that supports clean install and uninstall and more predictable updating. The MSIX Packaging Tool can help you convert existing installers. In Azure Virtual Desktop, MSIX App Attach can deliver apps without baking them into the base image. A good starting point is to inventory your App-V packages, identify the ones you still need, and prioritize candidates to convert to MSIX. MBAM MBAM gave IT admins centralized control over BitLocker, including policy enforcement, compliance reporting, and a self-service recovery portal. Many organizations used MBAM as their standard management solution. What to do instead: We recommend replacing MBAM with Microsoft Intune’s BitLocker policy management through an Endpoint security policy. Intune management provides backup of recovery keys to Microsoft Entra ID, reporting, and Conditional Access integration so you can require encryption for access to company resources. If you already manage devices with Intune, you may only need to create a disk encryption policy and confirm recovery keys are being escrowed. For detailed guidance, review Encrypt Windows devices with BitLocker using Intune. DaRT DaRT provided a bootable recovery environment with advanced tools like file recovery, registry editing, and offline troubleshooting. You typically used DaRT when a machine wouldn’t boot and you needed to repair it or recover data without reimaging. What to do instead: Windows includes the Windows Recovery Environment (WinRE) with tools like Startup Repair, System Restore, command prompt, and reset options. For many scenarios DaRT covered, WinRE is enough. You can also boot from a Windows installation USB, select "Repair your computer," and use the recovery tools for tasks like offline troubleshooting. For managed devices, you can pair recovery options with Intune remote actions, such as restart, wipe, or collect diagnostics, or use Quick Machine Recovery. Additionally, Quick Machine Recovery can automatically detect and fix boot failures using cloud-based remediation delivered through Windows Update, with no hands-on IT intervention required for managed devices running Windows 11 version 24H2 or later. You can enable and configure it through the settings catalog in Intune, and Windows Autopilot scenarios for redeployment. These don’t replace every DaRT capability, but they cover many common use cases and work without shipping a separate recovery toolkit. UE-V UE-V roamed (synchronized) some user application and OS settings to persist across devices so users could sign in to a different Windows PC and keep a familiar experience. This was often used in shared workstation scenarios. What to do instead: For Windows settings roaming, Windows Backup for Organizations syncs certain Windows settings across Microsoft Entra ID joined devices. Review the latest guidance to confirm which settings are covered and how to enable it in your environment. Important: Windows Backup for Organizations syncs Windows settings (theme, password, language) but doesn’t roam per-application settings for Win32 apps. Some apps may provide their own cloud-based sync. Windows Backup for Organizations is not a direct replacement for UE-V. For user files, we recommend OneDrive Known Folder Move to back up Desktop, Documents, and Pictures so content follows the user. Many Microsoft applications also sync their own settings through the cloud, which reduces the need for an OS-level roaming solution. Another option is to use a virtualized solution, like Azure Virtual Desktop or Windows 365. With a Cloud PC, users connect to the same environment from any device, so settings and apps are already there when they sign in. For scenarios where UE-V mattered most, like shared workstation environments, Windows 365 can be a practical alternative. And for Azure Virtual Desktop, FSLogix is a viable option. Important: Enterprise State Roaming does not roam per-application settings for traditional Win32 desktop apps the way UE-V did. So, Windows 365 may not be the right fit if you need settings roaming across multiple physical devices. AGPM AGPM brought version control, change tracking, and approval workflows to Group Policy management. Instead of an admin changing Group Policy Objects (GPOs) directly in production, AGPM enforced a check-out and check-in model with full audit history. This mattered most in environments with strict change management requirements. What to do instead: Move to cloud-managed endpoints and replace Group Policy settings with Intune configuration profiles and security baselines. The settings catalog in Intune includes thousands of settings, including many ADMX-backed policies. If you use custom ADMX files for third-party or internal applications, you can import them into Intune. For settings that aren’t available in the catalog, custom OMA-URI profiles can sometimes be used, depending on the CSP support for that setting. For change management, Intune offers Multi Admin Approval for certain policy changes, which can add a second-admin approval step. If you want deeper versioning and review workflows, we often see teams using Configuration as Code. Teams practicing Configuration as Code define Intune policies as code or structured data, such as in a JSON file stored outside the Intune admin center. This can be stored in version control like Azure DevOps or GitHub, and use Microsoft Graph – directly or via tooling – to deploy and reconcile the service. This enables deep versioning, peer review, and repeatable, auditable changes. And with Intune, you can use Graph API to get two years of audit events. Summary MDOP tool What it did Cloud-native replacement App-V (Server) Application virtualization and streaming MSIX packaging and Intune deployment (client still supported in Windows) MBAM BitLocker management and recovery Intune management of BitLocker and Microsoft Entra ID key escrow DaRT Bootable diagnostics and recovery Windows Recovery Environment (WinRE), bootable USB, and Intune remote actions UE-V User settings roaming Windows 365 Cloud PC, Windows Backup for Organizations, OneDrive Known Folder Move, app-native sync AGPM GPO version control and approval workflows Intune settings catalog, Multi Admin Approval, policy-as-code in source control Moving forward By moving to cloud endpoint management, most MDOP scenarios are covered through Microsoft Intune and Microsoft Entra ID supported capabilities with less infrastructure to maintain, making it easier for you to manage. If you haven’t started planning yet, we suggest starting with MBAM since Intune is the most direct replacement. Then, you can work through App-V, DaRT, UE-V, and AGPM based on what’s still in use. If you’re in the middle of an MDOP exit and need help leave a comment below or reach out to us on X @IntuneSuppTeam. Tell us which components you still have and how you manage endpoints today (Intune, Configuration Manager, hybrid, or other). We can help you sanity-check dependencies, choose an order of operations, and avoid common migration pitfalls. Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at aka.ms/JoinIntuneCommunity.Unpacking Endpoint Management is back - and we’ve got a lot to talk about
If you've been missing real, candid conversations about endpoint management, good news! Unpacking Endpoint Management is officially back. This series is all about what actually works. No fluff, just practical tips, proven strategies, and honest discussions to help you optimize and simplify the way you manage and secure endpoints today (and prepare for what's next). We're bringing together people from across Microsoft Intune, Security, and Customer Experience engineering and product teams, along with guest practitioners, to share what's worked, what hasn't, and what we've learned along the way. And yes…we're absolutely here for the tough questions. A quick update on the hosts Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, will continue to host the series. He's joined this season by Rachelle Blanchard as co‑host, bringing a strong community and discovery lens to the series. Rachelle focuses on surfacing real customer questions and guiding conversations toward practical outcomes, helping ensure each episode reflects how endpoint management works in the real world. Up next What should we cover? Drop ideas below in the comments. Sign in to the Tech Community and follow this post for the latest updates on upcoming episodes. Catch up on demand You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you. Policy: from hybrid to cloud-native Device security with Microsoft Intune Trends in endpoint management (live from Tech Takeoff 2026) Not sure where to start? Watch our most recent episode, App management at scale with Intune, now on demand! What's the format? This web series is streamed live on Tech Community, LinkedIn, YouTube, and X. In addition to open discussion, we answer your questions so sign in (or sign up for) the Tech Community and RSVP to submit questions early and throughout the live show. How do I join? There's no call or meeting to join. Simply head to aka.ms/JoinUEM. Show up at start time, watch live, and jump into the discussion with us. Help shape the series This series is for you - so tell us what you want to hear. Drop a comment below with: Topics you'd like us to cover Tough questions you want answered Speakers you'd love to hear from We can't wait to get started - and even more excited to hear from you along the way. Join the Community to get early insight into what's coming for Intune, connect with experts, and share real-world feedback that helps shape the product. 👉 aka.ms/JoinIntuneCommunityMigrating frontline mobile devices: A frontline-first approach to moving to Microsoft Intune
Frontline organizations consistently tell us that unified management is the goal but the challenge is getting there without disrupting day-to-day operations. Smartphones, Android handhelds, rugged scanners, and shared tablets now sit at the center of how retail stores run, how clinicians deliver care, how supply chains move, and how field workers’ complete work. These devices are mission critical, and any disruption is immediately felt on the ground. To strengthen security, reduce costs, and simplify operations, many IT architects and administrators are now evaluating or planning to move to Intune. This new series, “Migrating Frontline Mobile Devices - is designed to help. We’ve worked side by side with frontline customers, observing what works, where projects stall, and how small decisions early on can dramatically improve outcomes later. The articles in this series distil those lessons into practical guidance for teams who are considering, planning, or actively migrating devices. Frontline devices serve different needs and follow different operational rhythms than knowledge worker devices. Frontline migrations aren’t the same as standard knowledge-worker migrations and treating them as such often leads to operational problems or rollout delays. This article explains what the difference means in practice and how it shapes planning for successful frontline migrations. Why failures hurt more on the frontline A failed knowledge worker enrollment is an inconvenience. A failed frontline device enrollment or non-functioning device can affect revenue, disrupt essential services, and in some industries compromise safety. When a device is unavailable, critical work halts immediately: Pickers can’t complete scanning tasks Cashiers can’t take payments Health practitioners can’t document or prescribe care Drivers can’t dispatch Production lines stop Workers can’t perform required safety or compliance actions What we’ve learned: Frontline migrations must be coordinated with business and operational leaders; store managers, shift supervisors, clinical leads, and supply chain teams because they decide what is required and when devices can be taken offline. Why mobile frontline device migrations are different The operational impact of failure is higher on the frontline because frontline devices operate in very different environments to knowledge worker devices. Knowledge worker devices usually run in stable, well understood environments with known device catalogues, predictable lifecycles, assigned users, and steady connectivity. Frontline devices operate in conditions that introduce unique design and migration challenges. The environments they run in directly affect how and when a device can be enrolled or updated. Devices may run in low bandwidth or intermittent connectivity environments, making enrollment flows and policy delivery harder to complete reliably. Some operate in high-risk industrial or clinical settings where devices can only be taken offline during narrow operational windows. Others return to charging racks between shifts, meaning migrations must align with shift changes rather than user availability. Many run in kiosk or locked task modes tied to a single workflow, so even small configuration changes can disrupt critical tasks if not planned carefully. These environmental and operational realities show up across the entire device lifecycle from provisioning to updates to support. To make the differences clearer, here’s a concise comparison of frontline and knowledge worker devices: Category Frontline devices Knowledge worker devices Devices Smartphones, handhelds, rugged devices, scanners, wearables, tablets Laptops, desktops, smartphones OS and patch posture Often older versions; inconsistent patch levels due to operational constraints Typically, current OS or N-1; regular security patching cycles Ownership Shared, shift-based or individually assigned depending on role Individually assigned Network conditions Variable, often constrained Generally stable Provisioning Zero-touch essential User-led viable Updates Highly controlled Standard update cycles Apps Task-specific, time-sensitive updates Broad, less time critical updates Workflow impact Operationally critical Productivity-focused Typical usage scenarios Point-of-sale, healthcare, barcode scanning, delivery routing, inventory checks Email, productivity tools, collaboration, creative workflows Failure impact Immediate operational issues Localized user disruption Standard knowledge worker migrations are designed for predictable conditions such as consistent users, steady connectivity, current OS levels, and a governed device lifecycle. Frontline fleets rarely match this baseline, so their migrations require planning and design that reflects actual device state and use. A migration is a design moment, not just a technical step A migration offers an opportunity to reassess business needs, tighten governance, simplify and modernize app delivery, and confirm assumptions about how devices are used. It’s also a chance to raise your frontline security, aligning devices with Zero Trust principles. In successful frontline migrations: Teams build in time for design, evaluation, and piloting. Early alignment across stakeholders supports smoother execution and reduces the risk of disruptive rework later. Understand your estate before designing the migration Frontline migration projects always reveal something unexpected. Common patterns include: Mixed iOS/Android versions and multiple original equipment manufacturers (OEM) such as Samsung, Zebra, Honeywell, Apple and more. Devices running outdated OS versions or custom OEM images. Devices that haven’t checked in for months, often sitting unused in cabinets. App delivery paths reliant on sideloading or site specific packages with no update mechanism. Multiple active mobile device management (MDM) systems inherited through acquisitions or decentralized teams. Most migration issues that appear later in the project can be traced back to decisions made before anyone understood what existed in the field, how devices were being used, or what the business needed them to do in the future. What we’ve learned: Migration success improves dramatically when teams validate device inventory, usage patterns, and business requirements before choosing an enrollment method and designing configuration profiles. Real-world data turns assumptions into facts and avoids costly rework. Plan for identity – even if devices don’t use it today Many frontline devices run with shared logins or no user at all. Intune fully supports these scenarios, but identity gaps - shared credentials, app only authentication, and managed access patterns - often emerge over years of organic growth. These gaps can show up during migrations as both user experience issues and security risks. What we’ve learned: Even if you’re not ready to modernize frontline identity or introduce Microsoft 365 tools for workers, consider laying out the foundation. Mapping which users or roles should have identities, simplifying and securing access, and aligning devices to Microsoft Entra foundations will future proof your estate. What’s coming next in the series This series will explore the areas that consistently shape successful frontline mobile migrations the steps, patterns, and design decisions that matter most in real frontline environments. Over the coming weeks we’ll cover themes such as: Understanding your frontline estate - what exists today, how devices are used, and the realities that shape migration decisions Designing for frontline conditions - identity foundations, shared device patterns, kiosk considerations, and reliable enrolment flows Designing for frontline device scenarios - single user, shared, rugged, kiosk, and high-risk operational models Consolidating to a single Intune tenant - simplifying governance, policies, and operating models Getting the ecosystem right - apps, connectivity, certificates, and the infrastructure dependencies that influence reliability Executing the migration safely - pilots, phasing, cutover windows, and planning for 24/7 operations Life after migration - monitoring, support readiness, and ongoing operational ownership We’ll share practical guidance, common friction points, and patterns we’ve seen work across industries. Future articles will include perspectives from Microsoft Product Managers and community experts with hands-on experience managing large scale frontline device estates. Look out for the next article in the series - Understanding the reality of your estate. We’d love to include your perspective. If you have questions, scenarios, or experiences you want this series to address, share them in the comments below to help shape the upcoming articles, or reach out to us on X @IntuneSuppTeam. Our goal is simple: To help you migrate frontline mobile fleets to Intune without disrupting the business.
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!How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education
By: Aditya Middha | Product Manager 2 - Microsoft Connected Cache Starting on June 16 th , 2026, or soon after, Intune will enforce HTTPS content delivery for customers using Microsoft Connected Cache for Enterprise and Education. To continue using Microsoft Connected Cache to localize Intune Win32 app downloads and reduce the bandwidth impact on your network, you’ll need to configure HTTPS on Connected Cache nodes. Without this configuration, devices will still fetch the requested content, but they’ll fall back to the Content Delivery Network (CDN) and lose the performance and bandwidth savings that Microsoft Connected Cache provides. This guide assumes you have already deployed a standalone Microsoft Connected Cache node in your environment. If not, please see the Create and configure Microsoft Connected Cache nodes page. By the end of this walkthrough, you’ll be able to: Prepare the TLS certificate that your Connected Cache needs Enable HTTPS support on both Windows and Linux‑based Microsoft Connected Cache servers Validate that HTTPS is working end‑to‑end Diagnose the most common setup issues This guide mirrors the workflow described in Microsoft Connected Cache’s public documentation. For further explanation of what HTTPS support changes for Microsoft Connected Cache review HTTPS Support for Microsoft Connected Cache Overview, then proceed to Configure HTTPS on Windows or Configure HTTPS on Linux. Step-by-step: Enabling HTTPS support To keep this walkthrough easy to follow, the screenshots and command examples use a simple, reproducible environment that matches what most admins will see during their first HTTPS configuration. In this guide, the examples are based on: A single Connected Cache node deployment Windows 11, using a local user runtime account Public certificate authority (CA)-signed TLS certificate This baseline environment is only meant to make the screenshots and file paths predictable. Your own environment may look different, and that’s completely fine. Many customers run Microsoft Connected Cache on: Linux (Ubuntu or RHEL) Windows Server 2022 or Windows Server 2025 Networks with outbound restrictions Most of the workflow is identical across these variations. The folder structure, log locations, and command flow will look nearly the same on any Windows host. If you’re running Microsoft Connected Cache on Linux, the workflow is the same, but simpler—bash scripts are ran directly instead of being invoked through PowerShell. If your environment includes proxies, make sure all required endpoints are allowed. Before you start Before generating a certificate signing request (CSR) or importing a certificate, there are a few quick checks to make sure your Connected Cache server can enable HTTPS successfully. First, visit the “Cache Node Management” tab on Azure portal. Under the “Software Version” column, verify that your cache node is running on software version 2.0.0.2112 or higher. If not, you will need to reinstall Connected Cache. Next, confirm the hostname or IP address your client devices use to reach your Connected Cache node—this value will be configured when you generate the CSR. Also, ake sure port 443 is free on the host; Microsoft Connected Cache needs to bind to it. Finally, if your network performs TLS-inspection, ensure the required endpoints are allowed. Intercepted HTTPS traffic will cause devices to reject Microsoft Connected Cache’s TLS certificate, even if everything else is configured correctly. Once these checks are done, your node is ready for the HTTPS workflow: generate the CSR on your Connected Cache host machine, sign it with your CA, and import the resulting certificate. For more details, refer to the documentation: HTTPS on Windows Prerequisites. 1. Generate a CSR The first step in enabling HTTPS support is generating a CSR directly on your Microsoft Connected Cache node. This step cannot be skipped. Microsoft Connected Cache must create the CSR itself so it can generate and retain the private key that will later be paired with your signed certificate during TLS negotiation. When configuring the parameters for the generateCsr script, the most important values to get right are the Subject and SAN. These must match exactly how your managed client devices connect to your Connected Cache node. If the client devices use FQDN, include that FQDN; if they connect via IP, include that IP. A mismatch here won’t break CSR generation, but it’ll cause clients to bypass Microsoft Connected Cache later since they won’t trust the certificate during the TLS negotiation. For parameter configuration guidance on your specific environment, review these documented scenario-based parameter examples. After parameter configuration, you will need to locate the Installer scripts directory, the same as when you installed Microsoft Connected Cache originally. You can move directly to this path by running the following command in your terminal: Push-Location (deliveryoptimization-cli mcc-get-scripts-path) Once in the correct folder path, run the generateCsr command with your configured parameters. Running the command launches the CSR generation workflow inside the Microsoft Connected Cache-managed Windows Subsystem for Linux (WSL) distribution. The terminal output shows exactly what Connected Cache is doing: where it stores certificate files, where logs are written, which WSL distribution is being used, and the final location of the generated CSR. You’ll also see that Microsoft Connected Cache runs the CSR generation as a scheduled task inside WSL—this is expected and part of the normal flow. For example: This output confirms that Microsoft Connected Cache: Validated the CSR request Passed the Subject (Common Name) and SAN values to the internal script Generated the private key and CSR, stored both inside the container Wrote logs to the \Certificates\logs folder Created the CSR file in the Certificates folder When the process completes, you’ll see the timestamped CSR written to the Windows-side certificates folder (…\Certificates\certs). This is the file you’ll submit to your signing CA: Troubleshooting: Every time you run generateCsr, Microsoft Connected Cache writes a full log to a directory that ends with …\Certificates\logs. The terminal output shows you the exact path, and you can always return to this folder if you need to understand what happened during CSR generation. If you do need to troubleshoot, start by opening the most recent log file. The generateCsr log provides a detailed trace of each step. The following lines are checkpoints (in order) that you can look for in the more extensive log output: “Algorithm validation passed / CSR name validation passed” - Microsoft Connected Cache accepted your inputs and is ready to generate the CSR. “Subject Components: … / SAN Components: …” - Microsoft Connected Cache will embed these values into the CSR. If these don’t match your Connected Cache server hostname or IP address, regenerate the CSR. “Attempting to call http://localhost:5000/csr” - Microsoft Connected Cache internal controller is generating the keypair and CSR inside the WSL container. “Key verification succeeded” - Microsoft Connected Cache successfully generated and validated the private key. “CSR verification successful” - OpenSSL has validated the CSR structure. “Successfully copied logs to windowsCerts location” - The logs were written to the host machine directory. “CSR generation completed successfully” - Completed end-to-end successfully. One thing to be aware of: during a successful run, you may still see messages like: mkdir: cannot create directory '/keys': Permission denied chmod: cannot access '/keys': No such file or directory These are not errors. The script checks for required folders before creating them, and if they already exist, those checks generate harmless warnings. As long as the script finishes with a success message and you see a .csr file in the certs folder, the run is successful. 2. Sign the CSR This step occurs outside of the scope of Microsoft Connected Cache. Signing your CSR will rely on the PKI that your organization has chosen to use. This may include an internal ADCS, other enterprise internal PKI, or an externally hosted PKI (DigiCert, Let’s Encrypt, etc.). Of note, Cloud PKI will not work with Connected Cache because it requires the CSR be generated via SCEP before signing. Ensure that your client devices will be able to trust the CA signature. For many customers, we recommend signing using a public CA that Windows client devices automatically trust. Please reference documentation on signing the CSR for more details. The only requirement on the Connected Cache side is that the certificate is in unencrypted .crt format. Microsoft Connected Cache cannot import password-protected certificate formats yet - including .pfx bundles - even if they contain the correct certificate. For now, make sure your signing CA gives you, or allows you to export, a plain X.509 .crt file. After your CA signs the CSR, you’ll import the resulting certificate back to Microsoft Connected Cache. With the signed certificate in hand, place it in the same certs folder where your CSR was generated. Microsoft Connected Cache expects both files to live together so it can pair the returned certificate with the private key created earlier. A successful setup in the folder directory looks like this: If the certificate exists in the Certificates folder in .crt format, you’re ready to continue. Note: The CSR and .crt certificate do not have to have the same name. 3. Import the certificate back to Microsoft Connected Cache Before importing your certificate, remember that the CSR must have been generated on the same Microsoft Connected Cache node. You cannot skip directly to importing a certificate - Microsoft Connected Cache must have created the private key during CSR generation so it can pair the signed certificate with that key. After configuring the parameters referenced in the documentation to import the signed TLS certificate, run the importCert command from the same scripts directory used during CSR generation. When you start the import, Microsoft Connected Cache runs a full verification workflow inside its managed WSL distribution. The terminal output for this step is intentionally simple—it shows only that the certificate file passed basic validation, that the internal import script was invoked, and that the import is running as a scheduled task within the WSL distribution. You’ll also see that logging is active and that Microsoft Connected Cache has begun monitoring the process: Although the terminal output is brief, the full workflow is visible in the import logs. A successful import means Microsoft Connected Cache: Found your .crt file in the expected folder Ran cryptographic verification confirming the certificate, CSR, and private key all match Copied the certificate into the container and updated Microsoft Connected Cache internal configuration Restarted the container with the new certificate Enabled HTTPS for Microsoft Connected Cache’s Intune content endpoints Once these steps are complete, Microsoft Connected Cache is fully configured to serve HTTPS content. You usually won’t see new files added to the Windows certs folder after import as the changes occur inside the Connected Cache container. The final validation that import is successful is if the script exits successfully and the logs show that Microsoft Connected Cache restarted with the new certificate in place. Troubleshooting Troubleshooting certificate import is similar to troubleshooting CSR generation: every run produces a detailed log in the ...\Certificates\logs folder. If import fails, these logs will show exactly which step did not complete. At this stage, SAN or hostname mismatches do not show up; those only appear later during client-side validation. The importCert script only ensures that your certificate, CSR, and private key match (stored inside container, not visible from Certificates folder) and that Microsoft Connected Cache can load them. To help interpret the log, below are the checkpoints you can reference (in order): “Certificate file validation passed” - Microsoft Connected Cache found the .crt file in the certs folder and its .crt format is valid. “Using CertName: … / CSR being used: …” - Microsoft Connected Cache matched the certificate to the CSR that generated the private key. “SUCCESS: The CSR, certificate and private key cryptographic materials all match” - Microsoft Connected Cache verified the keypair, CSR, and certificate are a correct trio. “Nginx restarted successfully with new certificates” - Microsoft Connected Cache is now configured to serve HTTPS on port 443 inside the container. “Certificate import completed successfully” - The end-to-end import succeeded with no errors. Once the importCert script succeeds, your node is ready for validation. Validating HTTPS support end-to-end Once your certificate is imported, the final step is validating that Microsoft Connected Cache is now serving content over HTTPS. Detailed test commands are all documented in the Validate HTTPS on Windows guide. Complete the tests first on the Microsoft Connected Cache server, then on a client device. This order matters - server-side validation confirms Microsoft Connected Cache is listening on port 443 with its new TLS certificate; client-side validation confirms that client devices can trust and use that certificate. On your Microsoft Connected Cache server Start validation on the Microsoft Connected Cache host server. The server side tests include HTTPS and HTTP health endpoint checks that confirm: Microsoft Connected Cache is successfully bound to port 443 The TLS certificate loaded correctly The TLS certificate, private key, and CSR all correspond Microsoft Connected Cache can return its health endpoint over HTTPS If any of the server-side validation steps fail, check the generateCsr and importCert logs in the …\Certificates\logs folder. The validation guide includes troubleshooting tests that help distinguish whether the issue is certificate-related, connectivity-related, or due to another process on the host. Only move on to client-side validation once the Microsoft Connected Cache server passes its own tests. On your client device After confirming the server is configured correctly, the next stage is validating HTTPS content delivery from a client device that is pointed to use Microsoft Connected Cache. The client-side tests contain both browser-based and command line tests that help verify: The client trusts the issuing CA DNS resolves the Microsoft Connected Cache hostname correctly The device can complete a full TLS handshake with Microsoft Connected Cache The device is retrieving HTTPS content from Microsoft Connected Cache rather than falling back to CDN Once both server-side and client side-validation steps succeed, you can be confident that your Microsoft Connected Cache node is fully configured and ready to serve Intune content securely over HTTPS. Known issues with HTTPS Support Configuration Most customers will complete the HTTPS workflow without any problems, but there are a few known issues we want to call out proactively. These issues have been fully addressed with the release of the new Windows-hosted deployment application (v1.0.26.0) for Windows host machines, the new Linux-hosted deployment package (v1.10) for Linux host machines, and the latest GA container release (v2.0.0.2124_e) for all cache nodes. ImportCert issues on Windows Server 2022/2025 using a gMSA account, and on Windows 11 using a local user runtime account If your Microsoft Connected Cache runtime account is a Group Managed Service Account (gMSA) on a Windows Server 2022 or Windows Server 2025 host machine, you may see failures when running importCert. In the importCert logs, this can show up as unsuccessful permissions access or indefinite logging. The same importCert issues can also appear on Windows 11 if you are using a local user as the runtime account. Status: RESOLVED Please download Windows-hosted deployment application v1.0.26.0 by running the following command in an elevated PowerShell window: Add-AppxPackage https://aka.ms/do-mcc-ent-windows-x64 Then you may proceed to re-deploy your Connected Cache node, which will implement the necessary changes. You can further verify that you are deploying with the correct application version. When run in the terminal, the copied “Cache Node deployment command” given in the Azure portal will run deploymcconwsl.ps1 out of the folder path that looks like: C:\ProgramFiles\WindowsApps\Microsoft.DeliveryOptimization_1.0.26.0_neutral__8wekyb3d8bbwe\deliveryoptimization-cli ImportCert hangs on software version 2119_e (buffer bug) During the week of January 19 th , 2026, we deployed container version 2119_e to all customer cache nodes. We discovered a bug where the container’s internal buffer is not cleared during importCert, causing the import to run indefinitely. If you see this behavior and your Azure portal shows that your cache node is on version 2119_e, this is likely the cause. Status: RESOLVED: On March 3 rd , 2026, we pushed container version 2124_e to all cache nodes on the “Fast Ring” update schedule. If your cache node is on software version 2119_e today, you can change the update schedule configuration to the “Fast Ring”. Head to the 3 rd tab (“Updates”) of the Cache Node Configuration on the Azure portal and configure the update ring. Container version 2124_e will be pushed to all “Slow Ring” nodes in early April 2026. If your cache node is still not pulling down container version 2124_e after being configured on the Fast Ring, please reach out to us. The fixes for these issues have all been validated. Once ready for public release, the latest software version will be pushed to all cache nodes and the updated Windows installer will be available to download in Azure portal. Stay tuned to the Microsoft Connected Cache Release Notes for up-to-date information. Enabling HTTPS support on Linux hosts This guide walked through the setup of HTTPS using a Windows-based Microsoft Connected Cache host, since that’s what most customers deploy today. If you're running Microsoft Connected Cache on Linux, the overall steps are the same - generate a CSR on the node, sign it with your CA, and import the resulting .crt file - but a few details differ. For a Linux-hosted Microsoft Connected Cache nodes, shell scripts handle the entire process, specifically generateCsr.sh and importCert.sh. The Enable HTTPS Support on Linux guide documents these steps in detail, including the exact script parameters, file locations, and how to interpret the Linux-specific logs. The biggest differences on Linux are: You run the CSR and import scripts directly in bash (no WSL component). File paths and log locations follow the Linux directory structure (/var/mcc/...). Check port conflicts, firewall configuration, and TLS inspection using Linux tools (ss, iptables, proxy settings). Validation steps use Linux equivalents of the server side tests documented in the Windows validation guide. Maintaining your HTTPS configuration Once your Microsoft Connected Cache node is serving content over HTTPS, the next thing to plan for is ongoing certificate maintenance. TLS certificates aren’t a onetime import - certificates expire, CA chains change, and your operational process needs to keep up. Microsoft Connected Cache will soon surface certificate details both through a command line script and directly in the Azure portal, but those capabilities are not available yet. Until then, verification and rotation rely on simple checks you perform on the Microsoft Connected Cache host. Monitoring The easiest way to monitor your deployment today is to periodically check the Key Metrics chart in the Overview blade of your Microsoft Connected Cache resource in Azure. If Intune content is flowing through Microsoft Connected Cache, that’s a strong proxy signal that HTTPS is healthy. For the certificate itself, many admins perform a lightweight weekly or monthly review: ensuring the TLS certificate is still valid, not approaching expiration, and still matches the configuration you imported. Re-running the validation tests from our public documentation every so often is also a good way to catch any issues early. The updated Windows installer, as mentioned in Known Issues, will also have a PowerShell script that displays the status and expiration date of existing TLS certificates. Renewal When planning for renewal, we recommend starting at least 60 days before the certificate expires. Renewal is typically straightforward: either reuse the existing CSR (most common) or generate a new one, then have your CA resign it, convert it into .crt format, and test the renewed certificate on a test node if you have one. If your workflow doesn’t include a test Connected Cache node, you can still safely import the renewed certificate on your production node - if import fails, Microsoft Connected Cache simply keeps using the existing certificate until a valid one is applied, so you won’t break your environment. If your certificate management system has automation capabilities, you can script Microsoft Connected Cache’s certificate renewal workflow as well - for example, by using Secure Shell (SSH) to remotely to run the generateCSR or importCert scripts on the host machine. For larger or distributed environments, testing the signing and import processes on a non-production node first can help confirm SAN correctness, trust behavior, and chain completeness before touching production. We are actively working to streamline certificate monitoring and renewal inside Microsoft Connected Cache. Summary HTTPS support for Microsoft Connected Cache will soon become a requirement for delivering Intune Win32 apps, and every Microsoft Connected Cache node must be configured for HTTPS by June 16, 2026. After the deadline, Intune Win32 apps will only be delivered via HTTPS. However, all other content – Windows updates, Office apps, etc – will continue to be served via HTTP after the June 16 th enforcement date. This guide walked through the essentials: generating a CSR on your Microsoft Connected Cache node, submitting it to your CA, importing the signed certificate, and validating HTTPS from both the server and client devices. Along the way, you saw how to interpret the logs, verify Connected Cache is using your certificate correctly, and ensure that Teams and/or Intune content is flowing over HTTPS instead of falling back to CDN. As you move forward, keep your workflow consistent - regenerate or reuse CSRs the same way each cycle, validate regularly, and renew certificates well before expiration. Even though improvements are coming soon, completing this setup now ensures your environment is ready long before Intune HTTPS enforcement begins. With your certificate in place, HTTPS validated, and a simple renewal process in hand, your Microsoft Connected Cache deployment is prepared for the June 16 th , 2026 deadline and ready to deliver Intune content securely. FAQs Do I really need HTTPS Support, and by when? Yes. All Microsoft Connected Cache nodes serving Intune Win32 apps must deliver over HTTPS by June 16, 2026. If HTTPS isn’t configured, devices will fall back to CDN when requesting Intune win32 apps —content delivery still works, but you’ll lose caching benefits. Why do I have to generate the CSR on the Connected Cache node? Since Microsoft Connected Cache must generate and retain the private key itself. Certificates signed from any other machine, keypair, or CSR cannot be imported. The CSR you generate on the node produces the only key that Microsoft Connected Cache will accept. Can I reuse an existing certificate? Only if it was originally issued from the CSR generated on the same Microsoft Connected Cache node. If the certificate was created elsewhere (different machine, tooling, or CSR), Microsoft Connected Cache won’t accept it. Can I reuse my CSR when renewing the certificate? Yes. Many customers reuse the same CSR each cycle as long as the CA resigns it. Reusing the old certificate output is not supported. Can I “bring my own certificate”? Not yet. Microsoft Connected Cache only supports certificates created from its own CSR. Support for bringing an external certificate is coming soon; stay up to date by viewing the latest Microsoft Connected Cache Release Notes Can I use a wildcard certificate? Microsoft Connected Cache does not officially support them and they’re not recommended. Wildcards often involve shared private keys across systems, which creates operational and security risks. What certificate formats does Microsoft Connected Cache support? Microsoft Connected Cache only supports unencrypted .crt files today. Password protected .pfx or .p12 formats cannot be imported. What happens if I redeploy Microsoft Connected Cache or the hostname changes? If the hostname or connection path changes, you must request a new certificate that matches the new SAN parameters. If the hostname stays the same and the certificate came from the Connected Cache-generated CSR, you can continue using it. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam! Post Updates: 04/08/26: Updated the “Known issues with HTTPS Support Configuration” section to reflect that previously identified issues have been fully resolved in the latest deployment application and container releases, along with updated guidance for affected cache nodes.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!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.
