Microsoft’s Background Intelligent Transfer Service (BITS) has been around since Windows 2000 SP3 and provides a “firewall-friendly” means of transferring files across the network which also allows for restarts. It’s also the file transfer mechanism used for Windows updates (but is not exclusively used for Microsoft products) and is now at version 3.0 (included with Windows Vista and Windows Server 2008).

A few weeks back, I was discussing the problem of rebuilding remote servers with some colleagues. We considered that it may be advantageous to keep a copy of the build image locally (e.g. on a branch office server) but image management (making sure that the locally cached image is the latest version) is an important concern. One of my colleagues asked if BITS could be used to control the distribution of the image files (which could be expected to be around 2GB) so I decided to dig a little further. The short answer is “yes”, but there are some things to be aware of:

• Whilst recent versions of BITS can transfer files from either a web server (using HTTP/HTTPS) or a UNC shares (using SMB) but BITS 1.5 and earlier does not support the SMB protocol for the remote server.
• Uploads require Microsoft IIS (5.0, 6.0 or 7.0, but not 5.1) with BITS IIS extensions configured. This means that pushing updates to a folder on a client is not possible (unless running IIS on all the clients); however it is possible to “pull” a file, if another method of initiating the transfer exists (e.g. a process which polls a central location for changes; by running a remote script from RDP, telnet; or instantiating a job using another method). If running IIS for uploads is appropriate, then check out the article on using BITS to upload files with .NET by Phil Wilson (no relation!).
• IIS 5.0/BITS 1.2 or earlier each have a maximum file size for download of 4GB.
• BITS 2.0 and earlier only uses the network interface card to measure network traffic and is not aware of network conditions further out on the network (i.e. the client’s Gigabit Ethernet NIC may be barely used but the WAN link may be significantly slower and could possibly be running at full capacity). For this reason, group policies may be applied to control the behaviour of BITS. BITS 3.0 can also use an Internet gateway device to determine network usage, as well as supporting peer caching – for peer-to-peer distribution of files using BITS.
• BITS guarantees that the version of the file it transfers is consistent based on the file size and time stamp, not content (BITS does not protect against man-in-the-middle attacks but implementing IPSec would).

Microsoft provides a command line tool called BITSAdmin (bitsadmin.exe) for monitoring the progress of BITS jobs. BITSAdmin is available as a support tool for Windows XP SP2 and Windows Server 2003 but is included with Windows Vista and Windows Server 2008. James Finnigan has a good post introducing the concept of transferring files using BITS; Aaron Czechowski has another BITSAdmin script; Frank-Peter Schultze has a good post on scripting downloads with BITS; or refer to the full BITSAdmin syntax and examples for further details.

Various third party wrappers also exist, including:

• Bitsup.
• Bits C# Wrapper.
• Managed BITS.

I haven’t seen a PowerShell wrapper for BITS yet but I have used Alexander Sukhovey’s BGet command (batch) file to initiate and manage BITS file transfers.

If BITS is not appropriate, those with plenty of bandwidth might consider RoboCopy (I have used it in the past to synchronise folders across the network) but, for me, Mads Klinkby’s BITSync looks perfect – unfortunately the download link was unavailable at the time of writing this post.