I'm sure there are many ways to organize and use TSM Policy Domains, and I look forward to seeing the responses to your inquiry. Here at Cornell, we make heavy use of Policy Domains as you are thinking of doing - along organizational lines. Each department here who makes any significant use of TSM is given their own Policy Domain. This allows us to change the default management class, and provide any number of management classes or schedules that are customized to suit their requirements.
One thing that we did that I think worked out well is that we tried to keep the default STANDARD Policy Domain as simple as possible. If a single user from a new department came along, we just put them into the STANDARD domain. If, later, they requested specialized requirements, at that time we would move them into their own policy domain and change the management classes in their private domain. Similarly, if that department later added additional systems to be managed by TSM, we would at that time move them into their own private domain. To create their private domain, we would simply use the COPY DOMAIN and COPY SCHEDULE commands. This all works, so long as you ensure that the STANDARD domain is always a proper subset of all your other domains. This makes it safe to move a node out of STANDARD and into a new domain. Otherwise, you risk orphaning the management class that an existing file is associated with (i.e., the new domain doesn't have the same management class that the old domain had). One other caution is that before you move the node to a new domain, check which schedule it is associated with, because the act of moving a node to a new domain will break all schedule associations. One other thing I've noticed over the years, related to management class definitions. We started out defining management classes according to their attributes. E.g., name "1YEAR" was used for an archive management class that had a 1 year retention. This works for the most part, but now and then we get a large archive user who starts out using a management class, only to later want to change the retention. It's not easy to change the retention of files that are already archived. But - if all the files whose retention you want to change are all using the same management class, and none other are, then you can simply change the definition of the management class. For example, if you want to have a common management class for all logfiles, choose a name called "LOGFILES". Then you can change the name of that management class to change the backup/archive policy for all logfiles, without worrying about what other uses it might have. It's much less likely that you will want to change the definition of a management class named "1YEAR" to mean that files have a 2 year retention period! I look forward to seeing what others' experiences are.. ..Paul At 04:32 PM 8/14/2007, Keith Arbogast wrote:
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?
-- Paul Zarnowski Ph: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED]
