Welcome to the fourth post in our Microsoft Intune Reporting series.

In our first post, we introduced Intune’s reporting framework and core concepts, then dove in to identify and discuss the various Operational reports strewn throughout the system.

In our second post, we identified and discussed the many Organizational and Historical reports in Intune, along with where they excel and where their usage is limited.

In our third post, we began to discuss the options available for advanced Intune reporting beyond that which is provided from the out-of-the-box reports. We specifically introduced and discussed Intune integration with Azure Monitor / Log Analytics along with usage of the Intune Data Warehouse via Power BI Desktop.

In this final post, we will conclude the advanced Intune reporting topic by introducing and discussing how to access real-time Intune data via the Microsoft Graph API, followed by showing off an example custom Intune report created in Power BI and leveraging the Graph API data.

As before, our goal is to empower you to better leverage Intune’s data to understand your endpoint fleet, and help improve security and management of your company’s endpoints. Read on for more information!

Advanced Intune Reporting Continued

Let’s start with a quick refresher on what we mean by “advanced Intune reporting”. Intune collects a wealth of data from managed endpoints, and while much of it is accessible via the Intune portal and out-of-the-box reports, not all of it is, nor is the data always exposed alongside other relevant data, enabling administrators to quickly understand their endpoint environment and make informed decisions for management. Advanced Intune reporting involves querying that data directly from Intune and transforming the data to suit your particular needs, presenting it in whatever form you desire.

Our previous post discussed two methods of advanced Intune reporting, one being through the Azure Monitor / Log Analytics integration, and another through Intune’s Data Warehouse API. The remaining method to discuss is the most powerful and flexible of the three methods – leveraging the Microsoft Graph API directly to query live data from Intune on demand.

Microsoft Graph API

Overview

Microsoft Graph, also known as the Graph API, is defined by Microsoft as, “the gateway to data and intelligence in Microsoft 365”. Put simply, it is a huge collection of standardized APIs that can be used to access the wealth of data stored in nearly every Microsoft 365 service through a single connection point – this includes Azure AD data, Intune data, and far, far more.

The Graph API also functions as the shared underpinnings of the entire Microsoft 365 platform – core functionality across the platform continues to be updated to leverage Graph wherever possible, minimizing or eliminating the use of secret APIs in favor of using Graph. This means that the Graph API is actively and aggressively being developed with new features and functionality being added regularly, and that if data is being expressed in one of the Microsoft 365 web portals somewhere, it can also be available for your usage using Graph API so long as you know where to look for it.

The data used and collected by Intune is all exposed via Graph API. Unlike the Data Warehouse API, which is aggregated and updated daily and intended for trending-style reports, the Graph API provides access to live data within the platform – for reports needing the most up-to-date and detailed data available, Graph is the tool to use.

Microsoft provides a collection of documentation on how to use Graph to query Intune data, what APIs provide access to what data, and more. In the rest of this section, we’re going to summarize what you need to know to quickly get started, highlight some best practices and pitfalls, and show an example of what can be accomplished using Intune data provided by the Graph API.

Connection Requirements

The minimal requirements necessary to access Intune data via the Graph API are as follows:

• The tenant must have at least one active Intune license provisioned for any of the Intune APIs to be accessible.
  • This can be as part of a bundle license (such as Microsoft 365 Business Premium) or a stand-alone license, but a license must be present or an error will be generated when any of the API endpoints are queried.
• Credentials used to access the API must be one of the following:
  • A Service Principal / Azure AD App Registration with:
    • Permission to call Azure AD and the Microsoft Graph APIs generally
    • Permission granted to the specific Intune API scopes needed for the data you wish to query
  • A User Account with:
    • Permission to access the Azure AD tenant containing the Intune environment
    • Intune Administrator permissions granting access to the data you wish to query (custom Intune roles can be used, so long as they grant access to the necessary data)

One important distinction to note when configuring Graph API permissions or connecting to Graph is that there are two high-level types of Graph permissions – “Delegated” and “Application”.

