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.Introducing device association for Windows Autopilot device preparation
By: Maggie Dakeva, Senior Product Manager - Microsoft Intune We’ve heard organizations want Windows deployment to be simple for employees and predictable for IT admins. But before a device enrolls, how does the organization know that the device is really one of its own - and how can IT make sure the right experience and policy reach that device regardless of who signs in? Today, we're announcing device association for Windows Autopilot device preparation, a new way to bind a physical Windows 11 device to your organization before enrollment begins. Device association uses hardware-backed attestation to create a trusted relationship between the device and your tenant at the start of the provisioning journey. That relationship helps Windows Autopilot device preparation recognize the device during the out-of-box experience (OOBE), automatically treat it as corporate-owned, and apply the experience and policy intended for that specific device. The result is a more secure, more consistent, and more device-centric onboarding flow. Start with the device, not just the user Windows Autopilot device preparation already gives IT teams a straightforward way to configure new Windows devices with the apps, scripts, and policies employees need. Device association extends that experience by allowing IT to target a device preparation policy directly to a device before it enrolls. This is especially valuable when the deployment experience needs to follow the hardware rather than the person signing in. For example, one employee can enroll multiple devices that serve different purposes, and each device can receive its own device preparation policy. When both device-based and user-based assignments are available, the device-based assignment takes precedence. That gives administrators greater confidence that the correct configuration reaches the correct device from the beginning of its lifecycle. Create a simpler out-of-box experience Because an associated device is recognized before enrollment, IT can configure more of the Windows setup experience in advance. Device association enables organizations to: Configure Language and region. Automatically configure the keyboard and skip the keyboard selection page. When the device uses a Wi-Fi network connection during OOBE, the language and keyboard selection screens aren't hidden. Hide the Microsoft Software License Terms page. Hide privacy settings during OOBE. Apply a device name template that uses the serial number or a randomized value. Hide account-change options on company sign-in and domain error pages. These controls reduce the number of decisions an employee must make while setting up a device and help create a consistent, organization-ready experience from the first screen. Strengthen trust before enrollment Device association isn't only an experience improvement. It establishes device trust earlier in the deployment process. The association uses hardware-based attestation and TPM-backed cryptographic validation to verify the device's identity. Tenant affinity is stored in the device's UEFI firmware, where it persists across a Windows reset, operating system reinstallation, or removal of enrollment. This durable, hardware-backed relationship helps ensure that the device presenting itself for preparation is the device the organization intended to onboard. Associated devices are also automatically marked as corporate-owned. If your organization blocks personally owned Windows devices with Intune enrollment restrictions, device association can be used instead of uploading a separate corporate identifier. You can continue to use corporate identifiers where they fit your process, but an associated device doesn't need both. How the device association flow works Device association is designed as a clear workflow that starts with IT and finishes automatically during OOBE: Create the device preparation policy. Configure the apps, scripts, deployment settings, OOBE experience, and optional device name template that should apply. Export the device information. During OOBE, a technician opens the Autopilot menu and exports the DeviceLink CSV with the device information required for pre-association to a USB. For an existing device, the same information can be collected from Autopilot diagnostic logs. Figure 1. The Windows Autopilot menu with Assign device association selected. ormation was exported to a removable drive. Pre-associate the device in Intune. In the Microsoft Intune admin center, go to Devices > Enrollment > Device association > Devices, upload the CSV, and optionally assign a device preparation policy directly to the device. Complete association. When the device connects to a network in OOBE, it finds the pre-association record and completes association automatically. A technician can also trigger this step manually from the Autopilot menu. Enroll and prepare the device. The device receives the applicable device-targeted policy, is marked as corporate-owned, and presents the configured OOBE experience. Monitor the deployment. Administrators can review association state and assigned policy in the Device association blade and filter devices by state, policy, manufacturer, or model. The device association lifecycle consists of the following states: Pre-associated: The device was added on the service side and is waiting to complete association in OOBE. Associated: The device completed association by writing the tenant affinity to UEFI and is ready for enrollment. This happens automatically when a pre-associated device syncs with an MDM provider. Pending removal: A request to remove the pre-association is being processed. A device's association can be removed by an administrator or partner with physical access to the device who manually runs a local script that clears the tenant affinity information stored in the device's UEFI. This action should be performed only when the device should no longer be associated with the organization, such as when it is sold, recycled, or transferred. Manage the full device lifecycle The association remains with the device through reset and reinstallation, helping preserve the organization's intended provisioning path when a device is redeployed internally. When a device permanently leaves the organization - for example, when it's sold, recycled, or transferred—the association should be removed as part of decommissioning. Because the tenant affinity is stored on the device, clearing a completed association can be performed via script locally on the physical device, without access to the service. This lifecycle model is intentional: association is durable during normal reuse inside the organization, while permanent removal can be completed by an admin or partner who has control of the physical device. Designed to work alongside your existing Windows Autopilot strategy Device association is part of Windows Autopilot device preparation and can coexist with traditional Windows Autopilot deployments in the same organization. For a device already registered with Windows Autopilot, the association state determines which deployment runs. If the device isn't associated, its Windows Autopilot registration takes precedence. If it is associated, the Windows Autopilot device preparation deployment takes precedence. This gives organizations a practical path to introduce device association while continuing to support existing Windows Autopilot investments. Get started To use device association, you'll need a supported physical Windows 11 device with TPM 2.0 enabled and in a healthy state. Virtual machines aren't supported because device association relies on hardware-backed identity verification. Start by reviewing the Windows Autopilot device association requirements, then create or update your Windows Autopilot device preparation policy. From there, export the device information, pre-associate the device in Intune, and let Windows complete the trusted association during OOBE. With device association, Windows Autopilot device preparation moves device trust, targeting, and customization earlier in the deployment journey - before enrollment and before the employee reaches the desktop. That means fewer setup decisions for users, more predictable deployments for IT, and stronger confidence that the right device is joining the right organization with the right configuration. Learn more Overview of Windows Autopilot device association Requirements for Windows Autopilot device association Set up Windows Autopilot device preparation with device association
Rethinking “Allow my organization to manage my device” Why opt‑in enrollment works better for Intune
By: Ramya B Sharma – Senior Software Engineer | Microsoft Intune A new public preview feature in Microsoft Intune, we’ve introduced a toggle that allows admins to block automatic mobile device management (MDM) enrollment during the modern app sign-in flow on Windows. This enhancement directly responds to frequent customer requests for greater control over device enrollment, specifically the ability to prevent automatic MDM enrollment on Windows devices during app sign-in. While Microsoft Entra generally recommends automatic enrollment by default, most Intune customers - especially those supporting bring your own device (BYOD), mixed ownership, or multi-tenant access scenarios - benefit from an opt-in enrollment model instead. Recommended best practice Keep “MDM user scope” set to All so enrollment is available when needed, but configure the new toggle “Disable MDM enrollment when adding a work or school account on Windows” to Yes so MDM enrollment is not automatically selected by default during app sign in. This ensures devices are enrolled into Intune only through intentional enrollment flows, reducing accidental enrollments, support burden, and difficult recovery scenarios. Learn more: Automatic MDM enrollment in the Intune admin center. Why this matters For years, Windows users signing into work or school apps have been presented with: “Allow my organization to manage my device.” In most environments, this option was selected by default or clicked through without full understanding. That single action could result in: Microsoft Entra device registration Automatic Intune MDM enrollment Immediate policy application to the device For IT teams, this often led to: Unintended device enrollments Personal or BYOD devices becoming fully managed Difficult unenrollment and recovery experiences The new public preview toggle directly addresses these long‑standing issues. How the modern app sign in enrollment flow works When a user signs into a Microsoft work or school app on Windows, Windows may start a device registration flow. Historically, if: Automatic enrollment was enabled, and The user was in the MDM user scope Then registration could immediately turn into full MDM enrollment, even though the user only intended to sign into an app. What the new toggle changes The new setting“Disable MDM enrollment when adding a work or school account on Windows”: Allows account registration Stops the flow before MDM enrollment Removes the “Allow my organization to manage my device” screen from the app sign-in flow Preserves intentional enrollment paths Important: This setting applies to modern app sign in flows, not Windows settings–based enrollment. Allowing enrollment versus forcing enrollment This distinction is critical. Allowing enrollment: MDM user scope is configured to “All” or “Some” Enrollment is available when needed Devices enroll through deliberate flows Forcing enrollment Enrollment triggered implicitly App sign in becomes an enrollment decision Users may not realize the device is managed Recovery is harder later The new toggle lets organizations separate these behaviors. Impact across common Windows enrollment scenarios Scenario Default behavior Opt-in recommended behavior BYOD / personal devices High risk of accidental enrollment App access without device takeover Microsoft Office / Teams sign in May initiate MDM enrollment No MDM enrollment unless user chooses Microsoft Entra hybrid join (corporate) Microsoft Entra joined Microsoft Entra joined Windows settings enrollment MDM enrollment MDM enrollment Windows Autopilot / provisioning MDM enrollment MDM enrollment Security and governance benefits Opt-in enrollment supports: Least surprise Explicit consent Cleaner BYOD posture Safer break glass scenarios Reduced support escalations It also aligns well with Conditional Access and app level protection strategies. When to use the default behavior Default automatic enrollment may still be appropriate for: Fully corporate owned device fleets Locked down environments Dedicated provisioning scenarios The key is that it should be a conscious decision, not an accidental one. Summary In conclusion, for most organizations, the modern best practice is: Allow enrollment everywhere - require intent. Using the new Intune toggle to make enrollment opt-in during app sign in reduces risk, improves user trust, and simplifies the device lifecycle - without sacrificing Intune’s management capabilities. Recommended reading: For a concrete example of the end‑user experience with this model, see Step 6: Understand Microsoft Edge for Business End User Experience for Windows, which walks through how opt‑in enrollment and app‑level management are presented to users in Microsoft Edge for Business. Understand Microsoft Edge for Business End User Experience for Windows. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Configure Delivery Optimization for Windows to save bandwidth and speed up deployments
By: Carlos Diaz - Sr. Product Manager and Jason Sandys - Principal Product Manager | Microsoft Intune Delivery Optimization is built into Windows and can help reduce bandwidth usage during app and update deployments. Instead of downloading content from the internet every time, devices can download it from nearby devices or a local cache when available. Many organizations leave Delivery Optimization at its default settings or disable it entirely. As a result, they may miss opportunities to reduce network traffic, improve deployment performance, and make better use of existing network resources. This article focuses on the Delivery Optimization scenarios and the common configurations that Intune admins use most often: large-scale patching, Windows Autopilot provisioning, branch office bandwidth management, and Microsoft Connected Cache for scenarios where peer-to-peer sharing alone isn't enough. How Delivery Optimization works Delivery Optimization is an HTTP downloader with built-in peer-to-peer capabilities available in supported versions of Windows. It helps distribute Windows updates, Microsoft 365 Apps updates, Microsoft Defender definition updates, Microsoft Store apps, Intune Win32 apps package and other supported content. Delivery Optimization checks local sources before falling back to internet content caches. The most important Delivery Optimization policy setting is Download Mode, which determines how devices discover peers. Mode Description Mode 1 (LAN) Devices share content with peers behind the same IP/NAT boundary. Mode 2 (Group) Devices share content within a defined group, such as an Active Directory site, domain, or custom group ID. Recommended for environments with multiple VLANs or segmented networks. Mode 3 (Internet) Devices can share content with internet peers outside the organization. This mode is rarely used in enterprise environments. Delivery Optimization checks sources in this order: LAN or group peers and, if configured, Microsoft Connected Cache in parallel. Internet peers, if allowed in the Download Mode setting Internet content caches, which are always available as the final fallback Regardless of the mode you choose, the goal is to keep content download traffic local whenever possible. Common misconceptions Before configuring Delivery Optimization, it's worth addressing a few common misunderstandings we’ve heard from customers. "Does Delivery Optimization use my bandwidth to upload content to the internet?" In Mode 1 (LAN), peer sharing is restricted to your local subnet. Content is only shared with other devices on the same network segment, and no content leaves your LAN. Additionally, you have full control over upload usage through the Monthly upload data cap setting. "Is Delivery Optimization the same as BranchCache?" While both technologies help reduce bandwidth usage, they are built on different architectures and support different scenarios. BranchCache relies on BranchCache-enabled content servers to cache and distribute content, whereas Delivery Optimization is built directly into Windows and is designed to work natively with cloud-delivered content, including Windows updates, Microsoft Store apps, and Microsoft 365 Apps. "We disabled Delivery Optimization years ago. Is there any reason to revisit it?" Yes. Delivery Optimization has evolved significantly and now offers extensive management capabilities through the Intune Settings Catalog. Administrators can configure download modes, define group boundaries, control bandwidth usage, set cache sizes, and limit uploads. If Delivery Optimization was disabled in the past, it may be worth reevaluating your configuration. When properly configured, it can help reduce bandwidth consumption, improve content distribution efficiency, and accelerate update and application deployments. Essential policies The following settings, available in the settings catalog under Delivery Optimization, provide you a strong starting point: Setting Default Value* Recommended Value What It Does DODownloadMode 1 (LAN) 1 (LAN) Keeps peer-to-peer sharing within your subnet or Delivery Optimization group. DORestrictPeerSelectionBy 1 1 Devices discover and peer with others on the same subnet. DOMaxCacheSize 20% 20% to 30% Amount of local disk space allocated to the Delivery Optimization cache. DOMinFileSizeToCache 50 MB 5 MB Minimum file size eligible for caching and peer-to-peer distribution. DOMaxCacheAge 259,200 seconds (3 days) 1,209,600 seconds (14 days) Determines how long cached content remains available before cleanup. DOMonthlyUploadDataCap 20 GB 20 GB Limits the total amount of data a device can upload to peers each month. *The default values in this table are for Windows 11. The table above lists common Delivery Optimization settings, their default values, and recommended starting values. However, the best configuration depends on your network topology, device count, update cadence, and whether you’re using Microsoft Connected Cache. Use the scenario guidance below to tune from the baseline. for the full policy reference review: Configure Delivery Optimization (DO) for Windows. The defaults provide some immediate value, but organizations often achieve better results by: Defining peer groups Increasing cache size Increasing retention periods Lowering the minimum file-size threshold when appropriate When configuring Delivery Optimization, avoid managing the same setting from multiple locations, such as settings catalog and custom policy. Using the settings catalog as your primary management location can help reduce conflicts and simplify troubleshooting. Windows quality updates, feature updates, and Office updates are typically the largest bandwidth consuming events most organizations face. A 1 GB cumulative update pushed to 10,000 devices means 10 TB of traffic from the internet unless Delivery Optimization lets devices share locally. This is where properly configured Delivery Optimization pays for itself immediately. Coordinate Delivery Optimization with deployment rings. Start with a small seeder ring, typically 5 to 10 percent of devices, so those devices populate peer caches before broader rings begin hours or days later. If Microsoft Connected Cache is deployed, the same seeder ring also populates the cache node, creating a persistent local source for later rings. Scenario 1. Large-scale update deployments Large scale deployments vary greatly in complexity and challenges. Device count isn’t the only factor to consider. Network infrastructure and configuration can also play a role in your configuration and deployment of Delivery Optimization. How you tune Delivery Optimization for large-scale updates depends heavily on your WAN topology. The two most common designs call for different approaches: Star (hub-and-spoke) topology Branches connect to a central hub; internet traffic may be backhauled. Every update byte a branch device pulls from the internet crosses the internal link between the hub and spoke. Group boundaries: Identify local LAN configurations at branch locations. If all devices at a branch location are on a single subnet, use DODownloadMode = 1 with DORestrictPeerSelectionBy=1 to restrict peers to that subnet. If a branch site has multiple subnets, DODownloadMode = 2 with a branch-specific DOGroupID is more effective because devices can discover peers throughout the branch instead of being limited to their local subnet. Tip: Delivery Optimization Has Evolved Many organizations disabled Delivery Optimization during early Windows 10 deployments after experiencing unexpected WAN traffic. At that time, peer sharing controls were far less granular, making it difficult to limit content sharing to devices within the same network or site. As a result, some organizations chose to disable Delivery Optimization entirely and missed potential bandwidth savings from peer-to-peer content distribution. Today, modern Delivery Optimization policies provide significantly more control through features such as Group mode, Group IDs, subnet-based peer restrictions, bandwidth management settings, and integration with Microsoft Connected Cache. These capabilities help organizations realize the benefits of peer caching while maintaining tighter control over network traffic. Bandwidth throttling: Spoke links are often the bottleneck. Use DOPercentageMaxBackgroundBandwidth to limit Delivery Optimization background downloads to 10% to 25% of available bandwidth during business hours. Configure DOSetHoursToLimitBackgroundDownloadBandwidth to define the hours when those limits apply, then relax or remove the limits outside business hours. Cache retention: Set DOMaxCacheSize to 40% to 50% and DOMaxCacheAge to match your final deployment ring so cached content survives all ring phase days at branches. Branch peers are the only local sources. They need to hold content long enough for the full ring cycle. Hub site: Devices at the hub have direct internet access and also typically have more bandwidth available. Standard cache settings (20% to 30%, 3 days) are usually sufficient. Tip: Combine Peer Caching and Microsoft Connected Cache In star (hub-and-spoke) network topologies, Microsoft Connected Cache (MCC) can deliver the greatest bandwidth savings at central hubs and larger branch offices. By caching frequently requested updates and applications locally, MCC helps reduce the amount of content that must traverse upstream WAN links. You can configure an MCC server directly in your Delivery Optimization policy by specifying: DOCacheHost=<MCC FQDN> When configured, Delivery Optimization continues to prioritize content from nearby peers. If the requested content isn't available from peers, devices will attempt to download it from Microsoft Connected Cache. If the content isn't present in the cache, devices automatically fall back to Microsoft's internet content source. Think of the content retrieval process as a layered approach: Peers → Microsoft Connected Cache → Internet. This hierarchy helps optimize bandwidth usage while maintaining reliable access to updates and applications. Distributed topology With a distributed topology, all locations have their own local internet access. Each site reaches the internet directly, so the WAN penalty for a cache miss is lower. Group boundaries: Set DODownloadMode=2 and set a DOGroupID. The key is that each physical site is its own peer group. DORestrictPeerSelectionBy = 1 (Subnet) is still recommended but less critical because cross-site peer-to-peer traffic is less likely. Bandwidth limits: More relaxed than star. 25% to 50% during business hours is typical since each site has its own internet cache path. Tip: With local internet connectivity and Delivery Optimization Group mode, many locations achieve excellent bandwidth savings with no additional infrastructure. Microsoft Connected Cache adds value primarily at the largest locations (more than 100 devices). Scenario 2. Branch offices with limited WAN Branch offices often see the biggest Delivery Optimization savings. Instead of every device pulling the same update over the WAN, one device can download from the internet and share locally with peers on the subnet. Use DODownloadMode = 2 and assign a unique DOGroupID per branch location to keep peer-to-peer traffic within the branch. Set aggressive background limits (15% to 25% of link speed) to protect line-of-business applications. For very small branches with fewer than 10 devices, or locations where devices are frequently reimaged, consider adding a Microsoft Connected Cache node. A small cache server with a 100 GB drive provides a persistent local source that doesn't depend on any single peer being online. Scenario 3. Mass provisioning and Windows Autopilot During Windows Autopilot bulk provisioning or mass reimaging, many devices request identical content at the same time. Without Delivery Optimization, every device downloads independently from the internet cache, often saturating internet links and extending provisioning times. For environments with repeated content consumption, such as shared devices, labs, and kiosks that get reimaged frequently, peer-to-peer distribution has a structural limitation. After a mass reimage, no device has cached content available to share. This is where Microsoft Connected Cache provides the greatest value. Because the cache node retains content on-premises independent of device state, the first device after a wipe can download from the local cache rather than the internet cache. If you're using peer-to-peer alone, consider staggering reimage schedules so that some devices always have content available to share. Intune already uses Delivery Optimization to distribute Win32 and Microsoft Store apps, so no extra setup is needed beyond the core Delivery Optimization policies. The main tuning is around thresholds and retention. Lower DOMinFileSizeToCache from 10 MB to 5 MB so snaller app installers qualify for peer-to-peer sharing and extend DOMaxCacheAge to 7 days (604800 seconds) to accommodate app deployments that often span a full week. During large provisioning events, be generous with cache resources. Increase DOMaxCacheSize to 50 percent or higher to ensure early devices have room to cache and share content. Set DOMonthlyUploadDataCap to 0 (unlimited) so the first-wave of devices can serve a larger number of peers. Finally, provision devices in stages whenever possible. Even a 15-minute delay between groups gives Delivery Optimization time to build peer availability before the next wave starts. Scenario 4. Devices that move between locations In environments where employees frequently move between locations, isolating peer traffic can be challenging. For example, a device assigned to the Group ID for Branch A may be physically connected at Branch B, causing it to search for peers across the WAN. In this scenario, use DHCP to provide the appropriate DOGroupID and, when applicable, DOCacheHost source for the device’s current location. DOCacheHostSource=1 and set the DHCP Option 235 at the site to the FQDN of the Microsoft Connected Cache. DOGroupIdSource=3 and set the DHCP Option 234 to the GUID for the GroupID. Go further with Microsoft Connected Cache Microsoft Connected Cache is an optional on-premises content cache. It complements Delivery Optimization by providing a persistent local source when peers are unavailable. Tip: Start with Peer-to-Peer Caching First Before deploying Microsoft Connected Cache (MCC), consider optimizing Delivery Optimization peer-to-peer caching. Many organizations achieve substantial bandwidth savings through properly configured download modes, peer groups, cache settings, and deployment rings without introducing additional infrastructure. Peer-to-peer caching is often the simplest and most cost-effective first step because devices can share content directly with one another, reducing internet downloads and WAN utilization across the organization. Microsoft Connected Cache becomes particularly valuable when peer sharing alone cannot fully meet business requirements, such as locations with few devices, frequent device reimaging, limited peer availability, or a need for a persistent on-premises content source. In these scenarios, MCC can complement Delivery Optimization to further reduce bandwidth consumption and improve content availability. Microsoft Connected Cache is most valuable at small locations with few peers, in environments with frequent device resets, or anywhere large content volumes need a guaranteed local source. Devices can find the cache node in two ways: Static (Intune policy): Set DOCacheHost to the FQDN of your Microsoft Connected Cache server in the Intune Settings catalog. Simple, static, works well for single-site deployments. Dynamic (DHCP Option 235): Set DOCacheHostSource = 1 and configure DHCP Option 235 with the MCC server FQDN. Devices discover the correct cache node automatically based on network location. This is the preferred approach for multi-site deployments. When using Microsoft Connected Cache, configure DODelayForegroundDownloadFromHttp to 30 seconds and DODelayBackgroundDownloadFromHttp to 60 seconds. These timeouts control how long Delivery Optimization waits for a local source before falling back to the internet cache; they don’t control download speed. For setup details and hardware requirements, refer to: Release Notes for Microsoft Connected Cache for Enterprise and Education. Troubleshooting tips Slow downloads: The fallback timeout is the most misunderstood Delivery Optimization setting. It controls how long a device waits for a local source before requesting from the internet cache, not download speed. If downloads are slow, check network routing, DNS, and firewall rules. Cache misses: Internet cache Vary headers can prevent content from being cached on the first request. Microsoft Connected Cache respects these headers, which can cause initial cache misses. The product team is actively working on a fix. Diagnostics: Run the Delivery Optimization troubleshooter at aka.ms/DO-Fix for automated diagnostics. PowerShell: Use Get-DeliveryOptimizationStatus in PowerShell to see real-time download source, peer count, and bytes per source for each active download. Delivery Optimization reporting: Centralized reporting is available in the Windows Update for Business Delivery Optimization report or through PowerShell cmdlets. Monitor Delivery Optimization. Get started Delivery Optimization is already available on supported Windows devices you manage. The configurations in this post take minutes to deploy through the Intune settings catalog and can save significant bandwidth with every update cycle and application deployment. Start with the essential policies table, pilot the profile with a small device group, and review Windows Update for Business reports after a couple of patch cycles to measure the impact. Many organizations achieve their goals using Delivery Optimization peer-to-peer caching alone. For scenarios where peer caching is insufficient or a persistent local cache is required, Microsoft Connected Cache is available as an additional option. The product team is active in the Connected Cache Community at aka.ms/ConnectedCacheCommunity, and feature ideas can be submitted through the Intune feedback portal at aka.ms/IntuneFeedback. Resource Link Configure Delivery Optimization Configure Delivery Optimization Delivery Optimization Troubleshooter Run the Delivery Optimization Troubleshooter Microsoft Connected Cache Release Notes View MCC Release Notes Connected Cache Community Join the Community DO + MCC AMA Recording Watch the AMA Recording Intune Feedback Submit Product Feedback If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.Hybrid Autopilot as a Transition Strategy Toward Cloud-Native Endpoint Deployment
Hybrid Autopilot sometimes gets labeled as “legacy.” But in large enterprise environments, it can be a very practical transition architecture toward full cloud-native endpoint deployment. In one global rollout scenario I supported across multiple regions in a large enterprise environment, Hybrid Autopilot played exactly that role — helping modernize deployment while maintaining alignment with existing identity and infrastructure dependencies. Instead of treating Hybrid Autopilot as a long-term destination, we approached it as a controlled stepping stone toward Entra ID–only deployment. The challenge Many multinational environments still rely on: on-prem Active Directory legacy application dependencies region-specific provisioning constraints existing device naming standards network-dependent enrollment scenarios Moving directly to cloud-only join is often the goal - but not always realistic. Hybrid Autopilot helped bridge the gap. What worked well for us Several design decisions helped make Hybrid Autopilot scalable and predictable across regions. Machine-level secure connectivity before user sign-in One important enabler for Hybrid Autopilot in internet-based deployment scenarios was establishing machine-level secure connectivity before user authentication. Allowing devices to reach domain services during provisioning made it possible for offline domain join steps to complete successfully even when devices were deployed outside the corporate network. This supported direct-to-user deployment models without requiring traditional on-premises connectivity during setup, which becomes especially important in large enterprise global rollout scenarios. OEM hardware hash integration enabling deployment tagging and Zero Trust alignment Leveraging OEM-provided hardware hashes allowed devices to be pre-registered into Autopilot before shipment and associated with deployment group tags aligned to regional rollout logic. This enabled a consistent enrollment pipeline across distributed device shipments and created the foundation for automated targeting and naming alignment during provisioning. It also supported a stronger Zero Trust posture by ensuring that only officially procured and pre-registered corporate devices were allowed to enroll through the managed provisioning workflow. This helped reinforce device trust at the enrollment stage and reduced the risk of unauthorized or unmanaged endpoints entering the environment. Country-based deployment tagging Country group tagging then allowed hostname naming alignment to remain consistent with regional standards while enabling policy targeting and configuration logic to scale globally. This helped maintain predictable deployment behavior across regions while supporting large enterprise rollout consistency. Maintaining identity continuity during transition Hybrid join allowed compatibility with existing identity-dependent workflows to remain intact while preparing the environment for future Entra-native deployment approaches. Rather than forcing architectural change everywhere at once, this allowed transformation to proceed in controlled phases across regions. Why Hybrid Autopilot still matters? In large enterprise environments, endpoint modernization rarely happens in a single step. Hybrid Autopilot can support: modernization without disruption phased identity transition planning global rollout consistency alignment with existing provisioning standards preparation for cloud-native endpoint strategies When positioned correctly, it becomes part of the transition journey rather than technical debt. Curious how others are approaching this I’m interested to hear how others in large enterprise environments are using Hybrid Autopilot today. Are you treating it as a long-term deployment model, a transition architecture, or actively moving toward Entra ID–only deployment? It would be great to compare approaches and lessons learned across different enterprise rollout scenarios.Autopilot V1 vs “Device Preparation” (V2): Great direction — but is it enterprise-ready yet?
We evaluated Autopilot v2 but decided to stay on Autopilot v1 for large‑enterprise scale. Group Tags + dynamic groups are still essential for our device naming, segmentation, and governance model. We intentionally limit apps in EAS to speed up provisioning, so EAS‑based app deployment in v2 isn’t a compelling advantage for us. v2 looks promising, but until there’s stronger parity for enterprise‑scale targeting and naming, v1 remains the better fit. Curious how others at scale are balancing provisioning speed vs. segmentation without Group Tags.Debunking the myth: Cloud-native Windows devices and access to on-premises resources
By: Roger Southgate - Sr. Product Manager | Microsoft Intune Myth vs reality Myth: Cloud-native Windows devices can’t access on-premises resources such as file shares or legacy applications. Reality: With minimal or no configuration, cloud-native devices can seamlessly access on-premises resources using NTLM or Kerberos. Introduction Microsoft’s vision for secure, productive workplaces is clear: adopt cloud-first services, integrate Zero Trust throughout, and deploy Windows 11 devices as cloud-native endpoints to stay agile and future-ready. If you’re yet to begin this journey, review the Set up and configure a cloud-native Windows endpoint with Microsoft Intune tutorial. For context, a cloud-native device is a Windows device, joined to Microsoft Entra and managed by Intune. No domain join, no group policy, and no Microsoft Configuration Manager required. Leveraging complementary services such as Windows Autopilot and Windows Autopatch enables users to self-provision their devices, work remotely, and remain secure by applying the latest Windows Updates. But what about user’s data, files, and applications that they require to be productive? Moving to the cloud is a common goal for many organizations, though practical realities can make this a gradual process. Legacy technology, operational constraints, complexity, and other challenges can hinder adoption. While the goal might be to migrate all data to cloud-friendly repositories such as SharePoint Online and OneDrive, and transition applications to SaaS solutions, these migrations don’t happen overnight. In many cases, data may remain scattered across internal servers and on-premises repositories, creating scenarios where cloud-native devices still need to connect to these resources. Accessing on-premises resources What happens when you take a cloud-native device and try to access an on-premises resource such as a file share? Similarly, what about access to an application that is located on-premises? While these are just two examples, they can be used interchangeably in this scenario since the process of getting access is the same, regardless of apps or files. This is a topic that is raised (and often misunderstood) when discussing the transition of Windows devices to the cloud. Cloud-native devices were designed to take this scenario into account and have seamless access to on-premises resources. Note: This assumes you have line-of-sight to an Active Directory Domain Controller and that your on-premises resources, such as file shares and applications, use Windows authentication. Like a domain-joined device, a cloud-native device won’t have line of sight by default unless it’s physically on-site (for example, in a corporate office). If you require this functionality, you may need to use a VPN or Zero Trust Network Access (ZTNA) solution to provide this connectivity to on-premises resources. More on this later, when we touch on Microsoft Entra Global Secure Access. Legacy applications and authentication When people talk about legacy applications in this context, they typically mean apps that can only do legacy (NTLM or Kerberos) authentication with Active Directory. The good news is that for users synchronized using Microsoft Entra Connect Sync, cloud-native devices can seamlessly authenticate using NTLM and Kerberos just like domain-joined devices. When an on-premises domain account is synchronized to Microsoft Entra ID via Microsoft Entra Connect Sync, Windows uses details from Microsoft Entra ID, such as the source Active Directory domain name and the user’s User Principal Name (UPN), to locate a Domain Controller the same way an Active Directory domain-joined device does. If the user has signed into Windows using a password, Windows sends the on-premises domain information and user credentials to the Domain Controller to obtain a Kerberos Ticket-Granting Ticket (TGT) or NTLM token, based on the protocol the on-premises resource or application supports. From that point onwards, the TGT is used to get session keys that grant access to resources. Refer to How SSO to on-premises resources works on Microsoft Entra joined devices for additional details on how this process works. Note: Windows 11, version 24H2 and later releases have removed the NTLMv1 protocol as part of Microsoft's broader initiative to phase out NTLM. Refer to the Microsoft support article on Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 for additional details. Windows Hello for Business Passwordless authentication mechanisms such as FIDO2 and Windows Hello for Business are a cornerstone of Microsoft’s security vision. Adopting these authentication methods delivers stronger security and better, simpler user experiences. Windows Hello for Business provides phishing-resistant credentials as required by some security guidelines such as the Australian Cyber Security Centre ‘Essential Eight’. If you’re not already doing so, deploying cloud-native devices is a great opportunity to start using Windows Hello for Business, especially since it’s enabled by default on these devices. Windows Hello for Business is also a feature which results in a win-win scenario by enhancing security for IT, while also improving the user experience. While enabling Windows Hello for Business is a simple process, there’s some additional configuration required to enable single sign-on to on-premises Active Directory authenticated resources, and this is where we sometimes see customers running into issues. If username and password work successfully to access an on-premises resource, but Windows Hello for Business credentials don’t then ensure that you’ve setup Cloud Kerberos trust to enable single sign-on. Cloud Kerberos Trust removes much of the complexity once associated with configuring Windows Hello for Business, greatly simplifying the deployment process. When signing in with Windows Hello for Business, the device uses a partial Kerberos TGT issued by Microsoft Entra ID to obtain a full TGT from Active Directory, which in turn is used to get session keys to access resources. Refer to Microsoft Entra join authentication to Active Directory using cloud Kerberos trust for additional details. Zero Trust and modern connectivity On your Zero Trust journey, if you need to provide access to on-premises applications and services, consider replacing your traditional VPN with a modern solution, enabled by Microsoft Entra Private Access. Doing so will help you ensure secure, fine-grained access to private applications and resources, without exposing your full network - aligned with Microsoft’s three Zero Trust principles: verify explicitly, enforce least privilege, and assume breach. Review Zero Trust and Cloud-Native Windows for a deeper dive into this topic. On the subject of Zero Trust, did you know that Microsoft has developed a Zero Trust Workshop? By adopting Zero Trust, your organization can enhance its security posture and reduce risk and complexity while improving compliance and governance. Navigating the complexities of modern security is challenging and a Zero Trust strategy is the first step in providing clarity and direction. The Zero Trust Workshop is a guided framework to help you translate your Zero Trust strategy into actionable implementation steps which track your deployment progress and align with Microsoft recommendations. We’ve had many customers leverage the workshop to supercharge their Zero Trust journey and realize the full value of their existing security investments. The workshop can be run self-guided or in collaboration with your Microsoft account team or a partner and is vendor agnostic. Key takeaways If you aren’t already provisioning new Windows devices as cloud-native, check out Set up and configure a cloud-native Windows endpoint with Microsoft Intune and Cloud-native Windows endpoints: Begin by beginning to get started with a cloud-native Windows proof of concept today. Cloud-native doesn’t mean cloud only, these devices get the benefits of being cloud-first while maintaining the backward compatibility needed to access on-premises resources when necessary. Modern identity solutions such as Microsoft Entra ID, Windows Hello for Business, and Zero Trust Network Access can simultaneously enhance security and user experience. Be sure to check out our Zero Trust Workshop to help you plan and implement these and other technologies as part of your Zero Trust strategy. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam!Microsoft Intune Connector for Active Directory security update
Updated 04/18/25: Based on customer feedback around challenges with setting up the connector with build 6.2501.2000.5, we have released an updated build with improved functionality and updated our troubleshooting documentation with more guidance on avoiding configuration issues in your environment. The new build 6.2504.2001.8 is available for download in Microsoft Intune. New in build 6.2504.2001.8: The sign in page in the wizard now uses WebView2, built on Microsoft Edge, instead of the previously used WebBrowser. Error "MSA account <accountName> is not valid" which some customers reported during sign in has been fixed. As part of Microsoft’s Secure Future Initiative, we’re making an important security change which will impact customers deploying Microsoft Entra hybrid joined devices with Windows Autopilot and provide guidance on how to prepare. New capabilities or improvements aren’t planned as part of this security change. Review Microsoft’s recommendations based on your organization’s needs. Updated connector Today, Windows Autopilot uses the Intune Connector for Active Directory to deploy devices that are Microsoft Entra hybrid joined. To strengthen security in our customers’ environments, we’ve updated the Intune Connector for Active Directory to use a Managed Service Account (MSA) instead of a SYSTEM account. The old connector which uses the local SYSTEM account will no longer be available for download in Intune and will stop being supported in late June 2025. At that point, we’ll stop accepting enrollments from the old connector build. Follow the guidance provided below to update your environment to the new connector. The old connector build will continue to work for existing customers who already have it installed until the end of support date and is available for download in the Microsoft Download Center if needed. What is a Managed Service Account (MSA)? MSAs are managed domain accounts that have automatic password management and are generally granted just enough permissions and privileges to perform their duties. Standalone MSAs can only be used on a single domain joined machine and can only access resources within that domain. An MSA can run services on a computer in a secure and easy to maintain manner, while maintaining the capability to connect to network resources as a specific user principal. All these reasons make them a better fit for the Intune Connector for Active Directory than the current SYSTEM account option. Comparing the account permissions required between the new and old connector Old Connector New Connector Logged on account SYSTEM Domain\MSA Password management Set by user, subject to domain rules Managed by domain only – automatically reset Privilege set size (see notes for more details) MAX 5 Privileges: SeMachineAccountPrivilege - Disabled default SeChangeNotifyPrivilege - Enabled Default SeImpersonatePrivilege - Enabled Default SeCreateGlobalPrivilege - Enabled Default SeIncreaseWorkingSetPrivilege – Disabled default Registry access rights Full, implicit Read write, explicit Enrollment certificate rights Full, implicit Full, explicit Create computer object rights (required for hybrid Autopilot scenario) If connector is on the same machine as domain controller, unlimited If connector is not on the domain controller, delegation required Explicit delegation required Setting up the connector Before you begin First, you need to uninstall the existing connector by: Uninstalling from the Settings app on Windows Then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). To install and set up the new connector, you need the following minimum requirements: Downloading the connector build from Intune: Microsoft Entra account with Intune Service Administrator permissions Installation: .Net 4.7.2 Windows Server with 2008 R2 functional level Local administrator permissions Setting up the connector: Microsoft Entra account with an Intune license assigned and Intune Service Administrator permission Domain account with local administrator privileges Domain account should have permission to create msDS-ManagedServiceAccount objects Downloading the connector You can download the new connector from the Intune admin center and install in your environment. To set it up, launch the connector wizard and choose Sign In and sign in with a Microsoft Entra account with Intune service admin permissions and you’ll notice a new Configure Managed Service Account option. After signing in, the connector will enroll and only the Configure Managed Service Account option will be available. The account with Intune admin permissions should select that option to complete set up. For more detailed steps on installing the connector, review: Install the Intune Connector. Configuring organizational units (OUs) for domain join By default, MSAs don’t have access to create computer objects in any OU. If you wish to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. This can be done at any time (either before enrollment, or after the connector is enrolled): Update ODJConnectorEnrollmentWizard.exe.config: Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard” Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin OU name should be the distinguished name (see Additional information section) Note that the MSA is only granted access to the OUs configured in this file (and the default Computers container). If any OUs are removed from this list, completing the rest of the steps will revoke access. Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button. Success! – A pop up will appear showing success. Using the Intune Connector with multiple domains Customers who are already using the connector with more than one domain will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain. Configuring the connector The Intune Connector for Active Directory needs to be installed on each domain that you plan to use for domain join. If you need to have a second account redundancy, you will need to install the connector on a different server (in the same domain). Follow the steps above to ensure the connector is configured correctly, and that the MSA has appropriate permissions on the desired OUs. Ensure that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5: A list of Intune Connectors for Active Directory and their version in the Microsoft Intune admin center. Configure Domain Join profile: Follow the steps for configuring a domain join profile: Create a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot. Target the domain join profile to the appropriate device groups. Example of 2 domain join profiles targeted to different groups, with different domain names configured: Expected result: Connector in domain F11.F1.com will only join domain F11.F1.com. Connector in domain F12.F1.com will only join domain F12.F1.com. Additional information Retrieving Organizational Unit Distinguished Name If you need to customize the OUs that the MSA has access to, here are two easy methods to retrieve the distinguished name for these OUs: Let’s assume we have the following structure: Powershell Get-ADOrganizationalUnit (ActiveDirectory) | Microsoft Learn Get “=TestOUWithSpecialChars=”: PS Cmd: Get-ADOrganizationalUnit -Filter 'Name -like "*TestOUWithSpecialChar*"' | Format-Table Name, DistinguishedName Output: “OU=\=TestOUWithSpecialChars\=,DC=modesh2,DC=nttest,DC=microsoft,DC=com” Note, ‘=’ is escaped Get “NestedOU” PS Cmd: Get-ADOrganizationalUnit -Filter 'Name -like "NestedOU"' | Format-Table Name, DistinguishedName Output: “OU=NestedOU,OU=\=TestOUWithSpecialChars\=,DC=modesh2,DC=nttest,DC=microsoft,DC=com” Note, ‘=’ is still escaped Active Directory Users and Computers Select “View” from the menu, and enable “Advanced Features” Right click on the specific OU and click “Properties” Navigate to the “Attribute Editor” tab Select “distinguishedName” attribute and click “View” Summary The new connector aims to enhance security by reducing unnecessary privileges and permissions associated with the local SYSTEM account. This blog describes how to set up the new connector and configure it for your organization. Make sure to install the new connector by late June 2025 before the old connector becomes unsupported. If you have any questions, leave a comment on this post or reach out to us on X @IntuneSuppTeam. Post updates: 04/18/25: Updated post with a note on our release of our latest build, version 6.2504.2001.8, improving user experience and system performance. Supportability for the old connector has also been updated to June 2025 (previously May).
