Administering Removable Storage

Systems with a few stand-alone drives and a single Removable Storage-aware application typically require no Removable Storage administration. Systems with more complex configurations, such as those with tape or optical disk libraries or multiple Removable Storage-aware applications, do require administration, however. There are also rare cases in which a Removable Storage-aware application does require some administration on a system with a simple configuration.

Device Support

There are many drives and robotic libraries available, and not all of them can be supported. See the Microsoft Windows 2000 Hardware Compatibility List (HCL) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

Each of the supported robotic libraries has its own configuration method and options. In order for them to work correctly with Removable Storage you must configure your robotic libraries with certain settings of these options. Please consult the HCL for the proper configuration settings for all supported drives and robotic libraries.

Installing and Configuring Removable Storage-Aware Applications

Under normal circumstances, Removable Storage-aware client applications can perform any Removable Storage configuration or setup that they need at the time they are installed. If such an application requires an application media pool, for example, then the pool needs to be created when the application is installed and the permissions need to be set accordingly at that time.

Some applications use their own format or labeling scheme. In order for Removable Storage to correctly process OMIDs on the sides written by these applications, it needs a special dynamic-link library (DLL) that can read the label and determine the OMID. Such a DLL is called a media label library (MLL), and client applications that use them must install them.

Preparing Media

Most applications draw available media from the free pool. Placing media in the free pool is also called "preparing" the media, and must be done either by a Removable Storage-aware application or by an administrator. If your Removable Storage-aware applications do not automatically prepare media, you might have to use the Removable Storage snap-in. You can prepare media in the unrecognized pool, and you can prepare media in the import pool if you are certain that the media contains no useful data. Available media in application pools can also be prepared, but Removable Storage does not prepare allocated media.

To prepare a tape, for example, in the Removable Storage snap-in, right-click the media in the details pane, and then click Prepare.

Using Operator Requests in Removable Storage

A Removable Storage operator request is a request for an administrator to perform a task. Operator requests can be issued by Removable Storage or by Removable Storage client applications. Removable Storage generates operator requests in the following situations:

• Media must be moved online because an application has initiated a mount request for a medium that is offline.
• There are no available media online. An application has asked for available media and there are none online in the specified application media pool or the appropriate free media pool. The administrator can supply new media or available media that is offline to satisfy the request.
• A device failed and requires service.
• A drive needs to be cleaned and there is no usable cleaner cartridge available in the library unit.

Operator requests are displayed in the Removable Storage snap-in. Administrators can satisfy or cancel operator requests. After satisfying an operator request, the administrator must acknowledge the request in the Removable Storage snap-in. When an administrator cancels an operator request, Removable Storage notifies the application that generated the request. Removable Storage saves operator requests for less than one hour after they have been satisfied or canceled.

Security

Removable Storage provides security for itself, media pools, and libraries. It contains an access control list (ACL) that controls who can connect to the service and who can work with operator requests. To edit this ACL, right-click the root node in the Removable Storage snap-in. Each library has an ACL that governs who can perform specific tasks, and each pool also contains an ACL. Table 2.6 describes what permissions are required for specific snap-in operations.

Table 2.6 Permissions Required For Removable Storage Snap-in Operations

Controlling the Service

Removable Storage is configured in Windows 2000 to start automatically when you start your computer. It is possible to change the service to be manually started, but this is highly discouraged. Disabling the service breaks several applications that are included with Windows 2000, such as Backup and Remote Storage.

As with other Windows 2000 services, Removable Storage can be stopped, started, and restarted by means of the service control manager.

Service Startup Tasks

Removable Storage performs several tasks when it starts. During some of these tasks Removable Storage is unavailable to administrators and client applications. At other times during startup it can accept requests; however, execution might be delayed while Removable Storage completes this initialization. The following steps outline the process performed by Removable Storage during startup:

Note

It is important to note that the process is the same whether Removable Storage is starting after a system start or simply restarted while the system is running.