• “Delegated” permissions use user credentials and access is limited first and foremost by the permissions assigned to the user account – to access Intune data, the user must have the correct permissions within Intune. Delegated permissions are intended for interactive sessions, such as when you are running commands in PowerShell on the fly.
• “Application” permissions use Azure AD App Registrations / Service Principals for authentication and access is defined strictly by what API scopes have been configured for that service principal in Azure AD and which ones have been approved by an administrator. Application Permissions are slightly more complex to set up, but are intended to be used by automated processes, such as data collection for reports.

This documentation provides some basic instructions on configuring application access to the Intune Graph APIs.

Relevant Graph API Scopes

As mentioned above, Graph is huge. When you first look at the API reference documentation, you may find yourself overwhelmed – where should you even start to find the data you need? Here’s where we’ll do our best to answer that question.

For the purposes of reporting on Intune, the core data you’ll want is found in the “Device and App Management” megacategory, and more specifically within the “Corporate Management” category. The documentation for this section of the API identifies it as Intune data. Inside there, though, you’ll find several API subsections for “App Management”, “Device Configuration”, “Device Management”, “Mobile App Management”, and more.

You’ll also want to look at “User” and “Group” data so you can report on policy assignments and expand the information returned from the Intune APIs with additional data necessary for your reports.

You won’t likely need to worry about any APIs outside of those unless you want to expand your reporting to other areas of M365, such as Exchange Online, or SharePoint, etc.

Even those sections of the API are huge, though. I recommend starting with the specific scopes called out by Microsoft in this document, then expanding out to other various APIs as needed and as you get a better understanding of how everything fits together.

Fortunately, we have some excellent PowerShell modules from Microsoft that help making initial usage of the Intune Graph APIs much easier.

Usage in PowerShell

Leveraging the Intune APIs in PowerShell is facilitated by the official Graph PowerShell modules provided by Microsoft, known collectively as the Microsoft Graph PowerShell SDK, or simply the Microsoft Graph PowerShell Modules. These modules are hosted in the PowerShell Gallery and the open-sourced code can be found in their GitHub repository here. These modules provide a native PowerShell cmdlet experience for querying the various APIs and retrieving the data in structured objects ready to use for automation or data export to files for use by your preferred analysis tool. The module is well-documented, with extensive usage and contents information found here.

Important Note! You may also be tempted to use the “Microsoft.Graph.Intune” PowerShell module, found in the gallery here and on GitHub here. Be advised – this module is woefully out of date, having not been updated since July 2019. While it still works, it will only provide you with limited Intune data and will not facilitate access to any Graph APIs released in the past several years without doing raw queries with the generic “Invoke-MSGraphRequest” cmdlet. All in all, this module is strongly not recommended. This blog post will focus on using the current, supported PowerShell modules instead.

You’ll notice that the Microsoft Graph PowerShell SDK is comprised of a collection of modules. If you want to install them all, the easiest thing to do is to install the parent “Microsoft.Graph” module from the PowerShell Gallery, which will then trigger installation of all the other modules along with it. This can be done with the following command:

Install-Module -Name Microsoft.Graph

If you want to only install the modules you’ll need for retrieving Intune data, you’ll want to run the following command instead:

Install-Module -Name Microsoft.Graph.Authentication, Microsoft.Graph.DeviceManagement*, Microsoft.Graph.Devices*, Microsoft.Graph.Users*, Microsoft.Graph.Groups

Generally speaking, I recommend simply installing Microsoft.Graph and letting everything be installed, but the option is present to be more specific if needed.

Once the modules are installed, you can connect to Graph using the Connect-MgGraph cmdlet. This cmdlet supports both delegated and application authentication, and numerous means of entering the necessary information for both authentication types. If you are in an interactive session or planning to run a script on the fly, though, the easiest thing to do is just type in Connect-MgGraph – a browser window will open for authentication and then you’ll be in business.

For a list of all the commands available to you to retrieve device data via the Graph PowerShell modules, run this command:

