I'm seeing quite a few other people with this issue, and no response from Symantec on a solution or resolution. My experience with Backup Exec 2012 thus far has been analagous to pouring salt in a gaping wound, and this just may be the final straw for me. This is after getting through a completely blown upgrade from 2010 that I did according to Symantec's "Knowledge" Base. Then a clean re-install of 2012 and recreation of all my jobs (one per stinking server now). Then, the reconfiguration of all my B2D folders because 2012 uses a new format, and the old format is only read-only. Don't like it, paying customer? Tough! Oh, and the new Windows Agents? Yeah, they crash all the time.
I'm using a SAS - attached Quantum SuperLoader 3 with a single LTO-5 HH drive. Windows 2008 R2. BE2012 has this as supported on their compatibility matrix. When I move the media around and do a scan, the "barcode" column gets updated, but not the "media label" column. Backup Exec 2012 doesn't care about the barcode column, and assumes the tape is the one in the media label column. I've done many scans, and, I've actually got it to think that the same tape is in more than one slot.
Right now, the only way I've found to get the media label column to match the barcode column is to "inventory" each slot. This is unacceptable, as it adds additional wear and tear on my autoloader, and takes for frickin' ever. Why would I have a bar code reader in my tape library if my poor excuse for backup software refuses to use it? For reference, I've been using Backup Exec since version 10, and each version up to the latest service pack of the latest release of 2010 just needed a 'scan' operation to update all the media labels. This step back is comically bad.
If anyone has solved the 'scan' bug, or knows WTH Symantec is planning on doing with it, please let me know. This is adding 2 hours a week to my backup tasks, as I have to wait for it to pick up 16 tapes and look at them, rather than a 10 second scan-and-trust-the-barcodes.
Symantec, you really need to fix your stuff, because your paying customers are pissed, and rightly so.
This is a known issue in BE 2012 http://www.symantec.com/docs/TECH202030
The best workaround that I know of is to remove the tapes that you want to remove, close the library, let the library settle, run a BE scan job, open the library, add the tapes that you want, close the library, let it settle, run a BE scan job. I know this is a pain, but this is quicker than an inventory job.
This issue doesn't occur when you remove tape OR when you add tapes, but it does occur when you CHANGE tapes (ie remove & add at the same time).
If you have empty slots in your library then a quicker workaround is that you can ADD tapes to the empty slots in the library first, then remove the tapes you want and leave empty slots, close the library and a single scan will get it right.
Thank you, that's very good to know. This makes it look even more like a bug to me. I guess we have to wait for SP1b, or something? Nothing says "rushed to market" like minor version numbers on your service packs... Anyway, additional wear and tear on the library is less onerous than what the inventory job does on the library, drive, and tapes, so I'll use your workaround in the future. Thanks for the help!