The Company Portal app – A deep dive into bridges

It’s a miserable January morning here in the UK, so what better to do than jump down the rabbit hole that is the Company Portal app? I want to explore how the Company Portal app performs various actions and retrieves details such as application installation status and device compliance, as well as how it invokes actions like installing and uninstalling apps.

Tl;dr, the secret lies in Jeff Bridges

The Company Portal app relies on two crucial components to handle some core functionality – the ConfigMgr Bridge and the Intune Management Extension (IME) Bridge. These bridges serve as intermediaries between the app’s user interface and the underlying system management capabilities. The ConfigMgr Bridge acts as a conduit for configuration management tasks, while the IME Bridge facilitates communication with Microsoft Intune for device management operations. Together, these bridges enable the Company Portal app to retrieve installation statuses, check device compliance, and execute management actions seamlessly.

Where are these Bridges?

Logical question Dr Watson, lets explorer this a little further. The Company Portal app is installed in the hidden and protected C:\Program Files\WindowsApps folder. Instead of wrestling with UAC, lets peek at the executables in this folder using the Windows Terminal.

C:\Program Files\WindowsApps\Microsoft.CompanyPortal_11.2.1002.0_arm64__8wekyb3d8bbwe> Get-ChildItem *.exe -Recurse | Select-Object Name

BridgeLauncher.exe
ConfigurationManagerBridge.exe
IntuneManagementExtensionBridge.exe
RecoveryMediaCreationTool.exe
CompanyPortal.exe

Note: I’m using a Windows VM on Arm – the name of the Company Portal app will vary depending on the device architecture.

The 3 executables we are interested in are BridgeLauncher.exe, ConfigurationManagerBridge.exe and IntuneManagementExtensionBridge.exe.

Procmon

A good place to begin to understand the role of different executables is to leverage Procmon, a nifty tool from SysInternals.

As well as enjoying cheese, I spend a lot of time manipulating Procmon filters to build a picture of the rabbit hole I’m diving down. Here is a list of the executables you should filter on to remove the noise from other system processes.

• BridgeLauncher.exe
• CompanyPortal.exe
• ConfigurationManagerBridge.exe
• IntuneManagementExtensionBridge.exe
• Microsoft.Management.Services.IntuneWindowsAgent.exe
• wmiprvse.exe

You can also download a home made Procmon filter from here, if you like:-

Logs

Its always good to know where the log files are when deep diving. Logs are unique for each user, they can be found in the users profile path at:-

AppData\Local\Packages\Microsoft.CompanyPortal_8wekyb3d8bbwe\LocalState

• Log.BridgeLauncher_1.log
• Log.ConfigurationManagerBridge_1.log
• Log.IntuneManagementExtensionBridge_1.log
• Log_*.log

Configuration Manager Bridge

The ConfigMgr Bridge serves as a crucial intermediary component that enables the Company Portal to interact with the ConfigMgr Client. This bridge implementation leverages the WmiDataConnectorShared class in SCClient.Data.Shared.dll to facilitate the interaction between the Company Portal and the ConfigMgr client.

The bridge also implements a listener pattern through the ConfigMgr Trace Listener, which monitors and logs all interactions between Company Portal and ConfigMgr.

A typical bridge operation log entry follows this format:

2024-11-15T16:50:07.2850341Z  INFO  Event        None                      0  1487dc30-3bb0-46bf-98ee-76771bd9953e  12-0-0  [Configuration Manager Trace Listener] 15/11/2024 16:50:07: SCClient Information: 1: Getting all instances of CCM_Application    (Microsoft.SoftwareCenter.Client.Data.Shared.WmiDataConnectorShared at GetAllApplicationsWithType)

WMI Namespace Access

The bridge operates within the root\ccm\ClientSDK namespace, providing access to the following classes:

• CCM_Program: Handles deployment of Task Sequences
• CCM_Application: Manages application deployments
• CCM_SoftwareUpdate: Controls software update management

Applications

CCM_Application only records policy for applications targeted to the device (not the user) unless the policy targeted to the user has already been evaluated by the ConfigMgr client.