Get-Command -Module “Microsoft.Graph.Device*” -Verb “Get”

You’ll see there are a lot of commands – generally, one for each API in the documentation listed earlier. Fortunately, they are named consistently based on the object type being retrieved, so while there are many names and the names can be quite long, a decent knowledge of what data you are wanting to retrieve from Intune will enable you to find the right cmdlet quickly.

We’re not going to go through the usage of every cmdlet contained in the modules here, but you can find extensive reference documentation on each cmdlet here. The beauty of these modules is that they follow standard PowerShell design and usage principals – all of your existing knowledge of data collection, transformation, and export using PowerShell can be applied here without any need for learning new techniques. Use these modules to collect the detailed data you need, export it to CSV or whichever other format you find useful, import it into Excel or your other favored data analysis tool, and report away!

Usage in Power BI

If you want to skip the middle-man and have your reporting tool retrieve data directly from Graph, that is entirely supported as well. Just as with the Data Warehouse API in the previous post, we’ll use Power BI here to illustrate how we can pull data into our reporting tool directly from Intune’s APIs and then use said tool to express and visualize the data however we need.

When performing a direct query of a large amount of data from Graph, there are a few best practices you want to be aware of and take into account when designing your queries. This article from Microsoft provides a collection of best practices and guidance; you’ll want to pay special attention to the recommendations on handling data pagination to ensure you are getting all of the available data when you perform your queries.

Graph APIs can be queried from Power BI using the Web Content data query type. However, given that you’ll need to query multiple Graph APIs to get all the data you need for your report, the default “basic” query will be inefficient and/or insufficient for your needs – you’ll want to go into the advanced editor and use raw M scripts to query your data. Don’t worry – we’re going to make it a little easier for you.

Antoine Journaux, a Microsoft Senior Product Manager on M365 Defender, wrote an excellent blog post back in 2021 that walks through the process of using a Power BI Function to connect to Graph from Power BI, along with describing in detail some of the challenges you could face otherwise. It is an excellent post and required reading when you want to use Power BI with Graph – check it out here. Section 4 has the most important part – a pre-written Power BI function that takes a Graph API relative URL as a parameter that can be used for all of your report data querying. I’m reproducing the function text below for easy reference, but you should take the time to read the original post for the full information. Here’s the function code:

(GraphURI as text) as record =>
let
ResourceAppIdUrl = “https://graph.microsoft.com”,
OAuthUrl = “https://login.microsoftonline.com/”,

Resource = Text.Combine({“resource”, Uri.EscapeDataString(ResourceAppIdUrl)}, “=”),
ClientId = Text.Combine({“client_id”,ApplicationID}, “=”),
ClientSecret = Text.Combine({“client_secret”, Uri.EscapeDataString(ApplicationSecret)}, “=”),
GrantType = Text.Combine({“grant_type”, “client_credentials”}, “=”),
Body = Text.Combine({Resource, ClientId, ClientSecret, GrantType}, “&”),

AuthResponse= Json.Document(Web.Contents(
OAuthUrl,
[
RelativePath= Text.Combine({TenantGUID,”/oauth2/token”}),
Content=Text.ToBinary(Body)
]
)),

AccessToken= AuthResponse[access_token],
Bearer = Text.Combine({“Bearer”, AccessToken}, ” “),

