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!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).Configure the new Microsoft Intune connector for Active Directory with the least privilege principle
By: Arpit Sinha | Support Escalation Engineer – Microsoft Intune The purpose of the Microsoft Intune Connector for Active Directory, also known as the Offline Domain Join (ODJ) Connector, is to join computers to an on-premises domain during the Windows Autopilot process with the device ultimately becoming Microsoft Entra hybrid joined after the user logs into the device for the first time. The Intune Connector for Active Directory creates computer objects in a specified Organizational Unit (OU) in Active Directory during the domain join process. Important Note: Although fully supported, performing hybrid join during Windows Autopilot isn’t recommended as it can be difficult to configure, troubleshoot, and support over time. For additional information on this topic refer to Join your cloud-native endpoints to Microsoft Entra and the blog, Success with remote Windows Autopilot and hybrid Azure Active Directory join. Earlier this year, Intune released an updated Intune Connector for Active Directory that strengthens security and follows least privilege principles by using a Managed Service Account (MSA). As communicated in both the blog and Message Center, as started in July 2025, older versions of the connector will cease to operate successfully. Below are the useful steps you should follow while configuring the updated Intune Connector for Active Directory: Sign in to the Intune Connector for Active Directory Verify the Intune Connector for Active Directory is active Configure the MSA to allow creating objects in OUs (optional) Error when granting permissions to MSA account An issue that a small number of customers may experience during the connector installation is the inability for the installation process to grant the MSA account the necessary permissions on the default computers container or a specific organizational unit. The below screenshot shows the error message displayed when you encounter this error during installation. The installation log is named odjconnectorUI.txt, located in C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard, and shows the following when you encounter this error: Unknown error: System.DirectoryServices.DirectoryServicesCOMException (0x8007202F): A constraint violation occurred. Workaround and walk through To workaround the above issue, the following is a walkthrough for successfully installing the connector and the steps required to handle the MSA permission error. Follow the Install the Intune Connector for Active Directory on the server guidance to setup the new ODJ connector. You need to initiate the installation with an account that has the following rights: Create msDs-ManagedServiceAccount objects in the Managed Service Accounts container (domain rights) Local administrator on your Windows Server After successful installation and Microsoft Entra sign in (using an Intune Admin or Global Admin account), you’ll get the below confirmation screen in the Intune Connector for Active Directory showing that the connector is successfully enrolled and that an MSA account was successfully created. After selecting on ‘Ok’ in the above confirmation screen, wait a few seconds, and you might receive the error that mentions the MSA account 'could not be granted permission' and will show the MSA name which was created as highlighted in the below screenshot. Note the name of the MSA account as this is needed in a below step. Note: If setup is complete and successful, it won’t throw the above error. If the dialog is closed, go to location ‘C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard’ and relaunch ‘ODJConnectorEnrollmentWizard.exe’. Verify that the connector installation successfully created the MSA in Manager Service Account container in the Active Directory User and Computers console. Note that you must enable Advanced Features in the View menu to show this container. Validate that the 'Intune ODJ connector service' is Running with an Automatic Startup Type and with 'Log on As' use the MSA account configured during the connector’s installation only. As shown in the following example screenshot. Verify in the Intune admin center under Device > Enrollment > Intune Connector for Active Directory that the connector is Active. Note: Inactive connectors in the Intune Connector for Active Directory page will automatically be cleaned up after 30 days. Grant the Create Computer objects permission to the MSA account created by the connector installation on the organization unit or container that you configured the connector to use. This is best done using the Delegation of Control Wizard in the Active Directory User and Computers console. The following screenshot shows the end result. Note: Selecting ‘Configure Managed Service Account’ again will still result in the same permissions error. This is a known issue that can be ignored and will be addressed in the next released build of the connector.You can now proceed with provisioning devices using Autopilot. Look for the following event log events in Event Viewer on the server hosting the connector to validate correct functionality: Event Log Event Application and Services Logs > Microsoft > Intune > ODJConnectorService > Admin Event ID 30120 (successful Event) Application and Services Logs > Microsoft > Intune > ODJConnectorService > Operational Event ID 30130 and 30140 (successful Events) Summary Ensure that you’ve updated to the new connector as old versions will stop working. Additionally, ensure that the Managed Service Account has the correct permissions on the designated organizational unit. This is essential for the smooth operation of the Intune Connector for Active Directory. While you may encounter an error when selecting "Configure Managed Service Account", this can typically be safely ignored during initial setup. To confirm that the connector is functioning correctly and that devices can be provisioned through Autopilot without issues, monitor the event logs under the Intune ODJConnectorService. These logs provide critical insight into the provisioning process and helps validate successful connector enrollment and operation. Related information: Enrollment for Microsoft Entra hybrid joined devices Plan for Change: New Intune connector for deploying Microsoft Entra hybrid joined devices using Windows Autopilot Microsoft Intune Connector for Active Directory security update If you have any questions or want to share how you’re managing your Windows Autopilot devices with Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn.Deep dive into Windows Autopilot device preparation: How to deploy and when to use it
By: Maggie Dakeva - Sr. Product Manager | Microsoft Intune Provisioning devices at scale used to be complex and time-consuming, especially with today’s remote and hybrid work models. Windows Autopilot and Windows Autopilot device preparation simplify and secure the process, helping IT teams deliver ready-to-go devices with minimal touch. Understanding the differences between the two helps organizations choose the right approach for device lifecycle and deployment strategy. Understanding Windows Autopilot device preparation Windows Autopilot device preparation is a next-generation provisioning solution designed to simplify IT setup, improve reliability during device provisioning and provide better reporting and troubleshooting capabilities. While Windows Autopilot has long empowered organizations to automate device setup, Windows Autopilot device preparation introduces significant improvements in consistency, real-time visibility, and flexibility for device management. Key benefits of Windows Autopilot device preparation Simpler setup: Configure a single device provisioning policy that includes both Windows deployment configuration and out-of-box experience (OOBE) settings. Consistent and reliable provisioning experience: Windows Autopilot device preparation removes most of the complexity and unpredictability from device deployments, ensuring better workload coordination. Enrollment time grouping: Allows granular targeting of unregistered devices, reduces the complexity of dynamic group management and latency, and avoids conflicts due to group membership calculations during provisioning. Near real-time reporting: IT admins can review detailed status of each configured app and script in addition to overall status, speeding up issue resolution and unblocking user productivity. Windows Autopilot vs Windows Autopilot device preparation Many customers wonder when they should use Windows Autopilot and when to use Windows Autopilot device preparation. The key difference is in their supported provisioning modes and requirements: Windows Autopilot: Best suited for organizations needing advanced customization, multiple device type support, and hybrid join scenarios. Requires device registration and delivers configurations both during device and user phases. Windows Autopilot device preparation: Designed for rapid, Microsoft Entra joined deployments without the need for Windows Autopilot registration. Focuses on device-based targeting during OOBE and can deliver both apps and scripts, with enhanced troubleshooting and reporting capabilities. For a detailed comparison, review Compare Windows Autopilot solutions. Use Windows Autopilot device preparation if: You haven’t deployed Windows Autopilot before or are looking to simplify your deployment process. Your organization will use a user-driven flow where each user will set up their device. Your organization is transitioning to cloud-native (Microsoft Entra joined) devices or Windows 11. Your organization is deploying Windows 365 Frontline devices. You want to avoid managing Windows Autopilot registration and the complexities it brings during the device lifecycle and repairs. Your organization needs to deploy devices in sovereign clouds (GCCH, 21Vianet in China). You’d like better visibility into the provisioning experience with a more detailed report. Use Windows Autopilot if: Your organization requires pre-provisioning (device is prepared by technician) or self-deploying (shared device) flow. Your organization requires Windows Autopilot registration or the features it provides, such as hiding OOBE pages and renaming devices before enrollment, and device firmware configuration interface (DFCI). Device setup flow step-by-step Understanding the device preparation flow is key to leveraging this method effectively. Here’s an overview of the typical device journey: Overview of all steps of device preparation, described in detail below. Intune setup: You’d need to create a new device security group (steps) and a Device preparation policy in Intune where you include the group. Devices will receive configuration from that security group and will automatically be added to it during provisioning. Physical device setup: Windows Autopilot device preparation requires Windows 11 devices which are not registered for Windows Autopilot and supports only Microsoft Entra joined (cloud-native) deployments. You should always start with a clean image, pre-loaded with drivers. OOBE flow: User authenticates with their Microsoft Entra credentials. Enrollment: Device automatically Microsoft Entra-joins and enrolls in Intune. Windows backup (optional): If Windows Backup for organizations is configured for this user, they will see a page with options to restore user settings from previous device. Device preparation setup: Next, the Intune Management Extension is installed, then the bootstrapper agent which controls the provisioning process, and the device syncs with the mobile device management service (Intune).). Enrollment time grouping: After the device joins Microsoft Entra and enrolls in Intune, Windows Autopilot looks up the configuration assigned to the security group set for enrollment time grouping. Policy installation: Intune policies, line-of-business (LOB) apps, and Microsoft 365 apps are delivered to the device. If any LOB or Microsoft 365 apps are selected in the device preparation policy Windows Autopilot will ensure they deliver successfully before continuing to the next step. Script installation: PowerShell scripts selected in the device preparation policy are delivered. If successful, provisioning continues to the next step. Remediation and custom compliance scripts are not yet available. App installation: Win32, Microsoft Store, and Enterprise App Catalog apps selected in the device preparation policy are installed. If successful, provisioning continues. Apps must also be targeted to the device security group configured during step 1. Reboot: If needed, a coalesced reboot will be triggered prior to moving to the desktop. Device preparation completes: The device completes the Windows Autopilot device preparation setup, user is informed that Required setup is complete. After the device preparation setup is completed, the user may receive a cumulative Windows update at the end of OOBE (learn more) and then set up Windows Hello for Business. Desktop: The user proceeds to the desktop where additional Intune configuration which was not selected in the device preparation policy may be applied. Best practices for Windows Autopilot device preparation To maximize the benefits of Windows Autopilot device preparation, organizations should follow these best practices: Define clear security groups: Create a dedicated device security group in Microsoft Entra and assign the Intune Provisioning Client service principal as the group owner. This step is critical for profile assignment and app delivery. Use policies strategically: Windows Autopilot device preparation policies control the configuration of devices during OOBE. Carefully curate the list of critical apps and scripts, leaving additional configuration to deploy at the desktop. This will ensure an optimal user experience during OOBE. Use device-based apps: Assign apps to the device security group and configure them to install in the system context for successful deployment during OOBE. Manage timeout values: Review and adjust timeout settings in the device prep policy to ensure deployments don’t fail due to time constraints. Start troubleshooting by reviewing the report: Use the Windows Autopilot device preparation deployment report in Intune’s “Monitor” section for near real-time insights into deployment progress and to quickly spot any issues. Common issues and troubleshooting tips Even with the best planning, device preparation may encounter roadblocks. Here are some of the most frequently reported issues and strategies for addressing them: Device enrollment failures Blocked by enrollment restrictions: If corporate identifiers aren’t uploaded, devices may fail to enroll. Ensure these identifiers are added as required. Unsupported OS Version: Devices with incompatible OS versions will not appear in the device preparation deployment report and won’t display the device preparation page in OOBE. They may get the Enrollment status page, if configured for All users and all devices, or proceed straight to the Privacy settings page. Previously registered devices: If a device is already registered for Windows Autopilot, it can’t go through device preparation. Confirm that the registration is removed before deploying with Windows Autopilot device preparation. Application and script deployment issues App detection rules: Always review Win32 app detection rules and the Apps report in Intune. Inaccurate detection logic can cause apps to fail deployment. This is one of the most common issues causing deployment failures. Network constraints: Proxy settings, VPN clients, and Wi-Fi profile configurations may cause network instability if applied during the provisioning process. In addition, Delivery Optimization failures (often caused by network issues) can impede downloading app content. Review network setup and ensure reliable connectivity during the provisioning process. Script execution testing: Execute PowerShell scripts outside of Autopilot to ensure they work independently before inclusion in device preparation policies. Managed installer issues: If Managed Installer policy is enabled for your tenant, Win32 and Microsoft Store apps are skipped. This will be addressed in a future release. Monitor announcements on What's new in Windows Autopilot device preparation | Microsoft Learn. Targeting and context: Make sure apps are set to install in the system context and targeted to the device security group specified in the device preparation policy. Deployment timeout: If a device preparation deployment fails due to timeout, compare the timeout value in the device preparation policy with the actual deployment time reported and adjust as needed. Conclusion Windows Autopilot device preparation marks a significant evolution in Windows device provisioning, offering IT admins a predictable, flexible, and transparent deployment framework. By following the best practices outlined above and leveraging the robust troubleshooting features built in, organizations can minimize deployment headaches and ensure users can provision their devices and become productive as quickly as possible. FAQ Are corporate identifiers the new registration? Corporate identifiers aren’t a replacement for Windows Autopilot registration. They’re needed for organizations that block personal devices and to ensure only trusted devices can be enrolled in your tenant. How do I move from Windows Autopilot to Autopilot device preparation? You’d need to follow these steps: Create an assigned device security group and make sure all configurations are assigned to it. Create a new device preparation profile and assign it to your users. Deregister all devices from Windows Autopilot. Reset all devices. Note that some advanced scenarios aren’t yet available for Windows Autopilot device preparation but may be available in the future. Resources For more details, including updates and a full list of known policies or issues, review the Microsoft documentation below: Overview of Windows Autopilot device preparation Overview for Windows Autopilot device preparation user-driven Microsoft Entra join in Intune Compare Windows Autopilot device preparation and Windows Autopilot As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam or @MSIntune!From the frontlines: Managing common kiosk scenarios in your business
By: Saurabh Sarkar – Product Manager 2 | Microsoft Intune I'm Saurabh Sarkar and I've had the opportunity to collaborate with several customers on effectively managing their Windows kiosk devices to enhance productivity with Microsoft Intune. This post covers some of my experience, recommendations, and additional takeaways from these collaborations. It’s a continuation of our From the frontlines series which focuses on frontline worker scenarios. In this post, we’ll explore how to effectively utilize Intune to enhance the productivity of frontline workers in two example sectors: the airline industry and the food and beverage sector (restaurants). Background Kiosk devices are integral to modern business operations, particularly in retail, manufacturing, and the airline industry. These devices serve as dedicated terminals for specific tasks, enhancing efficiency and productivity. In retail, kiosks are commonly used for customer service functions such as self-checkout, product information, and order placement. They provide a seamless and interactive experience for customers, reducing wait times and improving satisfaction. In manufacturing and factory settings, kiosk devices are utilized for various operational purposes including inventory management, allowing workers to quickly check stock levels and update records in real-time. Additionally, kiosks facilitate employee check-ins, shift scheduling, and access to important safety information, ensuring smooth and safe operations on the factory floor. From a technological standpoint, managing these kiosk devices is crucial to maintaining their functionality and security. As shared in the introduction to this series, Intune allows organizations to centrally control and manage their kiosk devices. With Intune, administrators can centrally manage and remotely configure settings, deploy applications, and enforce security policies, reducing the risk of data breaches and unauthorized access. Moreover, this centralized management approach using Intune not only enhances the reliability of kiosk devices but also ensures compliance with organizational policies and industry regulations. Self-service kiosks in airports and restaurants Self-service kiosks at airports offer numerous advantages that improve passenger experience and operational efficiency. They help reduce wait times by allowing passengers to check in, select seats, and print boarding passes quickly and conveniently which is especially beneficial during peak travel times. For airlines, self-service kiosks reduce the reliance on staffing resources and ticket agents resulting in cost savings and allowing airlines to reallocate staff to other critical areas, such as customer service and baggage handling. These kiosks can be activated as needed during busy periods, eliminating the need for temporary staffing solutions. Passengers benefit from the user-friendly interfaces of these kiosks, which are designed to be accessible to people of all ages and tech-savviness. Multilingual support further enhances accessibility for international travelers. Similarly self-ordering kiosks in restaurants reduces wait times and speeds up the ordering process. They also improve order accuracy, as customers input their selections directly, minimizing errors that can occur with verbal communication. The interface allows customers to browse the menu at their own pace, customize their orders, and make payments easily, leading to a more satisfying dining experience. Additionally, kiosks help restaurants save on labor costs by reducing the need for cashiers, allowing staff to focus on food preparation and customer service. Kiosk device provisioning scenario using Windows Autopilot Imagine a busy pizza delivery restaurant that strives to deliver a seamless ordering experience for its customers while streamlining staff operations. The restaurant equips its tables and waiting area with userless Windows devices, each configured to meet the below requirements: These devices are userless, eliminating the need for individual user logins before placing an order. They are configured to display the restaurant's website exclusively, with restrictions on accessing any other URLs or opening any other browser tabs or applications. If the device remains inactive during a session, the browser should automatically refresh and redirect to the homepage, ensuring it’s prepared for the next customer. The IT team leverages Windows Autopilot’s self-deploying mode to transform standard Windows hardware into dedicated ordering terminals. As soon as a device powers on and connects to the internet, it automatically joins Microsoft Entra ID, enrolls in Intune, and configures itself for kiosk use. Microsoft Edge launches in full-screen kiosk mode, locking the device to the restaurant’s website and preventing access to other URLs, tabs, or system applications. The kiosk profile set by Intune ensures that customers only see what they need for ordering, with no distractions or risk of tampering. The restaurant’s digital signage hides unnecessary browser controls, such as the home button, and disables features that could allow customers to exit the ordering environment. If a session remains inactive for 15 minutes, the browser refreshes and returns to the homepage, erasing any previous selections and preparing the device for the next guest. Meanwhile, secure Wi-Fi configurations - automatically deployed via Intune and authenticated using robust device-based certificates - keep each device connected to the network, regardless of user or shift changes. With this setup, the restaurant empowers customers to order efficiently and autonomously, eliminates the need for staff to manage devices, and ensures every kiosk remains secure and ready for use throughout the day. This scenario highlights how Windows Autopilot, Intune, and Microsoft Edge kiosk mode work together to support innovative ordering solutions in the food service industry. Considering the above scenario and requirements, you can deploy a Kiosk type device configuration policy to managed Windows devices as shown in Fig. 1 below. Fig. 1 – Setting up Kiosk configuration profile for Windows. The figure below illustrates the configuration settings that need to be applied in the kiosk profile to fulfill the specified requirements. This is the second page of the Kiosk device configuration profile wizard that is shown after the admin initiates the creation of the profile. Fig. 2 – Configuring settings in Single app Kiosk mode profile for Windows. The following are key points about the configuration: With the logon type set to “Auto logon”, users don’t need to manually sign in to use the device. Note: The auto logon process uses KioskUser0 account and cannot be changed. By configuring digital/interactive signage, you ensure that the home button isn’t visible and prevents users from opening additional tabs in the browser. By configuring the browser's idle time, you ensure that after 15 minutes of inactivity, the browser restarts and redirects to the restaurant's homepage. This process prepares the device for the next user and clears any cached data in the browser. You can also deploy a Wi-Fi profile from Intune that automatically connects the device to allowed SSIDs. You can further automate this connection by deploying and utilizing a device-based certificate using an organization provided PKI and the Certificate Connector for Microsoft Intune or using Microsoft Cloud PKI for Microsoft Intune. The below screenshot shows the user experience in a Windows device running with the Single app Kiosk mode. As we can see, the user doesn't have the home button visible in the browser and is restricted from opening any additional tabs. Fig. 3 – User experience in a Windows device configured with Single app mode Kiosk mode. This is one example of how Intune assists in the management of kiosk devices in various industries. Other examples include the use of kiosk devices in movie theatres for ticketing and information distribution or retail shops for self-checkout and gathering product information. Please refer to the documentation Microsoft Edge Browser Policy Documentation for additional settings that can be configured in Microsoft Edge when using Kiosk mode. This post is part of the “From the frontlines” series which aims to guide customers by exploring recommended practices for deploying, managing, and securing frontline devices using Intune and Windows Autopilot. We’ll publish additional posts on other healthcare scenarios and industries, such as retail and airlines, in the upcoming months so stay tuned and check back frequently! Resources: Please refer to the documentation here for more guidance: To learn about how to get started with kiosk device setup for Windows refer to Frontline worker for Windows devices in Microsoft Intune To learn about the various settings available in the kiosk profile for Windows in Intune refer to Windows 10/11 and newer device settings to run as a kiosk in Intune To learn about all the Windows kiosks configuration options, refer to aka.ms/kiosk To learn about the advances that have been made over the past 12 months for kiosk scenarios with Windows 11 please check our recording from technical Takeoff session Windows 11 kiosks: Cloud management for the win - Microsoft Technical Takeoff We’d love to hear how you're leveraging Intune in your frontline worker scenarios! Feel free to share your experiences or ask questions by leaving a comment below, or by reaching out to us on X (@IntuneSuppTeam or @MSIntune). You can also connect with us on LinkedIn.
