Backgrounddownload.exe Application Error

[Kathrine Selvage]

TheIntune Management Extension is a complement to the out of the box windows management functions like the omadmclient. The IME allows to install applications on managed systems or to execute e.g. PowerShell scripts. Additional the IME checks and reports the compliance state of your device.

The IME syncs per default ever 60 min but you can change the time if you create an registry value Interval in MKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Settings. In this value you can specify the time in seconds.

To deploy a app via Intune you have to create a Intune.win file. How you can create such a file and how you can create a new Win32 app in Intune I describe in the this blog post. But now I want to explain how the local app installation process works:

Before the installation can start, two checks are made. The first is a detection if the app is already installed and the second is if the app is applicable for this system this means does the system full fill the requirements of the app.

The detection check is to check if the app is already installed on the system or not. This can be a registry key or the existence of a file or an MSI product code. Addition to that there are also the possibility to write a PowerShell script for the detection. This check is configured during the app creation in Intune.

The applicability check is used to check if the system meets the requirements of the app like min disk space, OS architecture, OS version or you can also create custom checks for a file, regkey or a custom script. Also this is configured during the creation of the app in Intune.

Also here are all checks passed in my case. There are two steps one is the applicability check the upper definitions and the second step is the check of the extended requirements this are the mentioned custom checks.

When the download is completed the Delivery Optimisation Service is notified that the download is done and telemetry data is generated for the Deliver Optimisation reporting. You can see how many bytes from which source (Internet/Lan/Group/MCC) are downloaded or how long the download took.

For this, the installation script is executed. In my case it is the install.bat script. For the installation an installer process is started as a user or machine session. After the installation is finished the process is evaluated if it ended with an error or if the installation was successful. The status of the installation can be found in the registry: HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\user\appid.

Like before the app installation, the app detection is executed again after the app installation to check if the app is detected based on the configured criteria after the installation. In my case the app was detected.

The installation is repeated 3 times. However, there must be at least 5 minutes between the attempts. When all this 3 attempts fails then at the app is in the GRS (Global Reevaluation Scheme). This means the IME waits 24h to try the next attempt to install the app.

The easiest way to trigger a sync of the IME is to restart the process. Open the Task manager and navigate to Services und search for Intune Management Extension. Right click on the Process and click Restart.

But there are also some other ways to do this. The first way is to trigger the sync via a PowerShell. If you look ate the code of the IME you see that there are two possible args for triggering an sync. This is an URL Monikers.

In the Task scheduler you can find an task with the name Intune Management Extension Health Evaluation. The Task will runs once a day and the action is to execute the (C:\Program Files (x86)\Microsoft Intune Management Extension\ClientHealthEval.exe)

The job is very simple, it checks if the IME service is running as it should or not. What the task does in detail you can see in the HealthCheck.xml. It checks if the service exists, how the startup type and the status is checked and how the memory usage is. If a check is not as it should be a remediation is executed. The result of the last run can be seen in the HealthReport.json.

I hope that this blog post has given you a view behind the scenes of the Intune management extension. As with every blog post, I try to keep this up to date and update the blog constantly. Thank you for reading my blog post.

Condition: This is observed on Windows 10 1909 laptop. PDC is connected and suddenly after 30-40 mins of usage Internet / Pulse Intranet sites go unreachable. On Wi-Fi symbol Yellow exclamation mark with no internet access appears, but PDC still shows as up and connected.

Workaround: Disable End-point upgrade on Pulse Connect Secure (PCS). Enable again only when a higher version of PDC is activated on PCS and let the users trigger the client upgrade through the browser.

Condition: Extra components need to be downloaded the first time the user connects to PCS version >= 9.1R10, to upgrade from version Condition: If the processes are started through a wrapper script (like bash or python), then in such a case, Pulse Client fails to identify and kill such processes as part of remediation based on MD5 sum of the script.

Condition: With new PSAM improvement changes, when PSAM is configured with client application functionality, ACL Deny results are always treated as UDP connection deny request which is causing the issue.

Symptom: If a SAML classic connection and PZTA connection of Pulse client both use same IdP and same user accounts, SAML Single Logout (SLO) will not happen during ZTA disconnect and credentials are not prompted in some scenarios.

