About Intune device ownership | Corporate vs Personal
Week 3 of Friday mail sack blog and going strong! I spotted this question on reddit this week and it’s one I’m frequently asked. I think it’s a topic with enough nuance to form a meaty post. The (paraphrased) question is:
Hey Scott… Why do some of my devices report as Corporate-owned and others as personal? Is there a way to control this and why does it even matter?
Answer: Intune looks at the devices’ enrollment method (which I’ll explain below) to decide if the device should have the “ownership” property stamped as “Corporate” or “Personal”.
Intune’s decision is not always perfect since some enrollment methods sit on the fence, however you get a couple of levers to override it. You get a feature called “Corp Device Identifiers” and experiences for manually correcting the value post-enrollment.
Why care? Well firstly, the ownership property is used to protect end user privacy by limiting inventory collection (such as phone numbers and app inventory) and limit remote device actions that you can initiate from the console. It can also be pretty useful for more granular Policy and App targeting (by including it in Azure AD dynamic device group or Intune assignment filter rules) and Intune portal experiences and reports (by using it to slice device lists).
Let me further explain these questions in detail:
- What does ownership do?
- How does Intune determine ownership?
- How can you override or change this decision?
What does ownership do?
Let’s start with the most important thing — why you even care about device ownership:
Protect user privacy:
For personal devices, Intune will not collect some key personal details during inventory collection that it otherwise does for corporate devices:
- Phone number (for mobile phones), and
- Installed applications
These attributes are none-of-the-business of the organization managing personal devices and this promise is also made clear to end-users in the mobile enrollment experiences. To make that privacy consideration more concrete, consider this example..
Would you like your employer to be able to pull a report of all the users (including you) who have the “Job seeker X” (I made this up) app installed on their personal phones so that the HR department could flag which users are a looking for jobs and at risk of quitting in the near future? Probably not right!
By the way, Intune does continue to collect app inventory information for “managed” apps — that is, the ones that it delivers to the device through mobile device management channels, it just won’t collect information on the stuff that users install themselves.
Prevent user self-service destructive actions:
Corporate-owned devices have some built-in protections around them when it comes to user self-service in the Company Portal app and website. For example, users are never allowed to use the “Remove” button on Corporate Windows devices, because this action removes the device from management. You do have some ability to customize this self-service behavior using Intune’s customization policies.
Device list filters
You can filter based on this property across many of the device list experiences in the portal, or in exported reporting options such as Log analytics and PowerBI.
Dynamic device groups and assignment filters
You can use this property to define or refine members of a dynamic device security group or control applicability of user targeted policies using assignment filters.
Tip: Notice the schema difference between Azure AD device and Intune device objects. When creating a dynamic device group based on ownership, you’ll use the value AAD device value “Company”, but when creating filters in Intune you’ll use “Corporate”. You’ll also notice the word “Company” used in Graph API.
And no, I have no idea about the history of this attribute and why it’s different between Microsoft cloud services.. I just know that it would be very difficult to consolidate at this late stage of the game.
Block personal device enrollment
Ownership can also be used to control which devices are allowed to enroll into Intune. You do this using the Enrollment device platform restrictions feature.
How does Intune determine ownership?
As mentioned, Intune makes the initial decision on ownership by mapping the Intune enrollment method.
At a high level the logic is:
- Apple Device Enrollment formerly known as DEP — Corporate
- Windows Autopilot and any other method that involves Azure AD Join or Hybrid Azure AD Joining — Corporate
- Android Enterprise (COSU, COBO, COPE) enrollment profiles — Corporate
- Any user-driven enrollment from the Company Portal app (Apple and Android) or Settings (Windows) — Personal
Here’s a closer look at those mappings. In the table below I’ve provided the granular ‘deviceEnrollmentType’ values from Intune’s managed devices graph API along with a brief description and it’s ownership mapping.
The Enrollment Type (deviceEnrollmentType) is not directly exposed in the Intune portal but you can easily see it using some browser debugging tools or Graph explorer.
How do you influence Intune’s ownership decision?
While Intune does a pretty good job mapping the “Corporate” enrollment methods to be “Corporate” devices, I’ve come across some issues with that logic. For example, you may choose to do a user-driven Company Portal enrollment when migrating iOS devices from another MDM product to Intune rather than going through the Apple Device Enrollment flow, which would require factory resetting all the devices and take a lot longer. In doing that you’d inadvertently end up with Corporate devices incorrectly marked as Personal.
The good news is that Intune gives you two features to fix that:
- Corporate Device Identifiers
- Manually after enrollment
Corporate Device Identifiers
The sole purpose of the Corporate Device Identifiers feature in Intune is to help you override the Intune logic I described above. With this feature you can pre-declare a list of identifiers (typically serial numbers for Apple and Android nowadays) that should always appear as “Corporate”, even if they enroll using one of the personal enrollment methods. With this feature you can add identifiers manually or import a CSV file.
Tip: In the MDM migration example I gave earlier, you could export all device serial numbers from existing MDM product, upload them to Intune as Corporate Device Identifiers and then enroll them in the way that causes the least friction for you and be happy that they’ll be correctly stamped as Corporate.
Manual update after enrollment
The final option to have up your sleeve is to manually update the property on devices once they’ve enrolled. You can do this on a device-by-device basis in the Intune Portal, or in bulk by leveraging Intune’s graph API.
Tip: If you change a device ownership property from Corporate to Personal on iOS and Android devices, end-users will receive a push notification in the Company Portal app that let’s them know about that ownership change.
From the portal
Here’s how to change ownership from the Intune portal. Notice the warning message and the “I acknowledge” checkbox.
From Graph API
You can directly update the ‘ownerType’ property in Graph API. When using the Graph API option there is no “Are you sure” option.
Below example is using Microsoft Graph Explorer:
Header:
https://graph.microsoft.com/v1.0/deviceManagement/managedDevices('Intune-Device-ID-replace-me')Request body:
{“ownerType”: “company”}
Powershell
My good friend David Falkus and fellow Product Manager has also built a PowerShell sample script including a function for setting the ownership property. This script can easily be adapted to update devices in bulk, or set to run automatically on a schedule.
You can find the sample script here on Github:
Summary
In this post I explained the importance of the device Ownership property in Intune, explained how it gets set and the various ways you have to influence that during or after enrollment. I hope you learned something new or this becomes a good reference for you in the future!
Feel free to reach out to me on Twitter or email with more weekly mail sack questions!
