Users and Network Connections
BITS transfers files only when the job owner is logged on and a network connection is established. BITS processes the transfer job using the security context of the job owner. The user who created the job is considered the owner of the job. However, a user with administrator privileges can take ownership of another user's job.
BITS suspends a job when the owner logs off or if the network connection is lost (BITS will not force a network connection). BITS resumes the job when the owner logs back on and a network connection is established. After the network connection is established, a short delay may occur before BITS begins transferring data.
If the network connection is lost, all jobs whose state is BG_JOB_STATE_QUEUED or BG_JOB_STATE_TRANSFERRING are moved to the BG_JOB_STATE_TRANSIENT_ERROR state with a BG_E_NETWORK_DISCONNECTED error code. When a network connection is established, all jobs in a BG_JOB_STATE_TRANSIENT_ERROR state, which may include any error code, are moved to the BG_JOB_STATE_QUEUED state.
For BITS to detect that a user is logged on, the user must use one of the following interactive logon options:
- Log on through the Welcome screen.
- Log on to a terminal service client.
- Use fast user switching.
- Starting with Windows 10, version 1607, log on from another device using Remote Powershell. See To manage PowerShell Remote sessions for details.
Running an application as another user (by using the RunAs command) is not an interactive logon; BITS will not run jobs associated with the specified user.
The LocalSystem, LocalService, and NetworkService system accounts are always logged on; therefore, jobs submitted by a service using these accounts always run. For information and limitations on using service accounts, see Service Accounts and BITS.
Job owners can provide a helper token to be used in situations where multiple tokens are needed to complete a transfer, such as for authentication with a remote host. See Helper Tokens for BITS Transfer Jobs for details. In earlier versions of Windows, the job owner effectively had to have administrator privileges to start a job that used a helper token. In Windows 10, version 1607, it is now possible for a BITS job owner to set helper tokens without being an administrator, as long as the helper token does not have administrator capabilities. This reduces the vulnerability footprint of background download or update tools by enabling them to run under the lower-privileged NetworkService account rather than under an account with administrative privileges.
Users with a restricted token (a token that contains restricting SIDs) cannot create or modify jobs.