Reporting on group membership for Entra ID devices (including assigned licenses)

Today’s topic is about generating a report of the set of groups each (Entra ID) device in the tenant is a member of. This is a task relevant to organizations using device-based licensing for Microsoft 365 Apps for Enterprise, among other scenarios. As the Entra ID UI is not exactly optimized for addressing scenarios around device’s group membership, and the Microsoft 365 Admin center even less so, we turn to the Graph API and/or the Graph SDK for PowerShell.

In fact, we already covered this in a previous article back in 2020, when no alternative of direct Graph API queries existed. A sample script was also provided, but as things have changed for the better since then, we can now also cover the cmdlets that can be leveraged to address such scenarios via the Graph SDK for PowerShell. That said, the solution we will present here is just for illustrative purposes, and we will not go beyond the basics.

OK, so how can we approach this task? We will need the list of devices first, and here comes the first “gotcha”. Devices we see and manage via Entra ID are not the same thing as devices in Intune, they are in fact represented by different object types as well as different identifier values. For the purposes of this article, i.e. reporting on device’s group membership and potential license assignments, we care about the Entra ID device object only. Which always includes the Intune device objects anyway.

The next “gotcha” is the device identifier. In Entra ID, we get more than a fair share of those, but for the task at hand we only care about two: the device’s object id, and the deviceId. Only the former one is considered as “key”, i.e. a value against you can run the GET method on the /devices endpoint, whereas the latter only works with $filter. And here’s the kicker, one of the many, many, many reasons why i just “love” the autogenerated crap in the SDK – the cmdlet parameter might be named -DeviceId, but it expects an id value:

$test = Get-MgDevice -Top 1
$test | select id,DisplayName,DeviceId

Id                                   DisplayName DeviceId
--                                   ----------- --------
0454a6b5-9b7b-4b16-a88f-79fedf2d37a5 DIMO        3aef7c7b-1271-4d14-aca0-2888e194ce4e

Get-MgDevice -DeviceId $test.DeviceId
Get-MgDevice_Get: Resource '3aef7c7b-1271-4d14-aca0-2888e194ce4e' does not exist or one of its queried reference-property objects are not present.

Get-MgDevice -DeviceId $test.Id | select id,DisplayName,DeviceId

Id                                   DisplayName DeviceId
--                                   ----------- --------
0454a6b5-9b7b-4b16-a88f-79fedf2d37a5 DIMO        3aef7c7b-1271-4d14-aca0-2888e194ce4e

But I digress. Once we have the list of devices we want to cover, we can fetch the required information via a single Graph API query, and thanks to some actual improvements in the SDK, a single cmdlet, per device that is. The script then boils down to deciding what are the properties of the device and group objects you want to expose, and the format to use. Different people will have different views here, but for the same of simplicity, I opted for the handful of the more important properties and a CSV file.

I am again providing you with two script samples, one leveraging “raw” Graph API requests and application permissions for a fully automated solution, and another one leveraging the Graph SDK for PowerShell and delegate permissions. The scripts will require Device.Read.All and Group.Read.All permissions to be granted. If you are going to run the “raw” script, do make sure to also configure the authentication variables (lines 12-14), or replace the whole authentication block. For the SDK version of the script, the user you will be running under must have sufficient permissions to read device and group objects within the organization, something like the Reports Reader role would do.

If you run the script without any parameter, it will report on all devices within the tenant. Alternatively, you can leverage the –DeviceList parameter to run it against a subset of the devices. Below you can find some examples on how to run the script, but first make sure to get your copy from my GitHub repo, for either the Graph API or Graph SDK for PowerShell version.

#Run the script without any parameter to generate a report on all devices
. \Graph_Devices_MemberOf.ps1

#Use the -DeviceList parameter to run it against specified devices only
. \Graph_Devices_MemberOf.ps1 -DeviceList 126e6c29-de6f-4622-9795-07ad9ff2e613,02c0168b-babe-4ab9-98a6-9e834eb6e49c

#You can also use a CSV file as input
. \GraphSDK_Devices_MemberOf.ps1 -DeviceList (Import-Csv .\blabla.csv).Id

One thing I forgot to mention above is that you can use either the device’s id or deviceId property when running the script with the -DeviceList parameter. As the script validates the input with a call against the /devices endpoint, we use a simple $filter query to check both properties:

$filter = "deviceId eq `'$device`' or id eq `'$device`'"
$uri = "https://graph.microsoft.com/v1.0/devices?`$filter=$filter&`$select=id,deviceId,displayName"

As you can see from the above, we also minimize the data returned by requesting only properties we expose in the output. If you want to add additional properties, make sure to update the corresponding $select query. Do not forget that some props need to be specifically requested, for example the assignedLicenses one on the group’s resource. Lastly, you must also add them to the definition of the $dInfo object which handles the output. Speaking of which, here’s how the output looks like:

And here are short descriptions on the fields you can find in the report:

• • Id – the device object id
  • DeviceId – the device deviceId (see text above for the difference).
  • Display Name – displayName of the device object.
  • Group – the object id of the group (“N/A” value indicates the device is not a member of any group).
  • GroupName – the displayName of the group.
  • GroupType – the type of group. Acceptable values include: Entra ID Security, Distribution and Mail-enabled Security. If you see any other value, i.e. Microsoft 365 Group, let me know 🙂
  • GroupSynced – indicates whether the group is synced from on-premises AD.
  • GroupMembershipType – membership type of the group, either Assigned or Dynamic membership.
  • GroupMembershipRule – if the group is dynamic membership one, the membership rule should appear here.
  • HiddenMembership – whether the group’s membership can be seen by non-members… left for “compatibility” purposes.
  • GroupLicenses – if the group has been assigned any licenses, a semi-colon separated list of the corresponding SKUIDs will be shown here.

As always, feel free to modify the scripts to better suit your needs and let me know if you have any feedback. Cheers!