Backup Failures & Test Unit Ready, TUR, Plug and Play Autorun Disable
Let me start by clarifying what the issue is and later go into how it is resolved.
We all like it when our devices appear in the device manager. Windows accomplishes this with Plug and Play. One of the commands Plug and Play sends to a device is the SCSI, TUR, Test Unit Ready command. If TUR is sent to a tape drive during a backup operation, that operation may be interrupted or in the least delayed. This typically results in several issues, poor backup performance, tape not streaming, hardware compression reduction, Not appendable (End marker unreadable) issues, tape drives needing to be cleaned, tapes identified as cleaning tapes and even SAN fibre port failures.
You ask, “How can all these seemingly disparate symptoms all be caused by the TUR request?”. The answer is that a single TUR should not cause any issue; however under certain conditions TUR signals can be spammed to the tape device. Eventually degrading the tape device’s ability to respond to data requests and even flood the port the tape device is attached to. Since TUR is a SCSI command it occurs on ALL tape devices, regular SCSI, SAS & even Fibre, because even though your tape may be connected via FCOE it is essentially still a SCSI device. So even locally attached tape devices can be affected. These conditions are of course compounded when a tape device is network or SAN attached and accessible by multiple hosts.
So whose fault is this anyway? Well the SCSI TUR command can be issued by the Operating System or the application. This means that Linux, MacOS, and Windows could send the command. It also means that Symantec Backup Exec or Net Backup could also send the TUR command.
I run backups which drive over twenty tape devices every night. In this example we will limit our discussion to Windows 2003, Windows 2008 R2 and Symantec Backup Exec 2012. As referenced in Microsoft KB 842411, Plug and Play can be disabled to prevent it from sending SCSI TUR commands to the tape drive. Our elation however is only fleeting when we find out that the registry entry which we have so carefully crafted is gone! Gone you ask? How? It must be an OS flaw? No, despite our due diligence in using Symantec supplied drivers we have not protected ourselves from the backup software or, as is in this case, the application which helps us maintain our drivers, the Symantec tapeinst.exe program. In some cases, the tapeinst.exe program will remove the autorun registry entry. I will leave that analysis up to Symantec to determine when and why that is.
Is it sufficient to say that we have a solution to our TUR / Backup issues? Simply set the autorun registry value to zero? No, we need to rely on our software partners, to whom we are valued customers to assist us and ensure that our environments remain stable. This is or at least was the way it should be. This is or was what was stated by Veritas and now Symantec in the tech article, TECH32254. Alas, this is not how it is in the real world.
Only time will tell if this issue will be resolved. It has already existed for several years. Let’s see if Symantec likes my “Idea” and fixes this bug. I can only request that the “Idea” not be locked from additional comments like the others have and a true response from the customer community be given. Or, like others, will I become numb to the issue and just click the .reg file I created yet another time.
OH, BTW LOL LOL let’s just create a scheduled task, THAT’S a GREAT IDEA!!!