Policy: from hybrid to cloud-native - Unpacking Endpoint Management

Overview: “Hybrid to cloud-native” endpoint management (Intune-focused)

The session discusses how to transition from on-premises endpoint management (e.g., SEC/Configuration Manager + GPO/AD) to cloud-native endpoint management using Microsoft Intune and cloud identity (Entra ID).

Speakers emphasize that this transition is not only technical—it requires process change and a mindset shift to avoid drift/conflicts and to establish a single source of authority.

---

Key technological concepts and product features

1) Why Intune/MDM became necessary (cloud policy delivery)

• MDM / Modern Device Management originated to manage devices without needing domain controller line-of-sight, moving policy and app delivery “out onto the internet.”
• The approach evolves toward cloud-native management, where devices pull down policy and apps via cloud services rather than relying primarily on traditional domain-based connectivity.

2) Common real-world end state during migration: hybrid everywhere

Many organizations end up in mixed configurations:

• Some devices fully migrated to MDM
• Some devices running hybrid (cloud + on-prem)
• Temporary periods where the same device runs GPO + MDM policy concurrently

3) “Cloud native tools” for patching: EAM (Enterprise App Management)

For third-party application patching without local packaging servers, the discussion points to:

• Intune Enterprise App Management (EAM), including:
  • Support for first-party and third-party apps
  • Reduced packaging effort compared to manual Win32 wrapper work (e.g., learning silent install commands, properties, answer files)
  • Auto-update as a key capability

4) Reducing and mapping legacy GPO complexity to Intune: Settings Catalog + GP Analytics + Security Copilot policy experience

Biggest scaling problem: organizations often accumulate hundreds or thousands of GPOs over many years.

Guidance focuses on starting from a desired outcomes / “blank piece of paper” mindset rather than trying to rationalize everything immediately.

Tools/features mentioned:

• Group Policy Analytics
  • Helps identify which legacy GPO settings map into Intune settings catalog
  • Guidance: prune before/after upload and select only settings that still make sense
• Security Copilot policy experience (AI-based)
  • Accepts either:
    • a compliance document/email/blog, or
    • a prompt describing an intent/specific scenario
  • Then maps intent to relevant settings catalog policies, aiming to remove manual research/mapping work

5) Admin Templates deprecation and Settings Catalog direction

A Q&A clarifies:

• Admin Templates are deprecated because their functionality is available in Settings Catalog.
• Settings Catalog is more flexible (e.g., filters) and supports a more modern policy creation workflow.

When to still use templates/custom ADMX/custom URI:

• Custom URI is described as the primary remaining niche:
  • e.g., when a setting isn’t available, or is intentionally not exposed
• If something is missing/complex, Intune may create a custom first-class UX that uses underlying Windows CSPs
  • Example alluded to: an Intune recovery scenario
• Some CSPs may intentionally not be exposed because they can impact delicate device/service behavior
  • e.g., certificate renewal schedules, DM client CSP/join mechanics

6) Handling registry-backed settings vs GPO registry preferences

The discussion distinguishes between:

• Registry settings managed via Intune/CSP and handled by the policy manager
• GPO approaches that write registry keys directly (historically more prone to flip-flop, detection issues, and drift)

Guidance:

• Prefer built-in / settings catalog approaches where possible.
• Registry mapping is documented (e.g., ADMX files show which registry behavior corresponds to policy settings).

7) Replicating GP granularity (WMI filters, security group scoping)

Intune equivalents to WMI filters + GPO targeting:

• Assignment filters in Intune
• Security group targeting

Also noted:

• Many CSP-backed settings use applicability logic, meaning the device may silently not apply settings when not applicable.
• This can reduce the need for very granular targeting that WMI filters historically provided.

8) Visibility after switching to cloud policies (replacing GPResult/RSOP)

To confirm policy delivery and “what landed on devices,” speakers recommend:

• Intune reporting
• Intune Explorer for detailed slicing/dicing reporting by device/settings
• Device diagnostics/logs for troubleshooting (noted as potentially noisy)
• Community tooling: SyncML Viewer to inspect the SyncML payload delivered from Intune to the device

9) Compliance signal and “multiple MDMs” on devices (platform limitation / single authority)

Key clarification:

• Devices generally require single source of authority for compliance.
• The platform limitation: you can have multiple MDMs, but single authoritative compliance is required for conditional access.

Specific warning:

• If Defender for Endpoint (MDE) configurations are applied via Intune, compliance may overwrite/compete with another provider (example: JAMF).
• Therefore, orgs must ensure they have the correct compliance authority model.

---

Migration strategy advice (the “how long/how to” part)

The recommended hybrid-to-cloud-native progression (“3 steps”)

Speakers recommend a multi-year, staged plan rather than a single switch:

1. Enroll existing devices into hybrid and co-management
   • Allows cloud management to start while legacy still exists.
2. Move workloads to the cloud
   • Treat policy as a workload too: shift from AD/GPO context toward Intune policy.
   • After workloads move, GPO on older devices can become unnecessary.
3. Deploy new devices as cloud-native
   • “Intune only / Entra only entry-only”
   • Hybrid legacy is removed gradually as hardware refresh cycles complete.

Timing guidance: the period of hybrid GPO + Intune depends on hardware refresh cycles (e.g., 3–5 years).

“Blank piece of paper” = how to migrate/retire safely

Instead of migrating everything:

• Define outcomes: secure + productive device
• Layer policy based on what’s actually required:
  • security/cyber
  • productivity
• Retire old policies rather than carrying forward “sludge” from decades of accumulation.

Example mindset:

• Treat “prune/retire” decisions like disabling floppy drives as a security-centric intent that may no longer be relevant today.

Common mistakes to avoid

• Skipping straight to the end / expecting resetless conversion
  • Even after cloud management is in place, you must still rationalize:
    • policy equivalents,
    • app migrations,
    • update rings / autopatching design,
    • and process changes.
• Conflating different kinds of “hybrid”
  • Some orgs assume cloud-native can’t coexist with on-prem resources (printers/fileshares/etc.).
  • Speakers argue cloud-native devices can still operate in hybrid office scenarios; connectivity translation (e.g., Entra Kerberos support) can address many cases.
• Bundling value changes with authority changes
  • Don’t change both:
    • “what value is set” (GP → Intune content), and
    • “who applies it”
  • Otherwise you may introduce interim drift/conflicts.
• Configuration drift control
  • Mentions Configuration Refresh to replay the last Intune payload when drift is suspected (e.g., refresh interval reduced to ~30 minutes).

---

Speaker / source identification

• Michelle Blanchard — Microsoft, Product Manager; hosts “Unpacking Endpoint Management”
• Danny Gillery — Product Manager, Intune space; co-host
• Rob York — PM Architect on the Intune team; desktop focus; cloud-native transition from Configuration Manager to Intune
• Mike Dano / “Dano” (Mike Dowski in subtitles) — PM on Intune policy space; previously owned endpoint management policy; discusses migration from on-prem to MDM and policy tooling including Security Copilot/settings catalog themes