Intune Customer Success articles

MDOP is out of support: What to do next with Microsoft Intune

Intune_Support_Team — Mon, 08 Jun 2026 16:58:58 GMT

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.

New Platform SSO with registration during Automated Device Enrollment on macOS

Intune_Support_Team — Tue, 09 Jun 2026 01:41:15 GMT

By Iris Yuning Ye, Product Manager – Microsoft Intune & Justin Ploegert, Principal Product Manager – Microsoft Entra

A new setting ‘Enable Registration During Setup’ for Platform single sign-on (PSSO) during Automated Device Enrollment (ADE) is now generally available for macOS devices in Microsoft Intune. With this new setting and a compatible version of the Intune Company Portal (5.2604.0 and newer), this feature enables users sign in with their Microsoft Entra account during Setup Assistant, complete device registration before reaching the desktop, and get immediate access to work resources and ready to be productive sooner.

Why this matters

Previously, Platform SSO registration occurred only after users completed Setup Assistant and reached the desktop. They then had to notice and act on a separate notification to finish Platform SSO registration. When Platform SSO registration isn't completed, it can cause issues with app authentication or lead to noncompliance, delaying users from getting started on the device:

Missed notifications - Users dismiss or ignore the post-enrollment PSSO prompt, leaving devices in an incomplete device registration state.
Broken app authentication - Apps like Microsoft Outlook could fail to authenticate because SSO isn’t fully configured.
Compliance gaps - Devices are flagged as noncompliant in the Intune Company Portal because Platform SSO registration isn’t completed.
Helpdesk burden - IT teams field repeated tickets for issues that should have been handled automatically during provisioning.
Migration blocker - Incomplete Platform SSO setup slows down migrating macOS devices to Intune.

Platform SSO during ADE with EnableRegistrationDuringSetup key eliminates these issues. Device registration, identity bootstrap, and credential setup all happen inline during Setup Assistant before the user ever reaches the desktop.

What the feature enables

Capability	Details
Microsoft Entra device registration during ADE	The device registers with Microsoft Entra ID before the user reaches the desktop. A hardware-bound Workplace Join certificate is issued and stored securely.
Early device identity	Device identity is established early in the provisioning process, enabling immediate access to resources protected by Conditional Access.
Platform SSO credentials during initial setup	When configured with Secure Enclave, credentials are stored in the device's Secure Enclave, providing hardware-bound, phishing-resistant protection aligned with Zero Trust principles.
Minimized delays	Users arrive at the desktop already signed in. No additional prompts, no waiting for policies, no broken apps.

How it works

This feature requires three policies that work together. All three must be configured correctly before enrollment starts and assigned to the same static user groups:

A Platform SSO settings catalog policy with “Enable Registration During Setup” configured to Enabled.
Intune Company Portal (version 5.2604 or newer) deployed as a line-of-business (LOB) app, which provides the Microsoft Enterprise SSO extension.
An ADE enrollment profile configured with Setup Assistant with modern authentication and Await final configuration = Yes.

When a device enrolls with these three policies in place, here's what happens:

The device powers on and begins the ADE enrollment flow.
Intune delivers the Platform SSO settings catalog policy with Enable Registration During Setup enabled.
Intune Company Portal is installed automatically as a LOB app, providing the Microsoft Enterprise SSO plug-in.
During Setup Assistant, the user signs in with their Microsoft Entra credentials. This first sign-in starts the regular enrollment process.
A second sign-in authenticates the identity in Intune Company Portal and fetches the SSO extension.
The device registers with Microsoft Entra ID, and a Microsoft Entra device registration certificate is issued.
The user arrives at the desktop fully authenticated, with SSO active and Conditional Access satisfied.

Note: During enrollment, users are prompted to enter their Microsoft Entra credentials at least twice. We're working on improvements to reduce the number of sign-ins in a future update.

Prerequisites

Requirement	Details
macOS version	macOS 26 and newer
Enrollment method	ADE via Apple Business
Intune Company Portal	Version 5.2604.0 or newer, deployed as a LOB app. Download from https://go.microsoft.com/fwlink/?linkid=853070
Intune role for configuration	Admin account with at least the Policy and Profile Manager built-in role
Group type	Assigned (static) user groups only. Dynamic groups and device groups are not supported.

Important: Review the full Platform SSO prerequisites in the Platform SSO configuration guide before you begin.

High level step-by-step configuration

Step 1: Create or update the Platform SSO settings catalog policy

In the Microsoft Intune admin center, go to Devices > Manage devices > Configuration. If this is your first time configuring Platform SSO, follow the full Platform SSO configuration guide.

Add and configure the following setting:

Setting	Value	Description
Authentication > Extensible Single Sign On > Platform SSO > Enable Registration During Setup	Enabled	Enables the Platform SSO registration process during Setup Assistant.

If using the Password authentication method, it’s recommended to add for password sync function:

Setting	Value	Description
Authentication > Extensible Single Sign On > Platform SSO > Enable Create First User During Setup	Enabled	Enables the password synchronization experience during Setup Assistant. This configuration is recommended for Password authentication method.

Tip: Microsoft recommends using Secure Enclave as the authentication method for the strongest hardware-backed security.

Assign the policy to your static user groups. Filter is also supported with correct static group setting.

Step 2: Install Intune Company Portal as a LOB app

Download the Company Portal for macOS PKG from https://go.microsoft.com/fwlink/?linkid=853070.
In the Intune admin center, go to Apps > All Apps > Create.
Add Intune Company Portal as a macOS LOB app.
Make it a required app and assign it to the same groups as the Platform SSO policy from Step 1.

Important: Company Portal 5.2604.0 and newer is required. If you install an older version, Platform SSO fails. When Intune detects Company Portal as a deployed policy, it sends it with priority during enrollment.

And clean up the App bundle ID that are not related to Company Portal, make sure only com.microsoft.CompanyPortalMac as the relevant App bundle ID is kept.

Figure 1: Microsoft Intune admin center Add App screen for a macOS line-of-business app, showing CompanyPortal-Installer.pkg details, macOS Tahoe 26.0 minimum OS, ignore app version enabled, install as managed disabled, and included app bundle ID com.microsoft.CompanyPortalMac version 5.26040.

Step 3: Set up the enrollment profile

In the Intune admin center, go to Devices > Device onboarding > Enrollment > Apple tab.
Create or edit an Automated Device Enrollment profile with these Management settings:

Setting

Value

User affinity

Enroll with User Affinity

Authentication

Setup Assistant with modern authentication

Await final configuration

Yes

Locked enrollment

Yes
Assign the profile to the devices afflicated with the users targeted as Steps 1 and 2.

Critical: You must assign all three policies to the devices afflicated with the users targeted. If any policy is assigned to a different group, or if any step is misconfigured, enrollment will fail. In that case, wipe the device and re-enroll with all steps correctly configured.

Key things to remember

✅ Three policies, one group: Settings catalog, Company Portal LOB app, and ADE enrollment profile, all assigned to the same static groups or devices/users affliated with the groups.
✅ Static groups only: This feature does not work with device groups or dynamic groups.
✅ One SSO policy per device: If you already have a Platform SSO policy assigned to enrolled devices, make sure device is wiped appropriately before kicking of enrollment with new PSSO flow.
✅ Latest Intune Company Portal: Version 5.2604.0 or newer is required.
✅ macOS 26 required: This feature is supported on macOS 26 and newer.
✅ Secure Enclave recommended: For the strongest hardware-backed credential protection.

For more details, refer to Configure Platform Single Sign-On (PSSO) during Automated Device Enrollment for macOS devices.

Looking ahead: Reducing Platform SSO sign-in prompts

Signing in multiple times during enrollment isn't the ideal experience, and we're actively working to streamline it with a new enrollment setting that enables users to complete both Intune enrollment and Platform SSO device registration with a single sign-in. This will further simplify the onboarding experience, reduce friction for users, and bring macOS enrollment closer to a truly seamless, zero-touch provisioning flow. Stay tuned to What’s new in Intune for the release.

Related resources

As always, we'd love your feedback. If you've piloted Platform SSO during Setup Assistant, share your tips and lessons learned in the comments below or reach out to us on X @IntuneSuppTeam.

Post Updates:
6/8/26: Refreshed guidance recommending this configuration for the Password authentication method and clearer targeting language around devices and users affiliated with the groups targeted.

Known issue: Upgrading Microsoft Tunnel version 20260129.1

Intune_Support_Team — Fri, 08 May 2026 23:05:24 GMT

We identified an upgrade issue with the early March release of Microsoft Tunnel version 20260129.1 that caused servers to become stuck and unable to complete the upgrade. The issue can be resolved by uninstalling and reinstalling the server to a newer version (20260330.1 or later). Alternatively, we’ve created a script to help you update affected servers. This blog explains how to use the mstunnel-patch-2602 script to remediate the issue.

Before you begin

Before you run the script, make sure you have the following:

Access to the Linux virtual machine hosting the Microsoft Tunnel server
Permission to run commands with sudo
The patch script downloaded to the server from https://aka.ms/mstunnel-patch-2602

When to use this script

Use this script if your server is showing one or more of the following behaviors:

The server remains on the affected version (20260129.1) and doesn’t move to the latest version
In the Intune admin center, the server health state appears as Healthy, but the upgrade banner shows an error
The server rolls back to the affected version because of a version mismatch in Agent Settings

