ebook
Advanced Intune Reporting
Your comprehensive resource about the various different types of reports in Microsoft Intune, plus where and how to access them.
M365 →
Cybersecurity →
Cloud & Datacenter →
Help Desk →
Ebook Overview
You have enrolled your endpoints into Microsoft Intune, you’ve configured policies, and you are managing your devices. What’s next? How do you validate your endpoints’ management states, and how do you track the health of your endpoints over time?
We here at Model Technology Solutions have talked at length about the capabilities Intune provides for managing endpoints & operating system updates, endpoint configuration, application deployment, and more.
This series of posts will focus on another important element of endpoint management – reporting, or, the ability to understand current and historic data about your endpoints’ actual state and the results of your management configuration.
This series will cover:
- Intune’s reporting approach
- Capabilities provided out of the box
- Methods of using Intune’s data to perform advanced reporting
This knowledge will enable you, as an Intune administrator, to better utilize the wealth of data contained within the Intune service for the benefit of your organization.
This series is for Intune administrators who want to better utilize the wealth of data contained within the Intune service to benefit their organization through increased visibility into and understanding of their endpoint devices’ state, as well as aiding with improving configuration and addressing potential security holes.
One important caveat – all information in this post is based on the current state of Intune as of January 2022. While the core Intune reporting structure is likely to persist well into the future, specific details of report names and locations may shift over time.
Table of Contents
Intune Reporting Overview
Microsoft Intune – a core component of Microsoft Endpoint Manager – is Microsoft’s modern, cloud-based platform for managing endpoint devices and applications. Intune contains a wealth of data on the endpoints it manages, all of which is available in various ways for administrators to use in managing Intune and the endpoint configuration. Microsoft has established and defined a framework for how that data is exposed within Intune to ensure the data administrators need is close at hand alongside their management activities.
This framework not only defines several types of reports by their intended usage, but allows the reporting data to be made available throughout the Intune environment in places intended to be easily accessible and relevant to the specific report types.
An important takeaway from this is that the “Reports” node in the Intune navigation menu is not a holistic collection of all of Intune’s reporting data.
This is unfortunately a common point of confusion for Intune users, and an understandable one at that. It would make sense that all of the reporting data would be found in a node called “Reports”…but in reality that is only a subset of the available data.
The following sections will discuss the various types of reports that comprise Intune’s reporting framework, the intent for each type, and where that data can be found in addition to the “Reports” module.
Types of Reports
The Intune reporting framework defines four types – or focus areas – of reports:
Operational
Provides timely, targeted data that helps you focus and take action.
Admins, subject matter experts, and help desk technicians will find these reports most helpful.
Organizational
Provides a broader summary of an overall view, such as device management state.
Managers and admins will find these reports most helpful.
Historical
Provides patterns and trends over a period of time.
Managers and admins will find these reports most helpful.
Advanced / Specialist
Allows you to use raw data to create your own custom reports.
Admins will find these reports most helpful.
In part one of this ebook, we will cover only the Operational Reports category. The remainder of the categories of data will be featured in future posts.
Where to Find Reports
As noted above, reports are found in different places in the Intune portal depending on their type and intended usage.
Operational reports comprise the majority of the reports available in Intune today. These can be found in numerous places throughout the Intune portal and can be grouped into three categories:
- Overview reports
- Monitor reports
- Dashboards
When navigating through the Intune web portal, almost every section initially loads an “Overview” or “Summary” page which displays a set of reports as tabs in the workspace – these are the “Overview” reports.
Furthermore, each section has either a link labeled “Monitor”, which loads a list of reports, or a category of views labeled “Monitor”, under which additional reports are listed. Essentially, everywhere in the Intune portal that lists “Monitor” is a collection of the “Monitor” reports.
Finally, the main Intune node titled “Dashboard” is where Dashboard reports can be found, including the pre-configured Intune overview dashboard and any custom dashboards created by administrators.
Organizational and Historical reports can be found in the “Reports” node in the Intune navigation menu. These reports are grouped into several categories and provide broader views of the organization’s managed endpoints and management state.
“Specialist reports” refer to the abilities exposed by Intune for creating custom reports. This data can be accessed via the “Reports” node in the Intune navigation menu in the categories labeled “Intune Data Warehouse” and “Azure Monitor”.
The following sections will go into further detail on the different types of reports and, most importantly, how to go about configuring custom reports.
Overview Reports
Overview reports can be found at the top level of the Devices and Apps nodes in the Intune portal. These depict a collection of actionable and summary information about the state of managed devices and apps, providing administrators with immediate access to key information they need. These reports also alert the administrators to specific issues they may want to address.
In the Devices node, the Overview report contains four separate tabs, each displaying one or more reporting tiles with summary information, including:
The “Enrollment Status” tab displays the counts of Intune enrolled devices by operating system, the enrollment failures by operating system, and the top enrollment failures in the past week.
The “Enrollment Alerts” tab displays a list of any active alerts generated from enrollment issues.
The “Compliance Status” tab displays:
Counts of managed devices by their compliance state.
Counts of managed devices broken into Compliant and Non-Compliant for each assigned Compliance Policy.
Number of devices without Compliance Policies assigned to them.
Compliance settings with the highest number of non-compliant devices.
The “Configuration Status” tab displays the counts of users and devices by configuration profile application status and the profiles with the highest count of deployment errors.
In the Apps node, the Overview report contains two separate tabs with reporting tiles, including:
The “Installation Status” tab displays the applications with the highest counts of installation failures by device type and the total count of applications with installation failures.
The “App Protection Policy Status” tab displays the total count of users who have been assigned application protection policies which are grouped by whether they are licensed or not, along with the count of users that have been flagged from application protection policies.
In both of these Overview reports, clicking on any of the reporting tiles drills down to specific Monitor reports with further information on the topic at hand.
Additional Overview reports can be found in the Endpoint Security node when selecting several of the options in the “Manage” category. These are functionally similar to the Devices and Apps Overview reports in that they may have multiple tabs of data with reporting tiles displaying high-level state information for administrators, though they also share the workspace with the interface for configuring the relevant endpoint security policies.
The specific reports at the time of writing include:
Under “Antivirus”
The “Summary” tab displays the counts of unhealthy endpoints by category, along with the count of active malware in the environment.
The “Unhealthy Endpoints” tab displays a list of all endpoints suffering from malware infection.
The “Active Malware” tab displays the identities of all active malware detected on managed devices.
Under “Firewall”
The “Summary” tab lists the count of devices with the firewall turned off.
The “MDM Devices Running Windows 10 or Later with Firewall Off” displays the list of specific devices with the firewall turned off.
Operational Reports
As noted above, Operational reports are located throughout the Intune web portal and are intended to provide timely, targeted data within the context of the administrator’s current actions.
For example, Operational reports about Device state can be found in the Devices node alongside the tools for configuring device policy.
Overview Reports
Overview reports can be found at the top level of the Devices and Apps nodes in the Intune portal. These depict a collection of actionable and summary information about the state of managed devices and apps, providing administrators with immediate access to key information they need. These reports also alert the administrators to specific issues they may want to address.
In the Devices node, the Overview report contains four separate tabs, each displaying one or more reporting tiles with summary information, including:
- The “Enrollment Status” tab displays the counts of Intune enrolled devices by operating system, the enrollment failures by operating system, and the top enrollment failures in the past week.
- The “Enrollment Alerts” tab displays a list of any active alerts generated from enrollment issues.
The “Compliance Status” tab displays:- Counts of managed devices by their compliance state.
- Counts of managed devices broken into Compliant and Non-Compliant for each assigned Compliance Policy.
- Number of devices without Compliance Policies assigned to them.
- Compliance settings with the highest number of non-compliant devices.
- The “Configuration Status” tab displays the counts of users and devices by configuration profile application status and the profiles with the highest count of deployment errors.
In the Apps node, the Overview report contains two separate tabs with reporting tiles, including:
The “Installation Status” tab displays the applications with the highest counts of installation failures by device type and the total count of applications with installation failures.
The “App Protection Policy Status” tab displays the total count of users who have been assigned application protection policies which are grouped by whether they are licensed or not, along with the count of users that have been flagged from application protection policies.
In both of these Overview reports, clicking on any of the reporting tiles drills down to specific Monitor reports with further information on the topic at hand.
Additional Overview reports can be found in the Endpoint Security node when selecting several of the options in the “Manage” category. These are functionally similar to the Devices and Apps Overview reports in that they may have multiple tabs of data with reporting tiles displaying high-level state information for administrators, though they also share the workspace with the interface for configuring the relevant endpoint security policies.
The specific reports at the time of writing include:
Under “Antivirus”
The “Summary” tab displays the counts of unhealthy endpoints by category, along with the count of active malware in the environment.
The “Unhealthy Endpoints” tab displays a list of all endpoints suffering from malware infection.
The “Active Malware” tab displays the identities of all active malware detected on managed devices.
Under “Firewall”
The “Summary” tab lists the count of devices with the firewall turned off.
The “MDM Devices Running Windows 10 or Later with Firewall Off” displays the list of specific devices with the firewall turned off.
Monitor Reports
Monitor reports can be found at various locations within the Devices, Apps, and Endpoint Security nodes, providing more detailed information beyond that which is listed in the Overview reports.
Each of these reports provide the ability to search across the displayed columns, modify which columns are displayed, sort by any column displayed*, and export the data to CSV format for further exploration in Excel or other data analysis tools. Furthermore, items in each report can be clicked through to review the specific item’s details, providing access to further information that may be relevant for the report.
*Note: At the time of writing this, most Monitor reports allow sorting by every column available, however some reports do not. Microsoft has stated that their intent is to allow sorting of all columns and they are slowly rolling that out across the range of Monitor reports found in Intune.
In the Devices node, there is a dedicated Monitor link that loads a collection of reports, organized into categories named “Configuration”, “Compliance”, “Enrollment”, “Software Updates”, and “Other”. The following reports can be found there:
Under “Configuration”
The “Assignment Status” report lists the counts of devices with errors, conflicts, or pending statuses for each Configuration Profile.
The “Assignment Failures” report lists the count of devices with errors for each configuration profile with assignment errors. Clicking through a profile provides more information on the specific devices that have failed.
The “Devices with Restricted Apps” report displays a list of devices upon which applications configured as restricted are currently installed. This report helps administrators quickly identify the users to contact and devices to align with organizational policy on restricted apps.
The “Encryption Report” lists each managed device along with their readiness for encryption, TPM chip version, and OS version. Individual devices can be clicked through to display the name of the profile applied to the device to enforce encryption and the status of the profile deployment.
The “Certificates” report lists the status of all certificates that have been deployed to devices from Intune.
Under “Compliance”
The “Noncompliant Devices” report lists information for all devices that are in a “Not Compliant” state. Clicking through on a device pulls up the device’s full information in Intune for further analysis.
The “Devices without Compliance Policy” report lists devices of any operating system for which no compliance policy has been assigned.
The “Setting Compliance” report lists, for each setting enforced by any compliance policies, the counts of compliant and noncompliant devices. Each setting can be clicked through to list the specific devices that are not compliant for the setting.
The “Policy Compliance” report lists, for each compliance policy, the counts of devices that are compliant, noncompliant, or have errors with the policy’s contents. Clicking through a policy lists the specific devices that are not compliant or have errors.
The “Noncompliant Policies” report lists, for each compliance policy that has noncompliant devices, the counts of devices that are noncompliant or have errors with the policy’s contents. Clicking through a policy lists the specific devices that are not compliant or have errors.
The “Windows Health Attestation Report” report provides a collection of key Windows health metrics for each managed device.
Under “Enrollment”
The “Autopilot Deployments” report lists all Windows Autopilot-driven device enrollments within the past 30 days.
The “Enrollment Failures” report prompts for the selection of one or more users, then lists enrollment failures logged for the selected users.
The “Incomplete User Enrollments” report provides further details for enrollments that were initiated but failed to be completed, listing at which phase of the enrollment process the enrollment was ceased, among other related data.
Under “Software Updates”
The “Per-Update Ring Deployment State” displays, for each configured update deployment ring, the count of devices with errors, which devices failed to be updated, and which were updated successfully. Clicking through an update ring loads the relevant configuration page for the update ring along with an Overview report listing further status information for the update deployment.
The “Installation Failures for iOS Devices” report lists iOS devices for which update installation failed and provides additional details on the failures.
The “Feature Update Failures” report lists, for each configured Windows feature update deployment, the devices with errors from the update process. Clicking through a feature update deployment provides a list of the specific devices which generated errors.
The “Windows Expedited Update Failures” report lists, for each configured expedited Windows update deployment, the count of devices which failed to install the update. Clicking through an update displays a list of the specific devices which failed.
Under “Other”
The “Device Actions” report lists a log of the device actions triggered within Intune for managed devices, along with the user initiating the action and the action’s result.
In the Apps node, there is a dedicated Monitor link that loads a collection of reports, described as follows:
The “App Licenses” report is used to track consumed and available licenses for applications for which license tracking is managed in Intune.
The “Discovered Apps” report provides a holistic list of all applications discovered on all managed devices. Clicking through an application lists the specific devices upon which that application has been found to be installed.
The “App Install Status” report lists, for each application, the install failure percentage, along with the counts of install failures for deployments targeting devices and users.
The “App Protection Status” report lists the count of all users that have been assigned application protection policies, broken down by whether they are licensed or not. Additionally, it lists the counts of flagged users and users with potentially harmful apps. Furthermore, it provides links to download more detailed app protection reports for iOS & Android, for Windows Information Protection without Enrollment, for Windows Information Protection via MDM, and for Application Configuration.
In the Endpoint Security node, a single Monitor report can be found at this time:
The “Assignment Failures” report lists the count of devices with errors for each configuration profile with assignment errors. Clicking through a profile lists more information on the specific devices that have failed. This is the same report that is listed in the Devices -> Monitor section and described above.
Many of the reports listed are currently in “Preview” mode and may see changes and expansions of capability before they are fully released.
Dashboards
Intune’s Dashboard reports are accessed via the Dashboard node in the navigation menu. This view is a pre-configured version of the standard Azure Dashboard functionality with a number of tiles listing key information about the Intune environment.
This dashboard can be rearranged and can have tiles removed, though very few tiles exist to be added which aren’t already present on the pre-configured dashboard.
Custom dashboards can also be created, though they are limited to the existing tiles, again, most of which are already present on the pre-configured dashboard. Still, this can be used to create more targeted views for specific subsets of Intune administrators.
Additionally, the reporting tiles link to relevant Monitor and Overview reports throughout the Intune interface, providing easy access to configuration options.
The data listed by default on the pre-configured dashboard includes:
Device enrollment status and count of enrollment failures in the past 7 days
Device compliance status and count of noncompliant devices
Device configuration status and count of policies with errors or conflicts
Client apps status and count of apps with installation failures
App protection policy user status per operating system
Count of Intune-enrolled devices per operating system
Count of devices per device compliance status
Device configuration profile status and count of users and devices by status, along with a weekly trend
The level of granular data that Intune provides with which to make improvements, decisions, and policies is by-far some of the best in the industry. Gartner agrees. We’re committed to supporting IT pros to fully utilize these tools for which they’ve already paid and gained access.
Organizational and Historical Reports
This section will discuss Intune’s Organizational and Historical reports. These reports are primarily targeted at managers and IT admins and are intended to provide a broader summary of a subject, such as device management state, along with identifying patterns and trends over a period of time. This post will define each of these reports present in Intune at the time of this post’s creation, along with info on what data the reports provide.
The 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.
Intune’s Organizational and Historical reports are found in Intune’s Reports node and are intended to provide broader summaries of overall views along with displaying patterns and trends over time.
Inside the Reports node, the available reports are organized by category and subcategory. Within each subcategory, a Summary view is displayed with high-level information about the relevant subcategory, similar to the Overview Operational reports. A second tab, titled Reports, is used to access each of the specific reports contained in the subcategory. Unlike the Operational reports, when loaded, these reports do not immediately display information, rather they prompt for report parameters to be defined. Upon entering or selecting the desired parameters and clicking the “Run Report” button, the report will be generated and will display information.
The three main categories that reports fall into are:
Device Management
Endpoint Security
Analytics
Each category and the reports contained within will be discussed in the following sections.
Device Management
The Device Management category contains reports focused on the management and configuration of endpoint devices. It contains five separate subcategories for reports:
Device Compliance
Device Configuration
Group Policy Analytics
Windows Updates
Cloud Attached Devices
Each contains a summary report along with one or more specific reports, as described in the following sections.
Device Compliance
The Device Compliance subcategory’s Summary report provides a high-level summary of the compliance state of managed devices, listing the count of devices by each possible compliance state. As a high-level summary, this is useful but doesn’t provide any new information not listed in the Operational reports. Additionally, this report must be refreshed manually with a “Refresh” button displayed at the top of the report.
Under the Reports tab, two reports can be found:
Device Compliance
Device Compliance Trends
The Device Compliance report shows the counts of devices that are compliant and noncompliant for the selected parameters. When configuring the report, you have the option of selecting specific compliance states, operating systems, and device ownership states to filter the results. Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which may take some time depending upon the quantity of data in the Intune environment.
Once the report generation is complete, the report will show a graphical breakdown of the in-scope devices’ compliance states along with a list of the devices. Numerous columns are available to be selected and displayed in the report, plus each column can be used to sort the data, and the report’s contents can be filtered via text to display a subset of the data. The filtered and sorted data can be exported to CSV format for further data analysis or other usage.
The Device Compliance Trends report shows a graphical trend report of device compliance states over the last 60 days. This report will automatically display the last 60 days of data for all compliance states and operating systems, but you can select your desired compliance states and operating systems to filter the report down to a targeted subset of the data. You can run your mouse over the report to view the specific values for each listed compliance state per date in the report’s range.
Device Configuration
The Device Configuration subcategory’s Summary report lists the status of the five device configuration profiles with the largest number of assignment targets. For each listed profile, it lists the profile’s type, then the count of devices by deployment status, organized by success, error, and conflicts. Additionally, this report must be refreshed manually with a “Refresh” button displayed at the top of the report. This provides a quick look at the status of your most important (by breadth) device configuration profiles, but does not provide the capability to click into the report and drill down to further details.
Under the Reports tab, a single report can be found: Profile Configuration Status.
The Profile Configuration Status report allows you to filter through all device configuration profiles to see their current status on assigned devices matching the selected parameters. When configuring the report, you have the option of selecting specific device operating systems and specific device configuration profile types.
Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which may take some time depending upon the quantity of data in the Intune environment.
When the report generation is complete, the report will list:
Each profile by name and its type
The target operating system
A count of devices in each profile deployment state (success, error, and conflicts)
The list of profiles can be filtered by name to find specific profiles based on matching text.
Unfortunately, this report also does not enable you to drill down into further details about which devices are in an erroneous state, nor link back to the reference profile. While this is useful for getting a high-level view of which profiles are most and least successful, it does not provide any use for identifying the causes of issues nor troubleshooting them.
At time of writing, this report is still in a Preview state, so with luck this report will gain more useful functionality before it is released into general availability.
Group Policy Analytics
The Group Policy Analytics subcategory provides summary reporting data for the Group Policy Analytics operational feature in Intune and is useful for planning a migration from Group Policy to Intune Policy for device management. If the Group Policy Analytics operational feature has not been used, then the Group Policy Analytics reporting will contain no data.
In order to use these reports, you must first export group policy objects from an Active Directory environment and import them into Intune for analysis. Policy objects can be imported in the Devices node under Devices -> Group Policy Analytics. Intune will analyze imported policy objects and provide information on mapping the legacy group policy objects to Intune device configuration profiles and other Intune policies. For more details on importing data, refer to the Microsoft documentation here.
Once group policy objects have been imported and analyzed, the Group Policy Analytics subcategory comes alive. Its Summary report provides an overview of group policy migration readiness, taking into account data from all imported policy objects and displaying how many configured policy settings are ready for migration, not supported in Intune, or deprecated. As with the other subcategories, this Summary report does need to be refreshed manually to take into account any policy objects that were imported since the last refresh.
Under the Reports tab, a single report can be found: Group Policy Migration Readiness.
The Group Policy Migration Readiness report displays further details about the readiness of your Group Policy implementation for migration to modern management with Intune and Intune policy, again assuming that you have imported all of your group policy objects into Intune.
When configuring the report, you can select specific migration readiness states, profile types, and Windows CSP names to filter the report results. Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which, as with the others, may take some time depending upon the quantity of data being processed.
When the report generation is complete, the report will identify:
Each setting defined in the imported group policy objects
Each setting’s group policy category
Each setting’s migration readiness
The minimum Windows OS version required to support the setting via modern management
The necessary setting scope (user or device)
The type of profile to be used to configure the setting
The results can be filtered via a text field and can be exported for usage in other systems or analysis. This can help dramatically accelerate a migration from legacy Group Policy to modern management with Intune Policy, as well as identify other necessary steps to take with your endpoints to prepare for the migration.
The minimum Windows OS version required to support the setting is based on when the relevant CSP (configuration service provider) was added to Windows or enabled to administrate the setting in question. If Intune policies are configured to manage a setting but the target device’s Windows operating system is a version older than what is supported, then the policy will not work, as the Windows operating system will be lacking the capability to apply the policy. This is an important consideration when migrating from Group Policy to modern management and another important reason to keep your Windows client devices updated and using a supported version of Windows!
Windows Updates
Speaking of keeping Windows up to date, let’s next look at the Windows Updates subcategory of organizational and historical reports. The Windows Updates subcategory’s Summary report has two separate quick reports, each of which must be refreshed separately, one for Windows Feature updates and one for Windows Expedited Quality updates.
The Windows Feature summary report lists each Windows feature update profile configured in Intune, along with the target Windows version for the profile and the count of devices within the assignment scope and their deployment state (success, error, in progress, rollback initiated, or cancelled).
The Windows Expedited Quality Updates Summary report lists the same thing, except for Windows Quality Update profiles, which enable deployment of specific updates outside of the Update Ring settings.
Under the Reports tab, two reports can be found:
Windows Feature Update Report
Windows Expedited Update Report
The Windows Feature Update Report is used to view more specific details of the deployment state for a given feature upgrade. Upon selecting a feature update profile and specifying values for the update aggregation status and device ownership state, then generating the report, a list of devices will be displayed along with numerous columns of information with device information and update state. A graphical summary of the devices’ update state will also be listed. This provides the ability to quickly understand the deployment status for a given feature upgrade among managed devices.
The biggest limitation of this report is that it only displays devices targeted by the selected feature update profile, and only one feature update profile can be displayed at a time. If you are deploying feature updates purely via Update Rings and not leveraging feature update profiles, then the data will not be representative of your full environment.
The Windows Expedited Update Report is a near match to the Windows Feature Update Report but, again, is based on Windows Quality Update Profiles rather than feature update profiles. If quality update profiles have been used to deploy out-of-band updates in your environment, this report can be used to understand the success of those deployments across the Windows endpoint fleet. Otherwise, this report will provide limited, if any, value.
At the time of writing, both of these reports are in a Preview state, so we can look forward to functionality improvements prior to a general availability release in the future.
Cloud Attached Devices
The Cloud Attached Devices subcategory contains reports useful for understanding the relationship between Configuration Manager- and Intune-based endpoint management in your full Microsoft Endpoint Manager implementation.
The subcategory’s Summary report provides a breakdown of co-management eligibility for devices that are cloud attached / tenant attached, listing the counts of devices that are already co-managed, versus eligible for co-management, awaiting Azure AD join, needing an OS update, or are ineligible for co-management. Furthermore, it lists a breakdown of the various co-management workloads and lists the count of devices for which the workload is managed by Intune versus managed by Configuration Manager.
Under the Reports tab, two reports can be found:
Co-Management Eligibility
Co-Managed Workloads
The Co-Management Eligibility report provides further details on cloud attached devices and their ability to be, or status as being, co-managed between Intune and Configuration Manager. When configuring the report, you have the option of selecting specific eligibility states to filter the results. Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which may take some time depending upon the quantity of data in the Intune environment.
When the report generation is complete, a list of cloud attached devices matching the specified parameters will be displayed, along with information on their eligibility status and operating system information. This data can be exported to CSV format for further data analysis or other usage. This can be useful to identify specific devices to target for modifications to bring them into a co-managed state. In a fully-cloud environment, where there are no devices that are Hybrid Joined, then this report will not display any information.
The Co-Managed Workloads report is used to display the specific devices for which a given workload is managed by Intune or Configuration Manager. Each workload is listed and can be configured to filter the report results down to the devices for which the workload is managed by Intune, Configuration Manager, or Both. Based on the selected parameters for each workload, once the “Generate” button is pressed, Intune will prepare the result and display a list of devices, along with which management tool owns which workload for the device.
This report is primarily used to understand which tool owns which workload for a given device, which can be useful in troubleshooting the co-management configuration in Configuration Manager. Beyond that, and if your environment is cloud-only and does not have Configuration Manager in use, then this report will be of little value.
Endpoint Security
The Endpoint Security category contains reports focused on the security posture of your endpoint devices. There are two separate subcategories for reports:
Microsoft Defender Antivirus
Firewall
Each contains a summary report along with one or more specific reports, as described in the following sections.
Microsoft Defender Antivirus
The Microsoft Defender Antivirus subcategory contains reports for quickly assessing and investigating further details of your endpoints’ protection state against malicious software. Its Summary report, once refreshed, shows the counts of endpoint devices based on their antivirus state – clean, pending scan, and critical condition (malware detected) – giving you rapid awareness of your endpoint fleet’s health state.
Under the Reports tab, two reports can be found:
Antivirus Agent Status
Detected Malware
The Antivirus Agent Status report provides a list of devices matching the selected report parameters, along with specific and relevant details about those devices, including the anti-malware version, antivirus engine version, device primary user, and more. This provides a single interface to give you the information you need to start remediating infections and identifying systemic issues with endpoints that may lead to infections. For report parameters, specific device antivirus states can be selected, enabling you to filter the report down to just those devices that need remediation. As with the other reports, the report data can be exported to CSV for use in further data analysis or other processes as needed.
The important thing to note is that this report is focused on the device state and configuration, listing all the configuration relevant to antimalware exposure. For details about specific malware detected in the environment, you’ll want to turn to the Detected Malware report.
The Detected Malware report generates a list of devices with malware detected upon them, listing details about the detected malware itself, such as its name, severity, category, frequency of detection, and more. The report parameters enable the report contents to filter by malware severity and its execution state – whether it is active, blocked, etc. The information in this report empowers you to further understand your current protection state and what threats have been detecting, beginning your journey towards remediation and hardening of security posture.
Firewall
The Firewall subcategory is unique in that there is no Summary report, only a single report instead, titled MDM Firewall Status for Windows 10 and Later. This report is intended to display the firewall status for all managed Windows devices. Like the other reports, it must be generated after selecting parameters before it displays any data, but the resulting data can be exported to CSV for further data analysis or usage. The only parameter available allows filtering of the firewall status values to get a subset of devices with a firewall state that interests you.
Once generated, the report lists each device that matches the specified firewall states, along with the devices’ firewall status, the management tool, and the device’s primary user. A small number of additional columns are also available. At the top of the report, it displays the counts of devices with each firewall state, giving you quick validation that all devices have their firewalls enabled or insight into the number of potentially exposed devices. This report’s job is to list the firewall status for each device, and it does that, but it does not provide any drill-thru capabilities for further information.
Analytics
The Analytics category contains a single subcategory, Endpoint Analytics.
Unlike the other categories’ subcategories, Endpoint Analytics is not an interface to a set of discrete Intune-specific reports but rather a front end exposing information from the larger Endpoint Analytics tool.
As defined by Microsoft, Endpoint Analytics is part of the Microsoft Productivity Score and it provides a collection of analytics intended to give you insights for measuring how your organization is working and the quality of your users’ experience on their devices. The goal for Endpoint Analytics is to help identify problematic policies or configuration combinations that could be detrimentally impacting your users, so that you can address the problems proactively without being buried in tickets.
A full exploration of Endpoint Analytics is outside the scope of this blog post, but the important takeaway for this post is that Endpoint Analytics leverages data collected from your endpoints to monitor on things like system startup performance, application reliability, and the ability for your users to work from anywhere securely by using the capabilities provided by Intune and Microsoft 365. It uses this data to not only provide a metric for user experience but also to provide environment-specific insights and recommendations to further improve your end users’ experience and optimize your endpoint management state.
Endpoint Analytics also provides the ability to create PowerShell script-based proactive remediation which Intune will deploy and run automatically on your endpoints when known issues are encountered, helping you leverage your knowledge of your infrastructure to automate issue resolution and free up your time for tasks that push your business forward rather than your valuable time being spent putting out fires all day long.
For Endpoint Analytics to function, a data collection policy does need to be configured and deployed from Intune to your endpoints. An interface on Endpoint Analytics’ Settings menu helps walk you through this. After the policy is deployed, data will start to flow into Endpoint Analytics and data will become available. This is a very useful tool for addressing common, and frequently “invisible”, issues with your endpoints and should be enabled in every Intune deployment.
Intune has quite a few Organizational and Historical reports, each designed with very specific-but-narrow use cases. For their use cases, they provide the necessary information in an efficient and clear manner. If additional information is needed, however, they don’t really provide any means of getting it. For that, we need to dive into Advanced Intune Reporting techniques.
Advanced Reporting with Intune Data Warehouse and Log Analytics
This section will begin to discuss the options available for advanced Intune reporting beyond that which is provided from the out-of-the-box reports. It will also identify the capabilities provided by Intune for accessing its underlying data and tools with which you can use that data to build your own reports, specific to your needs.
Under its hood, Intune collects a wealth of endpoint data, much of it not exposed through the out-of-the-box reports. Intune does however provide mechanisms for administrators to access that data and use it for many purposes, including automation of Intune management and custom reporting. Advanced Intune reporting involves querying that data directly from Intune and transforming the data to your particular needs, presenting it in whatever form you want. Here, you will be getting outside of Intune proper and into tools that you can use to query and work with Intune’s data.
The three primary mechanisms Intune provides for advanced reporting are through integration with:
Azure Monitor / Log Analytics
Intune’s Data Warehouse
Microsoft Graph API
Each of the following sections will provide specific details on each mechanism, how to set it up, and how to use it to build custom reports.
Azure Monitor / Log Analytics Integration
Overview
Azure Monitor and its underlying Log Analytics service provide a common monitoring & reporting framework used across all of Azure. Azure resources can be configured to route data to Azure Monitor via “diagnostic settings”, granting administrators some control over which types of data are sent to Azure Monitor. Similarly, Intune can be configured to send platform logs and metrics to Azure Monitor through the creation of diagnostic settings.
Once in Azure Monitor, this data can be queried and processed using Log Analytics’ query language, “Kusto”, or “KQL”. This data can also be presented through KQL visualization output and through Azure Monitor Workbooks. Workbooks provide a means of packaging and presenting pre-written queries in an ordered fashion to provide a dynamic report-type experience. Intune has several Azure Monitor workbooks pre-configured to show data if the appropriate diagnostic settings are configured.
Configuration
Before Intune can be configured to send data to Azure Monitor, an Azure Monitor / Log Analytics workspace must be created and available to receivea the data from Intune. You can follow the instructions in Microsoft’s documentation here to create a workspace via the Azure Portal. If you are creating a workspace specifically for your Intune logs, you may wish to review the cost considerations for the Log Analytics workspace and Intune logging configuration. Once a workspace has been created, the diagnostic setting to send data from Intune to Azure Monitor can be configured in the Intune portal.
In Intune’s Reports node, below the Operational & Historical reporting categories, can be found another category titled “Azure Monitor”. The first option beneath the category, “Diagnostic Settings”, is where Intune can be configured to send data to Azure Monitor.
Either click the “Add diagnostic setting” text to create a new diagnostic setting or click “Edit setting” to modify an existing setting, should one exist (as seen in the screenshot above). Within any diagnostic setting, there are four different types of Intune logs that can be configured to be sent to Azure Monitor, defined as follows:
“AuditLogs” – Contains records of Intune change events and can be used to determine who configured what in Intune, when. Types of change events include the creation, update / edit, deletion, and assignment of policies, along with the invocation of remote actions on managed devices.
“OperationalLogs” – Contains details on users and devices that successfully or unsuccessfully attempted to enroll in Intune, as well as details for non-compliant devices.
“DeviceComplianceOrg” – Provides operational reporting data for device compliance within Intune, along with details on non-compliant devices.
“Devices” – Provides records on each managed device reporting to Intune, including the primary owner / user information where applicable
To create the diagnostic setting, simply select the types of logs to be sent to Azure Monitor and select the “Send to Log Analytics workspace” option under “Destination details”. The workspace and its subscription will need to be selected, after which the diagnostic setting can be saved and data will begin flowing to Azure Monitor.
Diagnostic settings can also be used to send data to an Azure storage account, to an Azure Event Hub, or to a third-party log analytics solution, if desired.
Usage
The easiest way to use the log data sent to Azure Monitor / Log Analytics is via the “Workbooks” and “Log Analytics” views under Intune’s Reports node, in the “Azure Monitor” section. These expose relevant components of Azure Monitor and Log Analytics through the Intune portal itself, making it easier for Intune admins to focus on Intune data rather than be bogged down by other monitoring data.
The recommended first place to go is the “Workbooks” view. This view exposes the four workbooks that ship with Intune and leverage the log analytics data :
Intune Audit Activity
Intune Enrollment Activity
Intune Compliance Activity
Intune Device Activity
Any of the workbooks can be clicked on to open them up, which will automatically refresh the underlying queries and show graphs and relevant data from the logs. Do note that, if there is no data returned by a query (such as because the diagnostic setting was just configured, or because there haven’t been any enrollments in the past 7 days, etc.), then the workbook will show no data for a query.
The “Workbooks” view also provides the capability to build your own workbooks, though doing so requires adding custom Kusto / KQL queries to retrieve and process the Intune log data in whatever way is relevant for your needs. This is where things get very advanced, as knowledge of Kusto is required to write the queries. We won’t go into detail on how to write queries in this post, but you can refer to sources such as Microsoft’s KQL Tutorial for an introduction on using the language. You also may be able to find examples of Intune KQL queries on the Internet – do note that queries are non-destructive and do not affect the underlying data, so using random queries found on the Internet is generally safe. At the very least, though, you can use them as a reference to learn KQL and write your own queries.
In order to write and test queries, either for a workbook or for on-the-fly usage, navigate to the “Log Analytics” view in Intune’s Reports node. Here, you’ll get the full Log Analytics query interface, providing access to any data stored within a workspace. Intune’s logs will be found under the “Log Management” category and can be recognized easily as they all start with “Intune”. Queries can be written in the editor, ran to review the results, and saved for later usage.
Overall, the Azure Monitor / Log Analytics integration provides some powerful capabilities through the Kusto query language to analyze Intune log data, however the type of data in the logs is limited to specific use cases and won’t always be a useful solution depending upon what reporting data you are trying to represent. It is very useful for what it does, but for more advanced operational reporting, we recommend leveraging the Graph and Data Warehouse APIs, detailed below.
Intune Data Warehouse
Overview
Intune has a Data Warehouse service designed to provide historical data for custom reporting. This data is refreshed on a daily basis from the main Intune data and is intended for historical and trending reporting, not for real-time reporting. The Data Warehouse is exposed via an OData endpoint; Microsoft provides specific instructions on connecting to the Data Warehouse via Power BI, but any system capable of querying data through the OData standard can connect and retrieve data.
Once connected, reporting tools like Power BI or Microsoft Excel can visualize the data model and provide all the tools needed to build reports and present the data in whatever way is important to your business needs.
Configuration
Before discussing how to connect to the Data Warehouse, we first need to establish the prerequisites for accessing the data. In order to access the Intune Data Warehouse, one of the following conditions must be met:
User accessing the report must be one of the following:
Azure AD Global Administrator
Intune Service Administrator
Granted access to Intune Data Warehouse through Intune’s role-based access control
User-less authentication must be configured via an Azure AD App Registration
For instructions on configuring user-less authentication, refer to Microsoft’s documentation here.
Once the requisite access permissions are in place, we can configure the connection to the Data Warehouse. To do so, first go to the Reports node in the Intune portal. Another subcategory, alongside the Operational & Historical reporting subcategories and the Azure Monitor subcategory, is named “Intune data warehouse”. It contains a single view, titled “Data warehouse”, which contains the information needed to connect to the Data Warehouse, along with links to the documentation on using the data warehouse.
The “Data warehouse” view provides two ways of connecting to the Data Warehouse:
A link to a pre-made Power BI app for the Intune Data Warehouse, under a link titled “Get Power BI app” in the “Microsoft Power BI Online” section
The OData feed URL used by reporting tools to connect to the data.
The Power BI app is a pre-configured Power BI Online report that has some very basic reports in it, along with a pre-defined connection to the Data Warehouse, that can serve as an example for report creation or as a starting point for further customizations and development. The downside of this app is that it only functions in Power BI Online, meaning you lack the full capabilities provided by Power BI Desktop for report creation and management. It is a good place to start, though, if you’ve never worked with Power BI.
The OData feed URL can be used in any reporting tool that supports it, including Power BI and Microsoft Excel. This post will be working with Power BI and illustrating how to connect to the Data Warehouse from there.
To connect to the Data Warehouse from Power BI, first install or open up Power BI Desktop on your computer and pull up a new report. Once that is done, do the following:
In the Intune portal, in the “Data warehouse” view, copy the OData feed URL.
Open Power BI Desktop, then click File > Get Data, then select OData feed.
In the prompt that appears, ensure Basic is selected, then paste the OData feed URL copied from Intune into the URL field and select OK.
In the next window, select Organizational Account and click the Sign in button, then provide your Azure AD credentials with access to the Data Warehouse.
These instructions assume we are using user-based authentication, not user-less.
Click Connect and Power BI will connect to the Data Warehouse using the provided credentials.
In the “Navigator” window that appears, select one or more of the tables to import into Power BI, then click Load to load the data.
Be warned – Power BI will load all of the selected tables into the report and into memory – this can use a significant quantity of resources depending upon your environment. For initial testing and report-building, you may want to add more than the data you explicitly need in order to understand what data is available. However, for production reports, it is recommended that you only load the tables that are needed for your reports to keep the report size down and performance optimized.
Barring any errors, the Intune Data Warehouse will now be loaded into Power BI and ready for you to use to create reports!
Usage
Once imported into Power BI (or whichever reporting tool you are using), standard reporting techniques for your reporting tool can be used to explore and present the data. Given that the data is imported from a collection of tables, the first thing you may need to do is to create the relationships between the tables so that your reporting can take advantage of the richness and depth of the data and deliver the insights you need. Power BI will attempt to do this automatically when it imports data from the Data Warehouse, but you may want to review the data model and relationships and validate they are correct, adding any that are missing.
In the following screenshot, you can see part of the data model automatically generated by Power BI Desktop on import from the Intune Data Warehouse:
The right-hand pane, labeled “Fields”, lists each of the tables imported from the Data Warehouse. Expanding any given table will list the individual properties on those tables, containing the actual data to be used in your reports. Data types for those properties should be correct based on the source data type in the Intune Data Warehouse, but you can use your reporting tool to adjust data types if needed, along with adding filters and creating custom properties that build on the Intune Data Warehouse data as needed for your specific reporting needs.
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 Intune Data Warehouse data to build the custom reports you need.
The Intune Data Warehouse provides a powerful vehicle for connecting to Intune’s data and building most any custom reports you need. As stated above, its intent is to provide data for historical and trending analysis rather than real-time reporting, and at that it excels. If you do need access to Intune’s real-time data, though, then the remaining option for advanced Intune reporting, via the Microsoft Graph API, is where you need to go.
Advanced Reporting with Microsoft Graph API and Power BI
In this final section, 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.
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,
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 – 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.
Conclusion
In this book, 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 book 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!
Dashboards
Intune’s Dashboard reports are accessed via the Dashboard node in the navigation menu. This view is a pre-configured version of the standard Azure Dashboard functionality with a number of tiles listing key information about the Intune environment.
This dashboard can be rearranged and can have tiles removed, though very few tiles exist to be added which aren’t already present on the pre-configured dashboard.
Custom dashboards can also be created, though they are limited to the existing tiles, again, most of which are already present on the pre-configured dashboard. Still, this can be used to create more targeted views for specific subsets of Intune administrators.
Additionally, the reporting tiles link to relevant Monitor and Overview reports throughout the Intune interface, providing easy access to configuration options.
The data listed by default on the pre-configured dashboard includes:
Device enrollment status and count of enrollment failures in the past 7 days
Device compliance status and count of noncompliant devices
Device configuration status and count of policies with errors or conflicts
Client apps status and count of apps with installation failures
App protection policy user status per operating system
Count of Intune-enrolled devices per operating system
Count of devices per device compliance status
Device configuration profile status and count of users and devices by status, along with a weekly trend
The level of granular data that Intune provides with which to make improvements, decisions, and policies is by-far some of the best in the industry. Gartner agrees. We’re committed to supporting IT pros to fully utilize these tools for which they’ve already paid and gained access.
Organizational and Historical Reports
This section will discuss Intune’s Organizational and Historical reports. These reports are primarily targeted at managers and IT admins and are intended to provide a broader summary of a subject, such as device management state, along with identifying patterns and trends over a period of time. This post will define each of these reports present in Intune at the time of this post’s creation, along with info on what data the reports provide.
The 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.
Intune’s Organizational and Historical reports are found in Intune’s Reports node and are intended to provide broader summaries of overall views along with displaying patterns and trends over time.
Inside the Reports node, the available reports are organized by category and subcategory. Within each subcategory, a Summary view is displayed with high-level information about the relevant subcategory, similar to the Overview Operational reports. A second tab, titled Reports, is used to access each of the specific reports contained in the subcategory. Unlike the Operational reports, when loaded, these reports do not immediately display information, rather they prompt for report parameters to be defined. Upon entering or selecting the desired parameters and clicking the “Run Report” button, the report will be generated and will display information.
The three main categories that reports fall into are:
Device Management
Endpoint Security
Analytics
Each category and the reports contained within will be discussed in the following sections.
Device Management
The Device Management category contains reports focused on the management and configuration of endpoint devices. It contains five separate subcategories for reports:
Device Compliance
Device Configuration
Group Policy Analytics
Windows Updates
Cloud Attached Devices
Each contains a summary report along with one or more specific reports, as described in the following sections.
Device Compliance
The Device Compliance subcategory’s Summary report provides a high-level summary of the compliance state of managed devices, listing the count of devices by each possible compliance state. As a high-level summary, this is useful but doesn’t provide any new information not listed in the Operational reports. Additionally, this report must be refreshed manually with a “Refresh” button displayed at the top of the report.
Under the Reports tab, two reports can be found:
Device Compliance
Device Compliance Trends
The Device Compliance report shows the counts of devices that are compliant and noncompliant for the selected parameters. When configuring the report, you have the option of selecting specific compliance states, operating systems, and device ownership states to filter the results. Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which may take some time depending upon the quantity of data in the Intune environment.
Once the report generation is complete, the report will show a graphical breakdown of the in-scope devices’ compliance states along with a list of the devices. Numerous columns are available to be selected and displayed in the report, plus each column can be used to sort the data, and the report’s contents can be filtered via text to display a subset of the data. The filtered and sorted data can be exported to CSV format for further data analysis or other usage.
The Device Compliance Trends report shows a graphical trend report of device compliance states over the last 60 days. This report will automatically display the last 60 days of data for all compliance states and operating systems, but you can select your desired compliance states and operating systems to filter the report down to a targeted subset of the data. You can run your mouse over the report to view the specific values for each listed compliance state per date in the report’s range.
Device Configuration
The Device Configuration subcategory’s Summary report lists the status of the five device configuration profiles with the largest number of assignment targets. For each listed profile, it lists the profile’s type, then the count of devices by deployment status, organized by success, error, and conflicts. Additionally, this report must be refreshed manually with a “Refresh” button displayed at the top of the report. This provides a quick look at the status of your most important (by breadth) device configuration profiles, but does not provide the capability to click into the report and drill down to further details.
Under the Reports tab, a single report can be found: Profile Configuration Status.
The Profile Configuration Status report allows you to filter through all device configuration profiles to see their current status on assigned devices matching the selected parameters. When configuring the report, you have the option of selecting specific device operating systems and specific device configuration profile types.
Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which may take some time depending upon the quantity of data in the Intune environment.
When the report generation is complete, the report will list:
Each profile by name and its type
The target operating system
A count of devices in each profile deployment state (success, error, and conflicts)
The list of profiles can be filtered by name to find specific profiles based on matching text.
Unfortunately, this report also does not enable you to drill down into further details about which devices are in an erroneous state, nor link back to the reference profile. While this is useful for getting a high-level view of which profiles are most and least successful, it does not provide any use for identifying the causes of issues nor troubleshooting them.
At time of writing, this report is still in a Preview state, so with luck this report will gain more useful functionality before it is released into general availability.
Group Policy Analytics
The Group Policy Analytics subcategory provides summary reporting data for the Group Policy Analytics operational feature in Intune and is useful for planning a migration from Group Policy to Intune Policy for device management. If the Group Policy Analytics operational feature has not been used, then the Group Policy Analytics reporting will contain no data.
In order to use these reports, you must first export group policy objects from an Active Directory environment and import them into Intune for analysis. Policy objects can be imported in the Devices node under Devices -> Group Policy Analytics. Intune will analyze imported policy objects and provide information on mapping the legacy group policy objects to Intune device configuration profiles and other Intune policies. For more details on importing data, refer to the Microsoft documentation here.
Once group policy objects have been imported and analyzed, the Group Policy Analytics subcategory comes alive. Its Summary report provides an overview of group policy migration readiness, taking into account data from all imported policy objects and displaying how many configured policy settings are ready for migration, not supported in Intune, or deprecated. As with the other subcategories, this Summary report does need to be refreshed manually to take into account any policy objects that were imported since the last refresh.
Under the Reports tab, a single report can be found: Group Policy Migration Readiness.
The Group Policy Migration Readiness report displays further details about the readiness of your Group Policy implementation for migration to modern management with Intune and Intune policy, again assuming that you have imported all of your group policy objects into Intune.
When configuring the report, you can select specific migration readiness states, profile types, and Windows CSP names to filter the report results. Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which, as with the others, may take some time depending upon the quantity of data being processed.
When the report generation is complete, the report will identify:
Each setting defined in the imported group policy objects
Each setting’s group policy category
Each setting’s migration readiness
The minimum Windows OS version required to support the setting via modern management
The necessary setting scope (user or device)
The type of profile to be used to configure the setting
The results can be filtered via a text field and can be exported for usage in other systems or analysis. This can help dramatically accelerate a migration from legacy Group Policy to modern management with Intune Policy, as well as identify other necessary steps to take with your endpoints to prepare for the migration.
The minimum Windows OS version required to support the setting is based on when the relevant CSP (configuration service provider) was added to Windows or enabled to administrate the setting in question. If Intune policies are configured to manage a setting but the target device’s Windows operating system is a version older than what is supported, then the policy will not work, as the Windows operating system will be lacking the capability to apply the policy. This is an important consideration when migrating from Group Policy to modern management and another important reason to keep your Windows client devices updated and using a supported version of Windows!
Windows Updates
Speaking of keeping Windows up to date, let’s next look at the Windows Updates subcategory of organizational and historical reports. The Windows Updates subcategory’s Summary report has two separate quick reports, each of which must be refreshed separately, one for Windows Feature updates and one for Windows Expedited Quality updates.
The Windows Feature summary report lists each Windows feature update profile configured in Intune, along with the target Windows version for the profile and the count of devices within the assignment scope and their deployment state (success, error, in progress, rollback initiated, or cancelled).
The Windows Expedited Quality Updates Summary report lists the same thing, except for Windows Quality Update profiles, which enable deployment of specific updates outside of the Update Ring settings.
Under the Reports tab, two reports can be found:
Windows Feature Update Report
Windows Expedited Update Report
The Windows Feature Update Report is used to view more specific details of the deployment state for a given feature upgrade. Upon selecting a feature update profile and specifying values for the update aggregation status and device ownership state, then generating the report, a list of devices will be displayed along with numerous columns of information with device information and update state. A graphical summary of the devices’ update state will also be listed. This provides the ability to quickly understand the deployment status for a given feature upgrade among managed devices.
The biggest limitation of this report is that it only displays devices targeted by the selected feature update profile, and only one feature update profile can be displayed at a time. If you are deploying feature updates purely via Update Rings and not leveraging feature update profiles, then the data will not be representative of your full environment.
The Windows Expedited Update Report is a near match to the Windows Feature Update Report but, again, is based on Windows Quality Update Profiles rather than feature update profiles. If quality update profiles have been used to deploy out-of-band updates in your environment, this report can be used to understand the success of those deployments across the Windows endpoint fleet. Otherwise, this report will provide limited, if any, value.
At the time of writing, both of these reports are in a Preview state, so we can look forward to functionality improvements prior to a general availability release in the future.
Cloud Attached Devices
The Cloud Attached Devices subcategory contains reports useful for understanding the relationship between Configuration Manager- and Intune-based endpoint management in your full Microsoft Endpoint Manager implementation.
The subcategory’s Summary report provides a breakdown of co-management eligibility for devices that are cloud attached / tenant attached, listing the counts of devices that are already co-managed, versus eligible for co-management, awaiting Azure AD join, needing an OS update, or are ineligible for co-management. Furthermore, it lists a breakdown of the various co-management workloads and lists the count of devices for which the workload is managed by Intune versus managed by Configuration Manager.
Under the Reports tab, two reports can be found:
Co-Management Eligibility
Co-Managed Workloads
The Co-Management Eligibility report provides further details on cloud attached devices and their ability to be, or status as being, co-managed between Intune and Configuration Manager. When configuring the report, you have the option of selecting specific eligibility states to filter the results. Once the desired parameters are selected and the “Generate” button is pressed, Intune will generate the report, which may take some time depending upon the quantity of data in the Intune environment.
When the report generation is complete, a list of cloud attached devices matching the specified parameters will be displayed, along with information on their eligibility status and operating system information. This data can be exported to CSV format for further data analysis or other usage. This can be useful to identify specific devices to target for modifications to bring them into a co-managed state. In a fully-cloud environment, where there are no devices that are Hybrid Joined, then this report will not display any information.
The Co-Managed Workloads report is used to display the specific devices for which a given workload is managed by Intune or Configuration Manager. Each workload is listed and can be configured to filter the report results down to the devices for which the workload is managed by Intune, Configuration Manager, or Both. Based on the selected parameters for each workload, once the “Generate” button is pressed, Intune will prepare the result and display a list of devices, along with which management tool owns which workload for the device.
This report is primarily used to understand which tool owns which workload for a given device, which can be useful in troubleshooting the co-management configuration in Configuration Manager. Beyond that, and if your environment is cloud-only and does not have Configuration Manager in use, then this report will be of little value.
Endpoint Security
The Endpoint Security category contains reports focused on the security posture of your endpoint devices. There are two separate subcategories for reports:
Microsoft Defender Antivirus
Firewall
Each contains a summary report along with one or more specific reports, as described in the following sections.
Microsoft Defender Antivirus
The Microsoft Defender Antivirus subcategory contains reports for quickly assessing and investigating further details of your endpoints’ protection state against malicious software. Its Summary report, once refreshed, shows the counts of endpoint devices based on their antivirus state – clean, pending scan, and critical condition (malware detected) – giving you rapid awareness of your endpoint fleet’s health state.
Under the Reports tab, two reports can be found:
Antivirus Agent Status
Detected Malware
The Antivirus Agent Status report provides a list of devices matching the selected report parameters, along with specific and relevant details about those devices, including the anti-malware version, antivirus engine version, device primary user, and more. This provides a single interface to give you the information you need to start remediating infections and identifying systemic issues with endpoints that may lead to infections. For report parameters, specific device antivirus states can be selected, enabling you to filter the report down to just those devices that need remediation. As with the other reports, the report data can be exported to CSV for use in further data analysis or other processes as needed.
The important thing to note is that this report is focused on the device state and configuration, listing all the configuration relevant to antimalware exposure. For details about specific malware detected in the environment, you’ll want to turn to the Detected Malware report.
The Detected Malware report generates a list of devices with malware detected upon them, listing details about the detected malware itself, such as its name, severity, category, frequency of detection, and more. The report parameters enable the report contents to filter by malware severity and its execution state – whether it is active, blocked, etc. The information in this report empowers you to further understand your current protection state and what threats have been detecting, beginning your journey towards remediation and hardening of security posture.
Firewall
The Firewall subcategory is unique in that there is no Summary report, only a single report instead, titled MDM Firewall Status for Windows 10 and Later. This report is intended to display the firewall status for all managed Windows devices. Like the other reports, it must be generated after selecting parameters before it displays any data, but the resulting data can be exported to CSV for further data analysis or usage. The only parameter available allows filtering of the firewall status values to get a subset of devices with a firewall state that interests you.
Once generated, the report lists each device that matches the specified firewall states, along with the devices’ firewall status, the management tool, and the device’s primary user. A small number of additional columns are also available. At the top of the report, it displays the counts of devices with each firewall state, giving you quick validation that all devices have their firewalls enabled or insight into the number of potentially exposed devices. This report’s job is to list the firewall status for each device, and it does that, but it does not provide any drill-thru capabilities for further information.
Analytics
The Analytics category contains a single subcategory, Endpoint Analytics.
Unlike the other categories’ subcategories, Endpoint Analytics is not an interface to a set of discrete Intune-specific reports but rather a front end exposing information from the larger Endpoint Analytics tool.
As defined by Microsoft, Endpoint Analytics is part of the Microsoft Productivity Score and it provides a collection of analytics intended to give you insights for measuring how your organization is working and the quality of your users’ experience on their devices. The goal for Endpoint Analytics is to help identify problematic policies or configuration combinations that could be detrimentally impacting your users, so that you can address the problems proactively without being buried in tickets.
A full exploration of Endpoint Analytics is outside the scope of this blog post, but the important takeaway for this post is that Endpoint Analytics leverages data collected from your endpoints to monitor on things like system startup performance, application reliability, and the ability for your users to work from anywhere securely by using the capabilities provided by Intune and Microsoft 365. It uses this data to not only provide a metric for user experience but also to provide environment-specific insights and recommendations to further improve your end users’ experience and optimize your endpoint management state.
Endpoint Analytics also provides the ability to create PowerShell script-based proactive remediation which Intune will deploy and run automatically on your endpoints when known issues are encountered, helping you leverage your knowledge of your infrastructure to automate issue resolution and free up your time for tasks that push your business forward rather than your valuable time being spent putting out fires all day long.
For Endpoint Analytics to function, a data collection policy does need to be configured and deployed from Intune to your endpoints. An interface on Endpoint Analytics’ Settings menu helps walk you through this. After the policy is deployed, data will start to flow into Endpoint Analytics and data will become available. This is a very useful tool for addressing common, and frequently “invisible”, issues with your endpoints and should be enabled in every Intune deployment.
Intune has quite a few Organizational and Historical reports, each designed with very specific-but-narrow use cases. For their use cases, they provide the necessary information in an efficient and clear manner. If additional information is needed, however, they don’t really provide any means of getting it. For that, we need to dive into Advanced Intune Reporting techniques.
Advanced Reporting with Intune Data Warehouse and Log Analytics
This section will begin to discuss the options available for advanced Intune reporting beyond that which is provided from the out-of-the-box reports. It will also identify the capabilities provided by Intune for accessing its underlying data and tools with which you can use that data to build your own reports, specific to your needs.
Under its hood, Intune collects a wealth of endpoint data, much of it not exposed through the out-of-the-box reports. Intune does however provide mechanisms for administrators to access that data and use it for many purposes, including automation of Intune management and custom reporting. Advanced Intune reporting involves querying that data directly from Intune and transforming the data to your particular needs, presenting it in whatever form you want. Here, you will be getting outside of Intune proper and into tools that you can use to query and work with Intune’s data.
The three primary mechanisms Intune provides for advanced reporting are through integration with:
Azure Monitor / Log Analytics
Intune’s Data Warehouse
Microsoft Graph API
Each of the following sections will provide specific details on each mechanism, how to set it up, and how to use it to build custom reports.
Azure Monitor / Log Analytics Integration
Overview
Azure Monitor and its underlying Log Analytics service provide a common monitoring & reporting framework used across all of Azure. Azure resources can be configured to route data to Azure Monitor via “diagnostic settings”, granting administrators some control over which types of data are sent to Azure Monitor. Similarly, Intune can be configured to send platform logs and metrics to Azure Monitor through the creation of diagnostic settings.
Once in Azure Monitor, this data can be queried and processed using Log Analytics’ query language, “Kusto”, or “KQL”. This data can also be presented through KQL visualization output and through Azure Monitor Workbooks. Workbooks provide a means of packaging and presenting pre-written queries in an ordered fashion to provide a dynamic report-type experience. Intune has several Azure Monitor workbooks pre-configured to show data if the appropriate diagnostic settings are configured.
Configuration
Before Intune can be configured to send data to Azure Monitor, an Azure Monitor / Log Analytics workspace must be created and available to receivea the data from Intune. You can follow the instructions in Microsoft’s documentation here to create a workspace via the Azure Portal. If you are creating a workspace specifically for your Intune logs, you may wish to review the cost considerations for the Log Analytics workspace and Intune logging configuration. Once a workspace has been created, the diagnostic setting to send data from Intune to Azure Monitor can be configured in the Intune portal.
In Intune’s Reports node, below the Operational & Historical reporting categories, can be found another category titled “Azure Monitor”. The first option beneath the category, “Diagnostic Settings”, is where Intune can be configured to send data to Azure Monitor.
Either click the “Add diagnostic setting” text to create a new diagnostic setting or click “Edit setting” to modify an existing setting, should one exist (as seen in the screenshot above). Within any diagnostic setting, there are four different types of Intune logs that can be configured to be sent to Azure Monitor, defined as follows:
“AuditLogs” – Contains records of Intune change events and can be used to determine who configured what in Intune, when. Types of change events include the creation, update / edit, deletion, and assignment of policies, along with the invocation of remote actions on managed devices.
“OperationalLogs” – Contains details on users and devices that successfully or unsuccessfully attempted to enroll in Intune, as well as details for non-compliant devices.
“DeviceComplianceOrg” – Provides operational reporting data for device compliance within Intune, along with details on non-compliant devices.
“Devices” – Provides records on each managed device reporting to Intune, including the primary owner / user information where applicable
To create the diagnostic setting, simply select the types of logs to be sent to Azure Monitor and select the “Send to Log Analytics workspace” option under “Destination details”. The workspace and its subscription will need to be selected, after which the diagnostic setting can be saved and data will begin flowing to Azure Monitor.
Diagnostic settings can also be used to send data to an Azure storage account, to an Azure Event Hub, or to a third-party log analytics solution, if desired.
Usage
The easiest way to use the log data sent to Azure Monitor / Log Analytics is via the “Workbooks” and “Log Analytics” views under Intune’s Reports node, in the “Azure Monitor” section. These expose relevant components of Azure Monitor and Log Analytics through the Intune portal itself, making it easier for Intune admins to focus on Intune data rather than be bogged down by other monitoring data.
The recommended first place to go is the “Workbooks” view. This view exposes the four workbooks that ship with Intune and leverage the log analytics data :
Intune Audit Activity
Intune Enrollment Activity
Intune Compliance Activity
Intune Device Activity
Any of the workbooks can be clicked on to open them up, which will automatically refresh the underlying queries and show graphs and relevant data from the logs. Do note that, if there is no data returned by a query (such as because the diagnostic setting was just configured, or because there haven’t been any enrollments in the past 7 days, etc.), then the workbook will show no data for a query.
The “Workbooks” view also provides the capability to build your own workbooks, though doing so requires adding custom Kusto / KQL queries to retrieve and process the Intune log data in whatever way is relevant for your needs. This is where things get very advanced, as knowledge of Kusto is required to write the queries. We won’t go into detail on how to write queries in this post, but you can refer to sources such as Microsoft’s KQL Tutorial for an introduction on using the language. You also may be able to find examples of Intune KQL queries on the Internet – do note that queries are non-destructive and do not affect the underlying data, so using random queries found on the Internet is generally safe. At the very least, though, you can use them as a reference to learn KQL and write your own queries.
In order to write and test queries, either for a workbook or for on-the-fly usage, navigate to the “Log Analytics” view in Intune’s Reports node. Here, you’ll get the full Log Analytics query interface, providing access to any data stored within a workspace. Intune’s logs will be found under the “Log Management” category and can be recognized easily as they all start with “Intune”. Queries can be written in the editor, ran to review the results, and saved for later usage.
Overall, the Azure Monitor / Log Analytics integration provides some powerful capabilities through the Kusto query language to analyze Intune log data, however the type of data in the logs is limited to specific use cases and won’t always be a useful solution depending upon what reporting data you are trying to represent. It is very useful for what it does, but for more advanced operational reporting, we recommend leveraging the Graph and Data Warehouse APIs, detailed below.
Intune Data Warehouse
Overview
Intune has a Data Warehouse service designed to provide historical data for custom reporting. This data is refreshed on a daily basis from the main Intune data and is intended for historical and trending reporting, not for real-time reporting. The Data Warehouse is exposed via an OData endpoint; Microsoft provides specific instructions on connecting to the Data Warehouse via Power BI, but any system capable of querying data through the OData standard can connect and retrieve data.
Once connected, reporting tools like Power BI or Microsoft Excel can visualize the data model and provide all the tools needed to build reports and present the data in whatever way is important to your business needs.
Configuration
Before discussing how to connect to the Data Warehouse, we first need to establish the prerequisites for accessing the data. In order to access the Intune Data Warehouse, one of the following conditions must be met:
User accessing the report must be one of the following:
Azure AD Global Administrator
Intune Service Administrator
Granted access to Intune Data Warehouse through Intune’s role-based access control
User-less authentication must be configured via an Azure AD App Registration
For instructions on configuring user-less authentication, refer to Microsoft’s documentation here.
Once the requisite access permissions are in place, we can configure the connection to the Data Warehouse. To do so, first go to the Reports node in the Intune portal. Another subcategory, alongside the Operational & Historical reporting subcategories and the Azure Monitor subcategory, is named “Intune data warehouse”. It contains a single view, titled “Data warehouse”, which contains the information needed to connect to the Data Warehouse, along with links to the documentation on using the data warehouse.
The “Data warehouse” view provides two ways of connecting to the Data Warehouse:
A link to a pre-made Power BI app for the Intune Data Warehouse, under a link titled “Get Power BI app” in the “Microsoft Power BI Online” section
The OData feed URL used by reporting tools to connect to the data.
The Power BI app is a pre-configured Power BI Online report that has some very basic reports in it, along with a pre-defined connection to the Data Warehouse, that can serve as an example for report creation or as a starting point for further customizations and development. The downside of this app is that it only functions in Power BI Online, meaning you lack the full capabilities provided by Power BI Desktop for report creation and management. It is a good place to start, though, if you’ve never worked with Power BI.
The OData feed URL can be used in any reporting tool that supports it, including Power BI and Microsoft Excel. This post will be working with Power BI and illustrating how to connect to the Data Warehouse from there.
To connect to the Data Warehouse from Power BI, first install or open up Power BI Desktop on your computer and pull up a new report. Once that is done, do the following:
In the Intune portal, in the “Data warehouse” view, copy the OData feed URL.
Open Power BI Desktop, then click File > Get Data, then select OData feed.
In the prompt that appears, ensure Basic is selected, then paste the OData feed URL copied from Intune into the URL field and select OK.
In the next window, select Organizational Account and click the Sign in button, then provide your Azure AD credentials with access to the Data Warehouse.
These instructions assume we are using user-based authentication, not user-less.
Click Connect and Power BI will connect to the Data Warehouse using the provided credentials.
In the “Navigator” window that appears, select one or more of the tables to import into Power BI, then click Load to load the data.
Be warned – Power BI will load all of the selected tables into the report and into memory – this can use a significant quantity of resources depending upon your environment. For initial testing and report-building, you may want to add more than the data you explicitly need in order to understand what data is available. However, for production reports, it is recommended that you only load the tables that are needed for your reports to keep the report size down and performance optimized.
Barring any errors, the Intune Data Warehouse will now be loaded into Power BI and ready for you to use to create reports!
Usage
Once imported into Power BI (or whichever reporting tool you are using), standard reporting techniques for your reporting tool can be used to explore and present the data. Given that the data is imported from a collection of tables, the first thing you may need to do is to create the relationships between the tables so that your reporting can take advantage of the richness and depth of the data and deliver the insights you need. Power BI will attempt to do this automatically when it imports data from the Data Warehouse, but you may want to review the data model and relationships and validate they are correct, adding any that are missing.
In the following screenshot, you can see part of the data model automatically generated by Power BI Desktop on import from the Intune Data Warehouse:
The right-hand pane, labeled “Fields”, lists each of the tables imported from the Data Warehouse. Expanding any given table will list the individual properties on those tables, containing the actual data to be used in your reports. Data types for those properties should be correct based on the source data type in the Intune Data Warehouse, but you can use your reporting tool to adjust data types if needed, along with adding filters and creating custom properties that build on the Intune Data Warehouse data as needed for your specific reporting needs.
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 Intune Data Warehouse data to build the custom reports you need.
The Intune Data Warehouse provides a powerful vehicle for connecting to Intune’s data and building most any custom reports you need. As stated above, its intent is to provide data for historical and trending analysis rather than real-time reporting, and at that it excels. If you do need access to Intune’s real-time data, though, then the remaining option for advanced Intune reporting, via the Microsoft Graph API, is where you need to go.
Conclusion
So far, two of the three main mechanisms for advanced Intune reporting have been covered– Intune’s integration with Azure Monitor / Log Analytics and the Intune Data Warehouse. The final section of this book will cover the third mechanism, leveraging the Microsoft Graph API for access to real-time Intune data, along with providing an example of what a completed advanced Intune report in Power BI can look like.
Advanced Reporting with Microsoft Graph API and Power BI
In this final section, 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.
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,
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 – 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.
Conclusion
In this book, 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 book 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!