Android for Work - Contacts?
Hi guys, I'm testing out android for work, I've enrolled a device, which sets up Outlook via configuration policy, within the android for work profile, the contacts app does not populate, I've deployed settings to read \ write contacts for Outlook, I've set a configuration profile to auto grant permissions within the work profile. When going to the outlook settings and selecting 'Sync contacts' an error pops up and states 'contact permissions are not fully granted..." so within the workspace settings, I've checked the outlook app settings and the permission option for contacts is set to 'enabled by admin'. Also, if I try to 'sync your accounts' from the AFW contact app, outlook does appear, I sign in and then I receive an error of 'This email address is already connected with Office 365. Do you want to connect it with another service?" and then I select O365 Outlook app again, but nothing really happens. Is it supported to view contacts from Office 365 via the AFW contact app? (Not the personal contact app)? If so, how do I configure this?New policy implementation and web enrollment for Android personally owned work profile is now GA
We’re happy to announce two improvements for the management of Android personally owned work profile devices with Microsoft Intune, which is now generally available! A new implementation for how Intune delivers policies to devices. Web based enrollment. These updates modernize how Microsoft Intune manages devices and improves the enrollment flow. As of June 18, you will need to take action to opt in to the new implementation. This change will become required later in 2026, and we’ll continue to update this blog as rollout details become available. Keep reading to understand what’s changing, actions, and timelines you need to know. What’s changing New implementation We’re finalizing our work on moving the Android personally owned work profile implementation to the latest and greatest available – Google’s Android Management API (AMAPI). It has been almost a decade since Intune released support for Android personally owned work profile management. At that time, we accomplished this by building a custom device policy controller (DPC), in the form of the Intune Company Portal app. A lot has changed since then. Google released AMAPI and its companion app, Android Device Policy, which enforces AMAPI policy on devices. This is now Google’s recommended implementation, which we used to deliver the three corporate Android Enterprise management methods: corporate owned work profile, fully managed, and dedicated. Google no longer recommends use of custom DPCs and they’re deprecating associated functionality. The benefits of moving personally owned work profile management to AMAPI include: Faster release of new features across all four Android Enterprise management options. Consistent behaviors across all four Android Enterprise management options. The Microsoft Intune app will replace the Company Portal app as the user app (to manage devices, contact their IT department, collect logs, and more), providing an updated user experience and aligning it with the corporate Android Enterprise management options. Enables Intune to support the latest Android platform management capabilities, which are unavailable with custom DPC implementations. Web based enrollment The move to AMAPI also enables us to build a web-based enrollment flow for personally owned work profile devices, similar to web based device enrollment for iOS. The benefits of this include: Users don’t need to manually install an app to start Intune enrollment since they can start enrollment from a webpage instead. Users can access enrollment from any of the three different entry points which all launch the same webpage: Productivity apps - when admin has configured conditional access so that the user is required to enroll before accessing corporate resources (recommended) The Company Portal app This gives you more options for how to guide your users to get set up. A URL Android enrollment is more consistent with the iOS web-based enrollment flow. How to configure and monitor Web based enrollment As of June, 18th 2026 - A new setting is now available that lets you switch your tenant to the new web-based enrollment experience for all future personally owned work profile enrollments. We recommend that you configure this in a test tenant first, try out and document the user flow, and prepare your helpdesks accordingly before opting in on your main tenant. Once you opt in, there isn’t an option to opt out. Planned for Q4 2026, Intune will automatically configure all personally owned work profile enrollments across all tenants to be web enrollments. New implementation A new configuration policy allows you to migrate device groups to the new implementation. As a best practice, we encourage admins to evaluate migrating a smaller device set before migrating all devices. Before moving devices to the new implementation, you may want to email users or configure custom notifications to inform them of what to expect. Planned for Q4 2026, Intune will automatically migrate all remaining devices using the custom DPC implementation over to the new AMAPI implementation. Monitoring There is a new report that shows how many personally owned work profile devices are in each of the following states: On AMAPI Not targeted to move to AMAPI Targeted to move and pending completion (since it may roll out over some time) Attempted to move and hit an error (and why) How this will affect your users Web based enrollment After you opt in to web based enrollment or later after it’s changed to the default, all personally-owned devices (on all Android OS versions) will enroll with the web based flow. These devices will be managed with AMAPI. After enrollment, Intune will install a few apps automatically to ensure streamlined management. Microsoft Intune: User-facing app to manage devices, contact the IT department, collect diagnostic logs, and more. Company Portal: For mobile app management (MAM). Android Device Policy: To enforce AMAPI policies. This app is installed in a “hidden” state, so users won't see it in their app list. Microsoft Authenticator: To provide single sign on for users’ work account. Below is an example of the web based enrollment flow that a user would see if they needed to set a PIN on their device to meet admin requirements. New implementation When a device is moved to the new implementation (either through admin configuration or the later automatic move), devices won’t unenroll and users won’t lose access to corporate resources. Moving enrolled devices to the new implementation will be supported on any device running supported Android OS versions for user-based management methods at that time. The changes on the device will be: The Microsoft Intune app will install, and it will be the app for users to interact with instead the Company Portal. Users will not see a notification about this app installing. The Android Device Policy app will install to enforce policies. Users will not see a notification about this app installing and it will be in a “hidden” state on their device. If a device connected to corporate Wi-Fi with username and password authentication, when they move to AMAPI, they will lose access to corporate Wi-Fi until they sign in to the corporate Wi-Fi again. To avoid any potential disruption, we encourage you to move to certificate Wi-Fi authentication instead (as mentioned below). Timeline 2025: Use this time to revise any relevant policy configurations, update your internal documentation, and prepare your helpdesk teams, as advised below. June, 18th 2026: Enrollment: You’ll be able to opt in for all enrollments of personally owned work profile devices to be web based enrollments on AMAPI. New implementation: You’ll be able to set a configuration policy to migrate groups of previously enrolled devices over to AMAPI. Planned for Q4 2026: Enrollment: All enrollments (regardless of past configuration) will be web enrollments for devices running all Android OS versions. New implementation: All devices still on the custom DPC implementation and running supported Android OS versions for user-based management methods at that time will be automatically moved over to AMAPI. You will receive advanced notice of when these changes will be applying to your tenant. How to prepare We recommend you make these changes to prepare for the upcoming release and provide the most streamlined experience for users. Passkey support: If you have passkeys configured as the only accepted authentication method, users won't be able to enroll with the new web based enrollment flow. This is a known limitation, and we'll add passkey support before web based enrollment becomes the default for all personally owned work profile enrollments across all tenants - planned for Q4 2026. Important: Web-based enrollment doesn't support passkeys yet. If passkeys are your only allowed authentication method, enrollment will fail. Don't opt in to web-based enrollment until we announce passkey support for this flow. Replace custom policies: Intune ended support for custom configuration polices for personally owned work profile devices in April 2025. Custom policies are not supported in the new implementation. Replace all custom policies with equivalent policies using this setting mapping. Certificate authentication for Wi-Fi: If you’re using username and password authentication for Wi-Fi policies, we strongly encourage you to move to certificate authentication instead. Devices that are connected to corporate Wi-Fi with username and password authentication will lose access to corporate Wi-Fi when they are moved to AMAPI until the user signs into the corporate Wi-Fi network again. Devices using certificate authentication for Wi-Fi won’t lose access, and it’s also a more secure authentication method. Evaluate biometric configuration: Devices on the new implementation won't apply policies that prevent users from using face, fingerprint, iris, or trust agents to unlock their device. However, policies that prevent this at the work profile level are still supported. If you have this configured at the device level, consider blocking at the work profile level to protect work resources in an equivalent way. Note that for users who have turned on the setting to use one lock (unified password for the device and work profiles), then biometric settings configured for the work profile will apply to the device instead, since there isn't a separate work profile unlock. Review enrollment restrictions: In enrollment restrictions (also referred to as device platform restrictions) the “Android Enterprise (work profile)” restriction for personally owned work profile devices has a setting to Allow or Block “Personally owned” devices. This configuration will not apply to devices on AMAPI and the setting will be removed from the Intune admin center when all devices are moved to AMAPI. As communicated in the Intune Android 12 blog, this setting does not work reliably on devices running Android 12 and later. Conceptually, personally owned work profile management is meant for personal devices, so blocking personal devices from enrolling and only allowing corporate devices isn’t recommended. If you currently have the “Personally owned” setting set to Block for personal work profile devices, you should plan an alternate way for blocking these devices. Options include using a corporate management method instead (such as corporate owned work profile) or configuring the personal work profile enrollment restriction to block enrollments for all users except for users in a specified group. Update Android OS: Intune currently supports Android 10 and later on personally owned work profile devices. We recommend you guide users to update to their device’s latest supported Android version for the best experience. Helpdesk preparation: Inform your helpdesk teams of these coming changes so they know what to expect. For devices on the new implementation, diagnostic logs will be collected using the Microsoft Intune app (instead of the Company Portal app). Plan to update any user instructions you have after you try out the web based enrollment flow. iOS web based enrollment: We recommend you consider setting up web based device enrollment for iOS now or when we release Android web based enrollment for a more consistent and improved user experience. Changes to be aware of A few defaults will change as part of the move to the new implementation. Required app installation behavior: In the custom DPC implementation, users can uninstall required apps, and then they are reinstalled automatically within a few hours. In the new implementation, users won’t be able to uninstall required apps from their device, which is the same experience as on corporate Android Enterprise devices. Caller ID and contact search: In the custom DPC implementation, the settings to “Display work contact caller-id in personal profile” and “Search work contacts from personal profile” are two independent settings. In AMAPI, they are controlled with a single setting. If you have blocked either, Intune will automatically block both for devices on the new implementation. Intune will update the policy user interface to have a single setting once all devices are on the new implementation. Screen timeout: In the custom DPC implementation, you can configure screen timeouts either for the full device or for the work profile under “Maximum minutes of inactivity until work profile locks.” In AMAPI, you can only configure this at the work profile level. Intune will set this to the lesser of the two when devices move to the new implementation. We will remove the device level setting from policies when all devices are on AMAPI. Security provider and Google Play services: The compliance settings for "Up-to-date security provider" and "Google Play Services is configured" won't be supported for devices on AMAPI. This is because security providers will automatically be updated and Google Play Services are required for device enrollment and management. Intune will remove these settings from compliance policies when all devices are on AMAPI. Password: There will be some minor changes to how some configurations of password requirements apply on some devices. We will update to provide more information and guidance. Enrollment reports: A couple of enrollment reports will not report on devices enrolled into AMAPI management. They are the “Enrollment failures” and “Incomplete user enrollments” reports that are found in Devices > Enrollment in the Monitor tab. Google Domain allow listing: The device restriction setting “Google domain allow-list” will not be supported for devices on AMAPI. This capability is now managed directly in the Google Admin console rather than through device restriction policies. Once the onboarding account has been migrated to a Microsoft Entra account and federated with a Google account, admins can configure this setting in the Google Admin console under the Third-party integrations node by enabling “Authenticate Using Google.” Intune will remove this setting from device restriction policies once all devices are on AMAPI. Stay tuned to this blog for updates! If you have any questions or feedback on this change, leave a comment on this post or reach out on X @IntuneSuppTeam. Post updates 02/19/25: Updated the Timeline and How this will affect your users + New Implementations sections. 04/08/25: Updated these sections: How to configure and monitor, How this will affect your users, Timeline, How to prepare, and Changes to be aware of. 04/09/25: Updated the Changes to be aware of section to include details about TeamViewer supportability. 08/22/25: Added images and updated all sections with the latest information, including an updated Timeline section and removing the information about the delay to TeamViewer support. 09/09/25: Added a screenshot to clarify Android enrollment restrictions. 09/23/25: Update the Changes to be aware of section to include more information about 'Enrollment reports'. 02/12/26: Updates to the Changes to be aware of section to include more information about 'Security provider and Google Play services'. 03/27/26: Updates to the Changes to be aware of section to include more information about 'Google Domain allow listing'. 05/13/26: Updated the Timeline section to reflect availability in late Q2 of calendar year 2026. 06/18/26: Updated to note that as of June 18 this is now generally available! You may need to take action to opt in to the new implementation.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
Microsoft Intune Company Portal for Linux and Conditional Access Issue
Greetings everyone, I have the following scenario implemented regarding conditional access: Rule#1: For pilotuser1, for all cloud apps, for all platforms --> require MFA Rule#2: For pilotuser1, for all cloud apps except Microsoft Intune Enrollment and Microsoft Intune, for all platforms --> Require Device marked as compliant This should allow me to enroll to Intune successfully a non-enrolled device and require the device compliance for the other workloads. For Windows it works just fine. The problem lies with Linux. Following the instructions on Enroll a Linux device in Intune | Microsoft Learn & Get the Microsoft Intune app for Linux | Microsoft Learn I installed Intune App and Edge (Version 109.0.1518.52 (Official build) (64-bit)) on a VM with Ubuntu 22.04. I open the Intune App and try to sign in: First step is to Register the Device on Azure AD, it goes without a problem --> On the next stage I get the following and press continue: At this stage Microsoft Edge opens and I sign in successfully but the Intune App throws an error: The sign in logs on Azure AD show that even though I excluded Intune Enrollment from the CA policy, it is not enough. Sign-in error code: 530003 Failure reason: Your device is required to be managed to access this resource. Additional Details: The requested resource can only be accessed using a compliant device. The user is either using a device not managed by a Mobile-Device-Management (MDM) agent like Intune, or it's using an application that doesn't support device authentication. The user could enroll their devices with an approved MDM provider, or use a different app to sign in, or find the app vendor and ask them to update their app. More details available at https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access-device-remediation Application: Microsoft Intune Company Portal for Linux Application ID: b743a22d-6705-4147-8670-d92fa515ee2b Resource : Microsoft Graph Resource ID: 00000003-0000-0000-c000-000000000000 Client app: Mobile Apps and Desktop clients Client credential type: None Resource service principal ID: 01989347-a263-48ef-a8d7-583ee83db9a2 Token issuer type: Azure AD Apparently something is different in the enrollment process of Linux because I had no issues with Windows 10 enrollment . Any thoughts on the subject would be appreciated. Kind Regards, PanosAutopilot White Glove Error 0x80070002
Hi I need assistance to troubleshoot Autopilot White Glove Error 0x80070002 on Win10 2004. I have been searching the internet for this problem but haven't got any helpful information. Please take a look to my screenshot where I have run Michael Niehaus Script to diagnose Autopilot - point of failure is "Could not establish connectivity" and ODJ error. I have set up the Intune connector and a Domain Join Profile to all devices. Subsequently I also tried to skip AD connectivity but this is not resolving the problem. On my Intune Connector I found following error in event viewer: (this is repeating multiple times during enrollment) {"Metric":{ "Dimensions":{ "InstanceId":"A24408CD-28C0-4B29-B29B-0D529DBFD632", "DiagnosticCode":"0x00000000", "DiagnosticText":"Successful" }, "Name":"RequestHandlingPipeline_Download_NoWork", "Value":0 } } What can I check? Thank you!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.
Enroll Existing Azure AD Joined Machines to Intune
Hello Community, We have an environment with 1500 Devices consisting around 1000 Devices which are already Azure AD Joined & around 500 Devices which are Hybrid AAD joined connected to local AD. We want to onboard All devices to Endpoint Manager however we are unable to find a way to Bulk enroll devices to Intune. Our requirements are: Enroll Existing Azure AD joined device to Intune without User Interaction in Bulk or through some automated approach. (We do not want to manually enter Creds to enroll neither want to reset AADJ) Enroll Local AD joined devices in bulk without renaming the Computer Name as the Windows PPKG is forcing to rename the devices. How can we keep existing device name while enrolling. (We are aware of GPO Approach but did not tested it yet hence unaware of any Cons of using it) What we have Tried so far and our expectations? Created a Windows Provisioning Package but it does nothing on an Existing AADJ Machine except renaming its computer name. We do not want to perform Manual "Enroll Only in Device Management" Step but tested it and it does Enroll Device as Personal Device and not corporate. Provisioning package works well on a non-AADJ machine and enrolls the machine. We cannot disconnect AADJ or Reset Devices. We do not want our users to have local admin rights. (Optional) We would like to have current logged on user mentioned as Primary user in endpoint manager. (Optional) Do not want to use Provisioning package on Local Join Machine as it will rename them. (Optional) Tested some scripts but no success. Deep link do not work. Our Machines are not Managed through SCCM but we do have RMM Service in the environment which can deploy Apps and Packages on the devices. At the end our Motive is to enroll AADJ devices to Intune so we can start managing them, the enrollment process should not be a pain for our users or hampering their workflow. (We can ignore Optional requirement if its not possible to achieve ) Looking forward for some valuable suggestions! Thank you!
Allow user to AAD Join & InTune Enroll company devices only , not personal owned Win Pro/Ent device
I am trying to work out the best way of achieving the following restrictions: Allow Staff user accounts to be able to AAD Join and InTune AutoEnroll company owned devices Block Staff from AAD Joining and AutoEnrolling personal devices The obvious configuration for this is to set the staff users accounts group in AAD to be allowed to AAD Join and in InTune allow them to Auto Enroll whilst setting an Enrollment Restriction Policy for blocking personal devices. That is all good in theory , but the reality of that is that if a staff user has a personal devices that has Windows Pro, Enterprise or Education installed this configuration means they can still AAD Joined and InTune AutoEnroll. Is there a way to make certain only company owned devices can be Joined/Enrolled? The fact that most personal users will have Windows Home mitigate some of the risk and we are planning to use AutoPilot registration as an additional way of controlling things so we can design the InTune app and policy assignments groups so that they are populated only by devices with the HWID registered, so if done correctly even if they do enroll a personal device it wont receive any apps or policies anyway. There is the setting to restrict users to only be able to enroll or AAD join 1 device that could be configured but that doesn't stop them enrolling a personal device if they haven't enrolled a device already plus it is a tenant wide setting so removes flexibility for users that we might want to allow to enroll and join multiple devices. I cant help but wonder if there is a simpler , more robust way of doing this? The ideal scenario for us is to simply be able to say - only devices with registered HWID can be enrolled. Am I missing something that enables this? Thanks