Identify impacted servers

The issue affects servers on version 20260129.1, use the following hash to identify whether your deployment is on this version:

Agent: sha256:abbdcd854aa5ac376aed32c828e4c84917e776a701855cd1e3febed18a3e4dae
Server:sha256:ad57d6a7ffe21f64fc1577713063ae9b180914cf65bc70b4e49be21299cfc1d3

The issue was resolved with version 20260330.1, released March 30, 2026. You can verify your servers are on this version with the following hash:

Agent: sha256:163214b94af6d91a5ef02690f891c5a41e87b1059b9530324716ee34778c1785
Server: sha256:dd62c292528e8e5aa4e7b84418efa42fd3830ec0db40467947cde8125aa17d7e

Run the script

After downloading the script to the server, complete the following steps.

Step 1: Enable execution permissions

If needed, make the script executable:

chmod +x mstunnel-patch-2602.sh

Step 2: Run the script

Run the script with elevated permissions:

sudo ./mstunnel-patch-2602.sh

When the script runs, it performs the following actions automatically:

Checks whether the current server is using the affected build hashes.
Creates backups of the current configuration so the system can revert if the update fails.
Stops the Tunnel agent and server services.
Updates the configuration with version 20260330.1 hashes
Pulls version 20260330.1 and forces mst-cli install without requiring additional user input

Expected results

After the script completes successfully, the server should be updated to the March 30, 2026 version 20260330.1. This remediation is intended to resolve upgrade failures caused by a version mismatch and eliminate the need for a manual uninstall and reinstall workflow.

If you have any questions or issues running the script to update your servers, reply to this post or reach out to the team on X @IntuneSuppTeam.

Migrating frontline mobile devices: Aligning stakeholders before real-world testing

Intune_Support_Team — Fri, 01 May 2026 19:37:13 GMT

By: Carol Burns - Principal Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune)

Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments.

In the previous article, we focused on understanding the reality of your frontline device estate - what devices you have, how they’re used, and which tasks they must support. Now that discovery is complete, the next step is to assess what you’ve found and align your people and processes before beginning real‑world testing with Microsoft Intune and representative users and devices. This is where you turn discovery into an actionable plan your team can execute in real operational conditions.

Many organizations refer to this stage as a Proof of Concept (POC) or pilot. In this article, we use these terms to describe limited real‑world validation of frontline workflows with representative users and devices, rather than internal IT feasibility testing. Use the pilot to confirm that users can reliably complete critical tasks in live operational environments before wider rollout.

Translate discovery into decisions

Discovery produces facts, but readiness requires decisions. Before beginning real‑world testing with representative users and devices, your team should be able to answer questions like:

Are we migrating “as‑is,” or do we plan on correcting identity and usage anti‑patterns such as shared credentials or personal use on corporate devices?
Which workflows are non‑negotiable and must work on day one, and which can be improved later?
Do we need to refresh hardware now, or can we migrate current devices and plan standardization at refresh time?
What are our top constraints (OS support, connectivity, etc.)?

A useful way to structure discovery output is to categorize findings and determine whether they support limited real‑world testing or require further alignment before proceeding.

Pre‑requisites for real‑world testing typically include clear ownership of devices and apps, supported OS versions, and a manageable device or OEM mix.

Items that often require alignment before real‑world testing include shared devices without a defined shared‑device model, shared credentials or unclear authentication approaches, personal use on corporate devices (which affects wipe/re‑enroll decisions), certified app or peripheral constraints, and network or certificate dependencies that could impact enrollment and compliance.

Identify the stakeholders you must align (and why)

Real‑world testing of frontline workflows depends on more than technical readiness. A clear stakeholder map helps surface operational dependencies early and ensures that limited validation activities can be conducted safely without disrupting day‑to‑day work.

Not every environment requires all of the roles listed below at this stage, but these are the most common stakeholders needed to support limited real‑world testing of frontline workflows.

Operational stakeholders

Stakeholder	Why they matter	What to align
Operations / business leadership	Define frontline outcomes and approve change windows.	Critical workflows, downtime tolerance, shift patterns, pilot locations, operational sign‑off criteria.
Funding owners / procurement	Discovery often uncovers refresh or licensing gaps.	Device and accessory funding, carrier plans, spares, and standardization strategy.
Change management	Testing may introduce new sign‑in flows or device behaviors.	Communications plan, support readiness, rollback and escalation processes, exception management.

In addition to operational alignment, technical readiness across supporting IT teams is required to ensure testing reflects production like conditions.

Technical and support stakeholders

Stakeholder	Why they matter	What to align
Endpoint or Microsoft Intune owners	Build policy, enrollment, apps, and compliance.	Device categories, management models, policy approach, rollout waves.
Architecture team	Ensure alignment with enterprise standards.	Reference architecture, lifecycle approach, dependency mapping.
Microsoft Identity / Microsoft Entra team	Underpins Conditional Access and shared‑device patterns.	Authentication model, shared device sign‑in patterns, break‑glass scenarios.
Network team	Enrollment depends on connectivity and certificate flows.	Wi‑Fi (EAP‑TLS), proxies, segmentation, roaming, known dead zones.
Security / risk / compliance	Define guardrails and exceptions.	Wipe policies, logging, least privilege, auditability.
App owners / vendors	Critical frontline workflows depend on app behavior.	Compatibility, offline behavior, deployment approach.
Support / service Desk	Manage user impact during testing.	Runbooks, escalation paths, enrollment troubleshooting, shift‑based support.
Project management (large environments)	Coordinate testing across teams.	Timeline, risk tracking, cross‑team communications.

Readiness checklist before real‑world testing

Real‑world testing often produces limited value when it focuses primarily on Microsoft Intune enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions.

Readiness area	Questions to consider before real‑world testing
Licensing	Do you have the correct Intune licenses for the devices or users in scope? Are any add-ons needed?
Identity	Is Microsoft Entra configured for your enrollment approach? Are Conditional Access policies ready for real‑world testing? For shared devices, what sign‑in model will you use?
Stakeholder alignment	Who owns the success criteria? Who approves the testing scope and change window? Who funds required accessories or device refresh?
Operational readiness	Who provides day‑to‑day support for test devices? What is the escalation path for a broken critical workflow? What is the rollback or recovery plan?
Device lifecycle decisions	Will you test by migrating existing devices as‑is, replacing end‑of‑life devices first, or using testing to define the future standard?
OEM and ecosystem readiness	Are the devices still supported by the OEM? Are required peripherals supported? Do rugged or certified requirements limit device options?

Lack of clear ownership for testing success criteria is a common cause of inconclusive pilots, particularly where operational workflows span multiple teams.

Decide what your real‑world testing must validate

Real‑world testing often produces limited value when it focuses primarily on enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions.

Real‑world testing should validate high‑value operational outcomes, ensuring:

Critical workflows function end‑to‑end
- Scanning, inventory, delivery confirmation, POS, etc.
- Session transitions match shift patterns
- Offline or degraded‑mode behavior works as expected (where relevant)
Security works without disrupting operations
- Compliance and Conditional Access do not block legitimate frontline activity
- Wipe and recovery processes are realistic for shared devices
- App protection controls align with user experience
Supportability is operationally viable
- Device reset and re‑enroll processes are documented
- Troubleshooting steps are known and repeatable
- Escalation paths exist for frontline‑impacting incidents
Representative device scenarios are included
Include the different frontline scenarios identified during discovery, such as:
- Shared vs assigned devices
- Different OEM models or OS versions
- Sites with known connectivity constraintso
- Common peripherals that may introduce migration risk (for example, scanners or printers)

Plan for future standardization (without delaying testing)

You may need to begin real‑world testing using the environment you have today. However, this stage can also be used to identify patterns that may shape future procurement and standardization decisions without delaying validation activities.

Practical prompts to add to your planning:

If you could reset procurement going forward, would you reduce OEM or device model sprawl?
What might your target “approved device set” look like for the next refresh cycle?
Which procurement models could support consistent enrollment, warranty coverage, and access to spares across shifts?

Standardization doesn’t need to be a prerequisite for real‑world testing, but it can become a valuable outcome of the migration effort over time.

Moving from assessment to real‑world testing

After you’ve aligned stakeholders, clarified dependencies, and defined what your real‑world testing must validate, you’re ready to move from assessment to limited operational testing with representative users and devices.

The key takeaway is this: discovery tells you what’s real, but readiness determines whether you can safely test it in live operational conditions.

As always, we welcome your feedback and experience. If you’ve already tested frontline workflows in operational conditions, what advice would you give organizations preparing for this stage? Share your thoughts in the comments below or reach out to us on X @IntuneSuppTeam.

Explore the From the frontlines: Frontline worker management with Microsoft Intune series for additional guidance on managing frontline workers and devices.

Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions

Intune_Support_Team — Thu, 30 Apr 2026 15:47:22 GMT

By: Albert Cabello Serrano | Principal Product Manager - Microsoft Intune

A closer look at how Intune delivers updates to devices and the investments we’re making to help important changes move faster and more predictably.

A common concern we hear from IT admins is, “How quickly will this change actually reach my device?” In many cases, the answer is much faster than expected. Today, 90% of policy updates, app deployments, and device actions in Intune are completed in under an hour.