1. Cancel all work items that are still in queue from the last time the service ran.
2. Configure libraries, including associating drives with changers and identifying stand-alone drives.
3. Inventory the contents of each library. Removable Storage performs an inventory in each library according to its set default. At this point Removable Storage determines which slots have media and which media need identification. It also empties the drives, if possible. If the drives are currently in use, Removable Storage leaves the media in the drive and examines the media in the drive at a later time.
4. Start accepting requests from applications.
5. Complete the default inventory work, identifying media as needed.

Device Configuration

Because Removable Storage manages removable media devices, it relies on Plug and Play to tell it which devices are attached to a system, but Removable Storage must match drives with robotic libraries. If Plug and Play indicates that a robotic library is attached to a system, Removable Storage must go through the list of drives that are also attached and detect which ones are actually inside the robotic library and which are stand-alone drive libraries. If certain rules are followed, Removable Storage can do this mapping entirely on its own. If these rules cannot be followed, you must manually map drives to robotic libraries.

Auto-Configuration

Removable Storage auto-configures robotic libraries if the following are true:

• Robotic library hardware units support drive element address reporting with the ReadElementStatus SCSI command. Consult the manufacturer to find out if your library hardware unit supports this feature.
• All drives inside a robotic library are on the same SCSI bus as the library.

Manual Configuration

Because not all library hardware units and system configurations support the Removable Storage auto-configuration feature, Removable Storage provides a method for manually configuring library hardware units. However, only use this method when it is necessary, because Removable Storage cannot detect manually configured changes. In general, manually configure Removable Storage only when it detects a robotic library that it cannot configure. After it is set for manual configuration, a changer does not participate in auto-configuration even if its configuration is changed.

In most cases, Removable Storage starts auto-configuration after hardware is installed, moved, or removed. This happens automatically when you restart after adding the device. For changers that cannot be auto-configured, Removable Storage adds incomplete registry entries and generates an operator request to manually configure such changers. The following procedure can be used to manually configure Removable Storage.

To manually configure Removable Storage

You must complete all of the following steps to manually configure Removable Storage:

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

