Part one of this four-part series gave you a crash course in the Removable Storage Manager (RSM). Part two showed you how you could write a simple script that would identify the tape in your tape drive, then eject that tape by referencing the tape's GUID. Here in part three, I will build on that technique and show you how to bridge the gap between the RSM and the NTBACKUP program in Windows Server 2003. Part four will show you the commands to invoke NTBACKUP.
Part two showed you how to use the following two lines of code to identify a tape's GUID and assign the tape's GUID to the variable X. As you may recall, the first line in the script hard-codes the tape drive's GUID.
In part two, it was enough to simply identify the tape's GUID because all we were doing was ejecting the tape. But if you're going to be writing data to the tape, just knowing the tape's GUID may not be enough. A physical tape formatted for use with NTBACKUP will usually contain one or more partitions, and a partition will contain one or more pieces of logical media. When you automate NTBACKUP so it can interact with the RSM, you must usually direct NTBACKUP to write data to a specific piece of logical media, not to the tape itself. Since your script will have to reference each piece of logical media by its GUID, you will have to write some code to derive the GUID prior to executing a backup.
The process of determining the GUID for logical media is similar to finding the GUID for physical media. Simply remember the hierarchical nature of tapes: Physical tapes contain partitions, which contain logical media. You already have the code to get the GUID for the physical tape; you can use that to get the GUID for a partition. You can then use the partition's GUID to get the GUID of the logica...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
l media.
To make the code work, you must understand the lines of code displayed above. If you don't understand what those lines of code do, you should review part two before continuing. With that said, here are a few more lines of code that you can use to derive a tape's partition GUID and its logical media GUID:
Notice I have added the line @echo off to the beginning of this block of code. This line makes the output a bit cleaner and prevents the operating system from displaying redundant information as the code runs. The second line of code is the same line we were already using to hard-code our tape drive's GUID.
The three lines following @echo off actually derive the GUIDs. The third line in the script gets the physical tape's GUID and assigns it to the variable TAPEGUID. As part two explained, the %drvguid% portion of the command fills in the GUID of the tape drive. The /guiddisplay switch tells the command that you want the GUID of the specified object (in this case, the physical media, specified by the tphysical_media parameter). The /b switch tells the line not to display anything other than the GUID. (Of course, we are not actually displaying the GUID, but rather assigning it to a variable.)
The fourth line works in the same way, except this time we are asking for the partition GUID. (We used the /tpartition object instead of the tphysical_media object.) Likewise, this command required us to tell it which tape we want the partition off of, so we are referencing the %tapeguid% variable as a way of giving the command the GUID of the physical tape that we want partition information for. When the command executes, the partition's GUID will be assigned to the variable PARTGUID.
The last line of the script works the same way as the previous two lines except that this time we are getting the logical media GUID (notice the /tlogicalmedia switch) by referencing the partition GUID. When the command executes, the logical media's GUID will be assigned to the variable LOGGUID.
As I explained earlier, when you script a backup operation, NTBackup expects you to supply the logical media GUID for the tape. We now have the logical media GUID assigned to a variable.
Unfortunately, the logical media GUID is not in a usable format. As you may have noticed, the RSM works with GUIDs as a continuous 32-character hexadecimal string. The problem is that NTBackup can't accept a GUID in this format. NTBackup expects the GUID to be hyphenated with eight characters, a dash, four characters, a dash, four more characters, a dash, another four characters, a dash and 12 characters. Therefore, we need to parse the logical media GUID in a way that will insert hyphens into the correct positions. You can accomplish this by appending the following lines of code to the end of the script:
The first five lines of code in this block break down the logical media GUID (which was assigned to the LOGGUID variable) into five smaller chunks. Notice that each of these lines ends with two numbers. The first number tells the operating system what position to start in; the second tells it how many characters to capture. The captured characters are then assigned to a variable (part1, part2, etc.).
For example, in the first line in this block of code, the numbers used are zero and eight. The zero indicates that the operation should start at the beginning of the string. The eight indicates that the first eight characters after the starting point should be captured. If you recall the format of a GUID, there are eight characters before the first hyphen. After the first hyphen, there are four characters before the second hyphen. If you look at the second line of code in this block, you will see that it starts at position eight, captures four characters and assigns those characters to a variable named part2.
The last line in this block of code puts all of the pieces together. I have created a variable named BKUPGUID that is a combination of part1, a hyphen, part2, a hyphen, part3, a hyphen, part4, a hyphen and part5. This is the variable that we will be using to provide NTBackup with a GUID in part four of this series.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He currently writes for SearchWinComputing.com as well as other TechTarget sites.
