On Aug 7, 2008, at 4:12 AM, Maverick wrote:

Perhaps the scsi id if the device(s) has changed in the OS? Unfortunately, this is sometimes quite common on Windows systems and occurs when the server is rebooted and Windows autoassigns scsi id´s to the devices, causing inconsistency between OS and NetWorker. I think this might only be valid if you have more than 1 tape drive, so if you don´t, you can probably stop reading now.,. =)

Easiest way to check if the id´s have changed is to load (not mount) a tape in Tape0, and then run "mt -f \\.\Tape0 status". This will give you a list of features the drive supports, and at the very end you will get an error if there is NO tape in the drive. If there IS a tape in the drive, you don´t get any error. Do the same procedure for you other tape drives.

So, if you for example load (again, do not mount) a tape in what NetWorker believes to be Tape0, but the mt command states that the drive is empty, you have a scsi id problem. The reason you should not mount the tape is that if there is indeed a scsi id problem, the tape will not be loaded in Tape0, but in another drive (since Windows has assigned the scsi id for Tape0 to another drive), and this might cause NetWorker to wait for a reply from the wrong drive and the mount will hang/fail.

If you find that the id´s have indeed changed, the fastest way to fix it is simply to delete the jukebox and drives and run a new jbconfig.

That´s my suggestion anyway.

There is a way to prevent this from happening again with some registry editing, but let me know if the scsi id´s have really changed and i will post that as well.

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER