This month, a new version of Microsoft Intune 2408 came out with some very exciting features. We saw some improvements on the Discovered Apps Report and enhancements to the Intune Management Extension (IME) logs for Win32 Apps (really the only good apps, sorry not sorry). In this article we will cover the following:

• What is the Intune Management Extension?
• How App Logging/Troubleshooting Works Today?
• The New Discovered Apps Reports
• Win32 App Logging Enhancements
• Logging Enhancements for WinGet Installs
• Final Thoughts aka TL:DR

What is the Intune Management Extension?

The IME is not exactly super clear as the documentation has been a bit lackluster. We rely on what others have written about it, but what exactly is the IME?

If I don’t want to trust what others have written, let’s use the logs to figure out exactly what it does today. The following logs exist today in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs and check them out. A few of them don’t need their own sections:

• Client Cert Checking (The client cert check is pretty basic. It identifies that where the environment lives e.g. public cloud, and validates the certificate is found inside of the certificate store. I know, super simple.)
• Health Scripts (This checks for a valid AAD user session, sets the MDM device certificate, loads the user script settings, and processes resolved policies. Basically, it executes the detection scripts for remediations. One fun fact, this will also manage the App Control for Business managed installer for Intune.)
• Sensor (Logs the subscribed events like App Usage Config events.)
• Win32 App Inventory (Collects the app inventory via WMI, prints it, saves it, computes for deltas, and sends it up to Intune.)
• Agent Executor
• App Action Processor
• Client Health
• Device Health Monitoring
• Intune Management Extension service

Essentially, we learned that some of the stuff IME handles are:

1. WinGet Apps
2. Win32 Apps
3. PowerShell Scripts
4. Remediations
5. App Control for Business Managed Installer
6. Device Compliance
7. Analytics

I’m sure there might be more, but that is what this exercise is for, to evaluate the various logs within IME to see exactly what it does (since it’s not well-documented by Microsoft.)

Intune Management Agent Executor

After reviewing the log, we understand that the “Agent Executor” log shows the actions being executed by the agent like settings parameters, executing remediation scripts, installing stuff via WinGet.

The AgentExecutor we can see executes installs via WinGet for store apps e.g.:

We can also see it executing PowerShell scripts. We learn here that remediation scripts are being housed here (including the one for the App Control for Business Managed Installer): C:\windows\imecache\HealthScripts\

This shows the IME agent executing the detection script for our remediation:

One other thing we see is the agent parsing various parameters:

Intune Management Extension App Action Processor

The app action processor is what evaluates each individual application and determines if anything needs to happen or not. Let’s take a look at one:

The app is WinSCP for context. First, we see it identifies an app in scope of the device or user:

[Win32App][ActionProcessor] App with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb, targeted intent: RequiredInstall, and enforceability: Enforceable has projected enforcement classification: EnforcementPoint with desired state: Present. Current state is:
Detection = Detected
Applicability = Applicable
Reboot = Clean
Local start time = 1/1/0001 12:00:00 AM
Local deadline time = 1/1/0001 12:00:00 AM
GRS expired = True

Next, let’s check out the intents:

##First, it checks for Uninstall Intents
[Win32App][ActionProcessor] Found: 0 apps with intent to uninstall before enforcing installs: [].
##Second, it checks for Install Intents##
[Win32App][ActionProcessor] Found: 1 apps with intent to install: [078d9a48-cdc2-40c7-a82f-cf54ac0e62fb].
##Third, it checks for Uninstall after Enforcing Installs
[Win32App][ActionProcessor] Found: 0 apps with intent to uninstall after enforcing installs: [].
##Once done, it will see if any action needs to occur.
[Win32App][ActionProcessor] Evaluating install enforcement actions for app with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb.
##It determines nothing needs to happen
[Win32App][ActionProcessor] No action required for app with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb.

The interesting thing is when an app needs to be installed, we see this:

[Win32App][ActionProcessor] Evaluating install enforcement actions for app with id: 0cacd55b-f032-4e36-9678-aba95497d6f4.
##Once finished, it will show as detected
[Win32App][ActionProcessor] App with id: 0cacd55b-f032-4e36-9678-aba95497d6f4, targeted intent: RequiredInstall, and enforceability: Enforceable has projected enforcement classification: EnforcementPoint with desired state: Present. Current state is:
Detection = Detected
Applicability =  Applicable
Reboot = Clean
Local start time = 1/1/0001 12:00:00 AM
Local deadline time = 1/1/0001 12:00:00 AM
GRS expired = True

Intune Management Extension Client Health

This one I thought was interesting. Below is the flow/series of events that occur in the client health aspect of the IME:

1. Identifies the environment (e.g. Public Cloud).
2. Sets the MDM certificate’s thumbprint as an attribute.
3. Sets the Intune service URL as an attribute.
4. Verifies the IME service exists.
5. Verifies the IME service startup type is correct.
6. Verifies the IME service status.
7. Verifies the IME service memory usage.
8. Sends a health report to Intune.
9. Sets the download service URL as an attribute.
10. Gets the certificate and does a check-in using device check-in the AAD app.

Intune Management Extension Device Health Monitoring

This is another interesting service that I think we should lay out as well:

1. It checks to see if debugging is enabled.
2. Sets the OS version property and overrides it.
3. Fetches a new AAD token via the token manager.
4. The data sensor starts registering device health bookmarks (checkpoints used by Intune to capture device health status). When new data is found, it’s sent to Intune via the 1DS (One Data Collection) SDK and queued against the pipeline.
   • Boot Data
   • Logon Perf Data
   • App Usage Data
   • Hardware Readiness Data
   • Device Inventory Data
   • Driver Inventory Data
   • Querying of App hangs or crashes
   • CPU Daily Data
   • Memory Usage Data

Intune Management Extension

One of the things I didn’t know until I started digging into IME is that there is an EMS agent underneath as well. Also known as “EnterpriseDesktopAppManagement”

We can see in this log that it validates if recycle scripts are enabled, remote device actions, and if IME is allowed to rotate BitLocker keys.

Like other aspects of the IME, you can see it pulling the environment and certificate information. In addition, its setting global attributes for the userID and deviceID.

Once done, it pulls the gateway addresses for the discovery service e.g.:

• https://checkin.dm.microsoft.com/devicecheckinfe/wcoscheckin
• https://r.manage.microsoft.com/devicegatewayproxy/cimhandler.ashx

Next, it calls the location service to get other service addresses:

[Location Service] Calling LocationService ServiceAddresses Controller with checkin.dm.microsoft.com/RestUserAuthLocationService/RestUserAuthLocationService/Certificate/ServiceAddresses with True
[Location Service] Calling LocationService ServiceAddresses Controller with https://manage.microsoft.com/RestUserAuthLocationService/RestUserAuthLocationService/Certificate/ServiceAddresses with True
[Location Service] SendWebRequest, client-request-id: f96fa669-8945-4b59-a656-47bea9c309fa, Method: GET
[Location Service] Success!! LocationService ServiceAddresses Controller with https://manage.microsoft.com/RestUserAuthLocationService/RestUserAuthLocationService/Certificate/ServiceAddresses with True, statusCode = O
[Location Service] Got address for service: AriaService, url: https://self.events.data.microsoft.com/
[Location Service] Got address for service: CollectorService, url: https://us-mobile.events.data.microsoft.com/OneCollector/1.0/
[Location Service] Got address for service: SideCarGatewayService, url: https://fef.msua08.manage.microsoft.com/TrafficGateway/TrafficRoutingService/SideCar/StatelessSideCarGatewayService
[Location Service] Intune DownloadServiceUrl is https://fef.msua08.manage.microsoft.com/TrafficGateway/TrafficRoutingService/DownloadService
The sideCar gateway url from OnStart is : https://fef.msua08.manage.microsoft.com/TrafficGateway/TrafficRoutingService/SideCar/StatelessSideCarGatewayService

We also see it starting telemetry and sending data up to the connector (so that’s another thing the IME does you may not quite realize!)

We can also see it starting various tasks:

• Win32 AppOnTimer (how often it checks, defaulted to 60m).
• Content Manager (policy info)

It was interesting that it also does checks to see if it’s using Device Preparation. In addition, we see ESP checks and is delaying Win32 app timers at startup. One other thing it does is manage the state transitions that occur during the application deployment process:

The last thing I wanted to mention is how the IME does tamper validation for executing PS scripts, which is another cool thing:

How App Logging/Troubleshooting Works Today

So, we spent a TON of time covering the data that is inside of the IME logs, to give you a good idea of what the IME actually does.

Troubleshooting apps today can be tricky. We start by looking at the App Install Status.:

As we drill in, we see this:

So, wtf do you do now? You basically start googling 0x8024401F (because that’s what you want to do obviously).

Overall, there just isn’t a ton of information when we have issues, and this is just one example of that. It becomes incredibly tricky, and we are limited in what we can do when application issues surface.

The Discovered Apps Reports

I find the discovered apps report to be useful. Sure, it’s not some magical thing, but it can definitely have its uses. You can see that they have now added publisher information for fun:

You can even drilldown into a specific app and version to see who has it installed. Sometimes it’s useful when wanting to see what version of an application are out there on devices:

Enhancements to Win32 App Logging

