IBM response to NT cluster question:

>Anybody running the ADSM client on an NT cluster? I would like the shared
>filesystem to be backed up by the active node by declaring an ADSM node
>responsible solely for the shared filesystem. The plan is to have the
>scheduler service activated on failover etc by MSCS. If anybody can answer
>the questions below it would help me get this going quickly.

>1. Does the 'domain' statement respect the d: notation still?
>2. If I do connect as the same node from each of the machines will the
>shared filesystem be seen as two different ones now UNC naming is in
place?
>I.E. \\machine1\d$ and \\machine2\d$ when I would really need it to be
seen
>as the same by the ADSM server.

IBM's recommendation is to configure ADSM locally on both nodes of the
cluster to take care of the local drives, and configure a third instance of
the ADSM client to handle the shared resources.

The local instances of the dsm.opt file need to be coded with a DOMAIN
statement explicitly listed the local drives (DOMAIN ALL-LOCAL will not
work correctly because it will also process any cluster drives currently
owned by the resource):

NODENAME  local_machine_name  (this is the default if NODENAME is not
coded)
DOMAIN    C: D: E: ...        (all local drives explicitly coded)

This third instance of the client can be realised by coding a second option
file, e.g., cluster.opt, with the following information:

NODENAME  cluster
DOMAIN    \\cluster\q$  \\cluster\r$ ... (all shared drives explicitly
coded)

where "cluster" is the network name assigned to the cluster.

This will allow the ADSM server to manage the shared data separately from
the local data, and since the client is using the UNC name to access the
drives instead of the drive letter, the filespace name at the server will
be independent of which physical node initiates the shared-resource backup.
This set-up requires the UNC support introduced in ADSM client PTF 5.

If you configure this third, cluster instance of the client as a service,
be sure that the service "Log On As" is set to with the authority a domain
administrator account, as the local system account (default for service)
does not have the proper authority to backup the shared, cluster drives.

>3. Can the registry entry containing the encrypted ADSM password be simply
>copied between systems and still work? We have password expiry on in the
>server so the password may cycle on one machine and the other won't know
>about it until the scheduler fails to start on failover.

Unfortunately, this will not work at this time.  We are aware of this
limitation with the passwords and will be addressing the problem in the
future.

Jim Smith
ADSM Client Development