Press "Enter" to skip to content

Co-Management Client Apps Workload and System Account Proxy Configuration

0

This post describes an interesting, network issue @chimpusmaximus and I encountered with application delivery from Intune to a Co-Managed device.

Test devices were built and the necessary Co-Management settings applied for the Client Apps workload (amongst others).  The log files confirmed successful enrolment into MDM and the correct capabilities were reported:

image

The traditional stalwart of the IT demonstration and testing world was duly deployed to the user so that the installation could be started on-demand and log files analysed if problems were encountered:

image

However the application installation did not initialise, and the logs found in “C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log” had plenty of errors – mainly relating to missing proxy settings.

In the example below we can see an error of “no proxy was found in the registry for current user”, followed by my user account (which has been obscured).  Another interesting entry is the “Current Proxy = https://graph.windows.net” where it appears Microsoft attempt to provide proxy information to make things work if issues are detected or proxy information is missing – in our case the “fallback” MS provided proxy did not result in success:

image

After much troubleshooting all carried out by a determined colleague (@chimpusmaximus) it was discovered that a value for the proxy was missing from the system.  However not for the logged on user mentioned in the log files but rather for the SYSTEM account that was performing the download and installation.

My colleague was able to run a command similar to:

c:\windows\system32\bitsadmin.exe /util /SetIEProxy LocalSystem Manual_Proxy MyProxyServer:80 “;*.mydomain.com”

In order to add the corporate proxy information into the registry for the SYSTEM account, after which application deployments were successful.

I mocked up the error in my lab so I could take some further screenshots below.

Here you can see that I have set the Proxy for the SYSTEM account in my lab to “BreakClientApps” – (note there are no requirements at all for a proxy in my lab)

image

When I try to install Firefox, the IntuneManagementExtension log file is riddled with proxy related misery which is telling us that my proxy name could not be resolved (which makes sense).  The idea here is to show you that proxy information, if you use one, is crucial to the communication flow:

image

Setting the proxy information correctly has been mentioned above, but in my case I need to remove the dummy configuration which can be carried out by running the following command:

c:\windows\system32\bitsadmin.exe /util /SetIEProxy LocalSystem NO_PROXY

image

And confirmed with a /GetIEProxy switch:

image

After I’ve removed the dummy proxy information I try to install Firefox but I’m greeted by a locked “install” button in the Company Portal, with a status of “Download Pending”

image

The best way to solve this is to open up settings in the Company Portal and perform a “Sync” whereby the application will begin to install:

image

And after a short wait Firefox is installed successfully:

image

I hope this helps someone else to avoid the proxy woes we faced here. Thanks for reading.

Edit: Microsoft also posted some information on the “Pending” state for app installations on Co-Managed devices – that blog can be found here

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

This site uses Akismet to reduce spam. Learn how your comment data is processed.