A useful WMI query you can run against this class, to understand what the Company Portal will display, would look like this:-

Get-CimInstance -Namespace "ROOT\ccm\ClientSDK" -ClassName "CCM_Application" | Select-Object Name, InstallState

Something that messes with my Spidey senses is the applications returned are not ordered in the Company Portal

Task Sequences

You guessed it. We can also see advertised Task Sequences in the Company Portal too, facilitated by the ConfigMgr Bridge. Task Sequences are found via the not so obviously named class CCM_Program.

Get-CimInstance -Namespace "ROOT\ccm\ClientSDK" -ClassName "CCM_Program" | Select-Object Name, LastRunStatus

Software Updates

If ConfigMgr is managing the updates workload, for both first or third-party updates, they are obtained via the Bridge using the CCM_SoftwareUpdate class.

Get-CimInstance -Namespace "ROOT\ccm\ClientSDK" -ClassName "CCM_SoftwareUpdate" | Select-Object Name, Deadline

Intune Management Extension Bridge

The IME bridge also appears to watch events handled by the IME which is responsible for invoking the requested actions.

In the example below, we initiated a Win32 app install. Procmon helps us identify which bridge components and logs are at play and how the Company Portal is able to interact with the IME.

Stateless IW Service

The Company Portal communicates with Intune through the StatelessIWService endpoint, which works through Microsoft’s Traffic Routing Service. I have no insight into how or where this data is retrieved from behind the service, but the status of an app returned via this service aligns with the application and device status we see in the Intune Admin Center.

Here is what we do know:-

1. The StatelessIWService is the endpoint that Company Portal uses to get information about:
   • Application status
   • Device Compliance status
2. All communication happens through Microsoft’s Traffic Routing Service, which:-
   • Handles the routing of requests
   • Manages the connection security
   • Ensures reliable delivery of data

Community Ask: Someone let me know what IW means…here are my best guesses:-

• Intune Workflow
• Intune Workspace
• Igloo Water
• Interactive Web
• Interactive Workspace

Update 11th Feb 2025: IW stands for Information Worker
Thanks to Jevgenij Martynenko on LinkedIn, Source

Below is a nice SSL inspection which highlights the request by the Bridge to the traffic routing service and we can see application information in the response.

Deep Dive – Company Portal Initialisation and Flow

I’m still debating if this is useful but I had fun demystifying, slightly, what happens when the Company Portal app is launched. By examining the requests to the traffic routing service we can understand a little more on what is happening behind the scenes.

Stepping through the flow, lets peek at what is going on here:-

Here is what the JSON looks like in that response, it tells us where to connect to

A further GET request queries the StatelessIWService for the version information of a specific SSP

Another GET request now queries the device information to be displayed in the Company Portal

The response contains all the required information we would come to expect for the device.

So we have the device information, the flow now continues to get application specific information.

A GET request now queries application information to be displayed in the Company Portal

The Application and status information returned in JSON format and displayed in the Company Portal.

After we have processed all the IME goodness, our ever faithful ConfigMgr information is requested via the Client SDK.

What Can go Wrong?

Ever had customers contact you and tell you that these notifications are just out-right wrong?

Yeah – that happens.

There is a Win32LocalAppStatus JSON in the users profile that loses its way from time to time. Simply deleting this file will restore the correct notifications for the device.

The JSON looks a clear candidate to become confused. Nuke it from orbit Ripley.

Summary

In this deep dive, we’ve uncovered some of the core architecture and flow behind the Company Portal app and its bridge systems. While the ConfigMgr Bridge uses somewhat straightforward WMI calls to access application, task sequence, and update data through the ClientSDK namespace, the IME Bridge connects to Intune through the more mysterious StatelessIWService endpoint. Though we can’t peek behind the curtain of Microsoft’s Traffic Routing Service, we know it reliably syncs with the same data source as the information displayed in the Intune Admin Center.

Both bridges appear to implement trace listeners to monitor and log their interactions with the ConfigMgr and IME agent. If we get another dull day in the winter we might dive even a little deeper.

Thanks for reading!