In July and August Walter Ridderhof and Greg Heis and Jim Sellars discussed 
backing up disks on an NT cluster.  Walter described how he had succesfully 
done this, but signed off the thread by mentioning parenthetically that he 
couldn't forsee how PTF 5 of the NT client, which implements UNC names, would 
affect things.  It appears that the elegant solution he has implemented has 
indeed been "broken" by the UNC names.

On the NT cluster on which I've installed the newest client, each of the two 
systems has a C drive, and there are a total of 4 Raid Volumes; R, S, T and X.  
The cluster name is CLU, and the nodes are NA and NB.  "Normally" R and S are 
local to NA, and T and X are local to NB.  I can "see" the UNC names of the 
drives by starting up the GUI client or by performing a DSMC QU OPT and looking 
in the "domain" section.  For example, on node NA, the local drives will be 
named \\NA\C$, \\NA\R$, and \\NA\S$.  Like Walter, I have the same nodename and 
options file for NA and NB.  But the problem is when the disks fail over to the 
other node, their UNC names change, so the ADSM server thinks we have different 
drives here.  (I've already handled the C drive on each node problem 
satisfactorily).  As the disks fail back and forth between nodes, I will end up 
with eight filespaces; R$, S$, T$ and X$ on each of \\NA\ and \\NB\.  I have 
tried lots of different DOMAIN statements and the like, to no avail.

It appears to me that the solution is to make the nodename portion of the UNC 
name become "cluster aware", so that a disk on any node in the cluster would 
have the same UNC name.

Is anybody aware of any way to "fool" the BAClient into generating the nodename 
portion of the UNC name from some string which doesn't differ across the nodes 
in the cluster?

John Sorensen
SSSI