Introduction
Managing thousands of corporate devices through Microsoft Intune creates an enormous amount of operational data.
Every day, organizations collect information about devices, users, operating systems, compliance policies, configuration profiles, applications and enrollment activity. The challenge is no longer simply collecting the data. The real challenge is turning that information into something that administrators, security teams and management can understand and act upon.
This is where Microsoft Intune Data Warehouse and Power BI become particularly useful.
The Intune Data Warehouse provides an analytics-oriented view of Intune data, exposed through the OData protocol and organized into related entities. Microsoft describes the model as a star schema, with fact-style activity data connected to dimensions such as devices, users, policies and dates. The warehouse also maintains historical information through daily snapshots, which makes it particularly useful for analyzing trends rather than looking only at the current state.
Power BI then provides the visualization and analytical layer that turns this information into dashboards.
Instead of asking:
“How many devices are compliant?”
we can start asking more useful questions:
“Is compliance improving?”
“Which platforms have the highest non-compliance rate?”
“Which policies are causing the most failures?”
“Are there device groups consistently falling behind?”
“Where should the endpoint team focus first?”
That is the difference between reporting data and using data to make decisions.
What Is the Intune Data Warehouse?
The Microsoft Intune Data Warehouse (IDW) is a reporting and analytics service that exposes Intune information in a machine-readable format.
Microsoft documents the Data Warehouse API as an OData v4.0 service that can be consumed by analytics tools and custom applications. Authentication uses Microsoft Entra ID and OAuth 2.0.
The Data Warehouse contains information across areas such as enrolled devices, device properties and inventory, applications, app protection, configuration policies and compliance policies.
One of its most valuable characteristics is historical context.
Intune takes a daily snapshot at midnight UTC and stores that information in the Data Warehouse. Retention varies between fact tables, with some holding approximately seven days of information, others around 30 days, and some datasets retaining longer historical periods.
This distinction is important.
The Intune Data Warehouse should not be treated as a real-time monitoring platform. It is better understood as a historical analytics source.
That makes it particularly useful for Power BI dashboards where the objective is to identify trends, measure changes and understand the overall health of an endpoint environment.
Why Use Power BI for Intune Compliance?
The Microsoft Intune admin center already provides valuable reporting capabilities.
However, an organization often needs something more tailored to its environment.
A security manager might want a single page showing the overall compliance percentage, non-compliant device count, top failed policies and compliance trend.
An endpoint administrator might need a much more detailed view showing specific devices, operating systems, ownership types and policy states.
Management may not want to see thousands of rows of endpoint information at all. They may simply want to know whether compliance is improving, declining or remaining unchanged.
Power BI makes it possible to build these different perspectives from the same underlying data.
Microsoft itself documents Power BI as a supported way to consume the Intune Data Warehouse and create custom reports. The current Microsoft guidance recommends the OData Feed connector for connecting Power BI to the Intune Data Warehouse.
The Architecture
The architecture is conceptually simple:
Microsoft Intune → Intune Data Warehouse → OData → Power BI → Compliance Dashboard
The important part is understanding what happens between each layer.
Intune remains the operational management platform.
The Data Warehouse provides the historical reporting dataset.
OData provides the standardized interface through which Power BI accesses that dataset.
Power BI then transforms, models and visualizes the information.
The result is a reporting layer that can sit above the endpoint management platform.
Connecting Power BI to the Intune Data Warehouse
The first practical step is getting the tenant's Data Warehouse connection information.
In the Microsoft Intune admin center, Microsoft currently documents the following location:
Reports → Intune Data warehouse → Data warehouse
From there, administrators can retrieve the custom OData feed URL for the tenant.
The URL exposes the Data Warehouse service for the tenant.
In Power BI Desktop, the connection can then be created through:
Get Data → OData Feed
The tenant-specific OData URL is entered, and authentication is performed using an appropriate Microsoft Entra identity. Microsoft documents OAuth 2.0 authentication and notes that access is controlled through Microsoft Entra credentials and Intune RBAC.
This is important from a security perspective.
Power BI is not simply connecting anonymously to a database.
Access to the Data Warehouse is governed by identity and authorization.
An Important Change: The Old Connector
One of the most important considerations when building a new dashboard today is choosing the right connection method.
Microsoft states that the Intune Data Warehouse beta connector in Power BI, commonly referred to as connector v1, is being retired.
Microsoft recommends migrating existing reports to the Intune connector v2 or the OData Feed connector. Reports created after November 2025 already use connector v2 and are not affected by the retirement of connector v1.
For a new custom reporting solution, the OData Feed is therefore a strong option because Microsoft explicitly identifies it as the recommended connector for custom Power BI reporting.
This is one of those details that can easily be missed when following older Intune reporting tutorials.
A dashboard built successfully several years ago may not be the architecture you want to reproduce today.
Understanding the Data Model Before Building Visuals
One of the easiest mistakes to make in Power BI is connecting to a data source and immediately starting to create charts.
The better approach is to understand the data model first.
The Intune Data Warehouse uses a star-schema model.
In simple terms, fact tables contain measurements or activities, while dimension tables provide context for those measurements.
A date dimension tells us when something happened.
A device dimension tells us which device was involved.
A policy dimension tells us which policy was involved.
A user dimension provides context about who is associated with the device or activity.
Microsoft designed the model specifically so analytics tools such as Power BI can work with the relationships between these entities.
This is where Power BI becomes considerably more powerful.
Instead of treating every dataset as an isolated table, the model allows us to ask questions across the environment.
The Data That Matters for Compliance Reporting
Several Intune Data Warehouse entities are particularly useful when designing compliance dashboards.
The devices entity contains information such as device identifiers, operating system, Microsoft Entra device ID, ownership, enrollment information and compliance state references.
The complianceStates entity provides the recognized compliance states, including values such as Compliant, Noncompliant, and InGracePeriod.
For policy-level reporting, the compliancePolicyStatusDeviceActivities entity provides daily counts for states such as compliant, non-compliant, unknown, not applicable, error and devices in a grace period.
The compliancePolicyStatusDevicePerPolicyActivities entity goes a step further by allowing compliance status to be analyzed per policy.
This distinction is extremely useful.
A dashboard that only shows overall compliance might tell you that compliance is 92%.
A dashboard that also shows compliance per policy can explain why the other 8% are not compliant.
That turns a number into an investigation starting point.
Designing the Dashboard Around Questions
A good compliance dashboard should not be designed around the question:
“What charts can I create?”
It should be designed around:
“What decisions should this dashboard help someone make?”
That change in thinking has a major effect on the final product.
For example, an executive dashboard could start with five core indicators:
Total Devices
Compliant Devices
Non-Compliant Devices
Compliance Percentage
Devices Requiring Attention
These metrics should immediately answer whether the environment is healthy.
Below those indicators, a compliance trend can show whether the organization is moving in the right direction.
A platform comparison can show whether Windows, iOS/iPadOS, Android or other device populations are behaving differently.
A policy analysis can identify the policies responsible for the greatest number of failures.
And finally, a detailed device view can provide the operational information needed to investigate individual machines.
Measuring Compliance Percentage Correctly
One of the most important design decisions is how the compliance percentage is calculated.
A simple calculation could be:
Compliance % =
Compliant Devices / Devices Evaluated
But the definition of Devices Evaluated matters.
It may include or exclude devices that are unknown, not applicable or in a grace period depending on the organization's reporting policy.
This means two dashboards can use the same source data and produce different compliance percentages while both calculations appear mathematically correct.
The metric therefore needs a documented business definition.
For example:
Compliance percentage represents the proportion of devices evaluated as compliant, excluding devices marked Not Applicable.
Another organization may choose to treat devices in a grace period differently.
The calculation is not only a Power BI problem.
It is a governance decision.
Creating Useful Power BI Measures
Once the Data Warehouse has been loaded into Power BI, the next layer is the semantic model.
This is where DAX measures become valuable.
For example, a simple compliant-device measure could conceptually look like:
Compliant Devices =
CALCULATE(
DISTINCTCOUNT(devices[deviceKey]),
devices[complianceStatus] = "Compliant"
)
A compliance percentage could then be calculated from the relevant compliant and evaluated populations.
The exact DAX implementation will depend on the entities and relationships chosen for the model.
The important principle is to centralize the logic.
Do not create the same calculation independently on five different visuals.
Create the measure once and reuse it.
That makes the dashboard easier to maintain and greatly reduces the risk of inconsistent numbers.
Building the Compliance Trend
One of the strongest advantages of the Data Warehouse is historical analysis.
A single compliance percentage is useful.
A 30-day compliance trend is more useful.
For example, suppose the organization reports:
January: 87%
February: 89%
March: 91%
That tells a different story from an isolated 91%.
The trend demonstrates that the environment is improving.
The opposite can also happen.
A team might report 95% compliance today, but if the trend has fallen from 98% over several weeks, the situation deserves investigation.
The date dimension and daily snapshots make this type of analysis possible. Microsoft specifically documents the Data Warehouse as a historical view of the changing Intune environment.
Identifying the Policies Causing Non-Compliance
This is where the dashboard can become genuinely valuable to an endpoint engineering team.
Instead of showing:
401 non-compliant devices
the dashboard can show:
BitLocker policy — 148 affected devices
OS version requirement — 97 affected devices
Security configuration — 76 affected devices
Password policy — 52 affected devices
Other — 28 affected devices
Now the security or endpoint team has something actionable.
The compliance policy activity entities in the Data Warehouse are specifically designed to provide counts by compliance state and, for certain entities, by policy.
This allows Power BI to move from "How many?" to "Which policy?" and ultimately "What should we fix?"
That progression is what makes a dashboard useful.
Drill-Down: From Management to Endpoint
A well-designed Power BI solution should allow the user to move between levels of detail.
At the highest level, management may see:
92.4% Overall Compliance
Clicking that figure could lead to:
Compliance by Platform
From there:
Compliance by Device Group
Then:
Compliance by Policy
And eventually:
Affected Devices
This is the principle of progressive detail.
The dashboard starts with the answer and allows the user to investigate the reason.
That is much better than forcing the reader to navigate through pages of raw device data.
Using Filters Without Making the Dashboard Complicated
Power BI slicers can make an Intune dashboard dramatically more useful.
Typical filters could include:
Operating System
Platform
Ownership Type
Device Category
Compliance State
Policy
User Group
Date
But there is a balance.
A dashboard with twenty slicers may technically be flexible while being practically unusable.
The goal should be to provide only the filters that support real analytical questions.
A good dashboard makes the important information visible first and places deeper analysis behind sensible filtering and drill-through.
A Dashboard Should Tell a Story
This is one of the biggest lessons I have taken from building technical dashboards.
A dashboard is not a screenshot of data.
It is a story.
A useful sequence could be:
How healthy is the environment?
Then:
Is it getting better or worse?
Then:
Where is the problem?
Then:
Why is the problem happening?
And finally:
Which devices need attention?
That sequence creates a natural analytical journey.
It also aligns with the way different teams consume information.
An executive sees the first page.
A security analyst goes deeper.
An endpoint administrator reaches the device-level detail.
Power BI Performance Matters
A dashboard can be visually impressive and still fail operationally if it takes too long to load.
This is particularly important when working with endpoint data because device populations can become large.
The Data Warehouse contains fact-style activity tables that can grow significantly, while some datasets have relatively limited retention windows. Microsoft's documentation notes that fact tables can become large and commonly have shorter retention periods than dimension tables.
This makes data modelling important.
Instead of bringing every available entity into Power BI, only load the information that contributes to the reporting objectives.
Keep relationships deliberate.
Use appropriate measures.
Avoid unnecessary calculated columns.
Filter historical data where the business requirement allows it.
And design the semantic model before building dozens of visuals.
Power BI performance is often won in the model long before the report page is created.
Security and Access Control
The Data Warehouse contains operational information about an organization's devices and users, so security cannot be an afterthought.
Microsoft states that Intune Data Warehouse access is controlled through Microsoft Entra credentials and Intune RBAC. Intune administrators have access by default, while additional users can be granted appropriate Data Warehouse permissions through Intune roles. Microsoft also documents user-less application authentication for supported scenarios.
This means the Power BI solution should be designed with least privilege in mind.
Not everyone who can view a compliance percentage needs access to device-level information.
A management audience may only need aggregated metrics.
An endpoint team may require device details.
A security team may require more granular investigation capability.
The Power BI access model should reflect those requirements rather than simply giving everybody access to everything.
Refresh Strategy
The refresh strategy needs to reflect the characteristics of the Data Warehouse.
Because the warehouse uses daily snapshots, a dashboard built on top of it should not be presented as a real-time endpoint monitoring solution.
That does not make it less valuable.
It simply means the dashboard is designed for a different purpose.
Power BI can answer questions such as:
How has compliance changed?
Which policies have consistently caused problems?
Are non-compliance rates improving?
Which platforms are underperforming?
For real-time or near-real-time endpoint investigation, a different data source may be more appropriate.
Understanding the difference prevents a common reporting mistake: using a historical analytics source as though it were a live monitoring system.
Turning the Dashboard Into an Operational Tool
The best outcome is not a beautiful dashboard.
The best outcome is a dashboard that changes behavior.
Imagine an endpoint team beginning the week by opening the Power BI report.
The first page shows compliance has dropped from 94% to 90%.
The trend identifies that the decline started approximately one week earlier.
The policy view reveals that most failures involve one compliance requirement.
The platform analysis shows that the majority of affected devices are Windows endpoints.
The drill-through page identifies the specific devices.
The engineering team can now move from:
Data → Analysis → Investigation → Action
without manually exporting spreadsheets from the Intune portal.
That is the real value of combining Intune Data Warehouse with Power BI.
Example Dashboard Structure
A practical report could contain several pages.
The Executive Overview provides total devices, compliance percentage, compliant versus non-compliant devices, and the overall trend.
The Compliance Analysis page focuses on policy-level compliance, platform differences and the distribution of compliance states.
The Non-Compliance Analysis page identifies the most common causes, affected device groups and policies requiring attention.
The Device Detail page provides searchable device information for operational investigation.
The Trends & History page focuses on historical movement, allowing teams to identify improvement, deterioration and recurring patterns.
The exact number of pages is not important.
The logical flow is.
What the Dashboard Should Not Do
A compliance dashboard should not attempt to replace Intune.
Intune remains the endpoint management platform.
Power BI is the analytical layer.
The dashboard should therefore help people understand the environment rather than become another place where administrators attempt to manage devices.
This separation of responsibilities is healthy.
Intune manages.
The Data Warehouse preserves reporting-oriented information.
Power BI analyses.
The people operating the environment make decisions and take action.
Common Mistakes
One mistake is building visuals before understanding the Data Warehouse schema.
Another is calculating compliance without defining what "compliant" actually means.
Another is treating daily warehouse data as real-time information.
A further mistake is loading every available table simply because it is available.
And perhaps the most common mistake is building a dashboard for the person who created it instead of the person who needs to make decisions from it.
A dashboard should answer real questions.
If a visual does not help someone understand the environment or decide what to do next, it probably does not belong on the main page.
My Recommended Approach
I would approach an Intune Power BI project in four broad stages.
First, define the questions the dashboard must answer.
Second, understand the Intune Data Warehouse entities and relationships that can answer those questions.
Third, build a clean semantic model and reusable measures in Power BI.
Finally, design the report around the decisions the target audience needs to make.
This approach avoids a common trap where the project becomes:
"Let's import Intune data into Power BI and see what we can build."
Instead, it becomes:
"Let's solve a reporting problem using Intune data and Power BI."
That is a much stronger starting point.
Final Thoughts
Building compliance dashboards from the Intune Data Warehouse is a great example of how endpoint administration and data analytics can complement one another.
Intune already contains valuable information.
The challenge is making that information understandable.
The Data Warehouse provides the historical, structured foundation.
OData provides a standard access layer.
Power BI provides the modelling, calculations and visualization.
Together, they can create a reporting solution that helps security and endpoint teams move beyond static numbers and toward meaningful analysis.
The most important lesson is that a dashboard should not simply tell you what happened.
It should help you understand:
What happened?
Why did it happen?
Is it getting better or worse?
Where is the problem?
What should we do next?
That is where Power BI becomes more than a visualization tool.
It becomes a decision-support platform for endpoint security and management.
I remain learning, testing and improving my understanding of Microsoft Intune, Power BI and the broader Microsoft security ecosystem. Every dashboard, query and solution is another opportunity to turn technical data into something practical and useful.
We learn. We build. We improve.
Top comments (0)