In Windows Server 2003, BITS includes server extensions for IIS 6.0. The extensions provide client-to-server upload capability, but they're not selected in a default IIS installation. To install them, you'll need to dive deep into the Add/Remove Windows Components dialog box: Application Server / IIS / BITS Server Extensions. BITS doesn't include much in the way of a management UI, so you'll probably also want to install it's command-line utility, BitsAdmin, from the Support Tools. You'll find it on the 2003 CD-ROM, under \Support\Tools\Support.cab. Just run the Setup.exe located in the Tools folder to unpack and install BitsAdmin.

What's a BIT?
Transferring files can be a frustrating experience in a number of situations, especially when there's a slow network link involved. BITS is designed to solve that problem by transferring files in the background, using whatever bandwidth isn't being utilized by other processes. In other words, BITS uses "spare" bandwidth to gradually transfer files. Even better, BITS allows transfers to be interrupted, and will automatically resume where it left off. This is a great way to transfer files (very gradually) to remote users who only have dial-up connections. Every time they log on to check mail or whatever, BITS will get a little bit more of the file transferred. Eventually, the entire file will make it. Practically nothing will upset BITS, including logoffs, disconnects or even crashes. It just picks up where it left off.

BITS has a job queue, which lists all of the file transfers that it needs to complete. The queue contains jobs, which each represent a particular file. You can prioritize jobs in the queue, so that important files will transfer ahead of less important ones. BITS supports four different priority levels; jobs at the same priority will share transfer time, meaning they'll all crawl through the user's "spare" bandwidth at the same time. BITS uses HTTP and HTTPS as its only transport protocol, making it easy to funnel BITS jobs through firewalls, proxies and other network obstacles.

BITS Versions and How It Works
I mentioned earlier that XP includes BITS 1.0. That version is only capable of downloading files from a BITS server. Version 1.5 comes with 2003 and can perform uploads, as well. Microsoft is releasing an updated BITS 1.5 client for Windows 2000 and Windows XP. They've already released BITS 1.2 in the Windows 2000 Service Pack 3 and Windows XP Service Pack 1, but the functionality is pretty much the same as 1.0. You need to be a bit careful on versioning because of how BITS works.

When BITS starts downloading a file, it stores the incoming content in a temporary binary file. This technique prevents users from seeing the file while the transfer is in progress. However, different versions of BITS can use different binary formats. If you start with a Windows XP machine running BITS 1.0, install an updated version, and start transferring a file, the file will obviously be stored in the newer binary format. However, if you perform a system restore to any checkpoint prior to the new BITS client installation, then you'll be reverting back to BITS 1.0, which may not be able to read the binary format of the file transfer in progress. Unfortunately, that means your transfers will have to start over, and even worse, BITS won't clean up the now-useless temporary files.

How can you fix it? Well, you can't, but you can prevent it. That's where the BitsAdmin tool comes into play. Just run bitsadmin /reset /allusers before performing a system restore. That will clean up all outstanding jobs and reset the job list, allowing BITS to start over when the system restore completes. Note that only an Administrator can successfully execute the BitsAdmin command.

A Model of Simplicity
BITS is actually so simple, it's a wonder someone didn't think of it before. The key lies in the HTTP 1.1 protocol's specification for two methods: Head and Get. These are methods an HTTP client can use to request specific information from a Web server. BITS is nothing more than a specialized HTTP client; when it downloads a file, it does so over HTTP (or HTTPS). It uses the Get method's Content-Range and Content-Length headers to specify which portions of a file it wants to download. So, when BITS first starts transferring a file, it starts with byte 0 and asks for the entire file. If the transfer is interrupted after 1,000 bytes, BITS later resumes by asking for the same file, starting at byte 1,000 and continuing through to the end of the file. This technique is simple and reliable, although it does limit BITS to transferring static content. You can't, for example, transfer a file that's generated dynamically, because a dynamically generated file's length might change, messing up BITS' calculations and expectations.

Using BITS
BITS is actually designed to be accessed directly by applications, which must use BITS' Application Programming Interface (API) to place transfer jobs on the queue and to monitor jobs' status. Fortunately, BitsAdmin offers mere mortals like you and I a way to work with BITS. For example, bitsadmin /list /allusers will list all outstanding jobs for all users of the local computer.

If you want to place a download job on the queue, run bitsadmin /create JobName, providing a descriptive name for the job. Note that jobs always enter the queue in a suspended state, so you'll need to run bitsadmin /resume JobName to actually get it going. Similarly, you can use bitsadmin /suspend JobName to pause a transfer job, or bitsadmin /cancel JobName to cancel it altogether. Once a job completes, you'll need to use bitsadmin /complete JobName to actually finish the job and turn the temporary file into the actual, final file that was transferred.

If you feel like messing with jobs' priorities, you can run bitsadmin /setpriority JobName Priority, where Priority is FOREGROUND, HIGH, NORMAL, or LOW. BitsAdmin has a slew of other options that allow you to configure security credentials, proxy servers, and more. Looking like Greek to you? Here's a walkthrough of creating a new job to transfer a file:

1. Run bitsadmin /create MyJob to create a new job.
2. Run bitsadmin /addfile MyJob http://webserver/myfile.zip c:\myfile.zip to add a new file to MyJob. You've specified a source location by using http://, and you've specified a destination location on your local computer.
3. Remember that the job is suspended to begin with, so run bitsadmin /resume MyJob to shake it loose and start the transfer.
4. Run bitsadmin /info MyJob /verbose to see how your job is doing. You'll see the job's GUID, it's type and status, and a bunch of other useful information.
5. When the job finally completes, run bitsadmin /complete MyJob and C:\myfile.zip should magically appear.

Not so tough after all, and you should be having some clever ideas of building batch files to kick off your own BITS transfers to remote users.

Where Does This Work?
Assuming you've gotten the 1.5 client update from Microsoft (promised soon after 2003 was released), here's where you can use BITS:

• Upload from 2000/XP/2003 to 2000 running IIS 5.0 and the BITS 1.5 extensions.
• Upload from 2000/XP/2003 to 2003 running IIS 6.0 and the BITS 1.5 extensions.
• Download from almost any HTTP server-even non-MS ones-to 2000/XP/2003.

The download part works with nearly any HTTP server because it's the BITS client that handles the bandwidth throttling, job tracking, and other tasks. In addition to basic HTTP support (or HTTPS; BITS supports secured transfers), the Web server simply needs to be HTTP 1.1 compliant, which most are nowadays. The server's Head method must return the size of the file requested, and the Get method must support the Content-Range and Content-Length headers; this extra support is what allows BITS to resume a file transfer that was suspended due to a disconnect or something. The official HTTP 1.1 spec includes the necessary support, so any compliant Web server should be fine. Even an HTTP 1.0 server will work if it includes the necessary Head and Get support.

Why BITS?
Microsoft thinks BITS will be used primarily by application developers to transfer application-related files. I think administrators could also use it to trickle MSI and other files down to clients that have slow network connections. I think BITS will make a great part of future versions of Windows and Systems Management Server, too, especially when it comes to software distribution. Although BITS doesn't have a pretty user interface today, it does include a very functional command-line interface, making it easy to create batch files that create BITS jobs on users' computers. With BITS 1.5 in place, you can even upload files from users' computers to a centralized IIS server, such as computer inventory lists or other information.