Prologue
Proper case documentation not only helps in proper case management for the case owner but also helps to have a better understanding of the case and its status when it moves up the support hierarchy levels (L1 > L2 > L3). This helps to reduce the overall TAT of a case, due to lesser time spent on things that are otherwise wasted due to the below points.
- Setting up multiple comms with the end-user to gather the relevant information which should have been done at the first go
- Repetition of same TS steps or procedures by the higher-level team due to no clear information of what has already been done and its outcome
The other important aspect of providing a seamless support experience is proper data (log) collection.
It certainly does not helps either the end-user or the next level support engineer, when a case moves up the support hierarchy, without having proper or relevant logs. It results in the same wastage of time in setting up comms with the end-user to retrieve the necessary logs, thereby increasing the case age and TAT.
Where case documentation is like a habitual practice, relevant log collection requires knowledge and a clear understanding of the product – the underlying concepts and a clear overview of how things work.
– Joymalya Basu Roy
Introduction
For mobile devices (Android and iOS), in most cases, an Intune Administrator has to work with only the profile deployment status from the Intune portal to help troubleshoot issues, before reaching out to MS Support.
MDM log generation and analysis for Android and/or iOS devices managed by Intune is rather limited. The native MDM log collection is facilitated via the Company Portal app which collects the MDM log, silently uploads the collected log to the MS log database in the background, and provides a unique identifier to identify the uploaded logs, to be provided to the MS support.
However, the MDM logs that are collected remain hidden (not really, will have a post on this later!) from the IT administrators.
But when it comes to Windows 10, it’s an entirely different story.
Windows 10 does not restrict an Intune Administrator with the limitation of possible client end checks as in the case for mobile platforms, only if you know
- what to look for, and
- where to look for,
With Windows 10, there is no Company Portal log as such, but you have a similar option to get Management logs or which we term the MDM Diagnostic logs.
However, what is of more relevance is that you have the entire Windows Registry and Events at your disposal for tracking and tracing issues related to Intune management.
I have split the content into a two-post series, wherein
- Part 1 – Today we will be discussing the Windows 10 client end verification to check for policy deployments from Intune and the different log collection options that Windows has available for us.
- Part 2 (coming soon, stay tuned!) – We will be having a walkthrough of the Windows registry to check information related to Intune management and policy deployments, the important Event paths, and the specific individual log file locations.
So let’s get started.
Windows 10 MDM Log Checklist
This is all about Windows 10 client end check to validate policy deployment from Intune and the different log collection options that are available in Windows 10.
Check the policies as received
The first place to check the policies as received on a Windows 10 endpoint is from the Work Account Info.
Settings > Account > Access work or school > Work Account > Info
You get to see an overview of all the policies (Configuration profiles and MSI applications) delivered to the device by Intune here.
Note #1 The overview gives you the information about the feature that the policy controls and not the name of the policy as you configured in the portal.
Note #2 This does not includes win32 and PS script deployments from Intune.
If the policy status in Intune shows as Pending and you do not see the same under managed policies here, check the device SYNC status.
If there be any network-related issues (mostly common if the device is in Intranet or in restricted networks), verify with the network team, if the device is able to communicate to the required endpoints. Check the Intune network requirements as listed here.
However, if you can see that the device has received the policy for the particular feature, you can move to the next part which is…
Generate a simple MDM Diagnostic report
You can generate a simple MDM report from within the Info page of the Work Account using the Create report button.
This creates an HTML report file (MDMDiagReport.html) that can be found at the location C:\Users\Public\Documents\MDMDiagnostics
Reviewing MDMDiagReport.html
The file can be viewed with any browser. Here we are more interested to look under the Managed policies header to check what all policy settings Intune has delivered to the device. You will see the Default Value for the policy as well as the policy enforced value which reflects under the Current Value.
This can be your starting check to confirm if the policy settings as configured in the Intune portal is what is being delivered to the device or not.
If you see that the Current Value does not match or is not in accordance with what has been set in the portal, it is an Intune service-related issue as it is not delivering the policy settings which is configured.
However, if you see the policy settings have been correctly delivered, then it is up to the respective Configuration Service Providers (CSP) to implement the same. In such a case, if the policy state is in Error, you need to check a bit further – the event logs for the same.
Generate a detailed MDM Diagnostic report
Use the Export your management log files from Access work or school display without going inside the Work Account.
This results in a cab file (MDMDiagReport.cab
) at the same location C:\Users\Public\Documents\MDMDiagnostics
which you can extract using any tools like 7Zip/WinRAR.
An alternative to this is using CLI to trigger the MDMDiagnosticTool. Open a command prompt with admin rights and use the command
MdmDiagnosticsTool.exe -area <area name(s)> -cab <output cab file path>
The “area
” names are defined in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MdmDiagnostics\Area
however, you need to have specific knowledge of the issue to determine which area to use.
The resulting cab file will contain all the events and logs particular to the area as specified during log collection. Want to review the logs as collected, check out this blog post by Vimal Das.
Intune One Data Collector
Intune ODC is a master log collection tool to cover all the aspects of Intune.
This is a custom tool from Microsoft which is designed to collect a variety of files, registry keys, and command-line output to assist support engineers in troubleshooting Intune issues. If you have experience working with Microsoft Support for any Windows 10-related issue, you might have come across this name as it is pretty common for an MS Support Engineer to request ODC logs in several scenarios.
The tool is freely available on GitHub and can be used even without opening an MS Support Case (Offline Standalone)
- Navigate to this link and save the entire site content as Intune.xml
- Download the tool (Direct download link)
- Double-click on 1dc-c.diagcab to launch the troubleshooter and click on Next to continue
- Choose to send diagnostic information to Microsoft when prompted [Dont worry as this will still be offline log generation]
- Choose Custom Data Collection from the Data Collector List and click Next
- Browse and select the Intune.xml file that you saved in step 1 and click Next
- Allow the One Data Collector to complete and click Close when prompted
- Navigate to
%localappdata%\elevateddiagnostics
to get the logs collected by the ODC tool.
Latest.cab
will contain the results of the last run. If you unzip that, you get a file structure like shown below
The folders which are of interest to me are
- EventLogs
- Files
Within Files, you get the related logs regarding all aspects of Intune segregated and sorted into separate folders as shown below, within which you will get the actual log files.
That’s all for today, to be contd.
That’s all in store for today. Go ahead and have a look through the logs by yourself. Happy exploring!
In the next article of this series, I will be taking you through the relevant Windows registry entries for Intune, what Events logs to check, and information that gets stored locally on the device which can help you with troubleshooting issues related to Intune.
Till then – keep reading, keep learning, and most importantly – Stay Safe