The client apps workload (also known as mobile apps for co-managed devices) was introduced in System Center Configuration Manager 1806 and was done so as a pre-release feature. The documentation on the workload is today still somewhat lacking, so I figured I’d give you some more insights based on my own findings.
The main idea here is, that apps deployed from Microsoft Intune are available through the Company Portal, and apps deployed from SCCM are available through the Software Center. This is quoted directly from the documentation, but what does this really mean? What types of apps are we able to deploy from Microsoft Intune and what’s the expected behavior? This is something I will try to address in this post. Curious? Read on 🙂
- Flipping the switch, part 1: How to enable Co-management in SCCM Current Branch (System Center Configuration Manager)
- Flipping the switch, part 2: Moving Endpoint Protection workloads to Intune MDM (Co-management with SCCM)
- Flipping the switch, part 3: Moving Software Updates workload to Intune MDM (Co-management with SCCM)
- Flipping the switch, part 4: Moving Device Configuration workload to Intune MDM (Co-management with SCCM 1806)
As usual, the first few steps takes place in the Configuration Manager console. As this is a pre-release feature, you will have to turn it on manually. This is done in the Administration work space, in the Updates and Servicing section. See below illustration.
Also, you might need to consent to use pre-release features. This is done on the hierarchy settings of your site:
Next up is to move the actual workload into Intune. Depending on how far you are in terms of testing and piloting of Co-management, set the slider accordingly to either Pilot or just Intune:
Once above changes has been done, the Co-management Configuration Policy will be updated with a new revision and as of such, the clients needs to have their machine policies refreshed (everything standard SCCM behavior). Once refreshed, you can monitor the addition of the new workload in ComanagementHandler.log on the client.
In below snippet, my workload capabilities are moving from 63 to 127, which is indicating the switch of the new workload has been picked up.
Intune Management Extension
This is exciting and something that was added (fixed) just recently. Once the workload has been picked up, the client immediately installs the Intune Management Extension. This is done by downloading and executing the installation from the directory highlighted below. In short, the IME is the reason Intune is able to deploy Powershell scripts and Win32 apps to devices and is used in this Co-management scenario as well.
If you are interested in more details on the Intune Management Extension and it’s capabilities, I suggest that you read following blog post:
Deploying apps from Intune
Microsoft Store Apps
The first and obvious choice here is an ordinary Microsoft Store app. In this scenario I have several apps synced with Microsoft Store for Business to both SCCM and Intune, and one of them being the LinkedIn app.
This is all very basic Microsoft Intune, but for good measures, this is done in the Microsoft 365 Devices Management Portal at: https://devicemanagement.microsoft.com in the Client apps section:
In this scenario, the LinkedIn app is being assigned to a group consisting of users, which in return will give us the app in the Company Portal. (Sorry about the obscure language. The company portal on my computer insists on being in Danish :-()
Line Of Business Apps #1
This is another common and well known app type in Microsoft Intune. In my first example I’m deploying 7-Zip as a .MSIX file.
This app is also assigned as available to a group consisting of users for the user to manually install. The process illustrated below:
Line Of Business Apps #2
In this example, I’m assigning 7-Zip as a traditional .MSI as required to a group consisting of devices.
A required assignment is not being displayed in the Company Portal. The app is installed at the next sync of the device and the process can be monitored in the event log: Devicemanagement-Enterprise-Diganistics-Provider. Below an example of an entry displaying that the content download was started. You will find similar entries displaying that the content was successfully downloaded and the installation started and completed.
Last, but not least. Yet again 7-Zip and this time as a Win32 app. Microsoft Intune latest and greatest enhancement of app deployments.
In this example also assigned as available to a group consisting of users, which again will make it visible in the Company Portal as illustrated below:
Now, all of the actions in this regard is logged to the Intune Management Extension log at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
That goes for both the download, installation and the detection of the application and any troubleshooting will most likely start here.
We ended up being able to install following types of applications on to our Co-managed device from Microsoft Intune (which roughly translates into most needs)
- Microsoft Store for Business App
- MSIX Line of Business App
- MSI Line of Business App
- Win32 App
6 thoughts on “Flipping the switch, part 5: A closer look on the client apps workload (Co-management with ConfigMgr and Intune)”
Can this be done by assigning the apps to a group consisting of devices that are co-managed or does it only work for groups conaisting of users?
Available deployments only work for users – required deployments work for both 🙂
Can I create a Azure AD group dynamically for the comanaged devices?
Hey, not yet. This is something that is currently available in 1905 technical preview: https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-1905#bkmk_aadcollsync
Hi, great post. Does the Company Portal get installed automatically when moving the workload across to intune? Or is this something that needs to be downloaded before hand? Thanks
The company portal needs to be assigned to your devices like any other regular app and does not show up automatically 🙂