Here we find all relevant information about the processing of the Intune Windows Agent. We get deeper understanding what the agent is actually doing and it is the location to start troubleshooting Intune related error regarding Win32 apps.
The log file problem!
If you look closely on the screenshot above, you see log files capped by 2 MB in size and we only have two of them. The IntuneManagementExtension.log is the main logfile. That’s the one in which is actually written during execution and the _IntuneManagementExtension.log is the rollover log file. In total we have 4 MB log file storage to store processing information. As I already mentioned if you have a lot of Wn32 app we generate a lot of information to store in the log files. The next problem is that relevant error information might have been logged in the beginning of the Windows Autopilot app install process but after e.g. 30 app installations a lot of information is generated and finally the display of the error message on the ESP is very late in the process then. All this leads to the situations, that the log file might already be rolled over several times and relevant information from early in the beginning is already lost.
How to fix the Intune Agent log file problem?
Luckily the IME did take care of this and implemented some functionality to control the log file size and the amount of log files. As soon a we configure some registry values we can define the log file size and amount of files to keep. In the following screenshot you can see the modified behavior of the IME to store 4 MB large log files instead of the 2 MB and keeping 4 files in total:
The registry values to configure are:
To make sure that these values are early on the device available, we can target a small PowerShell script to write these values. The Intune Management Extension (IME) does not support an ordered installation, so we can’t target something to run at first in the policy and Win32 app processing. Anyway the experience form the field has shown that targeted PowerShell scripts are almost every time very early in the process. So targeting a PowerShell script should do the trick to be early enough to reconfigure IME log file behavior to make sure to capture all info even if a lot of log file information is generated due to a lot of assignments. That way we can make sure we can successfully troubleshoot Windows Autopilot and follow every processing from the beginning of the device lifecycle.
Enhance Intune Agent Logging PowerShell Script
Follow the GitHub link below to get a simple PowerShell script to add it to Intune via PowerShell scripting feature to reconfigure the IME logging:
Make sure to run the script in the 64-bit execution context and target it to your devices:
If you need some deeper understanding of the Intune Management Extension (IME) and PowerShell scripting I suggest to check out my blog post Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts
You could easily use this script with Endpoint Analytics > Proactive remediations to make sure the values stay the same over time. I didn’t saw the need for that as it is a LocalMachine value and it normally is not tampered. But If you feel you have to monitor this, just write a short detection script and you can use it with remediation scripting as well.
For me this is a very important functionality as I often was limited in troubleshooting by the amount of log file info I had available. Consider to test it out and implement some meaningful values for your environment.
Hopefully better IME troubleshooting for you all now 👍