AS9 not finding replaced drive 1

[SamBvr]

I had a thread in Dell servers forum, but now it looks like this is an application issue. So here goes:
The loader was failing POST for the tape drive, so the tape drive was changed. Now I get errors; here is the scenario:
Load tapes, starts inventory, "E-drive hndl error" displayed. I push the loader Mode button until it gets to LDR Ready, the E goes away, after 15 seconds it starts Calibrating, all is well until the next tape is loaded. I have received an E6092 error. It will feed, erase a tape and do backups , but the E is displayed with Calibrate and the Red alert light flashes on the loader the entire time.
I am being told by an HP tech that AS is not discovering the new drive. The drive was a Compaq 35/70 DLT LDRV replaced by a DEC TZ89. When I run AS9 Manager, Devices etc. the drive is still displayed as the Compaq. The DEC shows in the list of devices on the server console.
AS9 Real-Time Statistics shows it as the Compaq.
SCSI ID-LUN: 3- 0
Vendor: COMPAQ
Product: 35/70GB DLT LDRV
Revision: 296D
HP said I needed to reload AS9, I have checked every .ini, .ncf and other files on the server I can get to. This library backs up 10 servers and I don't want to have to redo all the scheduling. Any HELP will be greatly appreciated for sure! ~ Sam

 

[vschumpy]

All drives in the library need to return EXACTLY the same SCSI INQUIRY string, else ARCserve will not be able to handle them as part of the library configuration together.

If your hardware vendor replaced a drive with one of a different type (even if it is only a small difference in SCSI Inquiry), then they should be addressing this issue. There is nothing ARCserve can do to address this - as far as ARCserve is concerned it is a completely different drive type.

If it is this, it's probably no more difficult to address than a drive firmware flash, but very sloppy if the hardware vendor left site without checking this in the first place.

Some more detailed advice on troubleshooting tape drive and library issues, re-running device configuration, and tracking down the problem can be found in this comprehensive document:

http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=TEC342813

Also, the library itself should not still be erroring on it's own inventory process, this has nothing to do with ARCserve.