Windows CLAT is Now Generally Available
As organizations move toward IPv6-only and IPv6-mostly networks, some applications still depend on IPv4-only applications or services. Windows CLAT helps those applications continue to work when a network does not provide native IPv4 connectivity. CLAT is the client-side component of 464XLAT. It statelessly translates IPv4 traffic from the Windows client into IPv6 for transport across the network to a provider-side translator (PLAT), which provides stateful NAT64 translation to IPv4. Why CLAT? Compatibility with IPv4 resources: IPv6-only devices can reach IPv4 resources without requiring the whole network to be dual-stack. Reduced IPv4 address requirements: Devices can share a public IPv4 address through NAT64, reducing demand for scarce IPv4 addresses. This is critical for organizations that cannot obtain a significant block of IPv4 addresses for new networks due to IPv4 address depletion. Simpler network configuration: Organizations can deploy IPv6-only networks while retaining access to IPv4 resources. Seamless user experience: Translation happens as needed, without requiring users to know whether a service uses IPv4 or IPv6. Potential cost savings: IPv6-only deployment can reduce costs associated with IPv4 addresses and operating dual-stack infrastructure. Minimized security risk exposure: Similar to the above, dual‑stack networks expose two attack surfaces, each with its own vulnerabilities and configuration requirements. CLAT helps to reduce this by removing the need to secure an additional network. Incremental deployment: Organizations can introduce IPv6 in stages while maintaining IPv4 compatibility, rather than overhaul the entire network at once. A foundation for future IPv6 growth: CLAT helps organizations build on IPv6 rather than depend on an increasingly limited supply of IPv4 addresses. How Windows CLAT Helps Organizations Accelerate To IPv6-Only Feature What it is Why it’s important IPv4 application access on IPv6 networks CLAT is the client-side component of the 464XLAT architecture (RFC 6877). It translates IPv4 traffic so IPv4-only applications can communicate over an IPv6 network (where a NAT64/PLAT service exists.) Organizations can move network infrastructure toward IPv6 without waiting for every application or destination to support IP Local IPv4 compatibility for applications Allows IPv4 addresses to be assigned to support IPv4-only application flow on IPv6-only devices and networks. Helps existing applications continue to use familiar IPv4 networking while the device uses an IPv6 network underneath. Support across network interfaces The feature is designed for IPv6-capable connections across Wi-Fi, Ethernet, and cellular interfaces. Devices can maintain IPv4 application compatibility as they connect through different network types. Automatic recognition of IPv6-only networks CLAT can begin configuration discovery when IPv4 connectivity is unavailable, or when a network signals IPv6-only-preferred operation using DHCP Option 108 (RFC 8925). Reduces the need for users to configure connectivity themselves and gives networks a standards-based way to indicate that clients should prefer IPv6. Prefix discovery from network advertisements CLAT can discover the translation prefix from PREF64 information in IPv6 Router Advertisements, as defined by RFC 8781. Allows compatible routers to provide the information devices need to use for translation, and to advertise prefix changes as the network evolves. DNS-based prefix discovery CLAT can also discover the translation prefix by querying ipv4only.arpa, following RFC 7050 and RFC 8880. This provides an alternative when the network does not provide PREF64 through Router Advertisements. Gives organizations another standards-based discovery option for networks that rely on DNS to provide IPv4/IPv6 transition information. Where to Get More Details For a practical overview of enabling Windows CLAT, confirming its configuration, and collecting logs, see our Windows CLAT Public Preview blog. For a deeper explanation of what CLAT is and how it works, see Windows CLAT Enters Private Preview: A Milestone for IPv6 Adoption. Accelerating the Global IPv6 Migration We’re excited about the role Windows CLAT can play in the global transition to IPv6. By helping IPv4-dependent applications continue to work as networks evolve, this feature can make it easier for organizations to move toward IPv6-only and IPv6-mostly environments. We’re grateful to the customers and partners whose feedback helped bring Windows CLAT to general availability, and we look forward to seeing its impact across the IPv6 community.Preparing for end of support for CNAME auto-discovery in Windows MDM-only enrollment
Today, some organizations use an EnterpriseEnrollment DNS CNAME record to automatically direct devices to the Microsoft enrollment service during Windows MDM-only enrollment. Starting January 15, 2027, as part of our ongoing efforts to simplify and modernize enrollment experiences, Microsoft Intune will end support for CNAME-based auto-discovery in Windows MDM-only enrollment scenarios. This change reduces dependency on DNS-based discovery while providing a more consistent enrollment experience moving forward. After this change, users may need to enter the Microsoft enrollment server URL if it’s not already provided by the enrollment experience: https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc Who this change affects Your organization may be affected if: You use Windows MDM-only enrollment. You have configured an EnterpriseEnrollment DNS CNAME record. Your enrollment process depends on DNS record to automatically discover the enrollment service. You likely aren't affected if you exclusively use: Microsoft Entra join enrollment Microsoft Entra hybrid join enrollment Other enrollment methods that don't rely on EnterpriseEnrollment CNAME discovery How the user experience will change Today, in affected environments, a user can begin Windows MDM-only enrollment, and the enrollment service is automatically discovered using the organization’s EnterpriseEnrollment DNS CNAME record. The user doesn’t need to provide the enrollment server information. After this change, CNAME-based auto-discovery will no longer be used for these Windows MDM-only enrollment scenarios. If the enrollment service URL isn't already provided by the enrollment experience, the user will need to enter it when prompted. Enrollment can then continue using the Microsoft enrollment service URL. For example: Identifying affected environments Review your organization's DNS configuration and Windows MDM-only enrollment documentation.In particular, look for an EnterpriseEnrollment DNS record similar to: EnterpriseEnrollment.contoso.com If your organization configured the EnterpriseEnrollment record to support Windows MDM-only enrollment discovery, you should prepare for this change. You should also review and update documentation that assumes enrollment service discovery happens automatically through DNS, including: Internal enrollment guides Help desk procedures Device deployment instructions Provisioning documentation User onboarding materials Actions to take if you’re affected To prepare for this change we recommend the following actions: 1. Identify impacted enrollment workflows Review all Windows MDM-only enrollment scenarios used within your organization and determine whether they depend on EnterpriseEnrollment DNS discovery. 2. Update enrollment documentation Update user guides, knowledge base articles, onboarding materials, and other instructions to reflect the new enrollment process. 3. Prepare support teams Ensure help desk and deployment teams understand the change and know when the enrollment service URL may need to be provided. 4. Test enrollment scenarios Validate affected enrollment workflows before the change takes effect. Identify any required updates and determine where users may be prompted to enter the enrollment service URL. 5. Communicate with impacted users If users will need to enter the enrollment service URL, provide updated instructions before the change takes effect. Frequently asked questions Does this affect existing enrolled devices? No. Existing enrolled devices remain enrolled and aren’t affected by this change. Is Windows MDM-only enrollment being retired? No. Windows MDM-only enrollment remains supported. Only CNAME-based auto-discovery will become unsupported. Do I need to remove my EnterpriseEnrollment DNS record? Review your environment and DNS configuration requirements. This change only affects use of the record for Windows MDM-only enrollment auto-discovery. Will every user need to enter the enrollment service URL? Not necessarily. Some enrollment experiences may already provide enrollment server information. Manual entry is only required when the enrollment experience doesn’t provide it automatically. Should we begin testing now? Yes. We strongly recommend validating enrollment scenarios as early as possible and updating relevant documentation before this change takes effect. Next steps Review your Windows MDM-only enrollment processes and identify any dependencies on EnterpriseEnrollment DNS CNAME records. Update enrollment guidance, deployment instructions, onboarding materials, and help desk procedures that assume the enrollment service will be discovered automatically through DNS. Stay tuned to this blog for updates. If you have any questions, leave a comment below.
Proposal: Microsoft Motion – Core 2D Animation Studio for M365
Dear Microsoft Team, Following Microsoft Canvas, I propose Microsoft Motion: an independent core application for native 2D animation and motion graphics in Microsoft 365. Key Architecture: Ultra-Lightweight Core: Low-resource engine for fast keyframe animation, GIFs, and educational graphics. Modular Add-ons: Optional power tools for creators (2D character rigging, pixel animation, VFX). Seamless Canvas Integration: One-click asset pipeline between Canvas and Motion. This creates a unified, high-performance creative ecosystem for M365 without system bloat. Contact for technical discussions: email address removed for privacy reasons Best regardsProposal: Microsoft Canvas - Unified Creative Tool
Proposal: Unified Creative Suite & Performance Solutions The Concept ("Microsoft Canvas"): A lightweight application for Microsoft 365 that unifies Pixel Art, Vector Graphics, and Freehand Painting in a single engine. Designed for indie game developers, content creators, and designers. Technical & Structural Solutions: Custom Workspaces: Users select their target drawing style (Pixel, Vector, or Hybrid) at startup. The app loads only the required rendering engine, saving memory and CPU resources. Modular Packages: Keep the base app light and install extra toolsets/modules as on-demand packages. The "Fullness" Concept: A smart fill system that applies multi-toned textures, shading, and gradients as a cohesive object in one step. Impact: Bridges the gap between productivity and creative game/art design in M365, driving adoption among indie creators. Contact for feedback or technical discussions: [email address removed for privacy reasons]Windows Update certificate rotation in 2027
Some certificates used to establish trusted connections to Windows Update will expire on May 17 and June 19, 2027. While Microsoft is delivering solutions for most devices through normal monthly updates, some Windows versions will need IT action. Read the announcement and recommendations: Prepare for Windows Update certificate rotation in 2027. Questions? Leave us a comment below.Microsoft Intune Settings Catalog updated to support Windows 11, version 26H2
10.06.26 Update: The Windows security baseline for Windows 11, version 26H2 is now available for all customers in Microsoft Intune. This baseline reflects current Microsoft security recommendations and is the latest available Windows security baseline in Intune. Windows 11, version 26H2 is now available, and Microsoft Intune provides day zero support for validated Windows policy settings in the settings catalog. We continue to invest in the settings catalog infrastructure to ensure timely support for new Windows policy settings. This enables organizations to adopt new OS versions and features without delay and maintain secure, compliant, and well-managed environments. Settings catalog support for Windows 11, version 26H2 As part of Windows 11, version 26H2 settings catalog support, the settings catalog now includes all newly released settings and updates to existing settings introduced with the latest Windows 11, version 26H2 release. The following table highlights settings that are now available for configuration in the settings catalog and ready to use in device configuration profiles for Windows endpoints. While this update aligns with Windows 11, version 26H2 support, not every setting listed is a new 26H2 feature; some are existing Windows settings that are now available for management through the settings catalog. Category Policy Name Friendly Name Above Lock ConfigureAudioOnLockScreen Configure Audio On Lock Screen Application Management EnableMsixAllowedZones Enable MSIX Allowed Zones Device Lock ClearTextPassword Clear Text Password Device Lock RelaxMinimumPasswordLengthLimits Relax Minimum Password Length Limits Printers ConfigureWindowsReadyPrintDriverRanking Configure Windows Ready Print Driver Ranking Privacy LetAppsAccessForegroundText Let Apps Access Foreground Text Privacy LetAppsAccessForegroundText_ForceAllowTheseApps Let Apps Access Foreground Text – Force Allow These Apps Privacy LetAppsAccessForegroundText_ForceDenyTheseApps Let Apps Access Foreground Text – Force Deny These Apps Privacy LetAppsAccessForegroundText_UserInControlOfTheseApps Let Apps Access Foreground Text – User In Control Of These Apps Windows Update IgnoreWindowsUpdateGroupPolicies Ignore Windows Update Group Policies Windows Update SetMaxPauseDays Set Max Pause Days What this means for administrators Administrators can find the new settings within the settings catalog in the Microsoft Intune admin center under Devices > Manage devices > Configuration > Create > New policy. Select Windows 10 and later for the platform and settings catalog for the profile type. Before deploying Windows 11, version 26H2: Review the new and updated settings that apply to your organization. Test configuration profiles with a representative device group. Confirm that the targeted Windows edition and version support each setting. Monitor profile deployment and device status after assignment. Windows 11, version 26H2 security baseline Windows 11 version 26H2 security baseline will also be made available shortly in Intune. We are validating the final recommendations and plan to make the updated baseline available over the coming days following the Windows 11, version 26H2 release. The current baseline includes: A new recommendation for Configure Windows Ready Print driver ranking. An updated Turn off encryption support recommendation that changes the supported Transport Layer Security versions from TLS 1.1 and 1.2 to TLS 1.2 and 1.3. Configure NetBIOS settings - This setting is pending availability in the settings catalog and will be added to the baseline in a future update. Learn more Create a policy using settings catalog in Microsoft Intune Windows 11 - release information Learn about Intune security baselines for Windows devices We welcome your feedback. If you have questions about these settings or Windows 11, version 26H2 management in Intune, leave a comment on this post or follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation. Post updates: 10/06/26: The Windows security baseline for Windows 11, version 26H2 is now available in Microsoft Intune. We’ve also updated this post with the Settings Catalog additions introduced as part of Windows 11, version 26H2 support.Windows 11, version 26H2 security baseline
Update: The Windows 11, version 26H2 security baseline has been updated to reflect the general availability of Administrator protection. An updated v2 package is now available, and organizations should review and test the existing Administrator protection configuration as appropriate for their environment. You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Summary of Changes This release includes several changes since the Security baseline for Windows 11, version 25H2 to further strengthen enterprise security and align the baseline with current platform capabilities and industry standards. Security Policy Change Summary Printer\Configure Windows Ready Print driver ranking Configured as “Enabled” to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Internet Explorer\Internet Control Panel\Advanced Page\Turn off encryption support Updated from TLS 1.1 and TLS 1.2 to TLS 1.2 and TLS 1.3 to align with current security standards. User Account Control: Configure type of Admin Approval Mode (updated) Configured as “Admin Approval Mode with Administrator protection” to enable Administrator protection. User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection (updated) Configured as “Prompt for credentials on the secure desktop” to require credential verification for administrative elevation. Windows Ready Print driver ranking Configure Windows Ready Print driver ranking" is the newly added setting under Administrative Templates\Printers to control whether Windows prefers the modern inbox IPP class driver over third-party OEM drivers when installing new printers. We recommend enabling this policy to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Note that driver ranking applies when printers are installed via a connection method that supports IPP, such as USB or network multicast discovery. In those cases, if the printer supports IPP, Windows will install using the class driver even if a vendor V3/V4 driver is available. If the printer doesn't support IPP, or is installed directly as a TCP/IP printer, there's no change in behavior. Encryption Support We have updated the policy "Turn off encryption support" to allow only TLS 1.2 and TLS 1.3. Previous baseline releases permitted TLS 1.1 and TLS 1.2; however, TLS 1.1 is now considered obsolete and is no longer recommended for enterprise environments. This change aligns the security baseline with modern cryptographic standards while maintaining compatibility with widely deployed services that support current TLS versions. Administrator Protection (update) Administrator protection is now generally available. Organizations can enable it through Microsoft Intune or Group Policy. Important: Organizations should review and test their existing configuration and adjust these settings as appropriate for their environment. The security baselines for Windows 11, versions 24H2, 25H2, and 26H2 include settings that enable Administrator protection. The following policies are part of the security baseline: User Account Control: Configure type of Admin Approval Mode User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection An updated v2 package has been published for Windows 11, version 26H2, to reflect this change. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.Moving from Windows Autopilot to Windows Autopilot device preparation
By: Maggie Dakeva, Senior Product Manager - Microsoft Intune Organizations have spent years refining Windows Autopilot deployments. Profiles, Enrollment Status Page settings, group tags, dynamic groups, application assignments, and support processes all work together to deliver a familiar provisioning experience. Windows Autopilot device preparation is a re-architecture of Windows Autopilot designed around the customer asks we hear most often: simpler configuration, faster and more reliable setup, clearer progress for users, and near real-time deployment reporting for administrators. A single device preparation policy brings deployment and the out-of-box experience (OOBE) settings together, enrollment time grouping (ETG) places devices into the right security group during enrollment, and granular application and PowerShell script status makes troubleshooting easier. Autopilot device preparation is now the recommended solution for user-driven scenarios. Future engineering investments will focus on Windows Autopilot device preparation, enabling organizations to benefit from ongoing improvements to provisioning, reliability, reporting, and support. Moving eligible deployments positions your organization to benefit from those ongoing improvements while reducing the complexity of provisioning and support. So how do you move without disrupting devices that are already working - or forcing every deployment scenario to transition at once? The answer is a phased approach. Windows Autopilot and Windows Autopilot device preparation can coexist in the same organization. You can move eligible user-driven Microsoft Entra join populations in controlled waves, validate the full experience, and keep scenarios that still require Windows Autopilot on their existing path. The result is a practical way to adopt a simpler provisioning model while protecting the investments and workflows your organization still depends on. Start with the outcome, not a one-for-one migration Windows Autopilot device preparation brings enrollment settings, OOBE, device naming, required applications, PowerShell scripts, and enrollment-time targeting into a more coherent policy flow. The device preparation page, which replaces the Enrollment status page, gives users clearer progress and gives administrators more detailed deployment status for troubleshooting. Windows Autopilot device preparation includes two complementary capabilities: Device preparation policy defines the deployment experience, including OOBE settings, applications, scripts, naming, and ETG. Device association optionally binds a physical device to your organization before enrollment. It can establish corporate ownership and tenant affinity, enable associated-device OOBE settings, and support direct per-device policy assignment. Based on organizational needs, customers can choose to use device preparation policy, device association, or both. Device preparation policy provides the deployment configuration and experience, while device association adds pre-enrollment device affinity and device-based capabilities. Organizations can adopt each capability where it adds value to their provisioning model. But moving to that model shouldn't mean recreating every Windows Autopilot object exactly as it exists today. Instead, begin with the outcome each device population needs. Identify the required OOBE behavior, applications, scripts, naming, assignments, and support experience. Then design the device preparation policy and ETG model that delivers that outcome. This approach reduces inherited complexity and helps ensure that the new deployment is designed for Windows Autopilot device preparation and not constrained by the architecture it replaces. Choose what moves - and what stays Windows Autopilot device preparation is the recommended path for eligible user-driven provisioning scenarios, including: Corporate-owned Windows 11 devices User-driven Microsoft Entra join Windows 365 Continue using Windows Autopilot for scenarios that aren't supported or recommended for transition, including: Pre-provisioning Self-deploying mode Hybrid Microsoft Entra join Autopilot into co-management This isn't an all-or-nothing decision. The right transition plan deliberately separates eligible populations from valid exceptions. Translate the provisioning model Several familiar Windows Autopilot concepts have a corresponding role in Windows Autopilot device preparation: Windows Autopilot Concept Windows Autopilot Device Preparation Model Deployment profile Device preparation policy Enrollment Status Page profile Device preparation policy Enrollment Status Page in OOBE Device preparation page in OOBE Windows Autopilot registration Optional device association Profile and dynamic group-based targeting based on group tags Granular device preparation policy assignment with enrollment time grouping (ETG) using Microsoft Entra static security groups Device name template defined in the Autopilot deployment profile Device name template defined in the device preparation policy Windows Autopilot deployments report Windows Autopilot device preparation deployments report The goal is to preserve the required customer and administrator experience - not every historical configuration object. How the transition flow works A controlled transition can follow eight steps: Define the eligible population: Start with corporate-owned Windows 11 devices using user-driven Microsoft Entra join. Exclude scenarios that should remain on Windows Autopilot. Design enrollment time grouping (ETG): Create assigned, static Microsoft Entra security groups for populations that genuinely differ by location, role, device type, or required configuration. Don't build the new design around a group tag or a device object that must exist before enrollment. Create device preparation policy equivalents: Inventory each deployment profile and Enrollment Status Page pairing. Map the required OOBE settings, naming, applications, PowerShell scripts, blocking requirements, and dependencies into the new device preparation policy. Evaluate whether device association is required for all scenarios. For user-targeted deployments that don't need pre-enrollment tenant affinity or per-device policy selection, the organization can use the device preparation policy without device association and simplify the setup and management of device onboarding. For devices that need automatic corporate ownership, OOBE customization settings, or stronger pre-enrollment trust, continue with step 5. Pre-associate eligible devices. For existing registered or enrolled devices, collect the pre-association information by collecting the diagnostics logs, then exporting the DeviceLink CSV file found in the logs. Upload the CSV in the Associated devices blade in Intune and assign a device preparation policy to the device. Assignment can be done during the CSV upload process or after. Confirm that the device reaches the Pre-associated state before its planned reset or refresh. Note: Device pre-association is only available for devices that meet the minimum OS and hardware requirements , including TPM 2.0. Pilot the complete OOBE experience. Start with new devices or reset a small, representative set of devices. Validate policy selection, ETG placement, applications, scripts, naming, progress reporting. Expand and pre-associate remaining devices. Pre-associate additional populations in controlled waves. You do not need to force resets to all existing enrolled devices but simply pre-associate to prepare them so they enroll via the Windows Autopilot device preparation flow whenever each device next undergoes a natural or required reset. Retire registered flows. Retire deployment profiles, Enrollment Status Page profiles, groups, registrations, and processes only after reporting confirms that no active or planned population still depends on them. Pre-association doesn’t reset the device or disrupt its current use. The device remains enrolled and productive until its next natural or required reset, when Windows Autopilot device preparation takes effect. Don't remove the Windows Autopilot registration early. Doing so can remove Autopilot properties and affect dynamic-group membership that supports the device's current configuration. The next time the device enters OOBE, Windows recognizes the association and follows the Windows Autopilot device preparation path. If a device is both registered and associated, association takes precedence. Plan the pilot around this behavior rather than expecting an automatic fallback to Windows Autopilot. OEM and partner note: Device association uploads are currently only supported through Intune. OEM and partner pre-association scenarios aren't supported yet, but they’re on the roadmap. What this means for your organization You can prepare existing devices for transition while they remain enrolled and in use. You can move one eligible population at a time instead of committing to an organization-wide cutover. You can preserve Windows Autopilot for scenarios that still require it. You can use the transition to simplify assignment and provisioning logic rather than carry every legacy object forward. You can retire the old configuration gradually - after validation and dependency checks confirm that nothing still relies on it. A sample customer pilot setup scenario Consider a multinational organization, Contoso, that uses group tags to distinguish devices in the United Kingdom and Germany and to identify different device use cases. Dynamic groups use those tags to determine which deployment profile, Enrollment Status Page configuration, applications, policies, scope tags, and naming rules apply. The organization wants to move its eligible user-driven Windows 11 populations to Windows Autopilot device preparation without reproducing the same pre-created record and dynamic-group dependencies. The Contoso deployment team transitions to Autopilot device preparation with the following steps: Create static security groups for each required configuration. The team creates assigned Microsoft Entra security groups such as User Devices UK and User Devices Germany. It creates separate groups only when location, role, device type, scope, or required configuration differs. Create a device preparation policy for each population. The team creates a policy such as User Devices UK DPP and User Devices Germany DPP. Each policy contains the required OOBE settings, applications, PowerShell scripts, blocking behavior, and device name template, and identifies the corresponding enrollment time grouping (ETG) security group. Assign the device preparation policies to each population. The team assigns each device preparation policy to the respective sets of devices at time of pre-association or later. During enrollment, the device joins the group selected by the device preparation policy. For example, devices assigned the User Devices UK DPP join the User Devices UK group and receive the apps and policies assigned to that group. Configure scope through the static groups. The team assigns the appropriate regional scope tag to each ETG security group. The device receives the associated scope tag when it joins the group during enrollment. Set a naming template for each device preparation policy. The organization uses a naming convention where devices start with a prefix indicating their location. The team sets UK-%SERIAL% in User Devices UK DPP and DE-%SERIAL% in User Devices Germany DPP. Pre-associate pilot devices without disruption. Selected devices can be pre-associated while they remain enrolled and in use. The team collects diagnostics logs via script, extracts the DeviceLink CSV files, imports them in Intune, confirms the devices reach the Pre-associated state, and keeps the Windows Autopilot registration in place until the approved reset or refresh window. Validate the end-to-end experience with representative devices. The admin team uses test devices representing each target population to verify policy assignment, static group membership, scope tags, naming, applications, scripts, reporting, and successful completion of the device preparation flow. Existing devices can remain in service until their next natural or required reset. Seven-step regional Windows Autopilot device preparation rollout workflow, from creating security groups and device preparation policies through regional configuration, pilot association, and device validation. This scenario is illustrative, not a completed deployment or a measured customer outcome. It shows the transition pattern: define the supported scope, replace group-tag dependencies with ETG, move Enrollment Status Page and deployment profile settings to the device preparation policy, decide where device association adds value, validate end to end, and expand in controlled waves. Get started Begin with one eligible user-driven Microsoft Entra join population. Map its current Windows Autopilot outcomes to enrollment time grouping (ETG) and a device preparation policy. Pre-associate a representative pilot, validate the complete reset-to-desktop experience, and expand only when the results meet your deployment and support criteria. Moving to Windows Autopilot device preparation doesn't require a forced cutover. It requires a clear boundary, a deliberately redesigned assignment model, and evidence from each wave. That gives IT a controlled path toward simpler provisioning while keeping every device population on the experience that supports it best. Learn more Windows Autopilot device preparation overview Compare Windows Autopilot device preparation and Windows Autopilot Windows Autopilot device preparation user-driven Microsoft Entra join workflow Windows Autopilot device preparation requirements We’d love to hear your feedback! Share your thoughts in the comments below, follow us on LinkedIn or reach out to us on X @IntuneSuppTeam or @MSIntune.