Workaround: Install dependencies along with webkit2gtk3, which installs version 2.24.1. Then update webkit2gtk3. This will upgrade to version 2.28.2. After this, install Pulse Client. This will result in successful installation

Workaround: None. When connected to Server, this issue is observed only with the Pulse Client UI and not with the Tunnel service. Pulse Client UI automatically restarts without disrupting existing connection or tunnel traffic.

Symptom: For launching from a URL, the following are the prescribed parameters: connect, name, server, userrealm, username.Launching using a URL might throw an error, if: The same parameter is included multiple times while crafting the URL. Any other non-prescribed parameter, other than above-mentioned five prescribed parameters are used.

Condition: Entering differently worded values for the "server" parameter. The following three URLs refer to the same connection, but server values are worded differently. Though the connections with the following three server URLs ( -in/, -in, pcsserver.com/sign-in) would ideally be the same connection, these three connections are treated as different connections while launching from a URL.

Symptom: In case of an upgrade triggered from Pulse Client from version 9.0R3 to 9.1R1 and after the upgrade process is completed, the user is unable to connect, and a network error is displayed in the connection status of the Pulse Client UI.

Background Intelligent Transfer Service (BITS) is a component of Microsoft Windows XP and later iterations of the operating systems, which facilitates asynchronous, prioritized, and throttled transfer of files between machines using idle network bandwidth. It is most commonly used by recent versions of Windows Update, Microsoft Update, Windows Server Update Services, and System Center Configuration Manager to deliver software updates to clients, Microsoft's anti-virus scanner Microsoft Security Essentials (a later version of Windows Defender) to fetch signature updates, and is also used by Microsoft's instant messaging products to transfer files. BITS is exposed through the Component Object Model (COM).

BITS uses idle bandwidth to transfer data. Normally, BITS transfers data in the background, i.e., BITS will only transfer data whenever there is bandwidth which is not being used by other applications. BITS also supports resuming transfers in case of disruptions.

BITS transfers files on behalf of requesting applications asynchronously, i.e., once an application requests the BITS service for a transfer, it will be free to do any other task, or even terminate. The transfer will continue in the background as long as the network connection is there and the job owner is logged in. BITS jobs do not transfer when the job owner is not signed in.

BITS suspends any ongoing transfer when the network connection is lost or the operating system is shut down. It resumes the transfer from where it left off when (the computer is turned on later and) the network connection is restored. BITS supports transfers over SMB, HTTP and HTTPS.

BITS attempts to use only spare bandwidth. For example, when applications use 80% of the available bandwidth, BITS will use only the remaining 20%. BITS constantly monitors network traffic for any increase or decrease in network traffic and throttles its own transfers to ensure that other foreground applications (such as a web browser) get the bandwidth they need.Note that BITS does not necessarily measure the actual bandwidth. BITS versions 3.0 and up will use Internet Gateway Device counters, if available, to more accurately calculate available bandwidth. Otherwise, BITS will use the speed as reported by the NIC to calculate bandwidth. This can lead to bandwidth calculation errors, for example when a fast network adapter (10 Mbit/s) is connected to the network via a slow link (56 kbit/s).[1]

BITS uses a queue to manage file transfers. A BITS session has to be started from an application by creating a Job. A job is a container, which has one or more files to transfer. A newly created job is empty. Files must be added, specifying both the source and destination URIs. While a download job can have any number of files, upload jobs can have only one. Properties can be set for individual files. Jobs inherit the security context of the application that creates them.BITS provides API access to control jobs. A job can be programmatically started, stopped, paused, resumed, and queried for status. Before starting a job, a priority has to be set for it to specify when the job is processed relative to other jobs in the transfer queue. By default, all jobs are of Normal priority. Jobs can optionally be set to High, Low, or Foreground priority. Background transfers are optimized by BITS,1 which increases and decreases (or throttles) the rate of transfer based on the amount of idle network bandwidth that is available. If a network application begins to consume more bandwidth, BITS decreases its transfer rate to preserve the user's interactive experience, except for Foreground priority downloads.

3a8082e126