So where does the idea of “8-hour latency” come from? That number reflects a routine maintenance check-in used when devices are idle - not how Intune processes meaningful changes. Intune uses notification-based, priority-driven processing so that high-impact actions, like security policy changes or remediation steps, are handled promptly and reliably as possible.

In this context, latency isn’t about making every action instant - it’s about providing predictable, prioritized delivery at global scale. The sections below break down how Intune prioritizes different types of updates and recent investments that are helping time-sensitive changes complete more consistently.

How Intune delivers changes to devices

Cloud-based device management is designed for real-world conditions; devices are not always online, fully charged, or on stable networks. Intune uses an eventual consistency model so devices can continue to be productive while converging to the desired state over time, without management actions unnecessarily disrupting users or workflows.

Because devices operate in different conditions, not all device activity is handled the same way. To manage change reliably at scale, Intune uses different types of device check-ins depending on what needs to happen.

Types of device check-ins in Intune

Device check-ins generally fall into several categories, each triggered by a different type of action:

Single‑device check‑ins: Occurs when an admin or user initiates an action on a specific device, such as starting a device action or installing an app from the Intune Company Portal.
Change‑based check‑ins: Push‑triggered check‑ins used to deliver meaningful changes to devices as soon as possible.
Client‑initiated check‑ins: Background activity that helps keep devices healthy, such as when a user signs in to a device or when malware status changes.
Maintenance check-ins: Scheduled syncs that occur at predetermined intervals and can be client or service-initiated, depending on the platform. These typically occur approximately every 8 hours.

Regardless of what triggers a check-in, any pending changes will be applied to the device when it occurs.

What happens when an admin makes a change

When an admin makes a change in Intune, such as updating a device compliance policy, deploying an app, or setting a configuration, Intune identifies the devices impacted by that change and initiates a change‑based check‑in for affected devices.

For online devices, Intune sends a push notification prompting the device to establish a management session with the service, apply the change, and report enforcement status back to Intune. If a device is offline or unreachable, the change is applied when the device next checks in through available mechanisms.

Four investments that help critical updates move forward faster

The following product changes focus on reducing device‑change latency by shortening the time between an admin action in Intune and enforcement on the device, especially during peak or constrained conditions.

1. Check-in prioritization focused on what matters most

Not all device activity carries the same urgency. Routine background check-ins can compete for service resources with devices that have important pending changes, such as compliance updates, remediation actions, or administrator-initiated configuration changes.

Intune evaluates the potential impact of delaying a device check-in on security posture, compliance state or user productivity, and dynamically prioritizes processing accordingly. This real-time prioritization model ensures that high-impact actions move forward without being delayed by lower‑impact background activity. Prioritization adapts as conditions change, helping important updates reach devices more quickly and predictably without being delayed by lower-impact background activity.

2. Built-in resilience when multiple changes occur in quick succession

Change activity often happens in bursts, with several related updates occurring in rapid succession. These periods of activity may be driven by operational needs or background processes, and can involve adjusting assignments, updating multiple policies, or rolling out configuration changes across the same set of devices.

Intune dynamically coordinates notifications, so that each change requiring action triggers a corresponding device notification, even during high-activity periods. This helps improve consistency when applying multiple updates and reduces delays across consecutive changes on devices.

Over the next several months, these improvements will extend to additional payloads delivered through the Intune Management Extension (IME), including scripts, Win32 apps, and custom compliance across both Windows and macOS platforms.

3. More timely notifications on Windows

Intune notifies devices to check-in when changes require action. If the device is offline, on an unstable network, or low on battery, notifications may be delayed. This can cause missed check-ins or delayed actions.

When notification services are delayed, blocked, or unavailable, devices may fall back to scheduled maintenance check‑ins to apply changes. For timely delivery, required notification service endpoints need to remain accessible so devices can receive management signals when updates occur.

On Windows devices, Intune complements the Windows Notification Service (WNS) with the same notification protocol that powers Microsoft Teams via the Intune Management Extension. This helps increase the likelihood that devices receive management notifications when they’re online and reachable, improving visibility into whether policy updates or device actions have reached their destination.

For more information, see the network endpoints for Intune documentation.

4. Optimized maintenance check-ins for iOS devices

Background check-ins are still important to keep devices healthy when nothing else is going on. Unlike Windows devices, iOS devices don’t have client scheduled check‑ins and depend on service‑initiated maintenance check‑ins to ensure device health and compliance.

During peak usage periods, these maintenance check‑ins can account for a significant portion of overall traffic, which can compete with devices that require immediate updates.

Intune considers device activity in the scheduling of maintenance check‑ins during peak activity, making room for higher‑impact updates, while continuing to ensure devices check in regularly. This helps manage traffic and improves responsiveness when applying policies or remediation actions.

What this means for you

For IT admins: No additional configuration or workflow changes are required to benefit from Intune’s built-in notification system. When bidirectional communication with notification service endpoints is open, devices can receive and act on updates as they become available.

For security teams: Faster delivery of device changes helps shorten the time between a policy update, a tightened Conditional Access rule, an updated compliance baseline, and a remediation action. For Zero Trust frameworks, where posture signals drive access decisions, this helps narrow the window during which a device could be out of compliance or vulnerable.

Together, these improvements reflect how Intune is evolving into a more intelligent, priority-aware system. Rather than making every action instant, the focus is on prioritizing high-impact updates so they are delivered without unnecessary delays. This approach is expanding across a number of scenarios to provide a more consistent and predictable experience, helping reduce delays for key updates.

Resources to learn more

For another perspective on this topic, read an MVP’s take on demystifying the “8-hour” timing myth in this LinkedIn post.

You can also watch the recent Tech Takeoff about this same topic to learn more about these improvements.

Also, in the April edition of the What's New in Intune blog, we introduced a new segment called Myth vs. Reality. This post is part of that series. To stay current on new capabilities and updates as they ship, follow the What's New in Microsoft Intune blog.

What myth should we debunk next? Leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune.

Unpacking Endpoint Management is back - and we’ve got a lot to talk about

Intune_Support_Team — Thu, 28 May 2026 18:37:38 GMT

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

June 30, 2026 – 9:00 a.m. PDT
Topic TBD - What should we cover? Drop ideas below in the comments.
July 30, 2026 - 9:00 a.m. PDT
Topic TBD

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.

Device security with Microsoft Intune
Trends in endpoint management (live from Tech Takeoff 2026)

Not sure where to start? Watch our most recent episode, Policy: from hybrid to cloud-native, 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/JoinIntuneCommunity

As vulnerability discovery moves at AI speed, keeping current is foundational to reduce exposure

Intune_Support_Team — Wed, 22 Apr 2026 22:35:25 GMT

Recent advances in automation and AI are accelerating vulnerability discovery and shortening the window between disclosure and exploitation. As Microsoft outlined in our recent Security blog, this shift raises the bar for how quickly organizations need to reduce exposure across their environments.

For IT and security teams, this makes staying current on updates more critical than before. While responding to individual Common Vulnerabilities Exposures (CVE) remains essential, keeping current across devices and applications is foundational to reducing exposure as threats evolve.

This post focuses on the endpoint execution layer - how Microsoft Intune helps organizations understand their update posture, prioritize action, and reduce the time it takes for protections to land.

Introducing the security update status dashboard in Microsoft Intune

To act decisively, teams need clear visibility into where systems are current, where gaps exist, and how update deployments are progressing. Without a shared, defensible view of update status, it’s difficult to prioritize remediation or answer a basic question from leadership: “Are we patched?”

To address this, Intune is introducing the General Availability of a new security update status dashboard providing centralized visibility into update compliance across Windows Clients, Windows Servers, and Microsoft 365 Apps. The dashboard provides a clear, current view for leadership, backed by current data — without switching between multiple reports or tools.

Figure 1: Security update dashboard showing patch status for Windows clients, servers, and Microsoft 365 apps.

The dashboard surfaces:

Visibility into which devices are current on quality and feature updates, which are falling behind, and where remediation gaps exist across your Intune-managed estate
The data needed to prioritize action, track progress across deployment rings, and help demonstrate a more accurate compliance posture
Insight to where exposure is critical and needs immediate attention

Four ways to shrink your vulnerability window

The dashboard delivers visibility. The capabilities below help you act on it.

1) Windows Autopatch: deploy updates at scale with control

Windows Autopatch manages update orchestration through predefined deployment rings, releasing updates progressively across representative device groups so that quality and security updates reach broad production populations only after passing validation in pilot environments. IT teams shift from manually coordinating deployment schedules each month to focusing on policy and exception management while Windows Autopatch handles sequencing, scheduling, and rollout logic.

When critical vulnerabilities emerge, expedited update deployment allows devices to advance more quickly through the rollout process, providing security teams with an additional lever for reducing time-to-secure when AI-driven discovery shortens the window between disclosure and exploitation.

2) Hotpatch updates: Windows updates without the reboot

Even when updates deploy rapidly, protection is not realized until a device restarts, and users routinely defer reboots for hours or days. Hotpatch updates for Windows reduces this gap by applying supported security updates to in-memory processes without requiring frequent restarts. Eligible Windows 11 Enterprise devices can reach a protected state immediately after installation, helping reduce the vulnerability window.

Operationally, hotpatch updates shifts the restart requirement from monthly update to a smaller number of planned baseline updates per year, enabling organizations to deploy critical fixes without the productivity impact of forced restarts. You can enable hotpatch updates through quality update policies in Intune on supported systems.

