AzureADSharedMode - Teams without PIN
I prepared in Intune profile for Samsung devices in kiosk mode with a multi-app setting. I added Teams, Outlook, Egde and Managed Home Screen as apps. In addition, I also created a configuration profile for the Managed Home Screen application in which I set that it is necessary to configure a PIN for the session. I also set the Require PIN code after returning from screen saver option. Everything works great until the user leaves the Teams app on or someone calls the user logged into Teams. At this point, no PIN is needed to unlock the device. You can easily access Teams of the logged-in user. The user is asked for the session PIN only when he wants to switch to another app. I didn't set screen lock in android settings because in my opinion it's pointless since the device is in shared mode. Have you encountered anything like this? It poses a potential security risk if a logged-in user leaves the Teams app open, puts the phone down and walks away from it, and at that moment someone calls the phone and the person who picks it up without probelm gets access to the logged-in user's teams.From the frontlines: Frontline worker management with Microsoft Intune
So, here we are. You’ve been asked to start managing frontline devices for your organization with Intune. You may be a pro with Intune management - with experience managing Windows devices, personal mobile devices, or corporate-owned productivity user based mobile devices. Maybe you just completed your migration efforts from another product to Intune for some portion of your device estate. Or this may be your first interaction with Intune. Regardless of where you’re starting from, managing frontline worker devices in Intune is simple, and you can even leverage existing Intune policies you already configured. So, get out that rugged bar code scanner, Android tablet, kiosk device, shared iPad, wearable device, or any other frontline worker device and let’s get started! My name is Dan Andersen, Principal PM Manager at Microsoft. My team partners directly with engineering to assist in product development and our worldwide team has assisted over 1,800 enterprises successfully onboard their device scenarios into Intune. In this post I’m introducing a blog series focused on frontline worker (FLW) device management. Why focus on FLW? This space represents a multitude of devices and use-cases that have enabled frontline workers, and we’ve worked with others like you to craft great FLW solutions. We will use this series to share these solutions and options with you and hopefully make your FLW journey with Intune seamless and exciting. Before getting into the series, if you’re looking for some background on FLW usage examples, check out the Microsoft Intune Blog: Microsoft Intune empowers frontline workers in retail and beyond. Throughout this year we’ll deliver monthly blogs delving into FLW use-cases and how to manage these devices. We’ll dive into key scenarios and explain how to approach them and at times, specifically how to configure them. Instead of rewriting product documentation, we’ll include links to more details when applicable, and keep the posts focused on enabling success. Each blog post will be published here in the Microsoft Intune Customer Success blog and include “From the Frontlines:” in the title for easy searching. For quick reference, we’ll keep this table updated as we publish the series, so stay tuned here or follow us @IntuneSuppTeam on X for more in the coming months! Blog Topics Publish date From the frontlines: Revolutionizing healthcare worker experience February 28, 2025 From the frontlines: Accelerating retail worker shared device experience (Part one) March 25, 2025 From the frontlines: Accelerating retail worker shared device experience (Part two) April 23, 2025 From the frontlines: Delivering great dedicated device experiences for retail workers May 28, 2025 From the frontlines: Managing warehouse devices with Microsoft Intune July 01, 2025 From the frontlines: Managing common kiosk scenarios in your business August 28, 2025 From the frontlines: Delivering critical early responder device management September 30, 2025From the frontlines: Delivering critical early responder device management
By: Catarina Rodrigues – Product Manager 2 | Microsoft Intune In high-stakes environments like emergency response, speed, accuracy, and security are essential. Whether it’s paramedics delivering life-saving care or police officers responding to critical incidents, frontline teams need real-time access to information—right where the action is. To meet these demands, emergency services are increasingly deploying mobile devices, paired with advanced device management solutions, to empower their teams in the field. I’m Catarina Rodrigues, a Product Manager in the Microsoft Intune team, and in this blog of the “From the Frontlines” series, I’ll share my experience working with emergency services, exploring how to deploy and manage iPads and Android tablets using Intune. For more information refer to: Frontline worker device management overview in Microsoft Intune. Shared iPads in ambulances Ambulances operate around the clock, often with rotating crews. To ensure seamless and secure access to clinical apps, maps, and emergency protocols, organizations are increasingly often equipping vehicles with iPads that are prepared to be shared by personnel working shift. There are different ways to support Apple devices for frontline scenarios depending on the requirements. Shared iPad mode is recommended for shared use of iPads; it creates multiple user partitions, making it easy for several users to log in and access their applications and data according to their preferences. Intune together with Apple's Automated Device Enrollment (ADE) makes it simple to address this scenario seamlessly, enabling zero-touch provisioning and device supervision for additional security configurations. Below is an ADE enrollment profile configured to setup devices as Shared iPads: User affinity: Enroll without User Affinity Supervised: Yes Locked enrollment: Yes Shared iPad: Yes You can then configure the number of maximum cached users and inactivity settings for these profiles, as needed. Once iPads are enrolled and functional, users will be able to setup their profiles, where they’ll have access to the applications and data according to their permissions. Once their profiles are setup, users can see them in the login screen, as they will be available for them to login again in the future. Benefits of Shared iPad with ADE for IT admins and frontline workers Zero-touch deployment: Devices are automatically enrolled and configured via Apple’s Automated Device Enrollment (ADE), reducing manual setup and ensuring consistency across the fleet. Targeted assignment: Enables IT admins to permanently assign an iPad to a specific ambulance, streamlining shift handovers and ensuring paramedics always have access to the right tools. Persistent configuration: Shared iPad can cache up to 100 user profiles (24 recommended on a 32 or 64 GB iPad), ensuring device settings and apps remain consistent and reducing login friction. Enhanced security and compliance: While these devices are shared, device-level management and app protection policies keep sensitive data secure and encrypted. Remote actions and support: IT teams can monitor, lock, or wipe devices remotely through Intune, with supervision mode enabling deeper administrative controls, such as Lost Mode and Locate Device. This setup gives paramedics immediate access to clinical apps, maps, and protocols and all information they might need to access or share without compromising security or adding friction to their workflow. Fully managed Android tablets for police For police departments, data sensitivity is paramount. Officers need access to real-time intelligence, case files, and communication tools without risking exposure of confidential information. While there are other options to enroll Android devices in Intune (you can see an overview here), setting up corporate-owned, fully-managed Android tablets with Intune can deliver the data protection and device lock-down that police departments need, while ensuring police officers remain productive. Users won’t be able to change pre-defined configurations and install applications from the public store. These devices are associated with a single user, in this case a police officer, as they aren’t intended for shared use. To ensure minimal disruption in the working day of these users, IT admins can use device staging to decrease the number of steps needed to enroll a brand-new device and get it to a functional state. Device staging Device staging is designed to simplify and accelerate the deployment of corporate-owned, fully managed Android devices—especially in high-stakes environments. Instead of requiring police officers to navigate a lengthy setup process, IT teams or authorized third-party vendors pre-configure the devices using a secure enrollment token generated in the Intune admin center. This token allows the device enrollment and provisioning without needing the officer’s credentials, ensuring that critical apps, such as Intune and Microsoft Authenticator, are installed and ready before the device is even handed over. When the officer powers on the device for the first time, they simply sign in to the Intune app, and the device completes its configuration, applying all necessary policies and security settings (see image below). This approach not only saves valuable time during rollouts but also ensures that every police officer receives a consistent, secure, and fully operational device from the moment they turn it on—an essential advantage when reliability and speed are crucial. In the picture below, you see the steps users go through to complete enrollment which requires authentication using the Intune application, so that apps and policies assigned to that user identity are applied. Microsoft Intune and Android Enterprise corporate-owned, fully managed enrollment To enable device staging, IT sets up an Android Enterprise enrollment profile, with a token associated that has a configurable expiry date, up to 65 years in the future. This token can be revoked any time as needed. In addition, IT can also apply a device naming template to all the devices that are enrolled under the same profile, making it easier to identify and group devices by police station, department, or region. You can check the supported strings for this device naming template here. Below you can see an example of an enrollment profile configured with the following parameters: Token type: Corporate-owned, fully managed, via staging Apply device name template: Yes Device name template: {{SERIAL}} Benefits of corporate-owned, fully managed, via staging for IT admins and frontline workers End-to-end control and security: IT admins retains full control over the device lifecycle—from provisioning to retirement—ensuring that only approved apps, settings, and security policies are applied and maintained throughout use. Simplified, secure user experience with Managed Home Screen: Managed Home Screen provides a locked-down, customizable launcher that ensures users access only approved apps and settings. This minimizes distractions, enhances security, and delivers a consistent, role-based experience across all devices—ideal for high-stakes field environments. Faster, frictionless rollouts: Device staging eliminates the need for users to complete complex setup steps. Devices arrive pre-enrolled and pre-configured, so users can simply sign in and start working immediately. Consistent, compliant configuration: Every device is enrolled with the same baseline—apps, policies, and restrictions—ensuring compliance with organizational standards and reducing variability in the field. Reduced IT overhead: By shifting setup responsibilities to staging teams or vendors, IT departments can scale deployments without increasing support load or requiring one-on-one onboarding. Operational readiness from day one: Users receive devices that are mission-ready, with secure access to critical apps like dispatch systems, communication tools, and field data—right out of the box. This setup gives officers the tools they need while maintaining operational integrity and data confidentiality. Summary This blog post explored how to securely manage devices used by emergency services teams. These examples are applicable to other scenarios where workers need to access confidential, sensitive information while in the field. I hope this blog inspires you to try these methods and look forward to answering questions in the comments. This blog is part of the “From the Frontlines” series, where we explore different scenarios of how workers in field use devices and how IT admins can enable them. Check the other blog posts for more inspiration! Please refer to the documentation here for more guidance: For information on how to support Apple devices in the frontline refer to: Get started with iOS/iPadOS frontline worker devices. For information on how to set up Shared iPad refer to: Shared iPad devices. For information on how to support Android devices in the frontline refer to: Get started with Android frontline worker devices. For information on how to set up corporate-owned, fully managed Android devices refer to: Set up enrollment for Android Enterprise fully managed devices. If you'd like to learn more about incorporating device staging to reduce user steps during enrollment see: Device staging overview. To ensure your organization can navigate modern security challenges following Microsoft's Zero Trust approach see: Zero Trust security strategy. As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam or @MSIntune!New policy implementation and web enrollment for Android personally owned work profile
We’re happy to announce two improvements for the management of Android personally owned work profile devices with Microsoft Intune, which will be available in the first quarter of calendar year 2026. 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. Action may be required by you as we move to the new implementation. 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: A URL (new!) Productivity apps (when admin has configured conditional access so that the user is required to enroll before accessing corporate resources) The Company Portal app This gives you more options for how to guide your users to get set up. 3. Android enrollment is more consistent with the iOS web-based enrollment flow. How to configure and monitor Web based enrollment We will release a new setting that will allow you to switch your tenant to the new web-based enrollment for all personally owned work profile enrollments going forward. 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. Later on, we’ll automatically configure all personally owned work profile enrollments across all tenants to be web enrollments. New implementation We’ll release a new configuration policy that 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. Later on, Intune will automatically migrate all remaining devices using the custom DPC implementation over to the new AMAPI implementation. Monitoring There’ll be a new report that will show 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 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 We'll update these timelines to provide more specific timeframes in the coming months. 2025: Use this time to revise any relevant policy configurations, update your internal documentation, and prepare your helpdesk teams, as advised below. First quarter of calendar year 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. Later on: 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 AM API. 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. 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. 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. 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'.Support tip: Troubleshoot device cap reached when enrolling devices into Microsoft Intune
By: Premkumar N – Security Customer Experience Engineer | Microsoft Intune When Microsoft Entra or Intune device limits are reached, users will encounter an error when enrolling their device into Intune. While it can be difficult to understand the reason for the failure from the error message, this blog will explain the differences between Microsoft Entra device registration limit and the Intune device enrollment limit, along with the steps to resolve these issues. For an overview of Microsoft Entra and Intune device limit scenarios refer to: Understand Intune and Microsoft Entra device limit restrictions. Let’s look at the experiences on different platforms, followed by the resolution steps. Android Intune device limit reached When the Intune device limit is reached, an Android device enrollment will fail with the following error: To diagnose the issue, review the Intune Company Portal logs for the affected device. Capturing Company Portal logs: Users can select "Email Support" from the error screen to send the logs via email or Send logs from Company Portal. If the Company Portal logs display the “Device Cap Reached” error as shown in the example logs below, this indicates that the Intune device limit has been reached. 2025-07-16T15:07:39.8410000 VERB o.zzafi 13923 6035 sending event: EnrollmentFailureEvent( networkState=CONNECTED, enrollmentFlowType=Enrollment, enrollmentType=AfwProfileOwner, failureName=DeviceEnrollmentFailure, errorException=com.microsoft.windowsintune.companyportal.exceptions.EnrollmentException: Server error = <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Body> <s:Fault> <s:Code> <s:Value>s:Receiver</s:Value> <s:Subcode> <s:Value>s:Authorization</s:Value> </s:Subcode> </s:Code> <s:Reason> <s:Text xml:lang="en-US">Device Cap Reached</s:Text> </s:Reason> <s:Detail> <DeviceEnrollmentServiceError xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment"> <ErrorType>DeviceCapReached</ErrorType> <Message>Device Cap Reached</Message> <TraceId>xxx</TraceId> </DeviceEnrollmentServiceError> </s:Detail> </s:Fault> </s:Body> </s:Envelope>, errorMessage=, sessionGuid=xxx ) By default, Intune allows a maximum of 15 devices per user; exceeding this limit logs an error in the Company Portal. To address this issue, either remove inactive devices that have not checked in to Intune within a specified timeframe, or increase the device limit (up to 15) in the Intune settings. To remove stale devices: Navigate to the Microsoft Intune admin center > Devices > All Devices. Search using the affected user's UPN to view all enrolled devices. Remove any devices no longer in use. To increase the device limit: Navigate to the Microsoft Intune admin center > Devices > Enrollment > Device Limit Restrictions. Select the policy, go to Properties, then edit Device Limit, and adjust the limit (maximum 15). Note: If the Intune device limit is reached, errors are logged in the Microsoft Intune admin center under Devices > Monitor > Enrollment failures. Microsoft Entra device limit reached For Android, users will see the same error message when Microsoft Entra device limit has been reached. You can confirm the Microsoft Entra device limit has been reached by checking the Company Portal logs for the following error: com.microsoft.identity.broker4j.workplacejoin.exception.DrsErrorResponseException: { "code": "invalid_request", "subcode": "error_directory_quota_exceeded", "message": "User 'xxx' is not eligible to enroll a device of type 'Android'. Reason 'DeviceCapReached'.", "operation": "DeviceJoin", "requestid": "xxx", "time": "xxx" } Similar to the Intune device limit reached, to resolve this issue either increase the device limit in Microsoft Entra for Microsoft Entra registration or remove any stale devices associated with the user in the Microsoft Entra admin center. Stale devices are those that are no longer active and can be removed when they haven’t checked in for a specified period. One cause of stale devices is deleting or retiring an Intune device, which may leave behind a record in Microsoft Entra and contribute to reaching the Microsoft Entra device registration limit. To remove stale devices: Go to the Microsoft Entra admin center. Navigate to Microsoft Entra ID > Users. Search for the user using their UPN. Select Devices. This displays a list of registered devices for the user. Devices that are no longer in use can be removed. To increase the device limit for Microsoft Entra registration: Go to the Microsoft Entra admin center. Navigate to Microsoft Entra ID > Devices. Select Device Settings. Locate Maximum number of Devices Per User. Adjust the device limit as needed. iOS Intune device limit reached For iOS, device enrollment may fail with the following error if the device limit has been reached. To check the issue, select 'Report and Email logs' to collect Company Portal logs. If the logs show the below error, it confirms the Intune device limit has been reached. 2025-07-18 12:38:33.427 | utility | 31673 | AlertManager.swift:37 (push(alert:grouping:)) Pushing alert with: grouping = 0 title = Couldn't add your device. message = You have reached the limit of devices you can register. Please contact your company support to increase this number, or review and remove devices that are already registered with this account. into the AlertManager The resolution is the same as Android, refer to the earlier steps for Intune device limit reached on Android. Microsoft Entra device limit reached On iOS devices, Intune enrollment may successfully complete; however, device registration may still result in an error as shown below in the Company Portal app. To collect Intune Company Portal logs, select More > Send logs > Email Logs. When you see the following error message in the Company Portal logs: iOSunderlyingErrorMessage: { "ErrorType": "AuthorizationError", "Message": "User '00000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Ios'. Reason 'DeviceCapReached'.", "TraceId": "00000000-0000-0000-0000-000000000000", "Time": "2025-07-16 14:07:23Z" } To resolve, use the same steps as Android when Microsoft Entra device limit is reached. macOS Intune device limit reached For macOS, device enrollment will fail with the following error when the Intune device limit has been reached. To identify the issue, collect the Company Portal logs by selecting 'Report' and then email the logs. In the logs, when you see the following error, this confirms the Intune device limit has been reached. 2025-07-25 07:39:23.731 | utility | 14262 | AlertManager.swift:37 (push(alert:grouping:)) Pushing alert with: grouping = 0 title = Couldn't add your device. message = You have reached the limit of devices you can register. Please contact your company support to increase this number, or review and remove devices that are already registered with this account. into the AlertManager To resolve, use the same steps as Android when Intune device limit is reached. Microsoft Entra device limit reached For macOS when enrolling into Intune, if the Microsoft Entra device limit has been reached, you’ll notice the following error: In the Company Portal logs, when you see the following error, this confirms the Microsoft Entra device limit has been reached. Description: { "ErrorType": "AuthorizationError", "Message": "User '00000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Mac'. Reason 'DeviceCapReached'.", "TraceId": "00000000-0000-0000-0000-000000000000", "Time": "2025-05-27 05:24:52Z" } To resolve, use the same steps as Android when Microsoft Entra device limit is reached. Windows Intune device limit reached For Windows devices, enrollment will fail with the following error when Intune device limit has been reached: When you see this error, you can check the logs in the event viewer in this path: Source: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin Event ID: 71 MDM Enroll: Failed to receive or parse certificate enroll response. Result: The account has too many devices enrolled to Mobile Device Management (MDM). Delete or unenroll old devices to fix this error. To resolve, use the same steps as Android when Intune device limit is reached. Microsoft Entra device limit reached For Windows, when the Microsoft Entra device limit has been reached, you’ll notice the following error during Intune enrollment: When you see this error, you can check the logs in the event viewer in this path: Windows Device Source: Microsoft-Windows-User Device Registration/Admin Event ID: 304 The get join response operation callback failed with: exit code: Unknown HResult Error code: 0x801c000e Activity Id: a0a15e15-631a-46ab-b0a4-2f540778df7d The server returned: HTTP status: 400 Server response: { "code": "invalid_request", "subcode": "error_directory_quota_exceeded", "message": "User '8b000000-0000-0000-0000-000000000000' is not eligible to enroll a device of type 'Windows'. Reason 'DeviceCapReached'.", "operation": "DeviceJoin", "requestid": "a0000000-0000-0000-0000-000000000000", "time": "2025-05-30 15:33:09Z" } This is the result of the Microsoft Entra device limit reached for the user for Windows platform. To resolve, use the same steps as Android when Microsoft Entra device limit is reached. Device limit reached – Windows Autopilot hybrid join scenario The Microsoft Entra device limit reached error will also occur when changing the primary user in Intune for Windows Autopilot Microsoft Entra hybrid joined devices). In the Autopilot hybrid join scenario there will be two device records in Azure. The Microsoft Entra hybrid join record, and the standard Microsoft Entra join record. Changing the primary user only updates the hybrid joined record in Microsoft Entra, leaving the original user as the owner of the Microsoft Entra join record. The owner entries on the Microsoft Entra join record will impact the device registration limit. Rather than removing the Microsoft Entra join device, which deletes its join state and is not a recommended approach, remove the registered owner on that record. Note: Deploying new devices as Microsoft Entra hybrid join devices isn’t recommended, for more details refer to Microsoft Entra joined vs. Microsoft Entra hybrid joined in cloud-native endpoints: Which option is right for your organization. The following image shows the device state after the Microsoft Entra hybrid joined deployment is completed. User1 enrolled a Microsoft Entra hybrid join device with Intune and Windows Autopilot and the registered user for both the records is ‘user1’. After changing the primary user in Intune to user2, only the Microsoft Entra hybrid joined record is updated for user2. The Microsoft Entra device registration usage for user1 remains unchanged for the Microsoft Entra joined record, both before and after modifying the primary user of the Intune device. This counts toward the Microsoft Entra registration limit for user1. Resolution Before proceeding with the resolution steps for this scenario, it’s important to note the difference between a registered owner and a registered user: Registered owner: A registered owner is the user that cloud joined the device or registered their personal device. The registered owner is set at the time of registration. Registered user: For cloud joined devices and registered personal devices, registered users are set to the same value as registered owners at the time of registration. Remove the registered owner This action can be done using PowerShell and Graph Explorer. Step 1. Check the user's device count in Microsoft Entra ID using Graph Explorer or PowerShell. PowerShell: This query lists the registered devices for the user. Install-Module Microsoft.graph Connect-MGgraph Get-MgUserRegisteredDevice -UserId <userID> Get-MgUserRegisteredOwner -UserId <userId> Sample from PowerShell: Graph Explorer queries: Owned devices for the user GET https://graph.microsoft.com/v1.0/users/{user-id}/OwnedDevices Registered device for the user GET https://graph.microsoft.com/v1.0/users/{user-id}/registeredDevices Sample Graph Explorer output: Only the "ID" in the output is needed to remove the device in next step. { "@odata.context": "******", "@microsoft.graph.tips": "******", "id": "00000000-0000-0000-0000-00000000", "deletedDateTime": null, "accountEnabled": true, "approximateLastSignInDateTime": "******", "complianceExpirationDateTime": null, "createdDateTime": "******", "deviceCategory": null, "deviceId": "******", "deviceMetadata": null, "deviceOwnership": "Company", "deviceVersion": 2, "displayName": "******", "domainName": null, "enrollmentProfileName": null, "enrollmentType": "AzureDomainJoined", "externalSourceName": null, "isCompliant": false, "isManaged": true, "isRooted": false, "managementType": "MDM", "manufacturer": "******", "mdmAppId": "******", "model": "******", "onPremisesLastSyncDateTime": null, "onPremisesSyncEnabled": null, "operatingSystem": "******", "operatingSystemVersion": "******", "physicalIds": [ "******", "******", "******", "******" ], "profileType": "RegisteredDevice" } Step 2. After confirming the user association for the device, remove both the registered owner and user for the Microsoft Entra joined device record to clear the user count toward the pre-defined limit. Graph API query: Replace the 'deviceid' in the following query with the 'id' from the Graph Explorer output from the previous step. Delete Registered Owner DELETE https://graph.microsoft.com/v1.0/devices/{deviceid}/registeredowners/{user-id}/$ref Delete Registered User DELETE https://graph.microsoft.com/v1.0/devices/{deviceid}/registeredusers/{user-id}/$ref This can also be done with PowerShell as below. PowerShell commands In the below commands DeviceID = Microsoft Entra Device ID/ObjectID. It’s important to remove both the registered owner and registered user for the device. Remove registered owner: Remove-mgdeviceregisteredownerDirectoryObjectByRef –DeviceId <DeviceID> -DirectoryObjectId <userID> Sample PowerShell output: Remove registered user: Remove-mgdeviceregistereduserDirectoryObjectByRef –DeviceId <DeviceID> -DirectoryObjectId <userID> Sample PowerShell output: PowerShell or Graph Explorer can also be used to delete the device in other scenarios such as Intune device deletion and Microsoft Entra device ID deletion. Summary Device enrollment can fail when either Intune or Microsoft Entra device limits are reached. These errors can be confusing, however, understanding the difference between Microsoft Entra device registration limits and Intune device enrollment limits makes it easier to sort out and resolve the issue. These issues commonly stem from stale device records, or changing the primary user of a Microsoft Entra hybrid joined device. Resolving them involves removing inactive devices or adjusting device limit policies in the appropriate service. As a best practice, avoid changing the primary user of the Microsoft Entra hybrid joined device and deploy the Windows Autopilot device to new users with a fresh start. Additional information on this topic can be found in the Microsoft Learn docs below: Device limit - Understand Intune and Microsoft Entra device limit restrictions List RegisteredDevices for user - List registeredDevices - Microsoft Graph v1.0 ListOwnedDevices for user - List ownedDevices - Microsoft Graph v1.0 Remove the registered owners for the device - Delete registeredOwners - Microsoft Graph v1.0 Remove the registered user for the device - List registeredUsers - Microsoft Graph v1.0 If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam.Support tip: Changes to Google Play strong integrity for Android 13 or above
By: Wayne Bennett – Sr. Product Manager | Microsoft Intune Google recently implemented changes in May 2025 which require Android 13 or above devices to need hardware-backed security signals and a security patch released in the past 12 months to meet the strong integrity verdict. To minimise the impact of the changes, app protection and compliance policies in Microsoft Intune have been adjusted in alignment with Google’s recommended backward compatibility guidance. However, Microsoft Intune will also enforce the strong integrity requirements by September 30, 2025. You’ll have received a notice in your Message center (MC1085670) if you have devices that won’t meet the new strong integrity standard after this change. Content from the Message center post is also available here: Plan for Change: Google Play strong integrity definition update for Android 13 or above. Prior to this change, if you have existing or plan to create device compliance or APP conditional launch policies with the 'Check strong integrity' value, you should identify devices that don’t meet the new strong integrity verdict requirements. Configure APP or device compliance policy settings to either warn or block users that don’t meet the requirements: Configure device compliance policy For Intune enrolled Android devices, the Minimum security patch level setting can be configured within the Device properties section of compliance policies. You can either update an existing policy or create a new one: Navigate to the Microsoft Intune admin center. Select Devices > Compliance > Create policy, from the Platform list, select Android Enterprise, from the Profile type list, select either Fully managed, dedicated, and corporate-owned work profile or Personally-owned work profile and select Create. Enter a suitable name for the compliance policy and select Next. On the Compliance settings page, depending on the profile type you selected, ‘Minimum security patch level’ is found under either the Device Health or System Security section. To ensure devices meet the Strong Integrity verdict, you should configure ‘Minimum security patch level’ to a date less than 12 months old, the date must be entered in the format YYYY-MM-DD. On the Actions for noncompliance page, the default action is to mark the device non-compliant immediately, update this by setting Schedule (days after noncompliance) to 90 or another value which will allow you time to monitor the devices which don’t meet the patch level requirements. Note: You may wish to configure additional settings such as sending an email to the user, for more details refer to Available actions for noncompliance. On the Assignments page, target the policy to the required group of users or devices. On the Review and create page, save the policy by selecting Create. By configuring the setting Schedule (days after noncompliance), also known as a ‘grace period’, devices which don’t meet the minimum patch level won’t be blocked immediately. This gives you an opportunity to inform users they should update their devices before they’re blocked at a future date. To review the in-grace period devices within the Intune admin center, under Devices > Compliance > Policies, select the newly created security patch level compliance policy and select Per-setting status. Selecting the numerical value in the Noncompliant devices column shows a list of devices which are in the ‘Minimum security patch level’ grace period. You can then reach out to the individual users, asking them to upgrade. Configure APP conditional launch You can also use the conditional launch settings within APP to require a minimum operating system and patch versions. Either update an existing policy or create a new one: Navigate to the Microsoft Intune admin center. Select Apps > Protection > Create, choose Android as the platform you want to target with APP. On the Basics page, enter a name for the policy which makes it easily identifiable. Complete the Apps, Data protection and Access requirements pages with the Android app protection policy settings which meet your organization’s requirements.. Within the Device conditions section on the Conditional launch page configure the ‘Min OS version’ with a minimum required value, such as 13.0, configure Action to Block access, Wipe data, or Warn, as per the action required for your organization. Configure ‘Min patch version’ to a date less than 12 months old, the date must be entered in the format YYYY-MM-DD. On the Assignments page, target the policy to the required group of users or devices. On the Review and create page, save the policy by selecting Create. With the configuration shown, when users launch a targeted app they are blocked if the device does not meet the Android 13.0 or above operating system requirements but will only receive a warning if their device doesn’t meet the minimum patch version requirements. Monitoring You can use the Platform version and Android security patch version columns within the App protection status report to view the current OS version and security patch level deployed to each device. The app protection status report is accessed from the Intune admin center by selecting, Apps > Monitor > App Protection Status. Within the report, you can search and filter for specific Android security patch versions. For user-less Intune enrolled Android devices, use the devices view to check the OS version and security patch version level. From the Intune admin center, select Devices > By platform > Android. The OS version column is displayed by default, you will need to select Columns > Security patch level to view this information. Conclusion Using the examples in this blog post, you can update or implement new policies to identify devices which don’t meet the Play Integrity strong integrity verdict and inform your users prior to the changes which will be enforced at the end of September 2025. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn. Post Updates: 08/25/25: Expanded guidance for the 'Check strong integrity' setting across certain policies.
