Search for a command to run...
By getting information directly from MDMDiagReport.xml
I work as System Administrator for more than 15 years now and I love to make my life easier by automating work & personal stuff via PowerShell (even silly things like food recipes list generation).
No comments yet. Be the first to comment.
Or any other Azure service requiring special authentication strength
If you are using Azure Local (HCI), you might find the following PowerShell script AzureLocalVMImageUpdater.ps1 useful. What is it good for? The code replaces the Windows VM images in the specified Azure Local cluster(s) with the latest compatible ve...
Problem It happens that the hardware hash of your Autopilot device gets changed. Thanks to the replacement of the motherboard or some other issue. This can lead to future problems when your users need to reinstall the operating system, but the Autopi...
Learn how to use undocumented Azure APIs for massive performance gains
Keeping a secure, version-controlled backup of your Intune-managed device data, including BitLocker, LAPS, and FileVault keys, is a best practice for any modern IT team. In this post, I’ll guide you through an Azure DevOps pipeline that automates the...
In my previous post, I've talked about parsing Intune MDMDiagReport.html report and how to convert it to a PowerShell object. There is also the final post that merges all this knowledge into the fully-featured solution.
Today I will continue this journey for getting a better Intune report by looking at the MDMDiagReport.xml file that contains a lot of interesting information that is unfortunately not available in the built-in Intune HTML report. I've created function ConvertFrom-MDMDiagReportXML that converts this XML into PowerShell object with just important report data or output the results to nice HTML report.
I haven't find any documentation describing content of MDMDiagReport.xml so I've just reverse engineered it. It means that results can miss or show incorrect information. If this will be your case, please let me know, so I can fix this function.
Btw when I'll talk about built-in Intune HTML report I mean this one
Download, dot source and run PowerShell function ConvertFrom-MDMDiagReportXML
Call ConvertFrom-MDMDiagReportXML to get PowerShell object
Call ConvertFrom-MDMDiagReportXML | Out-GridView to get nice GUI searchable output
Call ConvertFrom-MDMDiagReportXML -asHTML -showURLs to get nice HTML report like
All this blog post is about is my function ConvertFrom-MDMDiagReportXML. Don't forget it is a function, so you will have to dot source the downloaded script first and then explicitly call it!
Check the examples section for some usage tips.
MDMDiagReport.xml is XML file containing details about processing of Intune policies.
It can be generated by calling MdmDiagnosticsTool.exe -out "C:\IntuneReport" and the result will look like this
As you can see besides the MDMDiagReport.xml folder contains also the built-in HTML Intune report and some related event logs.
You don't have to generate it manually, my function will do it for you.
MDMDiagReport.xml contains a lot of information about Intune policies processing but (same as original HTML report) not all of them. For example what is missing:
Applied scripts (scripts and remediation scripts)
Windows app (Win32)
Name of deployed MSI installation
These kind of data will be added in my next and hopefully final ultimate Invoke-IntunePolicyResult (like gpresult) function. 👍
Now when we have MDMDiagReport.xml we need to understand its content hierarchy.
After several days of testing, guessing and testing I've found these important XML nodes:
All Intune enrollments deployed to this client
What I get there: enrollment ID, scope, setting names
Deployment errors
What I get there: type of policy, policy name, error code, time of evaluation, ...
Deployment errors for MSI installations
What I get there: package ID, download URL, used command line, product version, status, assignment type
All policies deployed to this client
What I get there: enrollment ID, policy scope, policy area, policy settings
I ignore knobs policies because those are just some internal diagnostics data
Details for policies settings (metadata)
What I get there: policy type, default value, registry key and value it changes
Details for ADMX based? policies settings (metadata)
What I get there: policy type, source Admx file, registry key and value it changes
To be able to convert XML objects to PowerShell objects I have used function ConvertFrom-XML.
90% of function code is based on https://stackoverflow.com/questions/3242995/convert-xml-to-psobject. I just fixed some bugs and make it 30% faster.
My report contains more information than a built-in one and more importantly shows just useful information
Knobs (debug) policies etc are omitted
My report contains:
policy errors (if any)
installed MSI applications with version, state etc (name is missing from XML, but will be added in my next version)
details like what registry key/value is changed, admx template is used, URL to CSP documentation, etc
Function can return PowerShell object (with all benefits it brings) or quite nice HTML report
I've used great PowerShell module PSWriteHTML. So I didn't have to write a single line of HTML code by myself :)
Special thanks go to @evotecpl for his assistance with tuning of this report 👍
Check this nice detail (red background for cells with errors (code different from 0))
Function ConvertFrom-MDMDiagReportXML gets content of **MDMDiagReport.xml **, extracts just important parts and merge them together to one structured PowerShell object or HTML report and returns it. Nothing less nothing more.
For the final solution check my next post. There you will see Get-ClientIntunePolicyResult function that merges XML data with registry ones which leads to a complete Intune policy report.
You can use standard PowerShell filtering a.k.a Where-Object.
You can also use Out-GridView to get some basic GUI with decent filtering capabilities. The disadvantage of using Out-GridView is the lack of nice readable output for individual setting details.
Moreover, you can use -PassThru to pass selected object down the pipe for further processing like:
And you will get:
Which can be drilled down like:
And this is how it looks when you generate HTML report
And now compare it with built-in one :)
