We are now up to 6 primary TSM instances (as opposed to special purpose
instances). We try and keep
the policy sets setup the same so we can move nodes between them as needed.
This wasn't bad
when there was only a couple instances, but it's getting more of a issue
with 6 instances. For example,
As a matter of fact there is. TSM provides Enterprise Configuration
functionality, where you define one system as a configuration server and
subscribed other systems to profiles on the configuration server. We've
been using it with TSM 5 and 6 servers without any trouble, and it's
available
in sync across multiple TSM
servers
We are now up to 6 primary TSM instances (as opposed to special purpose
instances). We try and keep
the policy sets setup the same so we can move nodes between them as
needed.
This wasn't bad
when there was only a couple instances, but it's getting more
] On Behalf Of
Richard Rhodes
Sent: Thursday, January 14, 2010 12:58 PM
To: ADSM-L@vm.marist.edu
Subject: [ADSM-L] Keeping mgt classes in sync across multiple TSM servers
We are now up to 6 primary TSM instances (as opposed to special purpose
instances). We try and keep
the policy sets setup the same
Correct me if I'm wrong here, but I seem to recall that you could not replicate
domain/policy/mgmtclass from a configuration manager if there were nodes
assigned to the domain on the target (client) system.
Which made it pretty inconvenient.
I've used server-server export policy to achieve the
That's true if there is a locally-managed domain of the same name on the
node. If the domain is managed by the config server you can update
without trouble. I've gotten around the problem like this though:
1. COPY DOMAIN foo localfoo
2. UPDATE NODE * WHEREDOM=foo DOM=localfoo
3. DELETE DOMAIN