Now, we have the new Win32 App Logging called AppWorkload.log. Let’s break it down.

This is how things are logged:

1. The IME starts with the app check-in.
2. App poller starts.
3. It checks for Workplace Join, ESP status, and sidecar CSP provider status.
4. Creates a content folder.
5. Gets the AAD user session and MDM certificate.
6. Loads global Win32 app settings.
7. Processes user session (e.g. branding, ESP status).
8. Displays the Win32 apps for the user.
9. Processes policy subgraphs.

Below we’ll look at the app evaluation:

##It finds the apps
[Win32App] Got result with session id 1c00bdae-ce68-4174-a0f2-77eb285caf68
[Win32App] Got 16 Win32App(s) for user XXXXXXXX in session 1
##Starts processing Win32 App subgraphs
[Win32App][V3Processor] Processing 15 subgraphs.
##Found the subgraph for an app
[Win32App][ReevaluationScheduleManager] Found previous subgraph reevaluation time value: 8/20/2024 12:05:08 AM at key s+6FZt4hpVVF7uQtwH8rX3iE8Jwed/vH7ZaD6es7PNs=.
##Initializes the reporting state of the various apps
[Win32App][ReportingManager] App with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb and prior AppAuthority: V3 has been loaded and reporting state initialized. ReportingState: {"ApplicationId":"078d9a48-cdc2-40c7-a82f-cf54ac0e62fb","ResultantAppState":null,"ReportingImpact":null,"WriteableToStorage":true,"CanGenerateComplianceState":true,"CanGenerateEnforcementState":true,"IsAppReportable":true,"IsAppAggregatable":true,"AvailableAppEnforcementFlag":0,"DesiredState":2,"DetectionState":1,"DetectionErrorOccurred":false,"DetectionErrorCode":null,"ApplicabilityState":0,"ApplicabilityErrorOccurred":false,"ApplicabilityErrorCode":null,"EnforcementState":1000,"EnforcementErrorCode":0,"TargetingMethod":0,"TargetingType":1,"InstallContext":2,"Intent":3,"InternalVersion":1,"DetectedIdentityVersion":"6.3.4.14955","RemovalReason":null}
##Processes the subgraph with the first App ID
[Win32App][V3Processor] Processing subgraph with app ids: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb
##Checks Global Reevaluation Schedule
[Win32App][GRSManager] App with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb is expired.
Hash = s+6FZt4hpVVF7uQtwH8rX3iE8Jwed/vH7ZaD6es7PNs=
GRSTimeUTC = 4/25/2024 9:41:28 PM
##Sets a New Expiration Time (Note its 4 hours from now).
[Win32App][ReevaluationScheduleManager] Setting subgraph reevaluation time with value: 8/25/2024 5:38:46 PM for subgraph with hash s+6FZt4hpVVF7uQtwH8rX3iE8Jwed/vH7ZaD6es7PNs=.	AppWorkload	8/25/2024 1:38:46 PM	15 (0x000F)
##Invokes the Handler for App Detection
[Win32App][DetectionActionHandler] Handler invoked for 1 app detections.
[Win32App][DetectionActionHandler] Detection running for policy with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb.
[Win32App] ProcessDetectionRules starts
[Win32App] ProcessDetectionRules Parsing InstallEx...
[Win32App] DetectionType 2
[Win32App] Start detectionManager SideCarFileDetectionManager
[Win32App] Checked filePath: C:\Program Files (x86)\WinSCP\WinSCP.exe, Got versionStr:6.3.4.14955, compareValue 6.3.2.14890
[Win32App] GreaterThanOrEqual: actualVersion: 6.3.4.14955, compareVersion: 6.3.2.14890, applicationDetected: True
[Win32App] Checked under Path: %ProgramFiles%\WinSCP, filePath:%ProgramFiles%\WinSCP\WinSCP.exe, agent was checking under expanded: C:\Program Files (x86)\WinSCP\WinSCP.exe, applicationDetected: True
[Win32App] detectionManager SideCarFileDetectionManager got applicationDetectedByCurrentRule: True as system
[Win32App] Completed detectionManager SideCarFileDetectionManager, applicationDetectedByCurrentRule: True
[Win32App][DetectionActionHandler] Detection for policy with id: 078d9a48-cdc2-40c7-a82f-cf54ac0e62fb resulted in action status: Success and detection state: Detected.

Honestly, it’s exceptional. You can now see step by step all aspects of the Win32 app deployment/validation process.

You see the checks for OS, storage, etc.:

You can see below that the handler completed its job, updated the Company Portal and send reports/statuses up to Intune and saved the GRS values to storage:

Enhancements with WinGet Logging

Let’s check out WinGet as well, which is in the same log file.