Response = Json.Document(Web.Contents(
ResourceAppIdUrl,
[
RelativePath = GraphURI,
Headers = [#”Content-Type”=”application/json”, #”Authorization”=Bearer]
]
))

in

Response

With that code saved as a function in your report, you can then create additional queries that call the function to efficiently retrieve the data you want without having to rewrite that logic each time. Assuming you have saved your function with the name “PerformGraphQuery”, you can use it in other queries with the following code:

Response = PerformGraphQuery(“beta/deviceManagement/managedDevices”)

The relative URL listed in the example would just need to be replaced with the appropriate relative URL for the API you wish to query; that relative URL will be listed inside the documentation for said query, making it easy to transition from documentation to usage.

From there, standard Power BI processes can be followed to format the data in the PowerQuery Editor before moving into the main Power BI interface to build your report.

Just as before, a full tutorial of Power BI Desktop is out of scope of this blog post, but refer to Microsoft’s Power BI Getting Started documentation for a breakdown of how Power BI works and how to go about working with the Graph API data to build the custom reports you need.

While there is a lot of additional knowledge needed of how Graph is structured and how to use your reporting tool to take full advantage of this approach, the end result is powerful and can be use any way you can present the data. Graph API provides the capability for advanced, detailed, and robust Intune reporting to meet whatever your specific need is.

Example – The Model UEM Dashboard

We’re not going to end this post without showing an example of what can be achieved with the Graph API for Advanced Intune Reporting. Here at Model, we’ve developed a Power BI report of our own to help accelerate the analysis and troubleshooting of endpoint management issues with our managed clients.

Just as described above, this report leverages the Graph API to collect data from Intune, as well as Azure AD and Defender, to provide a more rapid vehicle for analyzing and identifying common errors and issues in our client’s endpoint fleets. This enables us to accelerate resolution of those issues by streamlining our triage processes. It also provides us with the ability to search and filter the lists of devices, updates, etc., by additional parameters not exposed within the Intune portal.

Here are some example images of what can be achieved by collecting data from Graph and customizing it to your needs in Power BI:

The above image is part of our Windows Updates and Servicing report, which gives us at-a-glance knowledge about our device update compliance state, while providing easy searching and filtering of current devices to identify which ones are noncompliant and why, all on the same page.

The above image is part of our Device Security report, quickly identifying devices with known vulnerabilities and allowing us to sort and filter to see which specific devices are affected by each detected vulnerability. This allows us not only to prioritize remediation but also know which devices need to be remediated without having to load any additional web pages.

This final image is an accumulated, filterable, sortable list of all software discovered by Intune across all of our managed devices, making it easy to find what users are using, both supported apps and non-supported apps, so we can identify opportunities for further application standardization, packaging, or other application management tasks.

Interested in setting up this kind of centralized dashboard in your own environment? You could do it on your own as described above, or you could have Model Technology Solutions do it for you.

Microsoft software’s strengths are generally not in reporting. As we’ve seen in the last two posts, much of the reporting data gathered in Intune is not easily accessible, and doing so can be a difficult and time-consuming task. This shortcoming extends to other software in the Microsoft suite.

To fill this gap, we offer a single-pane-of-glass solution for aggregating a broad spectrum of data from the different Microsoft endpoint software into one convenient PowerBI dashboard.

Do you have multiple Microsoft programs gathering data from your endpoints, including Intune? Would it be helpful to have a single, centralized location where you could go to view and export this data in near real-time for reporting purposes? Our dashboard, when deployed fully, aggregates data from more than just Intune – we can also set it up to pull and display data from Configuration Manager, Azure, Defender, and more. Using this dashboard, you can centralize, display, and export the data from all these different sources so that it can be referenced and used easily for the purpose of better understanding and managing your endpoint fleet.

We can set this dashboard up whether your environment is totally on-premises, in the cloud, or some of both. If you’re interested in seeing this dashboard’s capabilities when fully deployed, you can watch a demo here.

 Conclusion

In this series, we have provided a comprehensive look at Intune’s reporting approach, the capabilities provided out of the box, and the methods available for using Intune’s data to perform advanced reporting. Our goal has been to help you make the most of your investment in Intune and the data available within the platform – both by knowing where to find what you need via the wealth of native reports, as well as introducing techniques for more advanced Intune reporting.

Our hope is that this series has continued to be useful in introducing you to the various capabilities for reporting in Intune, and preparing you for building your own custom reports to power and inform your endpoint management processes to the benefit of your organization.

Thank you for making it through with us to the end of the series! If you’ve liked what you’ve read, let us know, and let us know other topics you’d like us to dive into in more detail in the future.