Unpacking Endpoint Management: Episodes Available On Demand
Over the course of the Unpacking Endpoint Management series, we brought together experts from across Microsoft Intune, Security, and Customer Experience teams to share practical strategies, lessons learned, and honest conversations about modern endpoint management. While the series has now concluded, the insights remain as relevant as ever. We invite you to explore past episodes on demand and continue connecting with the Intune community through Tech Community, Microsoft Learn, and future opportunities to engage with Microsoft experts. A quick update on the hosts Danny Guillory, a familiar face to the community and a Product Manager for Intune and Configuration Manager, hosted the series alongside Rachelle Blanchard. Together, they brought a strong mix of technical expertise, community engagement, and customer perspective to each episode. Rachelle helped surface real customer questions and guide conversations toward practical outcomes, ensuring each discussion reflected how endpoint management works in the real world. Thank you to everyone who participated Thank you to everyone who participated in Unpacking Endpoint Management and helped shape the conversations throughout the series. Catch up on demand You may have missed them, but you don't have to miss out on the learnings. Watch and learn when it's convenient for you. Policy: from hybrid to cloud-native Device security with Microsoft Intune Trends in endpoint management (live from Tech Takeoff 2026) Not sure where to start? Watch our most recent episode, App management at scale with Intune, now on demand! Watch on demand All episodes of Unpacking Endpoint Management are now available on demand via: aka.ms/JoinUEM. The series brought together experts from across Microsoft Intune, Security, and Customer Experience teams to share practical guidance, lessons learned, and real-world experiences from endpoint management. Continue the conversation While Unpacking Endpoint Management has concluded, there are many ways to stay connected with the Intune team and broader community. Join the Microsoft Intune Community here on Tech Community, and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to engage with experts, discover new content, and stay informed about the latest Intune guidance, best practices, and innovations. A Note from the Team Thank you for being part of the series. We're incredibly grateful to our customers, IT professionals, community members, guest speakers, and Microsoft experts who helped make Unpacking Endpoint Management such a valuable experience. Your questions, feedback, and real-world insights shaped every conversation and helped create meaningful discussions for the broader endpoint management community. Although the series has come to a close, our commitment to listening, learning, and engaging with our community remains unchanged. We look forward to continuing those conversations through the Microsoft Intune Community, Tech Community blogs, Microsoft Learn, events, and future opportunities to connect with Intune product, engineering, and customer success teams. 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/JoinIntuneCommunityConfigure Delivery Optimization for Windows to save bandwidth and speed up deployments
By: Carlos Diaz - Sr. Product Manager and Jason Sandys - Principal Product Manager | Microsoft Intune Delivery Optimization is built into Windows and can help reduce bandwidth usage during app and update deployments. Instead of downloading content from the internet every time, devices can download it from nearby devices or a local cache when available. Many organizations leave Delivery Optimization at its default settings or disable it entirely. As a result, they may miss opportunities to reduce network traffic, improve deployment performance, and make better use of existing network resources. This article focuses on the Delivery Optimization scenarios and the common configurations that Intune admins use most often: large-scale patching, Windows Autopilot provisioning, branch office bandwidth management, and Microsoft Connected Cache for scenarios where peer-to-peer sharing alone isn't enough. How Delivery Optimization works Delivery Optimization is an HTTP downloader with built-in peer-to-peer capabilities available in supported versions of Windows. It helps distribute Windows updates, Microsoft 365 Apps updates, Microsoft Defender definition updates, Microsoft Store apps, Intune Win32 apps package and other supported content. Delivery Optimization checks local sources before falling back to internet content caches. The most important Delivery Optimization policy setting is Download Mode, which determines how devices discover peers. Mode Description Mode 1 (LAN) Devices share content with peers behind the same IP/NAT boundary. Mode 2 (Group) Devices share content within a defined group, such as an Active Directory site, domain, or custom group ID. Recommended for environments with multiple VLANs or segmented networks. Mode 3 (Internet) Devices can share content with internet peers outside the organization. This mode is rarely used in enterprise environments. Delivery Optimization checks sources in this order: LAN or group peers and, if configured, Microsoft Connected Cache in parallel. Internet peers, if allowed in the Download Mode setting Internet content caches, which are always available as the final fallback Regardless of the mode you choose, the goal is to keep content download traffic local whenever possible. Common misconceptions Before configuring Delivery Optimization, it's worth addressing a few common misunderstandings we’ve heard from customers. "Does Delivery Optimization use my bandwidth to upload content to the internet?" In Mode 1 (LAN), peer sharing is restricted to your local subnet. Content is only shared with other devices on the same network segment, and no content leaves your LAN. Additionally, you have full control over upload usage through the Monthly upload data cap setting. "Is Delivery Optimization the same as BranchCache?" While both technologies help reduce bandwidth usage, they are built on different architectures and support different scenarios. BranchCache relies on BranchCache-enabled content servers to cache and distribute content, whereas Delivery Optimization is built directly into Windows and is designed to work natively with cloud-delivered content, including Windows updates, Microsoft Store apps, and Microsoft 365 Apps. "We disabled Delivery Optimization years ago. Is there any reason to revisit it?" Yes. Delivery Optimization has evolved significantly and now offers extensive management capabilities through the Intune Settings Catalog. Administrators can configure download modes, define group boundaries, control bandwidth usage, set cache sizes, and limit uploads. If Delivery Optimization was disabled in the past, it may be worth reevaluating your configuration. When properly configured, it can help reduce bandwidth consumption, improve content distribution efficiency, and accelerate update and application deployments. Essential policies The following settings, available in the settings catalog under Delivery Optimization, provide you a strong starting point: Setting Default Value* Recommended Value What It Does DODownloadMode 1 (LAN) 1 (LAN) Keeps peer-to-peer sharing within your subnet or Delivery Optimization group. DORestrictPeerSelectionBy 1 1 Devices discover and peer with others on the same subnet. DOMaxCacheSize 20% 20% to 30% Amount of local disk space allocated to the Delivery Optimization cache. DOMinFileSizeToCache 50 MB 5 MB Minimum file size eligible for caching and peer-to-peer distribution. DOMaxCacheAge 259,200 seconds (3 days) 1,209,600 seconds (14 days) Determines how long cached content remains available before cleanup. DOMonthlyUploadDataCap 20 GB 20 GB Limits the total amount of data a device can upload to peers each month. *The default values in this table are for Windows 11. The table above lists common Delivery Optimization settings, their default values, and recommended starting values. However, the best configuration depends on your network topology, device count, update cadence, and whether you’re using Microsoft Connected Cache. Use the scenario guidance below to tune from the baseline. for the full policy reference review: Configure Delivery Optimization (DO) for Windows. The defaults provide some immediate value, but organizations often achieve better results by: Defining peer groups Increasing cache size Increasing retention periods Lowering the minimum file-size threshold when appropriate When configuring Delivery Optimization, avoid managing the same setting from multiple locations, such as settings catalog and custom policy. Using the settings catalog as your primary management location can help reduce conflicts and simplify troubleshooting. Windows quality updates, feature updates, and Office updates are typically the largest bandwidth consuming events most organizations face. A 1 GB cumulative update pushed to 10,000 devices means 10 TB of traffic from the internet unless Delivery Optimization lets devices share locally. This is where properly configured Delivery Optimization pays for itself immediately. Coordinate Delivery Optimization with deployment rings. Start with a small seeder ring, typically 5 to 10 percent of devices, so those devices populate peer caches before broader rings begin hours or days later. If Microsoft Connected Cache is deployed, the same seeder ring also populates the cache node, creating a persistent local source for later rings. Scenario 1. Large-scale update deployments Large scale deployments vary greatly in complexity and challenges. Device count isn’t the only factor to consider. Network infrastructure and configuration can also play a role in your configuration and deployment of Delivery Optimization. How you tune Delivery Optimization for large-scale updates depends heavily on your WAN topology. The two most common designs call for different approaches: Star (hub-and-spoke) topology Branches connect to a central hub; internet traffic may be backhauled. Every update byte a branch device pulls from the internet crosses the internal link between the hub and spoke. Group boundaries: Identify local LAN configurations at branch locations. If all devices at a branch location are on a single subnet, use DODownloadMode = 1 with DORestrictPeerSelectionBy=1 to restrict peers to that subnet. If a branch site has multiple subnets, DODownloadMode = 2 with a branch-specific DOGroupID is more effective because devices can discover peers throughout the branch instead of being limited to their local subnet. Tip: Delivery Optimization Has Evolved Many organizations disabled Delivery Optimization during early Windows 10 deployments after experiencing unexpected WAN traffic. At that time, peer sharing controls were far less granular, making it difficult to limit content sharing to devices within the same network or site. As a result, some organizations chose to disable Delivery Optimization entirely and missed potential bandwidth savings from peer-to-peer content distribution. Today, modern Delivery Optimization policies provide significantly more control through features such as Group mode, Group IDs, subnet-based peer restrictions, bandwidth management settings, and integration with Microsoft Connected Cache. These capabilities help organizations realize the benefits of peer caching while maintaining tighter control over network traffic. Bandwidth throttling: Spoke links are often the bottleneck. Use DOPercentageMaxBackgroundBandwidth to limit Delivery Optimization background downloads to 10% to 25% of available bandwidth during business hours. Configure DOSetHoursToLimitBackgroundDownloadBandwidth to define the hours when those limits apply, then relax or remove the limits outside business hours. Cache retention: Set DOMaxCacheSize to 40% to 50% and DOMaxCacheAge to match your final deployment ring so cached content survives all ring phase days at branches. Branch peers are the only local sources. They need to hold content long enough for the full ring cycle. Hub site: Devices at the hub have direct internet access and also typically have more bandwidth available. Standard cache settings (20% to 30%, 3 days) are usually sufficient. Tip: Combine Peer Caching and Microsoft Connected Cache In star (hub-and-spoke) network topologies, Microsoft Connected Cache (MCC) can deliver the greatest bandwidth savings at central hubs and larger branch offices. By caching frequently requested updates and applications locally, MCC helps reduce the amount of content that must traverse upstream WAN links. You can configure an MCC server directly in your Delivery Optimization policy by specifying: DOCacheHost=<MCC FQDN> When configured, Delivery Optimization continues to prioritize content from nearby peers. If the requested content isn't available from peers, devices will attempt to download it from Microsoft Connected Cache. If the content isn't present in the cache, devices automatically fall back to Microsoft's internet content source. Think of the content retrieval process as a layered approach: Peers → Microsoft Connected Cache → Internet. This hierarchy helps optimize bandwidth usage while maintaining reliable access to updates and applications. Distributed topology With a distributed topology, all locations have their own local internet access. Each site reaches the internet directly, so the WAN penalty for a cache miss is lower. Group boundaries: Set DODownloadMode=2 and set a DOGroupID. The key is that each physical site is its own peer group. DORestrictPeerSelectionBy = 1 (Subnet) is still recommended but less critical because cross-site peer-to-peer traffic is less likely. Bandwidth limits: More relaxed than star. 25% to 50% during business hours is typical since each site has its own internet cache path. Tip: With local internet connectivity and Delivery Optimization Group mode, many locations achieve excellent bandwidth savings with no additional infrastructure. Microsoft Connected Cache adds value primarily at the largest locations (more than 100 devices). Scenario 2. Branch offices with limited WAN Branch offices often see the biggest Delivery Optimization savings. Instead of every device pulling the same update over the WAN, one device can download from the internet and share locally with peers on the subnet. Use DODownloadMode = 2 and assign a unique DOGroupID per branch location to keep peer-to-peer traffic within the branch. Set aggressive background limits (15% to 25% of link speed) to protect line-of-business applications. For very small branches with fewer than 10 devices, or locations where devices are frequently reimaged, consider adding a Microsoft Connected Cache node. A small cache server with a 100 GB drive provides a persistent local source that doesn't depend on any single peer being online. Scenario 3. Mass provisioning and Windows Autopilot During Windows Autopilot bulk provisioning or mass reimaging, many devices request identical content at the same time. Without Delivery Optimization, every device downloads independently from the internet cache, often saturating internet links and extending provisioning times. For environments with repeated content consumption, such as shared devices, labs, and kiosks that get reimaged frequently, peer-to-peer distribution has a structural limitation. After a mass reimage, no device has cached content available to share. This is where Microsoft Connected Cache provides the greatest value. Because the cache node retains content on-premises independent of device state, the first device after a wipe can download from the local cache rather than the internet cache. If you're using peer-to-peer alone, consider staggering reimage schedules so that some devices always have content available to share. Intune already uses Delivery Optimization to distribute Win32 and Microsoft Store apps, so no extra setup is needed beyond the core Delivery Optimization policies. The main tuning is around thresholds and retention. Lower DOMinFileSizeToCache from 10 MB to 5 MB so snaller app installers qualify for peer-to-peer sharing and extend DOMaxCacheAge to 7 days (604800 seconds) to accommodate app deployments that often span a full week. During large provisioning events, be generous with cache resources. Increase DOMaxCacheSize to 50 percent or higher to ensure early devices have room to cache and share content. Set DOMonthlyUploadDataCap to 0 (unlimited) so the first-wave of devices can serve a larger number of peers. Finally, provision devices in stages whenever possible. Even a 15-minute delay between groups gives Delivery Optimization time to build peer availability before the next wave starts. Scenario 4. Devices that move between locations In environments where employees frequently move between locations, isolating peer traffic can be challenging. For example, a device assigned to the Group ID for Branch A may be physically connected at Branch B, causing it to search for peers across the WAN. In this scenario, use DHCP to provide the appropriate DOGroupID and, when applicable, DOCacheHost source for the device’s current location. DOCacheHostSource=1 and set the DHCP Option 235 at the site to the FQDN of the Microsoft Connected Cache. DOGroupIdSource=3 and set the DHCP Option 234 to the GUID for the GroupID. Go further with Microsoft Connected Cache Microsoft Connected Cache is an optional on-premises content cache. It complements Delivery Optimization by providing a persistent local source when peers are unavailable. Tip: Start with Peer-to-Peer Caching First Before deploying Microsoft Connected Cache (MCC), consider optimizing Delivery Optimization peer-to-peer caching. Many organizations achieve substantial bandwidth savings through properly configured download modes, peer groups, cache settings, and deployment rings without introducing additional infrastructure. Peer-to-peer caching is often the simplest and most cost-effective first step because devices can share content directly with one another, reducing internet downloads and WAN utilization across the organization. Microsoft Connected Cache becomes particularly valuable when peer sharing alone cannot fully meet business requirements, such as locations with few devices, frequent device reimaging, limited peer availability, or a need for a persistent on-premises content source. In these scenarios, MCC can complement Delivery Optimization to further reduce bandwidth consumption and improve content availability. Microsoft Connected Cache is most valuable at small locations with few peers, in environments with frequent device resets, or anywhere large content volumes need a guaranteed local source. Devices can find the cache node in two ways: Static (Intune policy): Set DOCacheHost to the FQDN of your Microsoft Connected Cache server in the Intune Settings catalog. Simple, static, works well for single-site deployments. Dynamic (DHCP Option 235): Set DOCacheHostSource = 1 and configure DHCP Option 235 with the MCC server FQDN. Devices discover the correct cache node automatically based on network location. This is the preferred approach for multi-site deployments. When using Microsoft Connected Cache, configure DODelayForegroundDownloadFromHttp to 30 seconds and DODelayBackgroundDownloadFromHttp to 60 seconds. These timeouts control how long Delivery Optimization waits for a local source before falling back to the internet cache; they don’t control download speed. For setup details and hardware requirements, refer to: Release Notes for Microsoft Connected Cache for Enterprise and Education. Troubleshooting tips Slow downloads: The fallback timeout is the most misunderstood Delivery Optimization setting. It controls how long a device waits for a local source before requesting from the internet cache, not download speed. If downloads are slow, check network routing, DNS, and firewall rules. Cache misses: Internet cache Vary headers can prevent content from being cached on the first request. Microsoft Connected Cache respects these headers, which can cause initial cache misses. The product team is actively working on a fix. Diagnostics: Run the Delivery Optimization troubleshooter at aka.ms/DO-Fix for automated diagnostics. PowerShell: Use Get-DeliveryOptimizationStatus in PowerShell to see real-time download source, peer count, and bytes per source for each active download. Delivery Optimization reporting: Centralized reporting is available in the Windows Update for Business Delivery Optimization report or through PowerShell cmdlets. Monitor Delivery Optimization. Get started Delivery Optimization is already available on supported Windows devices you manage. The configurations in this post take minutes to deploy through the Intune settings catalog and can save significant bandwidth with every update cycle and application deployment. Start with the essential policies table, pilot the profile with a small device group, and review Windows Update for Business reports after a couple of patch cycles to measure the impact. Many organizations achieve their goals using Delivery Optimization peer-to-peer caching alone. For scenarios where peer caching is insufficient or a persistent local cache is required, Microsoft Connected Cache is available as an additional option. The product team is active in the Connected Cache Community at aka.ms/ConnectedCacheCommunity, and feature ideas can be submitted through the Intune feedback portal at aka.ms/IntuneFeedback. Resource Link Configure Delivery Optimization Configure Delivery Optimization Delivery Optimization Troubleshooter Run the Delivery Optimization Troubleshooter Microsoft Connected Cache Release Notes View MCC Release Notes Connected Cache Community Join the Community DO + MCC AMA Recording Watch the AMA Recording Intune Feedback Submit Product Feedback If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.Exporting all Microsoft Intune Enterprise App Management catalog apps to CSV using Microsoft Graph
By: Joe Lurie, Sr. Product Manager | Microsoft Intune Managing applications at scale is one of the biggest time-consuming tasks for IT admins. Between packaging installers, writing detection rules, and keeping everything up to date - it adds up fast. That's exactly the problem Enterprise App Management in Microsoft Intune is designed to address. Enterprise App Management gives you access to a curated Enterprise App Catalog with hundreds of popular Win32 apps that are pre-packaged, pre-tested, and ready to deploy. Microsoft handles the install commands, detection logic, and update-ready packaging. Automatic updates for catalog apps are expected to roll out in mid-2026, making the experience even more hands-off. You just pick the app, assign it, and move on. But what if you want a full inventory of what's available in the catalog? Maybe you're evaluating which apps your organization can migrate from manual packaging, or you want to share the list with your app owners for review. In this post, I'll show you how to pull the complete catalog using Microsoft Graph PowerShell and export it to a CSV file. Prerequisites Before you start, make sure you have: Intune admin permissions: An account with Intune permissions to read app and catalog data (such as Intune Administrator or a custom role with app read access). You will also need Microsoft Graph delegated scope: DeviceManagementApps.Read.All (you'll consent to this when connecting). An Intune Suite or Enterprise App Management add-on license: Enterprise App Management is part of the Intune Suite or available as a standalone add-on. Note: Microsoft has announced that Enterprise App Management will also be included in Microsoft 365 E5 licensing starting July 1, 2026 - check current licensing guidance to confirm availability for your tenant. Microsoft Graph PowerShell SDK (Beta module) installed: Note that the catalog API is currently in the beta endpoint which means cmdlet names and properties may change before reaching v1.0. If you don't have the beta module installed yet, run: Install-Module Microsoft.Graph.Beta.Devices.CorporateManagement -Scope CurrentUser -Force Step 1: Connect to Microsoft Graph First, authenticate to Microsoft Graph with the required scope: Connect-MgGraph -Scopes "DeviceManagementApps.Read.All" You'll get a browser prompt to sign in and consent. Once connected, you're ready to query the catalog. Step 2: Retrieve all Catalog apps Microsoft Graph exposes the Enterprise App Catalog through the /beta/deviceAppManagement/mobileAppCatalogPackages collection. The PowerShell cmdlet for it is: $catalogApps = Get-MgBetaDeviceAppManagementMobileAppCatalogPackage -All The -All parameter is important as it handles pagination automatically so you get every catalog package, not just the first page of results. 💡 Tip To see every property available on a catalog package object, pipe the first result to Format-List . $catalogApps | Select-Object -First 1 | Format-List * Step 3: Export to CSV Next, let's select the most useful fields and write them to a CSV file: $csvPath = "C:\Temp\IntuneCatalogApps.csv" New-Item -ItemType Directory -Path (Split-Path $csvPath) -Force | Out-Null $catalogApps | Select-Object ProductDisplayName, VersionDisplayName, PublisherDisplayName | Export-Csv -Path $csvPath -NoTypeInformation Open the CSV in Excel and you've got a clean, sortable list of every catalog package in the Intune Enterprise App Catalog. Putting it all together Here's the complete script you can save and run: # Connect to Microsoft Graph Connect-MgGraph -Scopes "DeviceManagementApps.Read.All" # Pull all Enterprise App Catalog packages $catalogApps = Get-MgBetaDeviceAppManagementMobileAppCatalogPackage -All # Export to CSV $csvPath = "C:\Temp\IntuneCatalogApps.csv" New-Item -ItemType Directory -Path (Split-Path $csvPath) -Force | Out-Null $catalogApps | Select-Object ProductDisplayName, VersionDisplayName, PublisherDisplayName | Export-Csv -Path $csvPath -NoTypeInformation Write-Host "Exported $($catalogApps.Count) catalog apps to $csvPath" -ForegroundColor Green # Disconnect when done Disconnect-MgGraph Sample output Your CSV will look something like this: Product Version Publisher Mozilla Firefox 137.0.1 Mozilla Corporation Google Chrome 135.0.6998.89 Google LLC Zoom Workplace 6.4.6 Zoom Video Communications, Inc. Adobe Acrobat Reader DC 25.001.20467 Adobe Inc. 7-Zip 24.09 Igor Pavlov Why this matters Having a complete list of what's in the catalog is useful for a few scenarios: App rationalization - Share the list with app owners and identify which apps you can stop manually packaging and switch to the catalog instead. Gap analysis - Compare the catalog against your current app portfolio to see what's missing. Change management - Track what's available over time as Microsoft continues to add new apps. Compliance and auditing - Document which catalog apps are available for your tenant. Wrapping up Enterprise App Management is one of the most impactful features in the Intune Suite. It takes the most tedious parts of endpoint management - app packaging and updates - and just handles it for you. And with a short Graph script, you can get full visibility into what's available. And to see how Enterprise App Management secures your app catalog, check out the companion post here: aka.ms/Intune/EAM-Security. Give the script a try and let us know what you think along with other Enterprise App Management topics you’d like to see by leaving a comment below or reaching out on X @IntuneSuppTeam. Want to learn more about Enterprise App Management? Check out the official documentation for the full details. Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at https://aka.ms/JoinIntuneCommunity.How Enterprise App Management secures your App Catalog from ingestion to device
By: Joe Lurie, Sr. Product Manager | Microsoft Intune One of the most common questions I get from customers when I talk about Enterprise App Management is some version of: "Okay, but how do I know these apps are safe?" It's a fair question. You're trusting a catalog of pre-packaged Win32 apps to land on thousands of managed devices across your organization. If you're responsible for endpoint security, you should be asking that question. This post explains how Enterprise App Management works behind the scenes, how apps get into the catalog, what happens before they're visible to your tenant, and why the architecture matters for your security posture. The architecture: Not a new system, but an extension of what you already trust An important design decision with Enterprise App Management is that it's not a separate app delivery system. It's an extension of the existing Intune Win32 app architecture. From the admin perspective, everything starts in the Intune admin center. But behind the scenes, there's a clean separation between the control plane and the data plane: Control plane: For each app being added to the Enterprise App Management catalog, Intune curates app metadata, including app version, install commands, uninstall commands, detection logic, requirements, and supported configurations. This metadata is validated and normalized before it shows up in your tenant. That's why catalog apps behave consistently whether you're deploying to 50 devices or 50,000. Data plane: Once an app is assigned by an admin, it flows through the same Win32 app delivery and enforcement pipeline you already rely on. Your devices don't know they're installing an "Enterprise App Management app" - they're enforcing a Win32 app with well-defined intent. Same Enrollment Status Page support, same reporting, same retry logic, same Intune Management Extension. No new agent. No new runtime. And finally, Enterprise App Management apps have the same support for App Control for Business with Managed Installer which can automatically tag the apps as safe. This is important because it means Enterprise App Management inherits all the trust and operational maturity of Win32 app management in Intune. Curated content is delivered through established, reliable infrastructure. How Enterprise App Management apps are delivered: The ingestion pipeline This section walks through what happens from the moment an app is sourced to the moment it appears in your catalog. Content ingestion It starts with the catalog. Microsoft receives app metadata, including install and uninstall commands, version info, and download URLs. The data is then ingested, flattened, transformed, and Microsoft's own identifiers are applied. After the data lands in the database, eligibility and filtering gates are applied through allow and deny lists. Apps on the allow list are permitted to download content from controlled internet locations. This process handles both net-new apps and version updates to apps already in the catalog. Security and functional validation This is the part that answers the "how do I know it's safe?" question. Once content ingestion is complete, every app is submitted for security and functional validation. This is a queue-driven service that runs two parallel tracks: Static malware detection scans the installer and related artifacts for malicious content, assigning a VirusTotal score. If an app receives a non-zero score, it's blocked from proceeding, full stop. Static scanning is about establishing baseline trust before deployment. It validates that binaries are intact, that they originate from trusted sources, and they don't carry known indicators of malware or tampering. This process catches embedded malicious payloads, corrupted binaries, and known bad signatures before they can impact any device. Dynamic analysis (detonation) runs in parallel. The app is installed and uninstalled inside a VM detonation chamber, producing install results, logs, and artifacts. This is about validating behavior, not just files. Modern threats don't always look malicious at rest; some issues only surface when an installer or application runs or interacts with the system. Dynamic evaluation catches unexpected system changes, unsafe persistence mechanisms, and activity inconsistent with enterprise deployment expectations. If an app fails automatic validation, it goes through manual validation by Intune engineering. Both layers are required. Static scanning provides speed and broad coverage, while dynamic scanning provides depth and behavioral assurance. After publication: Ongoing scanning The security story doesn't end at publication. Apps already in the catalog are periodically re-scanned. If a version that previously passed validation is later found to fail a malware scan, it's flagged and removed from the catalog. This is a critical detail - the catalog isn't a snapshot-in-time trust decision. It's a continuously validated inventory. Update velocity Once a new app version is received, the target is to have it available in the catalog within 24 hours. Around 80–90% of apps hit that timeline. The remainder are apps that don't pass automatic validation and require manual review, which takes longer. But the pipeline processes updates through the exact same ingestion and validation flow as new apps - no shortcuts. Where Zero Trust fits in If you've been following Microsoft's Zero Trust model, this pipeline should feel familiar. Zero Trust is built on three principles: verify explicitly, use least-privilege access, and assume breach. EAM's validation pipeline maps directly to these: Verify explicitly: Every app is verified through multiple independent signals, including source integrity, static malware scanning, and dynamic behavioral analysis, before it's ever exposed to a tenant. No app gets a pass based on reputation or publisher name alone. Trust is earned through evidence, every time. Use least-privilege access: Enterprise App Management catalog apps ship with prefilled, scoped install and uninstall commands, detection rules, and requirements. You're not handing an installer broad system access and hoping for the best. The deployment surface is defined and constrained by design. Assume breach: This is why the pipeline doesn't stop at initial validation. Ongoing re-scanning means that even apps that previously cleared every check are continuously re-evaluated. If an app that was clean six months ago is later found to carry a risk, it's flagged and pulled from the catalog. The system assumes that trust is perishable, exactly the way Zero Trust says it should be. In practice, this means Enterprise App Management gives you an app lifecycle that's not just convenient - it follows the same security framework your organization is likely already adopting for identity, network, and device access. The app layer is often the last piece to catch up, and Enterprise App Management closes that gap. Here's the ingestion flow that shows how all of this fits together: The Enterprise App Management ingestion pipeline: from source metadata through content ingestion, static and dynamic security validation, manual review for failures, periodic re-scanning, and finally publication to the catalog. Takeaways If you're evaluating Enterprise App Management or explaining it to your security team, here's what I'd suggest that you land on: Enterprise App Management reduces the packaging tax. Pre-packaged apps with prefilled install details, detection rules, requirements, and restart behavior mean you spend less time building the same scaffolding repeatedly and more time on policy and rollout strategy. Patching becomes more predictable. Guided update flows using supersedence and a documented expectation of 24-hour update availability give you a cadence you can plan around, not react to. The security model is layered and continuous. Static scanning, dynamic detonation, manual review fallback, and ongoing re-scanning mean the catalog maintains a high trust bar - not just at ingestion, but over time. And it's all built on the same Win32 delivery infrastructure that you and your devices already trust. The bottom line: Enterprise App Management isn’t just about convenience. It shifts the app lifecycle from a manual, error-prone process to one with built-in security validation, operational consistency, and governance you can defend to your security team. Rather than manually sourcing installers and creating detection rules, use this approach to streamline the process. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam! Want to go deeper? Check out the Enterprise App Management documentation and keep an eye out for upcoming changes to Intune Suite licensing that will make Enterprise App Management available in the Microsoft 365 plans you may already own. And as always, drop feedback at aka.ms/IntuneFeedback. Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at aka.ms/JoinIntuneCommunity .Blocking and removing apps on Intune managed devices (Windows, iOS/iPadOS, Android and macOS)
By: Michael Dineen - Sr. Product Manager | Microsoft Intune This blog was written to provide guidance to Microsoft Intune admins that need to block or remove apps on their managed endpoints. This includes blocking the DeepSeek – AI Assistant app in accordance with government and company guidelines across the world (e.g. the Australian Government’s Department of Home Affairs Protective Policy Framework (PSPF) Direction 001-2025, Italy, South Korea). Guidance provided in this blog uses the DeepSeek – AI Assistant and associated website as an example, but you can use the provided guidance for other apps and websites as well. The information provided in this guidance is supplemental to previously provided guidance which is more exhaustive in the steps administrators need to take to identify, report on, and block prohibited apps across their managed and unmanaged mobile devices: Support tip: Removing and preventing the use of applications on iOS/iPadOS and Android devices. iOS/iPadOS devices For ease of reference, the below information is required to block the DeepSeek – AI Assistant app: App name: DeepSeek – AI Assistant Bundle ID: com.deepseek.chat Link to Apple app store page: DeepSeek – AI Assistant Publisher: 杭州深度求索人工智能基础技术研究有限公司 Corporate devices (Supervised) Hide and prevent the launch of the DeepSeek – AI Assistant app The most effective way to block an app on supervised iOS/iPadOS devices is to block the app from being shown or being launchable. Create a new device configuration profile and select Settings Catalog for the profile type. (Devices > iOS/iPadOS > Configuration profiles). On the Configuration settings tab, select Add settings and search for Blocked App Bundle IDs. Select the Restrictionscategory and then select the checkbox next to the Blocked App Bundle IDs setting. > Devices > Configuration profile settings picker = 'Blocked App Bundle IDs' Enter the Bundle ID: com.deepseek.chat Assign the policy to either a device or user group. Note: The ability to hide and prevent the launch of specific apps is only available on supervised iOS/iPadOS devices. Unsupervised devices, including personal devices, can’t use this option. Uninstall the DeepSeek – AI Assistant app If a user has already installed the app via the Apple App Store, even though they will be unable to launch it when the previously described policy is configured, it’ll persist on the device. Use the steps below to automatically uninstall the app on devices that have it installed. This policy will also uninstall the app if it somehow gets installed at any point in the future, while the policy remains assigned. Navigate to Apps > iOS/iPadOS apps. Select + Add and choose iOS store app from the list. Search for DeepSeek – AI Assistant and Select. > Apps > iOS/iPadOS > Add App searching for 'DeepSeek - AI Assistant' app Accept the default settings, then Next. Modify the Scope tags as required. On the Assignments tab, under the Uninstall section, select + Add group or select + Add all users or + Add all devices, depending on your organization’s needs. Click the Create button on the Review + create tab to complete the setup. Monitor the status of the uninstall by navigating to Apps > iOS/iPadOS, selecting the app, and then selecting Device install status or User install status. The status will change to Not installed. Personal Devices – Bring your own device (BYOD) Admins have fewer options to manage settings and apps on personal devices. Apple provides no facility on unsupervised (including personal) iOS/iPadOS devices to hide or block access to specified apps. Instead, admins have the following options: Use an Intune compliance policy to prevent access to corporate data via Microsoft Entra Conditional Access (simplest and quickest to implement). Use a report to identify personal devices with specific apps installed. Takeover the app with the user’s consent. Uninstall the app. This guide will focus on option 1. For further guidance on the other options refer to: Support tip: Removing and preventing the use of applications on iOS/iPadOS and Android devices. Identify personal devices that have DeepSeek – AI Assistant installed and prevent access to corporate resources You can use compliance policies in Intune to mark a device as either “compliant” or “not compliant” based on several properties, such as whether a specific app is installed. Combined with Conditional Access, you can now prevent the user from accessing protected company resources when using a non-compliant device. Create an iOS/iPadOS compliance policy, by navigating to Devices > iOS/iPadOS > Compliance policies > Create policy. On the Compliance settings tab, under System Security > Restricted apps, enter the name and app Bundle ID and select Next. Name: DeepSeek – AI Assistant Bundle ID: com.deepseek.chat Under Actions for noncompliance, leave the default action Mark device noncompliant configured to Immediately and then select Next. Assign any Scope tags as required and select Next. Assign the policy to a user or device group and select Next. Review the policy and select Create. Devices that have the DeepSeek – AI Assistant app installed are shown in the Monitor section of the compliance policy. Navigate to the compliance policy and select Device status, under Monitor > View report. Devices that have the restricted app installed are shown in the report and marked as “Not compliant”. When combined with the Require device to be marked as compliant grant control, Conditional Access blocks access to protected corporate resources on devices that have the specified app installed. Android devices Android Enterprise corporate owned, fully managed devices Admins can optionally choose to allow only designated apps to be installed on corporate owned fully managed devices by configuring Allow access to all apps in Google Play store in a device restrictions policy. If this setting has been configured as Block or Not configured (the default), no additional configuration is required as users are only able to install apps allowed by the administrator. Uninstall DeepSeek To uninstall the app, and prevent it from being installed via the Google Play Store perform the following steps: Add a Managed Google Play app in the Microsoft Intune admin center by navigating to Apps > Android > Add, then select Managed Google Play app from the drop-down menu. r DeepSeek – AI Assistant in the Search bar, select the app in the results and click Select and then Sync. Navigate to Apps > Android and select DeepSeek – AI Assistant > Properties > Edit next to Assignments. Under the Uninstall section, add a user or device group and select Review + save and then Save. After the next sync, Google Play will uninstall the app, and the user will receive a notification on their managed device that the app was “deleted by your admin”: The Google Play Store will no longer display the app. If the user attempts to install or access the app directly via a link, the example error below is displayed on the user’s managed device: Android Enterprise personally owned devices with work profile For Android Enterprise personally owned devices with a work profile, use the same settings as described in the Android Enterprise corporate owned, fully managed devices section to uninstall and prevent the installation of restricted apps in the work profile. Note: Apps installed outside of the work profile can’t be managed by design. Windows devices You can block users from accessing the DeepSeek website on Windows devices that are enrolled into Microsoft Defender for Endpoint. Blocking users’ access to the website will also prevent them from adding DeepSeek as a progressive web app (PWA). This guidance assumes that devices are already enrolled into Microsoft Defender for Endpoint. Using Microsoft Defender for Endpoint to block access to websites in Microsoft Edge First, Custom Network Indicators needs to be enabled. Note: After configuring this setting, it may take up to 48 hours after a policy is created for a URL or IP Address to be blocked on a device. Access the Microsoft Defender admin center and navigate to Settings > Endpoints > Advanced features and enable Custom Network Indicators by selecting the corresponding radio button. Select Save preferences. Next, create a Custom Network Indicator. Navigate to Settings > Endpoints > Indicators and select URLs/Domains and click Add Item. Enter the following, and then click Next: URL/Domain: https://deepseek.com Title: DeepSeek Description: Block network access to DeepSeek Expires on (UTC): Never You can optionally generate an alert when a website is blocked by network protection by configuring the following and click Next: Generate alert: Ticked Severity: Informational Category: Unwanted software Note: Change the above settings according to your organization’s requirements. Select Block execution as the Action and click Next, review the Organizational scope and click Next. Review the summary and click Submit. Note: After configuring the Custom Network Indicator, it can take up to 48 hours for the URL to be blocked on a device. Once the Custom Network Indicator becomes active, the user will experience the following when attempting to access the DeepSeek website via Microsoft Edge: Using Defender for Endpoint to block websites in other browsers After configuring the above steps to block access to DeepSeek in Microsoft Edge, admins can leverage Network Protection to block access to DeepSeek in other browsers. Create a new Settings Catalog policy by navigating to Devices > Windows > Configuration > + Create > New Policy and selecting the following then click Create: Platform: Windows 10 and later Profile type: Settings Catalog Enter a name and description and click Next. Click + Add settings and in the search field, type Network Protection and click Search. Select the Defender category and select the checkbox next to Enable Network Protection. Close the settings picker and change the drop-down selection to Enabled (block mode) and click Next. Assign Scope Tags as required and click Next. Assign the policy to a user or device group and click Next. Review the policy and click Create. When users attempt to access the website in other browsers, they will experience an error that the content is blocked by their admin. macOS macOS devices that are onboarded to Defender for Endpoint and have Network Protection enabled are also unable to access the DeepSeek website in any browser as the same Custom Network Indicator works across both Windows and macOS. Ensure that you have configured the Custom Network Indicator as described earlier in the guidance. Enable Network Protection Enable Network Protection on macOS devices by performing the following in the Microsoft Intune admin center: Create a new configuration profile by navigating to Devices > macOS > Configuration > + Create > New Policy > Settings Catalog and select Create. Enter an appropriate name and description and select Next. Click + Add settings and in the search bar, enter Network Protection and select Search. Select the Microsoft Defender Network protection category and select the checkbox next to Enforcement Level and close the Settings Picker window. In the dropdown menu next to Enforcement Level, select Block and select Next. Add Scope Tags as required and select Next. Assign the policy to a user or devices group and select Next. Review the policy and select Create. The user when attempting to access the website will experience the following: http://www.deepseek.com showing error: This site can't be reached Conclusion This blog serves as a quick guide for admins needing to block and remove specific applications on their Intune managed endpoints in regulated organizations. Additional guidance for other mobile device enrollment methods can be found here: Support tip: Removing and preventing the use of applications on iOS/iPadOS and Android devices. Additional resources For further control and management of user access to unapproved DeepSeek services, consider utilizing the following resources. This article provides insights into monitoring and gaining visibility into DeepSeek usage within your organization using Microsoft Defender XDR. Additionally, our Microsoft Purview guide offers valuable information on managing AI services and ensuring compliance with organizational policies. These resources can help enhance your security posture and ensure that only approved applications are accessible to users. Let us know if you have any questions by leaving a comment on this post or reaching out on X @IntuneSuppTeam.
Supersedence Relationship Conflict in Intune Deployment of any Applications
Hi, I have been in touch with Microsoft Support, who confirmed the issue outlined below is a known problem, the Support case number is 2405230050000654. They have tested it in a test environment and experienced the same issue. Can this please be fixed? Issue example: We have R and RStudio deployed to some of our devices as required installs within Intune. The apps are available within the Company Portal for users to install. R is a dependency application of RStudio. When upgrading to the new versions of R and RStudio, I have set up the following: The new version of R has a supersedence of the previous version of R and is set to replace (uninstall) rather than update. The new version of RStudio has a supersedence of the previous version of RStudio and is set to update. The new version of R is set as a dependent app of the new version of RStudio. When deploying the new apps as a required install or if a user clicks install within the Company Portal to get the new version of the app, it gives a supersedence relationship conflict error: “App cannot be installed due to a supersedence relationship conflict. (0x87D300DB).” I have tried changing the supersedence of R to update rather than replace (uninstall), but the same error occurs. The only way to fix the issue is either by removing the dependency relationship between the apps or removing the Supersedence from the new R application, this then resolves the issue. However, R is required, and removing the dependency means that R is not automatically installed for the user and this functionality should be possible without having to do workarounds. This issue occurs with any apps set up in this manner, not just the example apps above. Please can this be fixed?
Required applications are not installing after autopilot is completed on the Hybrid AD joined device
Hello All, I am facing an issue where device has completed ESP phase (user ESP is skipped) and user is able to login to the device. We are having some more applications to install which are not blocked in ESP. Expectation is those applications has to be installed automatically after user logs into the device as those are deployed in required but I don't see any application installing and need to do a restart manually to install those applications automatically. Please give your advice on where it went wrong or where I need to check to resolve this issue. Thanks in advance!