##Service starts the WinGet process by detecting the app and stating the context.
[Win32App][WinGetApp][WinGetAppDetectionExecutor] Starting detection of app with id: 43def848-c409-4516-bbe0-b9cbb2967cfc and context: UserContext.
[WinGetMessageProcessor] Creating Message Processor for user: 75073ecb-1920-4111-b9e8-0fa6e95cc1cc and application 43def848-c409-4516-bbe0-b9cbb2967cfc.
##Creates the controller for the execution.
[Win32AppPlugin] [AgentExecutorController`1] Creating AgentExecutorController.
[Win32AppPlugin] [AgentExecutorController`1] Adding type Microsoft.Management.Clients.IntuneManagementExtension.WinGetLibrary.WinGetOperationResult to safe types.
[Win32AppPlugin] [AgentExecutorController`1] Adding type Microsoft.Management.Clients.IntuneManagementExtension.WinGetLibrary.WinGetInstallOperationProgress to safe types.
##Creates the Pipe Server
[AgentCommon] [AgentExecutorController`1] Creating AnonymousPipeServer.
[Win32AppPlugin] [AgentExecutorController`1] Ensure that user, JonathanTowles, can read and write to the pipe.
[Win32AppPlugin] [AgentExecutorController`1] Closing user token handle
[Win32AppPlugin] [AgentExecutorController`1] Adding pipe handle to command line parameters.
##Launches the Agent Executor Process with the context specified earlier.
[Win32AppPlugin] [AgentExecutorController`1] Launching Agent Executor process.
[ProcessMonitor] Launch process as current user.
[ProcessMonitor] Getting current user identity.
##Impersonates as the user to get the token
[ProcessMonitor] After impersonation: AzureAD\JonathanTowles.
[Win32App][WinGetApp] Not elevating token for user, using default privileges.
[ProcessMonitor] User profile successfully loaded. The user name is AzureAD\JonathanTowles
[ProcessMonitor] Execution environment block is created successfully.
##Runs WinGet to install the application
[ProcessMonitor] Calling CreateProcessAsUser: '"C:\Program Files (x86)\Microsoft Intune Management Extension\agentexecutor.exe" -executeWinGet -operationType "Detection" -repositoryType "MicrosoftStore" -packageId "9WZDNCRFJ3PZ" -installScope "User" -pipeHandle "11328"'
[ProcessMonitor] Proxy process created successfully.
[ProcessMonitor] Process id: 296696
[ProcessMonitor] Process got lpExitCode: 0, lastWin32Error: 1008
[ProcessMonitor] Closing Thread Handle.
[ProcessMonitor] Closing Process Handle.
[Win32AppPlugin] [AgentExecutorController`1] Starting wait for Agent Executor.
[WinGetMessageProcessor] Waiting for results to come in with timeout of 60 seconds.
[AgentCommon] [Microsoft.Management.Services.IntuneWindowsAgent.AgentCommon.ProcessMonitor] Starting waiter thread.
[ProcessMonitor] WaitForProcessToExit Enter.
[WinGetMessageProcessor] Processing Incoming message OperationResult and data Microsoft.Management.Clients.IntuneManagementExtension.WinGetLibrary.WinGetOperationResult.
Processing results for operation - Ok.
[WinGet] Detection Operation Result has arrived Ok
##Detection for the App is completed
[Win32App][WinGetApp][WinGetAppDetectionExecutor] Completed detection for app with id: 43def848-c409-4516-bbe0-b9cbb2967cfc.ontext="" type="1" thread="297" file="">sult.
##Winget operation results are stated
WinGet operation result:..
Operation result =.. Ok
Installed version =.. 11.2.448.0
Reboot required = False
Installer Error code =..
Extended error code =..
Detection result:..
Action status: Success
Detection state: Detected
Detected version: 11.2.448.0
Error code: ]LOG]!><time="09:05:04.9399363" date="8-25-2024" component="AppWorkload" context="" type="1" thread="75" file="">

Closing Thoughts

Yeah, that was long. Honestly, I really enjoyed learning about IME in detail. I didn’t want to trust what anyone else had written because many of those articles are a few years old (2-7 years to be specific).

My overall sentiment is that Intune logging still has some work to do, but the new Intune logging on application installs is probably the best logging I’ve seen on apps in Windows. Ideally, I’d love to see the level of detail in the new logs in the portal, but you only get a subset of it.

For the first time, there is a log you can literally go pull and know EXACTLY why an application install failed, why an app verification criteria failed, etc.

The other major takeaway is that IME is much more than just delivering apps. We have many aspects to IME that matter like scripting, remediation, compliance, and so much more. The IME is central to the framework of Intune, but with a stronger understanding it’s easier to troubleshoot and work with it.