In addition, with Autopatch update readiness, IT admins can better anticipate when planned quality or feature updates won’t reach a device, understand Autopatch and hotpatch enrollment coverage, and quickly identify blockers to bringing devices into a ready state.

3) Microsoft 365 Apps patching: keep Office and other apps current in lockstep

The Microsoft 365 Apps admin center includes Inventory and Cloud Update, giving administrators visibility into update status across connected devices by update channel so they can quickly spot systems missing the latest security updates and track progress. When an accelerated response is required, teams can tighten deadlines and move from staged rollout to immediate enforcement by removing waves, deferrals, or exclusion windows that may delay availability for specific groups, especially where channel divergence or scoped targeting leaves devices outside policy. Because expedited servicing reduces time for testing across diverse configurations, Cloud Update controls such as pausing a deployment or rolling back an update help mitigate risk while closing security gaps quickly.

4) Server updates: Configuration Manager or Azure Arc to accelerate compliance and operational workloads

For organizations managing servers, Configuration Manager helps streamline the identification, packaging, and assignment of security updates (for example, with Automatic Deployment Rules) based on classification and severity. Cloud-based sourcing through the Microsoft Update service can prevent deployment failures in distributed environments, while maintenance windows let you pre-stage updates for highly available systems and install them during defined downtime intervals - achieving compliance without unplanned service interruptions. For server estates that are Arc-enabled, you can also use Azure Arc to extend visibility and management across hybrid and multicloud infrastructure.

If you need even deeper coverage and insight, consider integrating Microsoft Defender Vulnerability Management (MDVM) to enrich update posture with vulnerability intelligence and prioritize remediation based on real exposure.

Using update currency as an enforcement signal

Deploying updates is half the job. Verifying they land - and holding the line when they don't - is the other half. Intune compliance policies let you define minimum OS build numbers, required update levels, and grace periods. Devices that fall out of compliance are flagged automatically.

Paired with Microsoft Entra ID Conditional Access, update currency can become a condition of access - checking that only current, healthy devices connect to corporate resources. This turns update posture into an enforceable control, not just a reporting metric.

Actions you can take today

The increasing use of AI in vulnerability discovery, combined with a rapidly evolving threat landscape, underscores the importance of taking proactive security measures. Here are actions you can take today:

Assess. Open the new security update status dashboard and know the baseline of your fleet. See how many Windows devices are behind on feature releases, quality updates, and Microsoft 365 Apps patches.
Automate. Configure Windows Autopatch for ring-based deployment, enable hotpatch updates on eligible devices, and set Microsoft 365 Apps servicing profiles. Enable expedited updates so you can respond to critical vulnerabilities quickly.
Enforce. Pair compliance policies with Conditional Access. Make being current a condition of access to corporate data.
Monitor. Review the dashboard weekly. Investigate deployment failures promptly and deploy proactive remediations to clear blockers.
Communicate. Share dashboard trends with security leadership and application owners. When stakeholders see the data, update compliance becomes a shared priority, not just an IT burden.
Evolve. Revisit your deployment rings, deferral windows, and compliance thresholds quarterly. Use failure patterns from the dashboard to refine your approach and evaluate Windows Autopatch for a fully managed experience that scales with your organization.

Every day a device remains out of date is potential exposure to unnecessary vulnerabilities. Intune gives you the tools, and now the visibility, to get current, stay current, and defend your organization at the speed the threat landscape demands.

Closing

Reducing exposure starts with knowing where you stand. The security update status dashboard in Intune provides a single place to understand update status across Windows devices and Microsoft 365 Apps, helping you identify lagging systems and prioritize action.

Make the dashboard part of your regular operational rhythm: review it, act on the gaps it surfaces, and track progress over time. With the right visibility and tooling, staying current becomes repeatable - not reactive.

Feature availability varies by license. Learn more about plan details and requirements here.

Read the latest Microsoft Security blog to learn how turning AI‑driven discovery into protection at scale can help secure your estate in an AI‑driven threat landscape.

Get started with Microsoft Secure Now for guidance in assessing risk and take recommended actions.

Migrating Frontline Mobile Devices: Understanding the reality of your estate

Intune_Support_Team — Wed, 15 Apr 2026 21:04:35 GMT

By: Carol Burns - Principal Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune)

Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments.

Frontline devices have evolved from a small set of task-specific tools into the way day-to-day work gets done. As new workflows, apps, locations, and teams get added over time, device estates expand quickly, making it harder to maintain consistency and visibility.

For many organizations, the reality of the estate isn't easy to keep track of. Devices may have been purchased locally, inherited through acquisitions, shared across teams, or left unused in lockers. They may be repurposed for new workflows or kept running far longer than originally planned.

This creates a gap between what teams think they have, how they expect devices to be used, and what happens in the field.

“Frontline estates aren’t complex because teams don’t care, they’re complex because operations evolve faster than governance.” -Sucheta Gawade, Microsoft MVP

If teams don’t close this gap early, it tends to show up during pilots and cutover: devices fail in real conditions, frontline teams revert to workarounds, and the migration slows down through rework, exceptions, and avoidable disruption.

To understand the estate, teams need to start by determining what the business needs devices to do and not just who happens to use them.

Start with what devices need to do

While some devices are assigned to individual users, many are shared across shifts, used for specific tasks, or operate without a fixed user at all.

Designing a migration around users or roles can obscure what really matters: the job the device must perform, when it must be available, and the impact if it isn’t.

Anchoring on business needs helps teams:

Focus on outcomes rather than ownership models
Simplify stakeholder conversations
Make clearer tradeoffs, when required, around user experience, productivity and security

One simple way for teams to gather this information is by mapping business tasks to what devices must reliably do.

Business Task	What the device must do	When it must work	Impact if unavailable
Take payment for goods	Run secure POS applications	Store open hours	Lost revenue
Pick inventory	Scan bar codes quickly and accurately	During shifts	Orders delayed
Document patient observations	Capture and submit clinical data	During care delivery	Delayed or incomplete care

This framing applies equally across retail, healthcare, manufacturing, transport, logistics and utilities. It creates a shared language between IT, operations, and security - one that is grounded in business impact rather than tooling.

Once business needs and intended device usage are clear, the next step is understanding how those devices support frontline work day to day.

Understand how devices are used in practice

Frontline usage patterns often diverge from what business owners and IT expect. Devices may be shared across shifts or used by alternate users. They may also be repurposed to support new workflows or kept running beyond their intended lifecycle, all without IT or executive oversight.

These gaps are best identified by partnering with operational and business owners to validate real-world usage through quick workflow walk-throughs, targeted questions, and a review of how devices are accessed and supported day-to-day. Some helpful questions:

How are devices shared?
When are they offline or unavailable?
What workarounds exist to keep critical tasks moving?

It’s also critical to confirm whether corporate-assigned devices have been used for personal activity. Personally used devices may also be treated as work devices, whether authorized or otherwise. This affects wipe and re-enroll decisions because personal use can introduce data retention, user impact, and acceptance risks.

Intended usage	Actual observed use	Notes/Workarounds
Assigned device	Shared across the shift	Shared credentials used
Always connected	Intermittent Wi-Fi	Offline workarounds
Single-app device	Multi-app usage	Local exceptions for multiple apps

This is also where identity assumptions surface, particularly in environments where devices are shared but access shouldn’t be.

“Identity reality matters: shared devices should not mean shared credentials. Migration is often the right moment to address this. Otherwise, teams simply re‑platform the same risks.” -Sucheta Gawade, Microsoft MVP

Teams often uncover important dependencies at this stage. For example, some frontline workflows rely on constant connectivity, while others must function reliably in low‑bandwidth or offline conditions. Similarly, older operating systems or unsupported device models may still be in active use because replacing them has operational or budgetary implications.

Understanding these realities early helps teams avoid designing for ideal conditions that don’t exist in the field.

Ground plans in device inventory

Inventory is most valuable when it supports planning decisions, not when it aims for completeness. For frontline migrations, teams need decision relevant information rather than a perfect asset register.

Understanding how devices are procured and funded across the organization is important. For example, whether devices are purchased centrally through IT or sourced locally by business/departments. Procurement paths often explain why inventory is fragmented and help determine who owns refresh cycles, warranties, and enrollment readiness.

At a minimum, this includes:

Device types and OEMs
OS version ranges and supportability
Whether devices are active, dormant, or missing
How devices align to business-critical tasks
Where specialist or certified devices are required such as intrinsically safe or ruggedized devices

This helps surface ecosystem considerations early:

Are required apps and services supported on the OS versions in use today?
Do OEMs still support the hardware?
Do environment constraints affect enrollment, updates, or day‑to‑day operation?

These questions are not about selecting solutions yet. They’re about understanding constraints that will shape options later.

With business needs understood, usage patterns mapped, and inventory validated, teams are ready to start designing approaches that work in frontline conditions.

Migration is also a good opportunity to plan for standardization and set a future procurement standard. Even if you migrate the current estate as-is, defining an approved OEM or model catalog for future purchases improves consistency. It can also accelerate troubleshooting and strengthen lifecycle governance as devices reach end of support.

What we’ve learned

The key lesson is simple: validate reality before designing anything.

Teams that invest time here:

Reduce rework during pilots
Avoid late‑stage surprises
Have stronger conversations with operational, security, and platform stakeholders

“We don’t declare success at enrollment. We declare success when a frontline workflow can run end-to-end with predictable support.” -Sucheta Gawade, Microsoft MVP

In future articles, we’ll look at how these insights shape design decisions. In the meantime, we’re interested in hearing what gaps you’ve uncovered between intended and actual device usage in your frontline environments. Leave a comment below or reach out on X @IntuneSupportTeam.

Create historical reports using Azure Log Analytics and Microsoft Intune diagnostic data

Intune_Support_Team — Tue, 07 Apr 2026 23:27:45 GMT

By: Janusz Gal – Sr Product Manager | Microsoft Intune

Azure Log Analytics gives Intune admins a flexible way to create custom reports from diagnostic data, especially when you need longer history or tailored calculations that go beyond what the Microsoft Intune admin center’s built-in reports provide. By using the Intune diagnostic data you’re already collecting, you can customize reporting for your organization’s unique requirements. In this post, you’ll walk through the steps to create a 30-day device compliance trend report. The resultant report can be run automatically, used in dashboards, or even further customized for a longer period or with additional data.

Before we begin, if you haven’t configured a Log Analytics workspace in your tenant, review the following detailed information on the pre-requisites and costs on Microsoft Learn: Route logs to Azure Monitor using Microsoft Intune.

In the Microsoft Intune admin center, navigate to Reports > Diagnostic settings, and add a new Diagnostic setting policy to send data to a Log Analytics workspace.

Figure 1 Reports > Diagnostic settings, used to configure new or existing diagnostic settings.

For a device compliance trend report, ensure the Devices log category is selected:

Figure 2 Reports > Diagnostic settings > Selected configuration; Devices log selected.

After configuring the setting, navigate to Reports > under Azure monitor, Log Analytics.

Figure 3 Reports > Log Analytics; used to query log Analytics workspaces.

In the New Query window, enter the following query:

IntuneDevices | where TimeGenerated > ago(30d) | summarize Total = count(), Compliant = countif(CompliantState == "Compliant"), NonCompliant = countif(CompliantState == "Noncompliant"), InGracePeriod = countif(CompliantState == "InGracePeriod"), NotEvaluated = countif(CompliantState == "Not Evaluated" or CompliantState == ""), ConfigManager = countif(CompliantState == "ConfigManager") by bin(TimeGenerated, 1d) | extend ComplianceRate = round(100.0 * Compliant / Total, 2) | order by TimeGenerated asc

This query will return daily device compliance trends over the past 30 days, from the IntuneDevice table.

Figure 4 Reports > Log Analytics; results after running query.

Select Chart > Chart type > Stacked Area to show a visual of the trending device state over time.

Figure 5 Reports > Log Analytics > Chart > Stacked Area.

If you’d like to create other reports but aren’t sure of the schema, one trick you can use is to run the following query in the above Log Analytics workspace to get all the column names:

IntuneDevices | getschema

Then to get all the values from those columns, you can modify the query to return the distinct values from a specific column such as CompliantState:

IntuneDevices | distinct CompliantState

Now that you have the query created in Log Analytics, you can save it to run anytime, pin it to a dashboard, or even create a new alert rule to let you know if compliance has gone below a certain threshold.

To pin it as a dashboard, on the Query pane select the ellipsis (…) > Pin to > Azure dashboard.

Figure 6 Reports > Log Analytics; pin query to dashboard flow.

Then select the dashboard you’d like to use.

Figure 7 Reports > Log Analytics; select dashboard to pin.

Once pinned, simply navigate to Dashboard within the Intune admin center, and you’ll see the query pinned on the selected dashboard.

Figure 8 Dashboard showing Log Analytics query.

To show more than the past 24-hours, select the Customize Tile button and select Override the dashboard time settings at the tile level, with Timespan set to Past 30 days.

Figure 9 Dashboard > Selected Query > Customize Tile button.

If you’d like to always see the data in a chart form, select the edit icon on the pinned dashboard item and append the following to the end of the query:

| render areachart with (kind=stacked)

Figure 10 Dashboard > Selected query > Edit > modified query to show chart.

After clicking Apply, the dashboard shows the following:

Figure 11 Dashboard showing updated historical device compliance query as a stacked area chart.

You’ve now seen end-to-end how to turn Intune diagnostic data into a 30-day device compliance trend report with diagnostic data and Log Analytics. From here, the next step is to operationalize it - save the query, extend the timeframe, join in additional diagnostic tables, or set an alert so you’re notified when compliance drops below your threshold. Better yet, see if you can pick one reporting gap your team is living with today and build it using this pattern. With the right tooling, Intune data can be shaped into views and insights that reflect your organization’s unique needs.

Let us know if you have any questions by leaving a comment below or reach out on X @IntuneSuppTeam!

Migrating frontline mobile devices: A frontline-first approach to moving to Microsoft Intune

Intune_Support_Team — Mon, 30 Mar 2026 17:52:54 GMT

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.

Best practices for securing Microsoft Intune

Intune_Support_Team — Sat, 14 Mar 2026 22:31:16 GMT

Microsoft Intune gives IT and security teams a powerful way to manage endpoints at scale - deploying apps, enforcing security baselines, and configuring the settings that keep users productive and your organization protected. That’s why strong admin protections matter, so the right people can make the right changes, in the right scope, with the right safeguards.

In this post, we’ll walk through three practical approaches to strengthen Intune protections:

Start with least-privilege, designing roles around real admin jobs
Embrace phishing-resistant authentication and privileged access hygiene, leveraging Microsoft Entra capabilities to reduce account and token compromise
Enable Multi Admin Approval in Intune for sensitive changes

Below we outline how to put each approach into practice.

1) Start with least-privilege: design roles around real admin jobs

Least-privilege works best when it’s grounded in how your team operates. As a best practice, don’t grant more administrative access than a role truly needs. In Intune, role-based access control (RBAC) lets you tailor permissions and scopes so teams can run day-to-day operations with the minimum set of permissions required, nothing more. Microsoft Entra ID roles that have access to Intune, such as Global Administrator and Intune Administrator, are considered privileged roles with broad permissions in Intune. The use and assignment of privileged roles should be limited and not used for daily administrative tasks within Intune.

Least-privilege is about limiting both the actions an admin can take and the users/devices those actions can be applied to. In Intune RBAC, scope tags enable you to constrain an admin’s visibility and actions to a defined set of users and devices - for example, only the devices assigned to a specific region, business unit, or platform team. When implementing RBAC policies, limit both the actions and users/devices an admin has permissions over.

Call to action: Treat Intune administration as a set of job-specific roles, not a blanket entitlement.

Inventory who has Intune Administrator, Global Administrator, or other high-impact roles, then remove broad assignments that don’t map to a named job function.
Leverage Intune built-in role definitions for common personas (Help Desk Operator, Application Manager, Endpoint Security Manager, Read Only Operator) and standardize assignments. Create custom roles for ultimate least-privilege control.
Implement scoped administration (scope groups and scope tags) for business units, regions, or platform teams, and validate that admins can only affect resources within their assigned scope.
Adopt time-bound privilege elevation such as Microsoft Entra Privileged Identity Management (PIM) for admin roles and require reauthentication on elevation and sensitive operations.

2) Embrace phishing-resistant authentication and privileged access hygiene

The security objective is straightforward: privileged access should be hard to obtain and hard to reuse. Microsoft Entra ID capabilities (Conditional Access, phishing-resistant multifactor authentication (MFA), risk signals, and privileged access controls) provide the policy engine that governs who can administer Intune, from where, and under what conditions.

Call to action: Every privileged Intune action (Intune RBAC Role Management, device wipe, script deployment) should require strong, policy-verified sign-in, not just a password.

Create Conditional Access policies dedicated to privileged roles and admin portals (Intune, Microsoft Entra, and related admin endpoints): require phishing-resistant authentication only, require a compliant device, challenge high-risk users or sign-ins, and restrict access by location or trusted network where feasible. Reduce or eliminate policy exclusions.
Eliminate standing access by using Microsoft Entra Privileged Identity Management to assign time-bound roles based on conditions and approval steps, including restricting access to who can administer and assign permissions to apps.
Move privileged accounts to phishing-resistant authentication methods and disable weaker methods for those accounts and through policy (see Plan a phishing-resistant passwordless authentication deployment).
Establish privilege admin workstations with higher security baselines and use them for Intune high privilege admin accounts.
Operationalize your token theft response plan by investigating risky sign-ins and unusual admin activity in Microsoft Defender XDR with signals from Microsoft Entra, Microsoft Defender for Cloud Apps, and Microsoft Defender for Endpoints.
Adopt a defense‑in‑depth strategy to reduce the risk and impact of token theft (see Protecting tokens in Microsoft Entra).

3) Multi-admin approval in Intune for sensitive changes

Multi Admin Approval introduces a practical governance control: selected Intune changes require a second authorized admin to review and approve before deployment. This is enforced for both Intune admin center actions and actions performed through Intune APIs. Multi Admin Approval reduces the risk that a single action can result in tenant-wide impact.

Call to action: Require a second approval for high-impact Intune workflows (such as Intune RBAC role management, device wipe, and script deployment) to add an additional safeguard and help contain potential tenant wide impact.

