App management at scale with Intune - Unpacking Endpoint Management

Technological concepts & product features discussed

1) EAM (Enterprise App Management) – auto updates for required apps

• A new EAM feature was released: “Auto updates in EAM.”
• Admins can choose between manual updates and auto updates.
• With auto update, Intune handles updates automatically when the newest updates are released.
• Currently limited to “required apps”; support for “available apps” is planned soon.

2) Windows app inventory improvements (replacing “discovered apps” experience)

David described major work to modernize app inventory:

• Built on the new device inventory platform for faster collection and refresh.
• Inventory updates can occur with diff updates multiple times per day (based on device activity), improving turnaround time.
• Added richer discovered/reporting attributes such as:
  • uninstall command
  • last refresh date (how current the info is)
  • architecture and language
  • install-related attributes (e.g., install location / installation method signals)
• Fixed multi-user device inaccuracies:
  • Previously, discovered apps behaved as if they reflected only the logged-in user, causing other users’ “installed” apps to appear removed/changed.
  • Now inventory collection preserves whether apps are user vs machine installed, and ties entries to the correct user context at once.
• UI/experience direction:
  • Inventory is surfaced under the Devices tab with “managed apps” vs “app inventory” views.
  • Microsoft signaled intent to move away from the “discovered apps” / “managed apps” split toward a unified app inventory context.

3) EAM vs Win32 packaging: reducing admin workload

When asked how to avoid making packaging a full-time job, the presenters positioned EAM as a step-by-step approach:

• EAM is a curated catalog of prepackaged apps to reduce manual packaging.
• Some customization remains possible via Script Installer:
  • Use a PowerShell script for installation logic instead of limited command-line usage.
• Update automation levels mentioned:
  • Superseded relationships (define which app version replaces which)
  • Guided upgrade with superseded (admin clicks to supersede)
  • Auto update (fully automated updates for selected apps)
• Guidance for admins:
  • If the app exists in EAM, start there.
  • If not, request it (feedback intake).
  • Fall back to Win32 packaging only if needed customization/script logic can’t be satisfied via EAM.

4) Script Installer and pre/post-install scripts

• Script installer is available for both Win32 and EAM apps.
• It runs a provided PowerShell script to handle install behavior (including logic that can cover pre/post actions).
• Microsoft said they do not currently plan dedicated pre-install/post-install script fields for EAM/Win32, but they invited feedback via aka.ms/intune feedback.

5) BYOD app protection vs device management

• The question focused on how Intune app protection policies relate to BYOD mobile devices where devices aren’t fully enrolled.
• Response: this requires coordination with the app protection team; it was treated as a follow-up topic.

6) Scale, failures at scale, and remediation strategy

For “why deployments work in testing but fail at scale,” the discussion emphasized:

• Simpler app installers are more reliable:
  • fewer custom actions / fewer extra components outside the normal installer flow
• Device health matters:
  • disk space
  • device activity (devices turned off fail to update)
• Use Explorer queries/views to find:
  • top failure codes / failure reasons for an app or app type
• Prefer proactive remediation scripts guided by observed failures, rather than only testing the installer itself.

7) Vulnerabilities: fastest removal of vulnerable software at scale

• Intune’s Vulnerability Agent moved into public preview.
• It brings vulnerability information into the Intune console:
  • Defender identifies vulnerable apps and provides prioritized recommendations (based on impact score).
• The agent uses AI/LLM name matching because:
  • Defender vulnerability app names often don’t exactly match Intune app inventory/app names.
• Remediation flow described:
  • Recommend updates (upgrade to versions that address CVEs)
  • Sometimes recommend removal/uninstall if update isn’t the right action
• App inventory support for uninstall:
  • tying app inventory + uninstall command-line discovery enables faster scripted uninstall/remediation
• Prevention layer:
  • also recommended: build App Control policies to block vulnerable installers/apps from being reinstalled.

8) App inventory uninstall strings: empty uninstall command concerns

• App inventory aims to reflect accurately what device APIs provide.
• If the uninstall string is empty, it likely means:
  • the app installer didn’t populate that field, or
  • uninstall info wasn’t available via those mechanisms
• When uninstall strings are missing, inventory may still include identifiers such as:
  • MSI product code (e.g., from uninstall registry keys)
  • package identifiers (store apps)
• Microsoft confirmed:
  • they use supported APIs (including package manager APIs for store apps)
  • no special/minimum Windows version beyond supported OS versions is required.

9) Inventory normalization & filtering of base apps

Plans/ideas mentioned:

• Add a normalized app name field to group the same app across:
  • architectures, versions, languages
• Improve handling of preinstalled apps (e.g., Notepad/Calculator):
  • no single API call exists to detect them reliably
  • Microsoft will use algorithms/hardcoding to classify them
  • they’ll be hidden by default to reduce noise, while still available if needed (e.g., vulnerability or version distribution analysis)

10) EAM dependency behavior and edge cases

• For dependent apps being uninstallable when the parent app isn’t installed:
  • presenters were unsure and said they would take it back to test/verify.

11) Dynamic scoping / collections like Config Manager

• Asked whether Intune can dynamically scope deployments based on app inventory (like Config Manager collections).
• Response:
  • Intune lacks a strong “dynamic collection” equivalent for this use case today.
  • Interim workaround:
    • use Explorer queries to find devices with certain app versions
    • add devices to static device groups
• Future improvement:
  • they’re aware of the request, but no direct solution was confirmed.

12) EAM evergreen updates vs custom proactive remediation scripting

• For using proactive remediation scripts to create evergreen installers instead of Intune app management:
  • concern: scripting creates operational ownership/accountability for the script lifecycle
• Suggestion:
  • with EAM’s evergreen/auto update features, admins may not need custom evergreen scripts anymore
• Encouraged feedback:
  • to understand scaling and process requirements.

13) “How does EAM update user-based apps?”

• EAM can update user-context apps when they’re within expected management/claim scenarios.
• Harder scenario mentioned:
  • apps installed as available/optional via Company Portal may be more difficult to update while preserving their available state without full ownership takeover.

14) Monitoring app failures / future insights

• Explorer provides queries such as top failures by app/app type.
• Future enhancements discussed as an open area:
  • desire for richer error code information and better failure insights.

15) EAM installer handling of languages/architectures

• Microsoft stated EAM handles architecture/language installers by providing appropriate options—admins don’t need to package separate installers themselves.

---

Key guides / workflows / “how to” takeaways mentioned

• Choose EAM first for common apps; otherwise request it; otherwise use Win32 if you need custom installation logic.
• For scaling reliability:
  • simplify installers,
  • verify device health readiness,
  • use Explorer to identify top failures,
  • proactively remediate.
• For vulnerability response:
  • use Vulnerability Agent to prioritize impact-driven updates/removals,
  • use app inventory uninstall commands for faster uninstall scripting,
  • use App Control policies to prevent reinstalls.
• For app inventory usage:
  • rely on inventory fields like uninstall command and refresh timestamps,
  • use planned normalized grouping for better matching.

---

Main speakers / sources

• Michelle Blanchard — Microsoft (product manager)
• Danny Gillery — Principal product manager, Intune
• David Guyire (spelled in subtitles “Guyire/Guyire”) — Product manager, Intune
• Nicole — Product manager, Intune (Windows app management and EAM)

Sources referenced in discussion:

• Microsoft Defender Vulnerability management
• Intune Explorer
• Windows device inventory APIs
• Microsoft Lighthouse (MSP concept mentioned)
• Company Portal (optional/available apps context)