1. Stop Removable Storage.
2. Back up the Removable Storage database by copying the files in %SystemRoot%\System32\ntmsdata\ to a secure temporary directory.
3. Restart Removable Storage. Note all the drives that appear as stand-alone drive libraries. Removable Storage displays all drives that are not mapped to a changer as stand-alone drive libraries, including ones that are actually in the changer but are unmapped.
4. Empty all drives on your system.
5. Place a medium in a drive in the library you are trying to configure, either by opening the library door or through a front panel and IE port (see your changer's documentation for details about how to do this). Click Refresh in the snap-in for each of the stand-alone drives, and then find the one that now shows that it has media in it. Open the property sheet for that drive and note the device name on the Device Info property page. Complete this step for each drive in the changer that you are trying to configure.
6. From the Start menu, click Run, type regedt32.exe or regedit.exe, and then click OK.
7. In the Removable Storage configuration information in the registry subkey HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtmsSvc
   \Config, create a REG_DWORD entry called AutoCfg and set the value to 0.
8. Stop Removable Storage.
9. In the registry editor, navigate to HKEY_LOCAL_MACHINE\System
   \CurrentControlSet\Services\NtmsSvc\Config. The Config subkey contains a subkey for each changer (such as Changer0) and a subkey for each stand-alone drive. Each changer subkey contains an entry for each drive bay in the changer, such as DriveBay0.
10. For each drive bay entry that has the value "???", replace that value with the device name (without any initial "\" or "." characters, such as "Tape3") of the drive in that bay.
11. Close the registry editor.
12. Restart Removable Storage. Removable Storage reads the new configuration information and initializes the devices.
13. Using the snap-in, mount a medium in each drive in the library after Removable Storage is initialized. If any of the configurations are incorrect, Removable Storage generates an error message either during initialization or the mount.
14. If the manual configuration was unsuccessful, stop the Removable Storage process. Copy your backup version of the Removable Storage database files back to the %SystemRoot%\System32\ntmsdata\ directory to restore the database and restart the manual configuration process.

If Removable Storage does not generate any error messages, the manual configuration was successful, and you have completed the manual configuration process.

Database Backup and Recovery

Removable Storage stores its catalog of media in a database on disk. While Removable Storage can recover some of the information by inventorying the attached libraries, all of the application-oriented information might be lost if the database is lost. For this reason, the Removable Storage database must be backed up regularly. For more information about backing up the Removable Storage database, see "Backup" in this book.

Maintaining a Consistent Database

The default location for the Removable Storage database is %SystemRoot%\System32\ntmsdata, which normally contains four files and a folder. Unless you change the location where the database is stored Backup takes the proper steps to create a consistent backup of the database when ntmsdata is selected for backup.

If you decide to move the database or if you do not use Backup, you are responsible for ensuring that you get a consistent database when you do a backup.

Important

The backup application that you use is responsible for backing up Removable Storage. If you do not use Backup, which is part of Windows 2000, and you do use Removable Storage, verify that the backup application backs up Removable Storage.

The database must be internally consistent to produce a backup that can be restored successfully. There are two ways of doing this: shutting down Removable Storage and exporting the database. The latter is what Backup does if you have not changed the location of the Removable Storage database and you select ntmsdata. If you can shut down Removable Storage while backing up the database, your backup operation can simply make copies of the database files themselves. If shutting down the service is not an option (for example, because a Removable Storage–aware application must remain running), you must provide a way for Removable Storage to export a consistent copy of the database for backup. You can also create a small Removable Storage–aware application that calls the ExportNtmsDatabase API. For more information about this API and about writing Removable Storage–aware applications, see the Microsoft Platform Software Development Kit (SDK) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

Tracking the Backup Media

The administrator must always know the location of the most recent Removable Storage database backup. To help identify the backup during disaster recovery, the administrator needs to record and maintain the medium display name and the on-media identifier in a safe place.

You might need this information to help the backup application identify the media from which to restore the database. You can get the display name from the property page for the medium, and the on-media identifier from the property page on the property sheet for the medium side.

Recovering the Database Files

Note

The information in this section assumes that there has been no change to the system configuration that affects Removable Storage since the backup was made.

To allow the recovery application to access media, it must be mounted in a drive. If you are going to restore the database using Backup, then Removable Storage must be running and you can use Removable Storage to mount the media, but without the full database you'll have to get Removable Storage running with enough of a database to mount the database backup tape for Backup. To do this, delete any files that might be in ntmsdata and start Removable Storage. Removable Storage then inventories each of the libraries attached to the system.

Tip

For large libraries, this might take hours. To minimize the time for this process, perform standard backups often.

Tapes made with Backup show up in the import pool. Start Backup and have it move these tapes to its own application pool. Select the ntmsdata directory and start a restore process. Backup will store the database files and set Removable Storage to run on the recovered database after the next service restart.

If you are not using Backup, you need to use other means to mount the media, restore the files, and recover the database. Most libraries have doors or front panels that you can use to mount media manually. Next, copy or restore the database files to disk. If Removable Storage is not running, you can copy the database files to a directory that holds the Removable Storage database (%SystemRoot%\system32\ntmsdata is the default directory). Then start Removable Storage. If you must have Removable Storage running while you are restoring the database files, copy or restore the database files to the directory \Export, which is a subdirectory of the one that contains the database, and run a utility that calls ImportNtmsDatabase. For more information about creating this utility, see the Microsoft Platform Software Development Kit (SDK) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. For more information about recovering Removable Storage, see "Repair, Recovery, and Restore" in this book.

Updating the Restored Database

The recovered database might not be synchronized with the state of media when the database was lost. Table 2.7 describes some reasons why the Removable Storage database might not be synchronized and how Removable Storage-aware applications can resolve each problem.

Table 2.7 Synchronizing Restored Database Files

Note

An application can recover the Removable Storage database when it has been lost,there is no backup copy, and the application has not lost the database that refers to the lost Removable Storage database. This process requires significant knowledge on the part of the administrator of the application.

Using the Removable Storage Snap-in

The Removable Storage snap-in allows you to perform several tasks. The snap-in can be found beneath the storage node in the Computer Management snap-in. It can also be started directly from the command line, by running Ntmsmgr.msc.

Inserting and Ejecting Media

Removable Storage uses a library's IE port, if it has one, for inserting and ejecting media, or it uses the door. Selecting an insert task on a library with a door but no IE port results in the same behavior as if you selected a door access.

When using a door access to enter or remove media, make sure that you consult the property page for the library and the document for the changer to determine the proper slot numbers. Most changers label each slot clearly, but some do not.

Caution

If during a door access you exchange media in libraries without bar codes, you need to run a full inventory after completing the door access. The change is not detected by a fast inventory and an identity mismatch occurs the next time media in the slot is mounted.

Tables 2.8, 2.9, and 2.10 show the results of moving CD media, tape media, and optical/rewritable media among media pools.

Note

Because CD media are read-only, Removable Storage does not allow each medium to be placed in the free pool.

CD media appear in the unrecognized pool only if they are formatted with a file system that Windows 2000 does not recognize.

Table 2.8 Moving CD Media Among Media Pools

Table 2.9 Moving Tape Media Among Media Pools

Table 2.10 Moving Optical/Rewritable Media Among Media Pools

Inventories

There are two types of inventories, fast and full. You can set which is to be used as the default inventory method in the Library property page in the Removable Storage snap-in.

A fast inventory only checks for slot state changes between full and empty. If the Removable Storage database indicates that a slot has a cartridge in it, but the fast inventory shows that it no longer has a cartridge, Removable Storage marks the cartridge that was in the slot as offline. If a slot was empty and is now full, Removable Storage identifies the cartridge in the slot. Slots that remain full are assumed to contain the same cartridge. Full inventory actually identifies each medium. This can take a while, unless the media has bar code labels. A full inventory of bar code–labeled media only reads the bar codes. Full inventories of media that are not bar coded read the on-media identifier on each medium in the library.

Cleaning Drives

Some drives, especially tape drives, require periodic cleaning. Usually there is a light on the front of the drive that indicates that a drive is dirty, and in this state most I/O operations fail. Under most circumstances a drive detects that it is dirty while a Removable Storage client application is running. How the client application handles this situation is typically described in the documentation for that application, but for some changers Removable Storage can automatically clean the drive for you after the application is finished using the drive.

In the Removable Storage model of device maintenance, each library unit can contain one cleaner cartridge. There is a wizard available through the snap-in, which you can use to insert a cleaning cartridge into each library that supports automatic cleaning.

Removable Storage maintains a usage count for each cleaner cartridge. When a cleaner reaches its maximum usage count, Removable Storage generates an operator request. If the administrator ejects a cleaner cartridge before it has reached its maximum usage count, Removable Storage displays the usage count information.

Caution

Problems occur if Removable Storage attempts to identify a cleaning cartridge as a regular medium. Most drives treat cleaning cartridges differently from regular media, and this different behavior can result in Removable Storage error messages that might appear as if Removable Storage or the library is malfunctioning. Never start Removable Storage for the first time with a cleaning cartridge in the library, or attach a new library with a cleaning cartridge inside. In both these cases Removable Storage performs a full inventory of the library, which includes trying to identify each cartridge. In addition, never insert a cleaning cartridge using the same mechanism used for ordinary media. If there is any doubt about the Removable Storage database's consistency, please remove the cleaning cartridges from the attached libraries. These problems might appear if the database becomes inconsistent or is restored from an old backup.

Work Queue Items

You can use the property page about the work queue item to control how long completed and failed work queue items are retained. If you are having problems you might set the work queue to retain failed items so that you can investigate. The property page for each failed item shows the reason that it failed.

On startup you might see a number of canceled work queue items. When Removable Storage is shut down there might be work queue items still queued. These are canceled the next time Removable Storage starts up.

Operator Requests

Use the property page on the root node of the Removable Storage snap-in to set a method to receive notification of outstanding operator requests. The two available methods are Windows 2000 Messenger Service and a system tray icon. When the messenger service is selected, an application message appears whenever there is an operator request. Make sure that the Messenger Service is running if this option is selected, and then start the Removable Storage snap-in to view the operator request queue and determine what Removable Storage is asking you to do.

If the system tray method is selected, a system tray icon appears whenever there is an outstanding operator request. Clicking on the system tray icon displays a snap-in of operator requests, making it easier to mark them refused or complete. All operator requests must be completed or refused.

The property page of the operator request node in the Removable Storage snap-in lets you set how long to retain completed and failed (including canceled) operator requests. It also provides buttons that can be used to process deleted, completed, and failed operator requests immediately. The Default button deletes all requests specified by the controls on the properties sheet, while the Delete all now button deletes all completed and failed requests.

Library and Drive States

A library is online while it is operating and connected to the computer that is running Removable Storage. A library is not present if it is not operating or if it is disconnected from the computer. Both robotic and stand-alone libraries can be either online or not present. If a library is removed, the administrator must manually delete the library from Removable Storage. Removable Storage does not automatically delete libraries to avoid deleting information that might still be valuable if the library was disconnected inadvertently or temporarily.

Drives in offline libraries are offline, but media in offline libraries are considered online since they reside in a library. Offline media physical locations, then, are different from offline libraries.

Scripting

You can create command scripts to perform routine or automated activities using the Removable Storage command-line program Rsm.exe. You can use this program to have Removable Storage perform a number of activities, such as ejecting tapes, creating medial pools and so on.

Troubleshooting

Problems with Removable Storage can be caused by hardware or software. The information required to help you resolve either type of problem is contained in the following paragraphs.

Configuration

If you are having problems with Removable Storage correctly configuring your devices, please consult the HCL to make sure your device is supported. If it is, make sure you have configured the device according to the guidelines listed for your device on the HCL. Many changers support many operational configurations, while Removable Storage requires certain settings of these configurations.

Make sure that the hardware is configured correctly. If the device is attached to the host by means of a SCSI bus, ensure that the bus is configured correctly, with no SCSI ID collisions, with proper termination and in accordance with all cable length and SCSI controller parameters, and so on. IDE devices need to be properly configured as master or slave devices and the like.

If all the hardware is configured properly, make sure that Windows 2000 has found the devices and loaded the drivers for them. Make sure you should see your changer under Media Changers in the Device Manager, and any drives under Disk drives or Tape drives. If a driver is loaded, check the system Event Log to see if the driver encountered an error while initializing the device.

If all the devices are working properly, but Removable Storage is still unable to configure them automatically, try manually configuring the devices.

Operation

If you are getting failed work queue items, the property sheet gives a reason for the failure, which can help you diagnose the problem.

If your library is configured correctly but begins malfunctioning, the first place to look for the cause is the system log. Look for Removable Storage messages, but also look for change, drive, and controller error messages. If these devices are experiencing errors, take appropriate actions to clear the errors, such as power cycling or resetting the device.

Operations can begin failing if the system runs low on system resources, such as memory and disk space. You can determine if this is the case by checking the system Event Log.

If the devices and the rest of the system appear to be operating normally, stopping and restarting Removable Storage might clear problems.

If media that are associated with client applications known to Removable Storage are always placed in the unrecognized pool when inserted, or mount requests fail because of an OMID mismatch, the MLL might be missing or installed incorrectly. Information about MLLs is contained in the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
\NTMS\OMID\Tape.

Typically, the directory %SystemRoot%\System32 contains all media label library DLLs and is accessible only by administrators.

© 1985-2000 Microsoft Corporation. All rights reserved.