Decide which change types require approval - start with high-impact changes such as Intune RBAC role management and device wipe. Then, add access policies for changes that affect authentication, compliance, security baselines, or broad assignment scopes.
Define approver roles and coverage (who can approve, SLAs, and what happens during incidents).
Document an emergency/break-glass path with explicit post-change review, so speed doesn’t erase governance.

How these measures add up to strong administrative protections

When combined, these practices help you shift from relying on “trusted administrators” toward building a more protected administration by design: least-privilege to contain impact, Microsoft Entra-based controls to ensure users are trusted and are who they say they are, and multi-admin approval to govern the changes that matter most. These practices help organizations advance safer speed, clearer separation of duties, stronger audit readiness, and more resilient endpoint operations.

If you’re looking for a place to start, here are a few quick steps: start with a quick wins pass - inventory broad, standing Intune role assignments and replace them with least-privilege RBAC roles; enforce Conditional Access and adopt phishing-resistant multifactor authentication for all admin scenarios; and place Intune RBAC role management, device wipe, script deployment behind multi-admin approval.

Rethinking “Allow my organization to manage my device” Why opt‑in enrollment works better for Intune

RamyaSharma — Wed, 11 Mar 2026 21:18:54 GMT

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

Intune_Support_Team — Thu, 09 Apr 2026 02:38:29 GMT

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.

Support tip: Resolve device noncompliance with Mobile Threat Defense partner apps

Intune_Support_Team — Wed, 06 May 2026 19:57:14 GMT

Using a Mobile Threat Defense (MTD) solution, such as Microsoft Defender for Endpoint, with Microsoft Intune helps keep your organization’s resources protected and allows you to block devices that aren’t compliant with your organization’s policies.

When an MTD detects a threat or determines that a device is noncompliant the device user will see one of two types of messages indicating:

Install and activate partner app: The device needs the [MTD app] installed and activated to restore access to work or school resources. This message indicates that Intune hasn't received a signal from the [MTD app] the device, or the connection was lost.
Resolve detected threats: The [MTD app] app identified one or more threats on the device. Open the [MTD app] and follow the guidance to resolve the threats before accessing work or school resources.

In this blog, we’ll focus on troubleshooting and resolving the first scenario, where users will need to install and activate the MTD app.

Note: For help resolving threats detected by the MTD app, open the partner app directly on the device for remediation guidance.

Prerequisites

Before you begin troubleshooting, confirm that:

The user device is enrolled in Intune through the Company Portal app.
The user has access to their work or school account credentials.
The device has an active internet connection.

Restore device compliance

Have the user follow these steps to resolve the noncompliance issue and restore access to work or school resources.

Step 1: Install and activate the partner app

If the [MTD app] isn’t installed on the device:

Open the Intune Company Portal app on the device.
Go to Devices and select the device.
Install the required [MTD app] shown in the noncompliance message.
Open the [MTD app] and sign in with your work or school account.
Complete any required setup or activation steps in the app.
Wait up to 30 minutes for the device compliance status to update.

If your device remains noncompliant after 30 minutes, continue to the next step.

Step 2: Refresh the connection

If the [MTD app] is already installed and the user is signed in, the connection between the app and Intune services may need to be refreshed:

Open the [MTD app] on the device.
Sign out of the work or school account.
Sign back in with the same work or school account.
Wait up to 30 minutes for the device compliance status to update.

If the device remains noncompliant after 30 minutes, continue to the next step.

Step 3: Reinstall the MTD app

If refreshing the connection doesn't resolve the issue, reinstalling the app can restore the signal between services:

Uninstall the [MTD app] from the device.
Restart the device.
Open the Company Portal app on the device.
Reinstall the [MTD app].
Open the app and sign in with the work or school account.
Complete any required setup or activation steps.
Wait up to 30 minutes for the device compliance status to update.

Check device compliance status

Users can verify their device's compliance status at any time:

Open the Company Portal app.
Go to Devices.
Select the device to view its current status.

If the device shows as compliant, they can access work or school resources. If it shows as noncompliant and they’ve taken steps to resolve, wait a few more minutes and check again, as compliance status updates can take up to 30 minutes to appear in the Company Portal app.

iOS/iPadOS: Enable simplified remediation for users

Admins can configure a simplified remediation experience on iOS and iPadOS to help end‑users return to a compliant state more easily. This experience streamlines how users address Mobile Threat Defense (MTD)–related noncompliance and reduces the number of steps required to restore access.

To enable this experience:

Follow the guidance in Simplifying compliance remediation with Microsoft Intune and Defender on iOS/iPadOS to configure the updated remediation workflow for your organization.
Once enabled, end‑users will see clearer guidance within the Microsoft Defender app when their device is marked noncompliant.
The Defender app will direct users through the necessary remediation steps automatically - such as re‑authentication, resolving threat signals, or re‑establishing the MTD connection.
After the guided process is complete, Defender will send updated device status to Intune so the device can return to a compliant state.

This simplified flow reduces support overhead and increases user success resolving MTD‑related compliance issues on iOS/iPadOS.

Android: Refresh the MTD connection when sign‑out is blocked

If the user is on an Android device, first have them try signing out of the Mobile Threat Defense (MTD) app and signing back in. This often re‑establishes the connection and allows Intune to receive updated device status.

If the option to sign out of the MTD app is blocked by IT policy, follow these steps to reset the app’s data instead:

Long‑press the Defender app in the work profile.
Tap ⓘ App info.
Go to Storage & cache → Clear data (do not select Clear cache).
Relaunch the Defender app - it will open to the welcome screen.
Sign back in with the work or school account.

Once signed back in, Defender will update Intune with the latest device data, and the device should return to a compliant state after Intune receives the refreshed signals.

Windows: Verify that Microsoft Defender for Endpoint is onboarded

For Windows devices, noncompliance with Defender for Endpoint is commonly caused by devices that are no longer properly onboarded or connected to the service. When a device is not onboarded, it can’t report risk signals, which may result in the device being marked as noncompliant in Intune.

Recommended action:

If you identify Windows devices showing as noncompliant due to missing or stale Defender for Endpoint signals:

Verify that the device is onboarded to Microsoft Defender for Endpoint
Review your existing onboarding policies in Intune
Onboard affected devices using Intune if needed

Once properly onboarded, the device can participate in compliance evaluation. If devices continue to appear noncompliant after verifying onboarding and policy assignment, we recommend opening a support case for further investigation.

To learn more about onboarding devices refer to the documentation:

If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!

Post updates:
02/05/26: Added two new sections covering simplified user remediation on iOS/iPadOS and refreshing the MTD connection on Android when sign-out is blocked.

05/06/26: Added a new section covering Windows devices that may be noncompliant due to not being properly onboarded to Microsoft Defender for Endpoint.

Intune my Macs: Accelerating macOS proof of concepts with Microsoft Intune

Intune_Support_Team — Mon, 30 Mar 2026 23:01:38 GMT

By: Neil Johnson and Chris Kunze - Principal Product Managers | Microsoft Intune

Intune provides a broad and mature set of capabilities for managing macOS devices across security, compliance, applications, and user onboarding. Many customers, however, aren’t always aware of just how much functionality is available or how to bring it all together. We've developed a starter kit to make it easy to explore and set up macOS configurations in Intune: Intune my Macs. Intune my Macs helps bridge that gap by making it easy to explore some recommended macOS configurations and quickly set up a successful proof of concept using Intune.

What is Intune my Macs?

Intune my Macs is an open-source project from the Microsoft Intune Customer Experience Engineering team that allows you to deploy a complete macOS proof of concept in minutes. This starter kit brings together over 31 enterprise-grade configurations - identified by Apple’s Mac Evaluation Utility - along with policies, scripts, and applications, all of which can be deployed using a single PowerShell script.

The project operates in dry-run mode by default, letting you preview exactly what will be created before committing any changes to your Intune tenant. When you're ready, simply add the --apply flag to the command-line to commit changes.

Important: From a support perspective, Microsoft fully supports Intune and its ability to deploy PowerShell scripts. However, Microsoft does not support the scripts themselves, even if they are on our GitHub repository. They’re provided for example only. You are responsible for anything that they may do within your environment. Always test!

See it in action

Want a quick walkthrough before you dive in? Watch the video below to see a deep-dive on Intune my Macs - from authentication to policy creation, app deployment, and beyond.

Why would you use it?

1. Jumpstart your macOS management

Instead of building macOS configurations from scratch, Intune my Macs provides a ready-to-use baseline of production quality Intune artifacts. These configurations are designed to help you quickly evaluate Microsoft Intune for macOS management while also serving as reference implementations you can adapt to your environment.

Below is an overview of what Intune my Macs deploys into your tenant, organized by category.

Category	Example configurations
Security	FileVault configuration, firewall enablement, Gatekeeper policies, Microsoft Edge policies
Compliance	Minimum macOS version (15.0), SIP enforcement, encryption requirements
Identity	Platform SSO via Secure Enclave with Microsoft Entra ID
Applications	Intune Company Portal, Microsoft 365, Remote Help, Intune Log Watch, Microsoft 365 Copilot, Windows App, and Edge
Scripts	Dock customization, FileVault key escrow (Escrow Buddy), onboarding automation
Custom Attributes	Hardware compatibility checks, Intune agent version reporting

2. Learn by example

Each configuration in the repository serves as a practical reference implementation. The naming conventions follow a consistent pattern (for example, pol-sec-001-filevault, scr-app-100-install-company-portal), and detailed documentation explains what each setting does and why it's configured that way.

