The Background Intelligent Transfer Service (BITS) is a critical component that assists the system and applications during downloads between the machine and a remote server, without compromising the network experience. It does this by intelligently managing prioritisation and automatically interrupting and resuming data transfers. We will see that it is possible to reset BITS via Powershell. This can solve some problems during application deployment.
What is BITS?
BITS, for Background Intelligent Transfer Service, is a component of Windows. It is primarily used for efficient prioritisation and asynchronous file transfer between devices that use idle network bandwidth, as well as for the delivery of software updates, especially by modern versions such as Microsoft Update, Windows Update, Windows Server Update Services and SCCM.
File transfer via BITS is an asynchronous system. The application makes a transfer request to the Background Intelligent Transfer Service and once this request is made, the item is terminated or is available for another function. The requested transfer then takes place in the background, although this depends on the availability of the network connection and whether the task owner is connected or not. If the network connection is lost, the transfer is suspended until the reconnection is made later.
Properties of a BITS task
A typical BITS job consists of six steps: A connection is established with the BITS service, a file transfer job is created, files are added to the transfer job, the file transfer job starts, the status of the transfer job is checked, and when the transfer is completed or cancelled, the job closes. Administrators can adjust the behaviour of the BITS transfer task to set task priority, proxy usage and task event notifications. Administrators can create and manage BITS tasks using Windows Remote Management (WinRM) and Windows Management Instrumentation (WMI) PowerShell cmdlets.
How to Reset BITS
On SCCM, you may sometimes see clients that are in a “Pending Content” status. You might think that this is a boundary issue. Indeed, in most cases, if many clients have this status, it is possible that a boundary has not been declared. So you check and confirm that it is not that problem this time. If you look at the execmgr.log file, you can see that the client was waiting for the content to be downloaded. You can then launch a Powershell window via Recast on the client and type the following command:
Get-BitsTransfer
With this cmdlet, it is really easy to see all the BITS transfers that are currently in progress. Currently, the ConfigMgr client is running as a Local System account. Therefore, to see the BITS transfers from the ConfigMgr client, we need to run the following command:
Get-BitsTransfer -AllUsers
As you can see in the image below, there is a problem with BITS. For some reason it had failed to download a bunch of jobs and many were queued up.
You can then reset the BITS transfer queue on the client in this case. This can be done on a task-by-task basis or by deleting the queue completely. You can, of course, use PowerShell to delete only those tasks that are in a failed state. If you wish to use this method, this single line should suffice:
Get-BitsTransfer -AllUsers | Where-Object <strong>{</strong> $_.JobState -like "TransientError" <strong>}</strong> | Remove-BitsTransfer
Let’s check the BITS transfer queue again by running :
Get-BitsTransfer -AllUsers
The BITS transfer queue was now empty. You can now redeploy the package to the client and confirm that it has been successfully downloaded by BITS.
