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 organizational lines. 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, Keith Arbogast Indiana University
