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 Microsoft Connected Cache-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.Why Windows Should Adopt ReFS as a Bootable Filesystem
ReFS could become a bootable filesystem — it only needs a few missing layers. No need to copy NTFS, just implement what the Windows boot process requires. Key missing pieces: System‑level journaling (not only metadata) Full hardlink + extended attribute support EFS, ACLs, USN Journal for security + Windows Update Boot‑critical atomicity for safe system file updates Bootloader‑compatible APIs (BCD, BitLocker pre‑boot, WinRE, Secure Boot) Goals: Use NTFS as a reference map, add the missing capabilities to ReFS, and optimize them using ReFS features (copy‑on‑write, integrity streams, block cloning). Result: A modern, resilient filesystem that can finally boot Windows - without losing its benefits.When the audio pipeline decides to act up 😂🤌
Ever since build 2820.x.x.x, I’ve been keeping an eye on one specific process — Audio Graph Isolation. And this little troublemaker 😂 sometimes decides it wants to “spice up your day.” Not by taking a few MB of RAM… Oh no, no — it goes straight for several gigabytes 😂 So you’re just sitting there, wondering why your system suddenly starts lagging, why the audio sounds like a corrupted Star Trek transmission after a virus attack 🙈😂 You open Task Manager, sort by RAM usage… And there it is, grinning at you, Audio Graph Isolation, quietly turning your system into its personal victim 🙈 How to deal with it until Microsoft finally fixes this regression? Honestly — the only thing that works is: 👉 force‑killing Audio Graph Isolation in Task Manager And boom, your system instantly gets its speed back. Unfortunately, because of this regression, you have to keep an eye on this process regularly, since the RAM leak can happen anytime during idle — whether you’re watching a movie, listening to music, or the system is just running with no user input.Migrating 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.Troubleshooting Windows Feature updates in Microsoft Intune
By: Luke Ramsdale – Sr Security Customer Escalation Engineer | Microsoft Intune Effectively managing feature updates for Windows devices is essential for maintaining system performance and security. This article focuses on the troubleshooting steps necessary to address common issues with feature update policies in Intune. The feature update policy in Intune allows you to choose the Windows feature update version that devices should stay on or update to. The process of managing feature updates on Windows 10 and 11 devices is done through a combination of update ring and feature update policies. Update ring policies utilize the Policy CSP - Update to configure the Windows devices with the desired settings. Note: The unified suite of Windows update tools is officially known as Windows Autopatch. For further details, please visit: Why Windows Autopatch is the smart update solution - Windows IT Pro Blog to learn more. Prerequisites The first step in troubleshooting feature updates is to ensure the prerequisites are in place. This is a crucial step to take to ensure a smooth feature update policy implementation; missing a prerequisite accounts for many feature update failures or undesirable behavior. Licenses The core functionality requires an Intune license, but it’s important to note that the cloud-based capabilities such as gradual rollout and optional feature updates require a license that includes access to the Windows Update for Business deployment service, for example: Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) Windows 10/11 Education A3 or A5 (included in Microsoft 365 A3 or A5) Windows Virtual Desktop Access E3 or E5 Microsoft 365 Business Premium For more information about gradual rollouts please refer to the following document: Configure schedules to gradually roll out Windows Updates in Intune Telemetry Ensure that a device restriction policy is deployed to all devices in scope for feature updates with reporting and telemetry configured. At minimum the Share usage data setting needs to be configured to “Required”. For more details on this setting, review: Device restriction settings for Windows 10/11 in Microsoft Intune Enable Windows diagnostic data collection Configuring diagnostic data collection is essential to ensure feature update reporting is accurate. This is a tenant wide setting and is configured in the Intune admin center under Tenant administration > Connectors and tokens > Windows data. For more information, review: Use Windows Update for Business reports for Windows Updates in Microsoft Intune Microsoft Account sign-in Assistant service Ensure the Microsoft Account sign-in Assistant service isn’t disabled, by default this is set to Manual. Connected User Experiences and Telemetry service Ensure the Connected User Experiences and Telemetry service is not disabled , by default this is set to Automatic. Supported version of Windows 10/11 The Windows operating system being updated must be either Professional, Enterprise or Education editions.editions. Network endpoints Ensure the devices can access the Intune and Windows update endpoints: Network endpoints for Microsoft Intune Connection endpoints for Windows 10, version 1809 - Windows Privacy Deploying feature update policies with update rings If you’re deploying update rings in parallel to feature update policies, then it is important to consider the implications of configuring certain settings in the update ring policy: Feature update deferral period (days) The recommendation is to configure this to ‘0’ but if you choose to change this it’ll delay the deployment of feature updates. Upgrade Windows 10 devices to Latest Windows 11 release If this option is configured to yes, then eligible Windows 10 devices will update to the latest Windows 11 feature update regardless of what is configured in any feature update policy. Note: It’s important to understand this update ring policy setting will overrule any Windows 10 feature update policy deployed. Paused feature updates If feature updates are paused in an update ring policy, then targeted devices won’t receive feature updates; ensure that feature updates are running for any update ring policies targeting users or devices that also have feature updates policies deployed. Conflicting feature update policies There are a couple of scenarios that are important to keep in mind when deploying feature update policies: Deploying multiple feature update policies to devices could target multiple versions of feature updates to a device at the same time. The latest feature update will always be offered to the device under these circumstances. An eligible Windows 10 device targeted with both Windows 10 and 11 feature update policies will update to Windows 11. Our recommendation is to target a single feature update policy per operating system version, in other words, one for Windows 10 and one for Windows 11 devices. We also recommended to deploy a new feature update policy per release, one policy for Windows 11 23H2 and a separate policy for Windows 11 24H2. In this scenario administrators remove the devices from the group targeted with Windows 11 23H2 and move them to a group targeted with the Windows 11 24H2 policy. Microsoft Entra hybrid joined devices When feature updates are failing to deploy to machines that are Microsoft Entra hybrid joined, it’s important to investigate whether there are any pre-existing group policy objects (GPOs) deployed via Active Directory Services. These can conflict with the settings configured in Intune in general and the feature updates specifically. There are a couple of ways to attempt to check and troubleshoot potential GPO conflicts: On a device you suspect has conflicts run the following at the command line as a local administrator: gpresult /v >c:\temp\gpo.txt Open the text file and examine the contents for group policies which are configuring Windows update settings or redirecting update scanning to WSUS servers. Consider configuring a scan source GPO to specify which sources should be used for each individual class of Windows update. For example, you can configure Feature Updates to use Windows Server Update Services (WSUS) and Quality Updates to use Windows Update as shown in the screenshot below. Configuring a scan source group policy can help ease the transition from an on premises managed environment and Intune. For more information about scan source group policy objects refer to Use Windows Update for Business and Windows Server Update Services (WSUS) together. Note: Using the GPO wins over the mobile device management (MDM) setting doesn’t work with Windows update policies. Safeguard holds A safeguard hold is a Windows function that prevents your device from receiving new feature updates. The Windows update service enforces a safeguard hold on a device when it determines that a feature update may have a negative impact on your device. Safeguard holds are applied when quality and compatibility data identify issues that might cause a Windows client feature update to fail or roll back. These holds can also be applied when a customer, partner, or internal validation finds an issue that would cause severe effects, such as data loss or loss of key functionality. The lifespan of a safeguard hold varies depending on the time required to investigate and fix the issue. Once a fix is found and verified, the safeguard hold is lifted, and Windows Update resumes offering new operating system versions to the affected devices It’s important to check the feature update failures report, which is mentioned in the next section. For more information on safeguard holds and Windows release health refer to: Safeguard holds for Windows Windows release health Troubleshooting Feature updates from the Intune admin center It’s important to enable the prerequisites for update reporting, there are two prerequisites which you must meet: Enable Windows diagnostic data collection from devices by configuring telemetry to be at least required. Configure the tenant level Windows data collection. Windows feature update report The Windows feature update report is a good starting point to get an overall status of the feature update deployment policy status. (Reports > Windows updates > Reports > Windows feature update report) This report runs on individual feature update policies and provides a summary and details of the feature update state. This report doesn’t automatically update and you need to generate it manually. The important data on this report is contained in the update state and update substate columns. If the update state is set to “Offering” and the update substate is set to “Offer ready”, then Windows update made the feature update available to the device. If the update state is “Pending” and update substate is “Scheduled”, then the update will be available for installation later. If it’s “Pending validation”, then there’s a problem validating the device by Windows update. Feature update failures report The first point of contact for troubleshooting feature updates should be the feature update failures report which is in the Intune admin center > Devices > Monitor > Feature update policies with alerts. This report shows you the reasons why individual devices have failed to install a feature update. Note: You need to configure the data collection pre-requisite discussed above before this report shows any data. This lists all the current feature update policies with an overview of the number of devices with errors. Clicking on the feature update policy will drill into the details and list the failures. This report should be the first place that an administrator checks to understand whether the feature update install has been attempted on a device and subsequently failed. For a full list of possible errors populated in this report and recommendations for remediation refer to:Use Windows Update for Business reports for Windows Updates in Microsoft Intune - Microsoft Intune. Checking the Windows update service using PowerShell It’s possible to interact with the Windows Autopatch service via graph explorer or via PowerShell cmdlets using Windows update APIs. The cmdlets are documented in Microsoft.Graph.Beta.WindowsUpdates Module and theGraph APIs are documented in Windows updates API overview. There is also a training course on how to manage updates using the SDK Manage Windows updates for cloud-connected devices by using the Microsoft Graph PowerShell SDK - Training. Administrators don’t need to use the SDK when deploying updates via Intune, but it can be used to investigate and troubleshoot deployment issues.deployment issues. The following is an example of how to request the properties of a Microsoft Entra device using the device identifier. You can view this record using a PowerShell cmdlet called: 'Get-MgBetaWindowsUpdatesUpdatableAsset' with the Microsoft Entra device id as a parameter, here is an example PowerShell script which gets the update information: Import-Module Microsoft.Graph.Beta.WindowsUpdates Connect-MgGraph $updateInfo = Get-MgBetaWindowsUpdatesUpdatableAsset -UpdatableAssetId '<insert Entra device id>' Write-Host "Update Information:`n$($updateInfo | ConvertTo-Json -Depth 10)" This is an example of the output where the feature update enrollment state is still “enrolling.” A Microsoft Entra ID device will need to be successfully enrolled into the Windows Autopatch service before it can start receiving the feature update policies. In this case the enrolling state could be caused if the feature update is paused in an update ring policy. Update Information: { "Id": "13315f1b-96b4-4a88-b453-342d984a6e05", "AdditionalProperties": { "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/updatableAssets/$entity", "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice", "errors": [], "enrollment": { "feature": { "enrollmentState": "enrolling", "lastModifiedDateTime": "2025-01-23T14:39:07.8854424Z" }, "quality": { "enrollmentState": "notEnrolled" }, "driver": { "enrollmentState": "enrolledWithPolicy", "lastModifiedDateTime": "2024-02-08T15:14:30.5073437Z" } } } } The ideal state is as follows; this shows the Microsoft Entra ID device is enrolled in the Windows Update for business service for feature updates. Note that the Entra ID enrollment into Windows Autopatch is distinct from enrolling a Windows device into Intune: Update Information: { "Id": "0dde8413-951b-4d95-b628-705881f4901b", "AdditionalProperties": { "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/updatableAssets/$entity", "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice", "errors": [ ], "enrollment": { "feature": { "enrollmentState": "enrolled", "lastModifiedDateTime": "2025-02-06T16:02:59.0065266Z" }, "quality": { "enrollmentState": "notEnrolled" }, "driver": { "enrollmentState": "enrolled", "lastModifiedDateTime": "2025-02-06T16:02:57.5209828Z" } } } } The enrollment state should equal enrolled if the device has a policy targeting one of the updates. Graph explorer The same principle can be used with graph explorer by navigating to https://developer.microsoft.com/graph/graph-explorer and querying the following: https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/<insert Microsoft Entra Device id> This returns the data associated with the asset in JSON format. In this example we see that the device is still enrolling for feature updates rather than enrolled. Note: When you create a feature update policy in Intune it will interact directly with Windows Update for Business using the documented Windows Autopatch APIs to configure the policies, however, these policies are not visible either though Graph or PowerShell. Troubleshooting Feature updates from the client side Device diagnostics The first step when troubleshooting feature updates from the client side is to get hold of the device side logs. Intune provides a way to gather logs from the device using the Intune admin center within device diagnostics. To ensure that device diagnostics is available in your tenant, navigate to Tenant admin > Device diagnostics and ensure that the options are enabled. Once enabled it’s possible to collect diagnostics from the device by navigating to the device overview page, Collect diagnostics. After a short period, the diagnostics will be available to download from the device diagnostics view on the device: For more information about device diagnostics please refer to Collect diagnostics from an Intune managed device - Microsoft Intune. Device diagnostic logs The device diagnostics feature in Intune gathers all the relevant MDM event logs along with other relevant data such as registry keys, log files, and commands. When troubleshooting feature updates, the key logs to investigate from the device diagnostics are the following: %windir%\logs\CBS\cbs.log The CBS, or component-based servicing, log gives detailed information on the installation of updates which relate to the component-based servicing system. This includes some aspects of the feature update install. If a feature update fails due to a missing or corrupted system component, the CBS.log may contain relevant errors. %windir%\logs\Panther\unattendgc\setupact.log Setupact.log contains detailed step by step records of the Windows setup process. This log contains the actions performed during a feature update installation and is useful for scenarios where the update is delivered to the device but has not installed correctly. SetupDiag is also available to download to help determine why upgrades fails for more information refer to: SetupDiag. %windir%\logs\WindowsUpdate\*.etl The Windows update log is useful for investigating issues with scanning, downloading, and installing updates. The etl files can be converted to a more friendly text log file using the PowerShell cmdlet Get-WindowsUpdateLog. For more information about troubleshooting via the Windows update logs refer to Windows Update log files. %temp%\MDMDiagnostics\mdmlogs-<Date/Time>.cab The mdmlogs cab is a diagnostic log package generated by the device diagnostics to capture all relevant MDM logs and compresses them into a cab file. The key logs and files for investigating feature updates are the MDM diagnostics report HTML file (which is discussed in detail below) and the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx. Checking the prerequisites via MDM diagnostics report Once the diagnostics are downloaded, the first step is to check that all the prerequisites for feature updates are satisfied. To do this unzip the DiagLogs zip file and search for a folder called: temp_MDMDiagnostics_mdmlogs, for example temp_MDMDiagnostics_mdmlogs-2025-01-28-16-51-20_cab, extract the files from the CAB file and search for the file MDMDiagHtmlReport.html. The MDM diagnostic information has a list of all the policies that are applied to the device from Intune, and in the case of feature updates, the following settings need to be deployed and configured on the device. Note that there are two columns for the values, the default Windows value and the current value which is configured by Intune. Here’s an example of how the policies look in the MDMDiagHtmlReport.html: Search this file for the CSP area, such as Update or DeviceHealthMonitoring as in the example below: These are the prerequisites areas, policies and settings that you should check: Area Policy Default Current Update DeferFeatureUpdatesPeriodInDays 0 0 Update ConfigureDeadlineForFeatureUpdates 7 10 Update PauseFeatureUpdates 0 0 DeviceHealthMonitoring AllowDeviceHealthMonitoring 0 1 DeviceHealthMonitoring ConfigDeviceHealthMonitoringScope BootPerformance, WindowsUpdates System AllowTelemetry 1 1 In this example the policy values equate to: Setting Value Description DeferFeatureUpdatesPeriodInDays 0 The number of days a feature update can be deferred, 0 days is recommended but this can be configured for up to 365 days. ConfigureDeadlineForFeatureUpdates 10 Number of days before the feature update is installed automatically, in this case 10 days. PauseFeatureUpdates 0 0 means that feature updates are not paused. 1 means that they are paused. AllowDeviceHealthMonitoring 1 1 means DeviceHealthMonitoring connection is enabled. ConfigDeviceHealthMonitoringScope BootPerformance and WindowsUpdates data are sent to Microsoft. AllowTelemetry 3 3 means that all telemetry data is being sent to help fix problems, 1 is basic. Basic is the minimum telemetry setting required for feature updates. If you want to understand these values further, refer to the CSP documentation: Policy CSP - Update Policy CSP - System Policy CSP - DeviceHealthMonitoring Verifying Intune policy is applied When a policy fails to apply on a device, the error returned from the CSP is reflected in the Intune admin center reports. For all CSPs, including the update, device health monitoring and system policy CSP, any errors that occur when applying the CSP settings appear in the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin event log. To access this event log, you can either request the device diagnostics from a device and extract it from the zip file or access the event log directly on the device. To access this on a device, open the event viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Here is an example of an error in the DeviceManagement-Enterprise-Diagnostics-Provider admin event log from the WiFi CSP: The error is as follows: MDM ConfigurationManager: Command failure status. Configuration Source ID: (773B7171-7CB3-41CE-9480-64439F370613), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (WiFi), Command Type: (Add: from Replace or Add), CSP URI: (./Vendor/MSFT/WiFi/Profile/Danger Zone/WlanXml), Result: (The service has not been started.). In the above error, a Wifi profile has failed to be applied via the Add/Replace command. The ‘Result’ is the important part. This can take the form of a hex code, such as 0x86000009, or can be more meaningful as in the example above: “The service has not been started”. In this case the device is a virtual machine which has no WiFi adapter, so the service is not running. Update, System, and Device health monitoring CSP errors are not common, but it is important to understand how to investigate potential CSP errors. Check the registry The best method for checking the device side settings is to review the MDM diagnostics report that can be collected using device diagnostics as described above. The diagnostics report reflects the settings configured in the registry. It’s also possible to check the prerequisites and the update settings in the registry. This helps verify the settings are configured as per the policies in Intune. Safeguard holds Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TargetVersionUpgradeExperienceIndicators This key specifically is related to Windows feature updates and tracks information about how a system is expected to behave during an upgrade to a newer Windows version. The GE24H2 subkey in the above screenshot refers to Windows 11 24H2 and the values in this subkey help assess whether the device is ready for the update. Telemetry settings Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection This location is where Windows stores telemetry specific settings, the value should either be 1 (Basic) or 3 (Full). In this screenshot, the AllowTelemetry_PolicyManager value shows 3 which means “Full”. Device health monitoring Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceHealthMonitoring The device health monitoring settings highlighted in red below are required for various update reports in the Intune admin center. Make sure the WindowsUpdates setting is present for ConfigDeviceHealthMonitoringScope and AllowDeviceHealthMonitoring is set to 1 (enabled). Reviewing these registry entries is useful for verifying the settings have applied successfully, editing the values directly in the registry has no impact on functionality. Note: If the administrator has configured the tenant wide Windows data settings in Tenant administration > Connectors and token > Windows data, the Windows update scope entry will not be present. This is only present when deploying the health monitoring settings via a device configuration profile: Use Windows Health Monitoring profile on Windows devices in Microsoft Intune. Update settings Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update This key contains all the update CSP settings which are configured by the update policies. This includes feature, quality, driver, and update ring settings. There are potentially many settings in this key and they vary depending on the settings configured in the policies configured in Intune. To understand what these settings mean refer to: Update Policy CSP. Microsoft Compatibility Appraiser The Microsoft Compatibility Appraiser is a built-in Windows telemetry component that evaluates the compatibility of installed software and hardware in Windows. It runs as part of the Windows Compatibility Telemetry process. Windows uses Microsoft Compatibility Appraiser for reporting and telemetry and is a key component for the Intune feature update reports. You configure Intune to leverage this tool using the Windows data tenant wide setting as described previously in the prerequisites section. In some circumstances where devices show up as unknown in the Intune update reports, it’s useful to attempt to trigger Microsoft Compatibility Appraiser manually to force the device to report back telemetry data. To do this you can either manually run a scheduled task on the device or execute it using PowerShell or the command line. Manually running the scheduled task Navigate to the start menu > type “task scheduler” and open the task scheduler > navigate to Microsoft > Windows > Application Experience > Microsoft Compatibility Appraiser Exp> right click > Run. Running the appraiser at the command line The task above runs a command which you can also execute manually or script it to run on many machines: Compattelrunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun Both methods will trigger Microsoft Compatibility Appraiser to report the required telemetry data and update the Windows update reports. Summary This blog covered many aspects of troubleshooting feature updates, here are the key points: Make sure the prerequisites are in place. It’s important to emphasize that implementing the prerequisites for feature updates is important to ensuring a smooth feature update deployment. Take time to ensure that these are configured correctly as this is especially important for reporting. In more complex environments with Microsoft Entra hybrid joined devices, it’s important to ensure that there are no conflicting settings deployed from multiple sources, for example, having GPO settings, Microsoft Configuration Manager update policies, and conflicting Intune update policies deployed. Try to ensure that update policies are deployed from only one source. If multiple sources must be used, consider using the scan source group policy. It’s possible to interact with Windows Autopatch using PowerShell cmdlets and Graph APIs. This provides insight into a tenant's configuration, but it’s not a requirement as Intune will configure this for you using feature update and update ring policies. Note: It’s also important to understand that the Intune configured Windows Update client policies will not be visible via the PowerShell cmdlets or Graph APIs. Take note of whether safeguard holds are applied to specific device models, checking the feature update failures report will assist with identifying these. The device side event logs, Windows update logs, MDM diagnostics report, and registry values are all important sources for trying to narrow down why a device isn’t installing a feature update, or if a feature update was unexpectedly not installed or installed. Collecting diagnostics from affected devices will gather the relevant logs and data required for troubleshooting, this is important to gather if a support request is opened. Hopefully these tips help you with troubleshooting feature updates! If you have any questions, leave a comment on this post or reach out on X @IntuneSuppTeam. Post update: 04/10/25: Added link to: Why Windows Autopatch is the smart update solution - Windows IT Pro Blog.
