Two recent posts from Microsoft’s Intune Customer Success team are worth treating as client work, not roadmap trivia. One is a hard support deadline: the Microsoft Desktop Optimization Pack reached end of extended support on April 14, 2026. The other is a set of field lessons from Platform SSO deployments on Macs before macOS 26.
For MSPs, the takeaway is pretty practical. Inventory the old Windows management pieces now, then pilot the Mac identity changes carefully. Neither item is dramatic by itself. Both can turn into noisy tickets if they sit untouched.
MDOP is now out of extended support
Microsoft says MDOP reached end of extended support on April 14, 2026. That means Microsoft no longer provides security updates, bug fixes, or technical support for the MDOP components.
The first job is not migration planning. It is discovery. Check whether any client still depends on App-V Server, MBAM, DaRT, UE-V, or AGPM. These are the kinds of tools that can disappear from day-to-day conversation while still sitting under a packaging process, a recovery workflow, or an old Group Policy change process.
Microsoft’s replacement map is mostly what you would expect if you already manage endpoints through Intune and Entra ID. App-V Server should no longer be the forward path. Existing App-V client and sequencer support follows the Windows versions they ship with, but new packaging work should move toward MSIX, Intune app deployment, and MSIX App Attach for Azure Virtual Desktop where that fits.
MBAM is the one I would prioritize first. If a client still uses MBAM for BitLocker management, move the conversation to Intune BitLocker policy and recovery key escrow in Microsoft Entra ID. Do not assume the migration is done just because encryption is enabled. Test recovery key backup, recovery lookup, help desk process, and reporting before calling it complete.
For UE-V, the replacement is not one product. It is usually a mix of OneDrive Known Folder Move, Enterprise State Roaming where applicable, Windows 365 or Azure Virtual Desktop, and FSLogix for profile/container scenarios. That makes the assessment more important. Ask what user state actually needs to roam before designing the replacement.
AGPM is a governance problem as much as a tooling problem. In the Intune world, look at Settings Catalog, Multi Admin Approval for sensitive changes, Graph-based export and review workflows, and policy-as-code habits for versioning. The exact answer depends on how formal the client’s change process needs to be.
DaRT is similar. Replace it by documenting the modern recovery path: Windows Recovery Environment, Intune remote actions, bootable media, and Quick Machine Recovery where it applies. The point is not to recreate every DaRT habit. The point is to make sure the help desk knows what to do when a device cannot boot, a user is locked out, or remote remediation fails.
Platform SSO is powerful, but the rollout details matter
The second Intune Customer Success post is a field report on deploying Platform SSO for Macs running versions before macOS 26. This is not an end-of-support notice. It is a lessons-learned post from Microsoft’s internal Intune administration team.
The value is easy to understand. Platform SSO brings Mac sign-in closer to the Windows Hello for Business model by using device-bound authentication, Primary Refresh Tokens, and Conditional Access token protection. Microsoft’s recommendation for pre-macOS 26 deployments is to start with the Secure Enclave method and deploy the Extensible SSO profile through the Intune Settings Catalog.
The caution is that the user experience has real edges. Users can dismiss the registration notification. Password reset requirements can block registration in ways that are not obvious to the user. Duplicate SSO profiles can create confusing behavior. A macOS update may require repair or re-registration. TLS inspection can break authentication if the relevant Microsoft endpoints are intercepted.
That makes this a bad candidate for a broad silent rollout. Start with a small pilot, confirm the exact macOS versions in scope, and make sure the help desk knows what the registration prompt looks like. Keep one SSO profile per device. If the client uses SSL/TLS inspection, validate the required Microsoft endpoints before blaming Intune or Entra ID for failed registration.
There is also a timing detail to keep straight. Microsoft notes that newer macOS versions have a newer Platform SSO setup flow with registration during Automated Device Enrollment. So the pre-macOS 26 guidance is still useful, but it should not be treated as the only pattern for every Mac you enroll going forward.
MSP checklist for this quarter
- Inventory MDOP components by client, not just by tenant. Look for App-V Server, MBAM, DaRT, UE-V, and AGPM dependencies.
- Prioritize MBAM replacement if BitLocker recovery keys or reporting still depend on old infrastructure.
- Move new app packaging work toward MSIX and document any App-V packages that still need to survive for now.
- Write down the post-DaRT recovery process so the help desk has a supported path during a boot or access incident.
- For Mac Platform SSO, pilot Secure Enclave first, keep the profile design simple, and test registration with real users.
- Check password reset policies, duplicate SSO profiles, macOS update behavior, and TLS inspection before rollout.
The common thread is supportability. MDOP is a clear deadline problem. Platform SSO is a rollout-quality problem. Both are good reasons to schedule a short endpoint review with any client that still has legacy Windows management tooling or a growing Mac fleet.
Sources
- MDOP is out of support: What to do next with Microsoft Intune, Microsoft Intune Customer Success, June 2026.
- Deploying Platform SSO for pre macOS 26 with Microsoft Intune: Lessons Learned, Microsoft Intune Customer Success, June 2026.