3. Reduce time to value

Tasks that typically require extensive research, configuration, and testing can now be completed in just about 5 minutes, thanks to this streamlined approach. The script handles:

Microsoft Graph SDK authentication
Policy creation via Intune settings catalog and custom configuration profiles
Script deployment with proper execution settings
PKG application uploads
Optional group assignments
Optional Microsoft Defender for Endpoint integration

If you're evaluating Microsoft Defender for Endpoint on macOS, the project includes an optional --mde command-line flag that deploys the full Defender for Endpoint configuration, including system extensions, privacy preferences, network filter settings, and a script that can be used to install the client.

How it works

This starter kit is driven by XML manifest files that define each configuration artifact. The main PowerShell script reads these manifests, resolves the associated JSON/mobileconfig/script files, and creates the corresponding objects in Intune via the Microsoft Graph API.

You can scope this starter kit to specific artifact types using command-line flags like --apps, --config, --compliance, --scripts, or --custom-attributes. A custom naming prefix defined using the –prefix command-line flag) keeps your deployed objects easily identifiable, and the --remove-all command-line flag provides a clean way, based on the custom naming prefix, to delete everything created by an earlier run.

For more information on how to use this project, be sure to review the prerequisites and instruction in the readme file.

Bonus: Utility tools

The project also includes several analysis and documentation tools:

Export-MacOSConfigPolicies.ps1 - Back up existing Intune macOS policies to JSON

Find-DuplicatePayloadSettings.ps1 - Detect conflicting settings across all your Mac configuration files

Generate-ConfigurationDocumentation.py - Create Markdown or Word documentation from the manifests

Get-IntuneAgentProcessingOrder.ps1 - Understand script and app processing sequence

Get-MacOSGlobalAssignments.ps1 - List Mac policies assigned to All Devices or All Users

Summary

Intune my Macs isn't meant to be a one-size-fits-all production starter kit, but it’s a great way to get started. Use it to quickly implement a proof of concept, learn from the configuration patterns, and adapt the policies to your organization's specific requirements.

Whether you're evaluating Intune for macOS management, setting up a new tenant, or just looking for reference implementations of common security configurations, this project can save you significant time and effort.

Resources

GitHub Repository

Full Configuration Documentation

Microsoft Defender for Endpoint Setup

If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!

Post Updates
03/30/26: A video walkthrough has been added above. Watch to see Intune my Macs deploy a complete macOS proof of concept in minutes.

Debunking the myth: Cloud-native Windows devices and access to on-premises resources

Intune_Support_Team — Sat, 15 Nov 2025 00:05:54 GMT

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!

Support tip: Aligning network policy with Microsoft Intune and Zero Trust

Intune_Support_Team — Sat, 08 Nov 2025 01:04:31 GMT

By: Jon Callahan – Sr Product Manager | Microsoft Intune

Cloud services don’t just rely on the network. They redefine it. As organizations adopt Microsoft Intune and advance their Zero Trust strategies, many discover that traditional, perimeter-based architectures no longer align with modern security expectations or the connectivity needs of a distributed workforce.

Zero Trust is built on the principle of "never trust, always verify,” where access decisions are enforced through identity, device health, and compliance signals. Microsoft Intune strengthens this model by extending security and management through the cloud. By removing dependencies on on-premises infrastructure, it strengthens network resilience and Zero Trust enforcement with policy-driven device management and secure connectivity to Microsoft endpoints.

This is where friction occurs. Traditional enterprise networks were built around a castle-and-moat model of perimeter defense: build high walls around the perimeter and trust everything inside, rather than identity-based access. Centralized egress points, VPNs, proxy servers, and deep packet or TLS inspection worked well when apps, data, and users stayed inside the moat.

Today, work and data are everywhere. Legacy network designs often force traffic into hairpinned routes (indirect paths through central gateways) that add latency, reduce performance, and increase management overhead for Intune, Microsoft 365, and other SaaS apps.

The challenge deepens when network teams try to maintain allow lists for cloud services using static IP addresses. Microsoft’s endpoint IPs can change frequently, especially with CDN-backed services like Intune and Microsoft 365, to strengthen security, improve resilience, and scale globally. This is why Microsoft recommends domain-based egress policies, frequent updates based on the published endpoint lists, and bypassing SSL inspection for Microsoft-bound traffic that doesn’t support inspection.

Enabling cloud services

The shift to hybrid work environments shows the limits of perimeter-based networks. Users expect fast and reliable access to their apps and data whether at home, in the office, or on the go.

To support this shift, organizations need to modernize their network architecture and policies. Local internet egress and optimized paths to trusted services like Intune are essential. Policies built on Zero Trust and cloud-native principles help ensure performance and security. In contrast, controls such as VPN-only access, TLS inspection, or centralized proxies often slow users down and block required endpoints.

When networks get in the way, the impact is noticed:

Device check-ins and compliance evaluations fail, leaving devices marked as non-compliant
Enrollments stall or time out
Apps download slowly, fail to update, or never install

When these failures occur, users often blame Intune or their IT admins, even when the real issue is network policies.

In a Zero Trust model, network policy works alongside identity and device-based signals to enforce access decisions. Network policy should enable cloud services, not obstruct them. Adopting cloud-native connectivity and Zero Trust enforcement protects users, devices, and data while improving reliability and user experience.

This approach aligns with Microsoft’s Secure Future Initiative (SFI) and the principle of “Secure by Design,” which extend Zero Trust principles into the foundation of how services are built and operated. As part of this effort, Intune service endpoints are moving to Azure Front Door to enhance security, reliability, and performance while simplifying firewall management across Microsoft services. For details on required IP addresses and endpoints, see Support tip: Upcoming Microsoft Intune network changes.

Outbound traffic management

Aligning network policies with Zero Trust and cloud-native architecture can require trade-offs. Outbound traffic management is critical for Intune’s performance, but organizations differ in their compliance needs and tolerance for complexity. Below are three common models we see with our customers.

Endpoint enforced access

This model eliminates perimeter bottlenecks by moving enforcement closer to the user, device, and apps, which is the core of Zero Trust. Enforcement happens at the endpoint through identity, compliance, and device health signals, while the network provides fast, direct internet access with minimal restrictive filtering.

Best for: Organizations ready to adopt a Zero Trust network architecture built on Intune and identity-driven signals, or those with minimal outbound filtering requirements.

How to implement:

Policy-based enforcement and compliance: Intune enforces and validates device health and measures device compliance and app protection policies for Microsoft Entra Conditional Access
Identity-driven enforcement: Microsoft Entra Conditional Access evaluates signals such as user identity, device compliance, and risk level before granting access to cloud resources
Threat protection: Microsoft Defender for Endpoint monitors device risk and blocks compromised endpoints from accessing cloud resources; enforce the built-in firewall on Windows and macOS devices
Bypass traffic inspection: Don’t decrypt or inspect Intune and related Microsoft traffic using technologies like proxies, TLS inspection, deep packet inspection, or data loss prevention systems
Use split-tunnel VPN and local internet egress: Route Intune and Microsoft 365 traffic locally to avoid unnecessary hairpinning

Benefits:

Establishes Zero Trust controls with identity, device, and threat-based enforcement
Local internet egress and optimized paths to Intune and Microsoft 365 avoid latency and centralized paths
No allow list or complex firewall rules to manage
Avoids VPN, proxies, and TLS inspections and reduces the risk of interfering with user experience and device management failures

This model requires strong endpoint management and identity controls to ensure Zero Trust enforcement.

Domain enforced filtering

When endpoint-only enforcement doesn’t meet your organization's requirements, Fully Qualified Domain Name (FQDN) filtering offers a middle ground by adding network controls while staying adaptable to dynamic cloud services. This approach should be paired with endpoint enforcement to maintain a Zero Trust architecture.

Best for: Organizations that need outbound restrictions for compliance, while maintaining reliability and flexibility in cloud services.

How to implement:

Use domain-based rules: Filter traffic by FQDN rules that rely on DNS to adapt to changing IP addresses and CDN-backed services.
Leverage automation: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date.
Bypass traffic inspection for trusted services: Avoid decrypting or inspecting Intune traffic, which can break certificate pinning and cause service failures.
Resolve locally: Use local DNS and Internet egress so devices connect to the closest Microsoft endpoint.

Benefits:

Builds on endpoint enforced Zero Trust controls
Easier maintenance than IP-based filtering
Automatically adapts to Microsoft's dynamic, cloud-hosted services
Reduces service disruptions when automated
Aligns with most regulatory and compliance frameworks

This model requires more robust network automation and may introduce additional processing overhead compared to endpoint-enforced access.

Domain and IP enforced filtering

This model combines FQDN-based rules with IP filtering for the strictest assurance. It provides maximum control but introduces the most overhead. Like domain enforced filtering, this too should be combined with endpoint enforcement to maintain a Zero Trust posture.

Best for: Organizations in highly regulated industries that require dual enforcement with domains and IPs to meet strict audit and assurance needs.

How to implement for Intune:

Combine domain with IP rules: Use FQDN alongside IP address ranges to filter traffic.
Automate aggressively: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date.
Bypass traffic inspection for trusted services: Exclude certificate-pinned services from TLS inspection to avoid breaking Intune functionality.
Optimize performance: Architect your network to use local DNS and internet egress so devices connect to the closest Microsoft endpoint.

