Introduction

This blog post is basically my own troubleshooting flow after a recent Autopilot failure at work. The failure was linked to application installation and the cause was interesting. To verify what was going on I compared a failed Autopilot logs with a known good Autopilot log set side by side. The test computer at my desk consistently succeeded with Autopilot, while the users computer consistently failed during the Enrollment Status Page phase. I will explain what’s happening in the log to give you an overview how to troubleshoot it yourself going forward.

Looking for clues in the logs

The log in question here is the IntuneManagementExtension.log found in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Here is the section from the IntuneManagementExtension.log where it detects apps required for the ESP (Enrollment Status Page). This is taken from the failed Autopilot machine and at this point everything looks OK.

Here is the same section from a known good Autopilot session.

The log then adds info about each of these apps to the registry

On an Autopilot deployed pc (or intune managed) you can find these registry entries in the following location:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\{USER GUID}\{APP_GUID}

The USER_GUID will more than likely be different on each computer unless the same user is used on both computers. In the below screenshot I’ve expanded the USER_GUID to reveal several GUIDs that match Win32 applications installed on that computer.

The ESP (Enrollment Status Page) set’s the status of each of these apps.

[Win32App] CreateNewInstanceForWin32App setting appInstallState NotInstalled with userSID for Win32App_3dfa3b3b-83a4-4ed9-a7cf-a8376136ab26_1

And after some logging it starts processing each application in turn, notice how it now shows the app GUID and the apps friendly name, including whether there are application dependencies or not. The starting process for each application logging starts with the following line.

[Win32App] ExecManager: processing targeted app

The log then sorts out what it’s doing in steps such as below for each app.

[Win32App] ===Step=== Start to Present app 3dfa3b3b-83a4-4ed9-a7cf-a8376136ab26 [Win32App] ===Step=== Detection rules [Win32App] ===Step=== Check applicability [Win32App] ===Step=== Check Extended requirement rules [Win32App] ===Step=== Check detection without existing AppResult [Win32App] ===Step=== Download [Win32App] ===Step=== ExecuteWithRetry [Win32App] ===Step=== Execute retry 0 [Win32App] ===Step=== InstallBehavior MicrosoftEdge, Intent 3, UninstallCommandLine STABLE [Win32App] ===Step=== Detection rules after Execution [Win32App] ===Step=== Set ComplianceStateMessage with applicationDetectedAfterExecution [Win32App] ===Step=== Set EnforcementStateMessage

All those steps above should describe the process from start to finish of each required app within the ESP. According to the log, this application installed correctly, and the application type was .bin as this app is Edge Chromium and Edge Chromium is treated differently to ‘normal’ Win32 applications (.intunewin).

Next it cleans up the staged content and verifies the installation state and finally checks if the ESP is finished yet, if not it progresses to the next app.

So the first application installation was successful, which is great.

Let’s move on to the next app in the list, and it’s Chrome as revealed in the log.

Proceeding through the steps we can see that it fails in the ===Step=== Download phase

Just for comparisons sake, let’s compare that failure section to the same section from a working machine

What do the errors mean ?

The app install fails with the following error line:

JobError callback (Context: BG_ERROR_CONTEXT_NONE; ErrorCode: 80072EFD) for job 4abe5657-ae62-41be-8a3b-2f88e7f460cc

Looking at the first reference, a search on the internet for BG_ERROR_CONTEXT_NONE brings me to these Microsoft doc links

• https://docs.microsoft.com/en-us/windows/win32/api/bits/ne-bits-bg_error_context
• https://docs.microsoft.com/en-us/windows/win32/delivery_optimization/bg-error-context

And strangely BG_ERROR_CONTEXT_NONE translates to… no error:

BG_ERROR_CONTEXT_NONE An error has not occurred.

But the second error code is indeed an error..

Job has failed. Error: 80072EFD Job 4abe5657-ae62-41be-8a3b-2f88e7f460cc (BG_JOB_STATE_ERROR) failed to complete, cancelling…

Using the Error Code lookup ability in CMTrace, I checked the 80072EFD error code and it translated to:

Looking for clues in Endpoint Manager

Looking in Microsoft Endpoint Manager, for the device in question and then selecting Managed Apps, and typing in the name of the application

clicking on the Chrome app that failed I can see the following.

Clicking on Show details should reveal some more information.

And this does indeed sound like either a network problem (see first message) or quite possibly a Background Intelligent Transfer Service (BITS) related problem.

BG_E_ERROR_INFORMATION_UNAVAILABLE (0x8020000F) Error information is only available when the state of the job is BG_JOB_STATE_ERROR. The error information is not available after BITS begins transferring the job’s data or the client exits.

• https://docs.microsoft.com/en-us/windows/win32/bits/bits-return-values

Back to IntuneManagementExtension.log log, I looked for the next app installation attempt, and the app was Cisco WebEx Meetings, a Win32 app.
[Win32App] ExecManager: processing targeted app (name=’Cisco WebEx Meetings’, id=’6e1e9458-26ba-406a-bdc6-2a27dc3ec905′) with intent=3 for user session 0

And just like with Chrome, this app again fails to download.

further down in the log I noticed this nugget…

Exception occurs when downloading Win32App user session 0, the Exception is System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it xxx.xxx.xxx.xxx:80 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)

Wait what ?

No connection could be made because the target machine actively refused it xxx.xxx.xxx.xxx:80

So using whois I traced the IP address in the log and it turns out to be a Network services (telecommunications) provider. A content delivery network….

pulling more data out of the log relating to the actual content it was trying to download (and from where…)

and checking swdb02.manage.microsoft.com revealed that the IP address blocking connections also belongs to Microsoft…

I’ll update this post with further information later if we determine why that content provider blocked the download of applications causing the ESP to report a failure.

Summary

Sometimes you have to really dig into the logs to determine where the failure actually occurred, I hope this gave some clarity of the process.

cheers !

niall