Local Disks now Showing up as Cluster Disks

[rtiebout]

The physical nodes of our cluster just started reporting that they couldn't backup the local disks anymore. After looking into it the dsmerror logs show that the disks are now seen as \\clustername\c$ and are cluster disks and can't back them up with the clusternode option set to yes. those same disks used to be \\hostname\c$ and were backing up just fine for a long time.
What has changed? i've upgraded the client versions and am now running 5.5.1.16
I can get the backups to run if i set the physical nodes dsm.opt option for being a clusternode but then all of the filespaces will be named incorrectly. Any help would be greatly appreciated.

Thanks.

[Eldoraan]

I would assume someone shared the C: out via SMB and now the client sees it as a shared resource on cluster. Do you use domain statements in your dsm.opt files? It's best to lock down Windows cluster configs so that a "E:\TSM\dsm.opt" file on a cluster resource with E: as member only backs up the E: drive. So "Domain E:" in that dsm.opt file will tell TSM to only backup the E: drive and nothing else.

[JohanW]

What was your previous client version? If it was old enough, the configuration may have to be done again, including the cluster service configuration (you do have the CAD, scheduler &c. configured as cluster resources, don't you?), because the location for certain things in the registry has changed.

Check the appropriate version of the manual for cluster configuration, esp. the Registry Replication, and check everything.

[JohanW]

.. Do you use domain statements in your dsm.opt files? It's best to lock down Windows cluster configs so that a "E:\TSM\dsm.opt" file on a cluster resource with E: as member only backs up the E: drive. So "Domain E:" in that dsm.opt file will tell TSM to only backup the E: drive and nothing else.

That's normal in a cluster, and I can only hope everyone already has it configured that way.

I would assume someone shared the C: out via SMB and now the client sees it as a shared resource on cluster ..

And this is absolutely NOT normal, and I should hope nobody does this.

OP, if so, please let us know. I'm not about to test for this effect myself ..

[rtiebout]

We do use the DOMAIN statement to make sure that the cluster resources only back up their own drives.
I'll check on the sharing of the local drives but other than the default admin shares there shouldn't have been any other cluster shares created for those drives.
My previous client version was 5.3.0.5 What is the best way to upgrade the tsm clients? cluster or otherwise. Should i uninstall the client then install the new one? Which registry locations have changed?

[JohanW]

No need to uninstall, as far as I've found. Changes for all versions are documented here.

Technical changes for Version 5.4 - January 2007

The following changes have been made to the product for this edition:

Registry format and location changes
The format of the Tivoli Storage Manager passwords stored in the Windows Registry and the registry location where passwords are stored has changed. Your existing registry keys will be migrated to the new format during the first session with a Tivoli Storage Manager server after you install the client. See Upgrade path for clients and servers, Step 4: Creating a generic service resource for failover and Step 5: Creating a generic service resource for failover for more information about the changes.

This may or may not affect cluster resources, so give it a gander.

[rtiebout]

After speaking with TSM support and searching the web we came up with a Microsoft HotFix that seemed to fit this issue. And after applying the hotfix the local disks are now seen by TSM as beeing local to the system and no longer cluster disks.
Here is the microsoft hotfix page: http://support.microsoft.com/kb/928385
Thanks for all the help.