Background 

I was looking for an external hard drive for a Windows 2003 Server. The drive will be used mostly for backups. My long-range plan is to be able to save workstation backup images to the drive via the network, but to be able to attach the drive directly to a workstation, if necessary, to restore an image. The drive should be reasonably fast when attached to the server, so eSATA seemed to fit the bill. However, since the workstations don't have SATA cards, the drive needed to support USB as well. I chose a 500GB Seagate FreeAgent Pro USB/eSATA version, along with a SIIG eSATA II-150 PCI card for the server.

I should perhaps mention that while the SIIG card is supported under Windows Server 2003, the FreeAgent drive is not. I talked to Seagate sales before I purchased the drive, and the impression I got was that although the drive is not officially supported, it should work. And it fact it does--with one important modification.

Symptoms 

The problem I encountered after connecting the drive to the eSATA card was the following error in the Windows System event log:

Source: Disk
Event ID: 7
Description: The device, \Device\Harddisk2, has a bad block.

At first I thought this indicated a bad disk. But eventually I saw a pattern:  the bad block error only occurred if the drive had entered its "sleep" state, i.e. had spun down. By default, this happens after 15 minutes. If I accessed the drive in Windows explorer after it had spun down, in the few seconds that it took it to spin back up, Windows would get impatient and report a bad block error. Note that the "sleep" mode I'm referring to is an internal feature of the Seagate drive--it is not under the control of Windows Power Options in the Control Panel.

If I attached the Seagate drive via a USB cable, let it spin down, and then accessed it, I did not get a bad block error.

Another symptom, one that I did not at first associate with the FreeAgent disk, was the following message in the Application event log:

Source:  VSS
Event ID:  12289
Description:  Volume Shadow Copy Service error: Unexpected error DeviceIoControl(\\?\Volume{ba849e07-88fb-11d9-9c6f-806d6172696f} - 0000017C,0x0053c020,00039B48,0,00038B40,4096,[0]).  hr = 0x80070017.

This error occurred when I started an ntbackup job. Apparently during Volume Shadow Services initialization, it couldn't immediately access to the Seagate drive and so logged this error. A bad block error was also logged at exactly the same time. 

Cause

My speculation is that Windows knows that USB drives may spin down, and it will wait for them to become accessible. However, because an eSATA drive runs as a BIOS-attached drive (similar to a SCSI drive), Windows treats it as an internal drive and expects it to be "on" at all times.

Solution

The solution is to attach the drive to a Windows XP or Vista machine, install the FreeAgent Tools software, go to Utilities, and set the Drive Sleep Interval to Never. Then move the drive back to the server. The Sleep Interval setting is maintained even though the drive is powered down when moving it to another machine. Once I did this, both the bad block and the VSS errors stopped.

Conclusion

It's obviously a pain to have to install a 142MB software package just to change the Sleep Interval, but Seagate Support said there is no other way. Too bad they don't make a simple command-line utility for updating the drive settings. (The software has lots of slick backup/restore features, integration with Internet drive access, etc.--all kinds of things that I don't need in this environment.) I tried installing the FreeAgent software under Windows Server 2003, but the installation failed with a message that it only runs under Windows 2000, XP, or Vista. Hence the solution of temporarily installing the software on a desktop machine.

I wonder if others have had similar problems with eSATA drives that like to go to sleep? Eventually Windows may need to add an option to treat eSATA drives like it treats USB drives. Considering that this drive is only used once a day during backups, it would be nice if sleep mode worked without causing errors. In the meantime, I'll hope that keeping the drive out of sleep mode resolves the "bad block" errors.