Re: [ADSM-L] A few questions about managing multiple Spectrum Protect se

A few things that could cause issues:

1) At-Risk status is stored as a node attribute on the server in question. So having two OC's manage a node will lead to conflicting At-Risk assignments.
2) At-Risk intervals are also stored as a server attribute on each server. Same issue as above

It all depends on what you're looking to accomplish. For my own part, it'd be nice to have all my TSM servers at all the our locations visible on the 'main' OC. It's also nice for all my site IT staff to only see their own TSM servers, which is why they all have their own OC installs. They typically don't mess with OC settings because they use it as a dashboard service only. This means that I'm probably OK to merge all my site TSM servers into the main OC without much fuss, since while the site admins could change server settings such as 'At Risk' and alert intervals, they're exceedingly unlikely to do so.

This is based quite a bit on a trust level that exists in our organization that is not applicable everywhere.

What IBM really needs to do is institute some level of role-based authentication and control. One OC install should be able to service a main office/branch model, where certain staff only have interest/rights to see certain TSM workloads.

__________________________

Matthew McGeary
Technical Specialist - Infrastructure
PotashCorp
T: (306) 933-8921
www.potashcorp.com

From: Evan Dunn <edunn AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: 09/09/2015 02:24 PM
Subject: Re: [ADSM-L] A few questions about managing multiple Spectrum Protect servers with the Operations Center
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

You guys are right that this is not a supported OC configuration. But, to get this to work you would want to look at configuring the OC manually (not using the Hub Configuration built in). Take a look at serverConnection.properties in (/opt/tivoli/tsm/ui/Liberty/usr/servers/guiServer/) on the OC you have setup for the main office (use the OC to configure the main office). Copy this to your spoke office, and point things to the spoke server values (note: either set the IBM-OC- admin ID to never expire on all the servers, or use the undocumented parameter SERVER_ADMIN_PASSWORD_DECRYPTED with a unique admin) Don't forget to restart the OC to pick up the changes! (service opscenter.rc restart) By doing it this way, you can use the spoke as if it was a hub, without making it a true hub. With that said -- caveats: 1) replication visibility will only work on the main office OC 2) REPL_MODE=RECEIVE nodes won't be visible (not an issue in the configuration you want), but would be an issues if replication from hub to spoke (instead of spoke to hub) 3) this is unsupported, untested 4) other stuff may or may not work (I tried it out and didn't see things explode) (I do not represent IBM or Spectrum Protect) Good luck!