I inherited two TSM servers whose Policy Domains were named for
client operating systems (AIX and NT) and the enterprise database
(Oracle). When the TSM servers were originally built they were used
exclusively to backup clients belonging to the technical team that
maintained TSM. So, those Policy Domains suited their purposes.
Now, management thinking has changed. TSM administration has been
moved to the infrastructure team, and has been charged with providing
backup services to a much larger customer set; related teams, other
divisions in the IT department, and to departments on campus.
We are building a new TSM server to suit the new mission, and are
thinking of naming policy domains with team and department acronyms
instead of operating system names. The purpose would be to sort
access authorities, backup schedules and retention parameters along
There may be more suitable or more helpful organizing concepts. We
would be glad to know them.
How do other TSM admins organize their domains and policy sets
conceptually? What does a TSM policy domain correspond to in real
life? Is it a customer department, a client OS, the production/test
status of the client, a set of retention parameters? How can the
hierarchy of policy domain, policy set, management class be
implemented so that it is the most helpful in managing a large set of
clients with diverse owners, retention demands and backup schedules?
With my thanks,