device enrollment manager
2 TopicsDesktop support enrolling Autopilot devices - DeviceCapReached error
We're currently in the middle of a quarterly equipment lease swap and have had a couple of people on our team getting the DeviceCapReached error when we go to enroll an Autopilot device. This is happening because we're enrolling the devices with our accounts, rather than having the user sign in, then taking the laptop back from them to put it in the right on prem OU, run updates and install all of the software they need. I understand this isn't how Microsoft designed Autopilot to work, but this is where we're at. I've done research into potential resolutions, but I have a lot of questions. First, some important details User-driven deployment profile (future proofing, I guess) Microsoft Entra hybrid enrollment Intune device enrollment limit - 7 Azure tenant device limit - 20 The first option seems to be creating a script that clears out stale devices from our Azure tenant. When I've spoken with our Infrastructure team about device removal in the past, they said we're using Entra Connect to sync with on prem AD, so they we're against the idea. I've found a way to convince them otherwise, but it's going to take time and scripting. The next option is using a device enrollment manager account, but the https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment-manager-enroll?source=recommendations mentions it enrolls the device in shared mode and that device limits won't work on devices enrolled this way. It also says "Do not delete accounts assigned as a Device enrollment manager if any devices were enrolled using the account. Doing so will lead to issues with these devices." but doesn't elaborate further. So, this option seems like a dead end. Third option is to increase the device enrollment quota in Azure, but since this is a tenant wide setting, we don't necessarily want to give Rick in accounting the ability to enroll as many devices as he can carry. I found a comment in https://www.reddit.com/r/Intune/comments/1f34o0v/device_limit_reached_cant_remove_devices_from_user/ that suggested using Remove-AzureADDeviceRegisteredOwner (now Remove-MgDeviceRegisteredOwnerByRef with the graph modules). But this just change the primary user. Doing so didn't stop me from getting the error message. So here are my questions - If you've gone through this, how did you resolve the issue? What exactly are the consequences of using a DEM account to enroll devices? If I look at the devices attached to my user account, and filter by Autopilot devices, I have 42. Other offices have a single desktop person, and they have > 80 devices. What device property, in which directory, causes this error? Do you have a stale device script you'd recommend? I'll write my own, for sure, but having something to go off of would be nice1.3KViews0likes3CommentsBest practices for enrolling shared devices in Intune
We need to enroll a couple of computers as shared devices in Intune. These devices are Windows 11 computers, but we plan to add a couple of iOS devices as well in the short term (iPads). These machines still need to be managed with Intune for updates, security policies, etc. Until now we have used an administrator account to set up these machines, but this is not ideal as employees can leave the company and the machines need to be reassigned to a new primary user, the management name needs to be updated, etc. I am considering using a dummy user as an Enrollment Manager to set up shared machines, but I am wondering if there are best practices for this. In particular: Is it better to use a "dummy user" account or a "resource account"? What kind of license is required for this user? Intune Plan 1? Even if this is a resource account? Any issue if, after setup, the "dummy user" never logs in the device anymore? Other considerations to keep in mind for this scenario? As this user would not be an admin and wouldn't have any access to SharePoint sites or other company data, it would be easier to make an exception from dual factor authentication, would this be considered an acceptable risk or a big no? Thank you for sharing your opinion and past experience on this. G.Solved13KViews0likes4Comments