Benefits:

Builds on Zero Trust with the strictest network controls
Provides dual verification for outbound traffic
Helps satisfy strict regulatory and compliance requirements

This model introduces the highest administrative overhead and complexity to maintain. It’s also the most likely to cause performance issues and service disruptions if not properly automated. However, for organizations with strict regulatory requirements, these trade-offs may be necessary to meet compliance obligations.

Extending with cloud-first controls

While traditional network models address outbound traffic at the infrastructure layer, a Zero Trust approach uses cloud-native security tools that eliminate many of these challenges. Issues like hairpinning, brittle IP allow lists, TLS inspection conflicts, and complex firewall rules stem from applying perimeter-era tools to cloud-based services. Cloud-first network and security tools reduce friction and strengthen Zero Trust.

Cloud-delivered secure web gateway (SWG): Provides secure access to internet and SaaS apps while protecting against internet threats, building on the capabilities of traditional proxies (Microsoft Entra Internet Access)
Zero Trust Network Access (ZTNA): Connects users securely from any device and any network without relying on VPNs or central tunneling (Microsoft Entra Private Access)
Data loss prevention (DLP): Protects sensitive information across endpoints, Microsoft 365 apps, SaaS services, browsers, and on-premises file shares, with classification and policy enforcement (Microsoft Purview DLP)
Cloud access security broker (CASB): Provides SaaS discovery, session control, and real-time policy enforcement (Microsoft Defender for Cloud Apps)

Managing outbound traffic for cloud services is about more than connectivity. It’s about aligning network policies so they enable cloud services and embrace Zero Trust principles like identity, device health, and compliance signals over legacy perimeter defenses. Microsoft Intune supports through policy-driven device management and security that reinforce Zero Trust and cloud-native adoption. The result is an architecture that secures your environment and delivers the reliability and user experience needed for today’s hybrid work.

Resources

As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam!

Post updates:
11/06/25: Updated URLs for Automation category (see Domain-Enforced Filtering section).

From the frontlines: Empowering call center agents with Windows 365 Frontline

Intune_Support_Team — Thu, 20 Nov 2025 00:53:25 GMT

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.

Simplifying compliance remediation with Microsoft Intune and Defender on iOS/iPadOS

Intune_Support_Team — Thu, 30 Oct 2025 17:49:50 GMT

By: Harish S | Sr. Product Manager - Microsoft Defender & Rishita Sarin | Product Manager 2 - Microsoft Intune

One tap to compliance: Introducing the Resolve workflow for Compliance Remediation in Microsoft Intune and Microsoft Defender on iOS.

We’re thrilled to announce a major step forward in simplifying the compliance remediation experience for users and IT admins alike. As part of a collaboration between Microsoft Intune and Microsoft Defender, we’re introducing a new compliance remediation workflow, which uses a Resolve button to make it easier than ever for users to bring their mobile device back into compliance.

Why this matters

Traditionally, when a user’s device was marked noncompliant due to missing security apps like Microsoft Defender, they had to navigate through multiple apps, follow multi-step instructions, and often re-authenticate – often to resolve a single issue. This created friction, confusion, and delays in regaining access to corporate resources.

With the new end-to-end remediation workflow triggered by the Resolve button, we’re eliminating those extra steps.

What’s news

Starting with the latest releases in Intune and Defender, users on iOS and iPadOS will have a Resolve button directly within Microsoft 365 productivity apps (such as Microsoft Outlook or Teams) when their device is non-compliant due to Defender-related requirements. This button:

Detects the non-compliance reason.
Launches or installs Microsoft Defender if it’s missing.
Automatically re-evaluates compliance requirements once Defender is running.
Returns the user to their app – no switching, no guesswork.

This is powered by just-in-time (JIT) registration and compliance remediation which embeds the compliance flow directly into the app experience.

Microsoft Defender experience: Guided, automated, and frictionless return to compliance

The Resolve button is more than just a shortcut, it’s the entry point to a guided remediation workflow powered by Defender. Once launched:

Defender auto-triggers a guided workflow that remediates issues with minimal or no user interaction.
A checklist guides the user through necessary steps to return to compliance, ensuring clarity and confidence on common scenarios such as authentication issues, missing permissions, device registration issues, remediate active threats, and more.
Upon completion, Defender updates the compliance state of the device.
The user is automatically redirected back to the productivity app they started from with no manual navigation required.

This seamless handoff between Intune and Defender ensures that users stay focused on their work, not on troubleshooting.

Conclusion

Effortless for users, efficient for admins.

If you already use JIT registration and compliance remediation in Intune for enrolled iOS devices, the Resolve button is automatically enabled for supported scenarios. If not, consider setting up JIT now to experience the new compliance remediation experience, it’s simple to configure and significantly improves user experience and support efficiency. Refer to the following documentation for more information:

If you have any questions, leave a comment on this post or reach out on X @IntuneSuppTeam.

Microsoft Intune Settings Catalog Updated to Support New Windows 11, version 25H2 Settings

Intune_Support_Team — Fri, 24 Oct 2025 17:12:19 GMT

By Mayur Jahdav, Product Manager | Microsoft Intune

With the recent release of Windows 11, version 25H2, Microsoft Intune delivered support for 36 new 25H2 settings. IT admins can confidently manage devices running the latest Windows OS version from the moment they deploy it in their environment for testing or production use.

We continue to invest in the settings catalog infrastructure to ensure timely support for new Windows policy settings. This enables organizations to adopt new OS versions and features without delay and maintain secure, compliant, and well-managed environments.

New settings in the settings catalog

As part of our day zero support for Windows 11, version 25H2, the settings catalog includes the newly released Windows 11, version 25H2 settings. The following table lists newly added settings that are now available for configuration using the settings catalog and are ready for use in device configuration profiles to manage Windows endpoints.

Category Name	Name	Friendly Name
Administrative Templates\Windows Components\App Package Deployment	RemoveDefaultMicrosoftStorePackages	Remove Default Microsoft Store packages from the system.
Administrative Templates\Windows Components\Sync your settings	EnableWindowsBackup	Enable Windows Backup
Auditing	AccountLogonLogoff_AuditGroupMembership	Account Logon Logoff Audit Group Membership
Human Presence	ForceOnlookerDetectionAction	Force Onlooker Detection Action
Human Presence	ForceOnlookerDetection	Force Onlooker Detection
Microsoft App Store	ConfigureMSIXAuthenticationAuthorizedDomains	Configure MSIX Authentication Authorized Domains
News And Interests	DisableWidgetsBoard	Disable Widgets Board
News And Interests	DisableWidgetsOnLockScreen	Disable Widgets On Lock Screen
Power	EnableEnergySaver	Enable Energy Saver
Printers	RequireIppsPolicy	Require Ipps Policy
Privacy	LetAppsAccessSystemAIModels	Let Apps Access System AI Models
Start	TurnOffAbbreviatedDateTimeFormat	Turn Off Abbreviated Date Time Format (User)
Start	HideCategoryView	Hide Category View (User)
Start	ConfigureStartPins	Configure Start Pins (User)
Start	AlwaysShowNotificationIcon	Always Show Notification Icon (User)
Start	ConfigureStartPins	Configure Start Pins
Start	HideCategoryView	Hide Category View
System	AllowOOBEUpdates	Allow OOBE Updates
Windows AI	SetMaximumStorageSpaceForRecallSnapshots	Set Maximum Storage Space For Recall Snapshots
Windows AI	DisableSettingsAgent	Disable Settings Agent
Windows AI	AllowRecallEnablement	Allow Recall Enablement
Windows AI	SetDenyAppListForRecall	Set Deny App List For Recall (User)
Windows AI	DisableClickToDo	Disable Click To Do (User)
Windows AI	SetCopilotHardwareKey	Set Copilot Hardware Key (User)
Windows AI	SetDenyAppListForRecall	Set Deny App List For Recall
Windows AI	DisableImageCreator	Disable Image Creator
Windows AI	DisableCocreator	Disable Cocreator
Windows AI	SetMaximumStorageSpaceForRecallSnapshots	Set Maximum Storage Space For Recall Snapshots (User)
Windows AI	DisableClickToDo	Disable Click To Do
Windows AI	SetDenyUriListForRecall	Set Deny Uri List For Recall (User)
Windows AI	DisableGenerativeFill	Disable Generative Fill
Windows AI	SetDenyUriListForRecall	Set Deny Uri List For Recall
Display	ConfigureMultipleDisplayMode	Configure Multiple Display Mode (User)
Windows Backup And Restore	EnableWindowsRestore	Enable Windows Restore

As Windows evolves and releases features through future feature updates as well as continuous innovation, we’ll continue to review newly added or updated settings to includ in the Intune settings catalog. These may include new controls for security, privacy, user experience, and device management. Be sure to check What's new in Microsoft Intune regularly for additional settings as we add them and check out Create a policy using settings catalog in Microsoft Intune for guidance on how to configure and assign settings to your managed devices.

If you have questions or feedback, please leave a comment on this post or reach out to the Intune support team on X @IntuneSuppTeam.

Post updates:
10/23/25: The Settings Catalog table has been updated. Settings that were previously limited to 'Windows Insider users' are now generally available.

Setting	Value
User affinity	Enroll with User Affinity
Authentication	Setup Assistant with modern authentication
Await final configuration	Yes
Locked enrollment	Yes