If you are still running Netware, you can find out what is happening with MSHSM by looking at three Netware console windows
You can see the same information from the 'Monitor' screen on the MS-HSM GUI, and this is the Windows method of finding out what is happening. The tab contains radio buttons that let you examine the Activity/Warnings log, the Error log, the Migrations log, the Demigrations log and the Deletes log.
This is what the Monitor screen looks like:
you can also get some data from the hsm command line. You will need to open a command line window, then navigate it to the bin directory where the Managed Server HSM Engine is installed, which is usually c:\Program Files\CaminoSoft\ HSM 5.2\Bin.
you would generally switch on the command by issuing
csmcmd [command name] on
then run the command and it will write output to the activity log. When you want to stop the command you run
csmcmd [command name] off
So for example to list out files that were disqualified from migration during the scan run
cscmd track candidate failing on
and restart the CsManager service to pick up the new option, then run
cscmd track candidate failing
Then when you don't want to see these items on the activity log anymore type
cscmd track candidate failing off
and restart the CsManager service again
Other useful commands are:
To list files while they are being scanned and evaluated for migration.
cscmd track candidate marking
To list files that are being qualified for migration during the scan.
cscmd track candidate passing
To display any file that is in use.
cscmd track candidate inuse
To display any file that could not be accessed during the scan.
cscmd track candidate access denied
To track all the drives on the managed servers that are being filtered. (handy if you are running in a Microsoft Clustering environment as the activity log lists the drives Managed Server HSM Engine is able to see during its startup)
cscmd track filter drives
To discover the setting for managed nodes or drives visible to the Managed Server HSM Engine. The activity log lists the drives or nodes that Managed Server HSM is able to see during its operation.
cscmd track managed nodes
To track the SQL used to list the profile on a managed server.
cscmd track sql getprofile
If this is a Netware disk, check that it has its 'Migrate' flag which was set to 'on'.
If the 'Migrate Archived files only' box is checked then make sure the drive is getting backed up.
MSHSM will not recall any files if they are moved or the directories are re-organised. Directories can be renamed and stub files can be renamed without requiring recalls, and recalls will still work afterwards.
However, because the stub files contain the UNC name of the migrated file, the back-end migrated data cannot be relocated or renamed.
Check that your virus scan product will not try to scan migrated files. Most products have something like a 'scan migrated files' flag which should be set to 'NO'.
The stub files are critical to MSHSM operation. With Netware, Caminosoft offers two routines for managing them, a STUBCHECK facility to check the integrity of the stubs, and a STUBSAVE utility to backup and recover the stubs. They recommend that you set MS-HSM up to do this by default after every migration. The Stubcheck utility runs as an NLM and writes out results into a log file in the DATA:/MSSCRIPT/MSSTUBCK.LOG.
The Stubcheck Utility can be invoked manually by running an undocumented Netware command
MNG STUB CHECK diskname VERBOSE
Typical output looks like
Checking: FLDLINK1.CSD (31599 bytes)
Success at target: HSMSERV1/SYS:\HSM\00\00\14\6E
As far as I know, this is the only way to find out what files are migrated and the relationship between the physical location of the archived data and the stub file.
The Stubsave utility can also be run automatically or by using a Netware console command
MSSTUBV SAVE PATH data: FILE sys:/msscript/stubsave.sav FLAG /L
Stubs are recovered using the command
MSSTUBV RESTORE PATH data: FILE sys:/msscript/stubsave.sav FLAG /L
MSHSM will delete target data once the stub is purged from the Netware source disk. If you define Netware disks with purge immediate, so as soon as you delete a stub, the backend migrated data is also deleted. If you restore the stub then recall cannot work, as there is no data there to recall anymore.
It's advisable to change the Netware settings to retain purged data for a few hours to allow accidentally deleted stub files to be recovered. However even without purge immediate Netware will quickly purge stubs on a busy disk, so if a stub is accidentally deleted then it is possible that the migrated data will be lost too.