Improper AVD Host Decommissioning – A Practical Governance Framework
Hi everyone, After working with multiple production Azure Virtual Desktop environments, I noticed a recurring issue that rarely gets documented properly: Improper host decommissioning. Scaling out AVD is easy. Scaling down safely is where environments silently drift. Common issues I’ve seen in the field: Session hosts deleted before drain completion Orphaned Entra ID device objects Intune-managed device records left behind Stale registration tokens FSLogix containers remaining locked Defender onboarding objects not cleaned Host pool inconsistencies over time The problem is not technical complexity. It’s lifecycle governance. So I built a structured approach to host decommissioning focused on: Drain validation Active session verification Controlled removal from host pool VM deletion sequencing Identity cleanup validation Registration token rotation Logging and execution safety I’ve published a practical framework here: The framework is fully documented and includes validation logic and logging. https://github.com/modernendpoint/AVD-Host-Decommission-Framework The goal is simple: Not just removing a VM — but preserving platform integrity. I’m curious: How are you handling host lifecycle management in your AVD environments? Fully automated? Manual? Integrated with scaling plans? Identity cleanup included? Would love to hear how others approach this. Menahem Suissa AVD | Intune | Identity-Driven ArchitectureSplitting single-tenant Microsoft Defender XDR Sentinel logs in multiple company scenarios
This article describes a simple, yet effective solution for the problem of segregating Microsoft Defender XDR and Entra ID Sentinel logs ingestion in a single-tenant with multiple companies scenario, leveraging Log Analytics workspace transformations and some simple KQL query statements.
Single-Sign On
After troubleshooting an issue for a customer, we determined that the prerequisites for enabling SSO at the AVD host pool level is not strictly enforced when a user goes to execute the SSO workflow from MSRDC or the Windows App. Meaning, that if an administrator does not enable the -IsRemoteDesktopEnabled flag on the Service Principals "Microsoft Remote Desktop" and "Windows Cloud Login" respectively. Setup: Deploy Entra ID Joined session hosts to a host pool and enable the "Microsoft Entra single sign-on" RDP property to "Connections will use Microsoft Entra authentication to provide single sign-on" or update the RDP connection string with 'enablerdsaadauth:i:1'. Result: User will not receive the 'Windows Security' dialog box to access the session host with their Entra ID credentials. Caveat: Be aware that to sign in with Entra ID credentials, minimally, the host pool RDP settings must contain 'targetisaddjoined:i:1'. Microsoft states this is going away and blending into 'enablerdsaadauth:i:1', which also enables SSO. It seems a bit odd of a move in my opinion and having two separate RDP properties makes sense if a company does not want SSO. But it is in alignment with Microsoft's push for passwordless authentication. For the Microsoft AVD team, why does this behavior exist and is it on the roadmap to be fixed if it's a known gap?Why Entra ID attributes don’t always appear on Microsoft 365 profile cards
While working with Microsoft Entra ID and Microsoft 365 profile cards, I ran into a behavior that often causes confusion: attributes like EmployeeType can exist in Entra ID and Microsoft Graph, yet not appear consistently on Microsoft 365 profile cards. This post breaks down why this happens, what’s actually happening behind the scenes, and what you can realistically expect when working with profile card attributes in real environments. Profile cards should be treated as a presentation layer, not a guaranteed real-time reflection of every Entra ID attribute. If you’ve seen similar behavior with other attributes or workloads, I’d love to hear how you’ve approached it in your environments.Platform SSO for macOS
Introduction As organizations accelerate their journey to passwordless authentication, Microsoft’s Platform SSO for macOS offers a seamless, secure, and user-friendly experience for device and application sign-in. Built on Apple’s SSO framework and tightly integrated with Microsoft Entra ID, Platform SSO empowers users to leverage modern authentication methods Touch ID, smart cards, and passkeys across their macOS devices, enterprise apps, and browsers. In this blog, we’ll walk through the essentials of Platform SSO, supported authentication methods, configuration steps, and best practices for deployment in enterprise environments. What is Platform SSO for macOS? Platform SSO is a Microsoft feature for macOS (13+) that leverages Apple’s SSO framework to enable single sign-on using Entra ID credentials. Users benefit from passwordless authentication, enhanced security, and a consistent experience whether logging into their device, enterprise applications, or web browsers. Key highlights: Passwordless sign-in: Use Touch ID (Secure Enclave), smart cards, or passwords for device and app authentication. Enterprise SSO plug-in: Activated for both application and browser-based sign-in, ensuring centralized identity management. No agent required: Utilizes built-in macOS platform capabilities for easy deployment and management. Authentication Methods Supported by Platform SSO Platform SSO supports three primary authentication methods on macOS: Feature Secure Enclave Smart Card Password Passwordless (phishing resistant) ✅ ✅ ❌ Touch ID supported for unlock ✅ ✅ ✅ Can be used as passkey ✅ ❌ ❌ Local Mac password synced with Entra ID ❌ ❌ ✅ Supported on macOS 14.x+ ✅ ✅ ✅ MFA mandatory for setup ✅ ✅ ❌ Secure Enclave: Recommended for most users, Secure Enclave uses hardware-bound cryptographic keys for app and web sign-ins, enabling passwordless and phishing-resistant MFA. After a reboot, users enter their local password once, then Touch ID can be used for subsequent unlocks. The device receives a hardware-backed Primary Refresh Token (PRT) for device-wide SSO. Smart Card: Ideal for high-security or compliance-driven environments, Smart Card authentication provides complete passwordless sign-in and unlock. After sign-in, the device receives a PRT and Workplace Join (WPJ) certificate for seamless SSO to Microsoft 365, Safari, and Entra-protected apps. Password: Users sign in with their Entra ID password, which syncs to the local account for SSO across apps. Intune password policies ensure alignment with Entra ID password rules, preventing sync or sign-in issues. How Platform SSO Works When a Mac device joins a Microsoft Entra ID tenant, it receives a hardware-bound WPJ certificate accessible only by the Microsoft Enterprise SSO plug-in. Apps and browsers require this certificate to access resources protected by Conditional Access policies. Platform SSO is configured using the Intune settings catalog and should ideally be assigned at device enrollment, but can also be applied to existing devices. Deployment Steps Device Enrollment in Intune: Organization-owned devices use Apple Business Manager or Apple Configurator; personally-owned devices enroll via Company Portal. Prerequisites: macOS 13+, Intune Company Portal app v5.2404.0+, supported browsers (Edge, Chrome with SSO extension, Safari), Intune RBAC permissions. Create Platform SSO Policy in Intune: Enable Platform SSO, select authentication method (Secure Enclave, Password, Smart Card), assign to user groups. Define Policies in Platform SSO Settings: Assign to users or groups with user affinity; avoid assigning to device groups to prevent Conditional Access issues. Enable MDM Push Certificate: Required for macOS enrollment in Intune. Deploy Company Portal App: Via Intune or manually from https://aka.ms/EnrollMyMac. Enroll Device and Validate Profiles: Sign in to Company Portal with Entra ID credentials and confirm device management profile. Customizing the macOS Login Experience Platform SSO allows administrators to push Login Window Text and Show Full Name settings from Intune, enabling a personalized and informative login experience for users. These settings help display the user’s full name and custom messages during sign-in, improving clarity and branding. Best Practices Assign Platform SSO policies during device enrollment for a seamless experience. Ensure password policies in Intune and Entra ID are aligned. Use Secure Enclave for most users; Smart Card for compliance scenarios. Regularly review group memberships and issuer assignments for certificate-based authentication. Document all scoped policies for compliance and troubleshooting. Conclusion Microsoft Platform SSO for macOS is a game-changer for organizations seeking secure, passwordless authentication across devices and applications. By leveraging Entra ID credentials, Touch ID, smart cards, and passkeys, IT teams can deliver a modern, seamless, and secure experience for users while maintaining compliance and reducing operational overhead. Ready to get started? Explore the official documentation and accelerate your passwordless journey today!
