I teach our Level 1 students that having fewer domains rather than more
makes more sense.  Further, I suggest a separate domain for systems that
have vastly different retention policies for most if not all of their
data.  If you find, though, that you have a number of clients that have
lots of different sorts of data, each requiring a different retention,
then you are left with having fewer domains and more management classes.
I believe, in general, this is the way to go.  That said, it's a bit
more difficult to define the various includes to get data going to the
right place.

Most importantly I've learned the notion of KISS - Keep It Simple
Stupid.  The more of anything you have, the more complicated it is.
Well run TSM shops typically have several (less than 10) domains and
probably on the order of 30 management classes (and most of these are
repeats across the domains).  As you noted: most organizations don't
have the time or inclination to actually do the work do define retention
policies in the first place!

Once done, however, you have a much easier and predictable system to
manage.  And probably will spend less time in a court of law somewhere
down the line.

Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
www.storserver.com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Norman Bloch
Sent: Wednesday, June 18, 2008 9:48 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Best practice for Policy Domains

I remember I read many years ago in the manual : a Policy Domain is a
logical grouping of nodes.
Rather than splitting between OS, I would make Policy Domains for File
servers, Application servers, Mail Servers, whatever if it's unix or
windows or ...
Norman



Shannon Bach <SBach AT MGE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/06/2008 21:22
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
[ADSM-L] Best practice for Policy Domains






I have always been told that it is easiest to maintain as few Policy
Domains as you can get away with.  Currently I have a standard Policy
Domain which is the Default for all Windows boxes, a Policy Domain for
our
Domino TDP servers, an UNIX Policy Domain for all UNIX flavors.
Recently
I was talked into creating a separate Policy Domain for 2 UNIX clients
that backup directly to tape and need special retentions.  Now it has
been
suggested that I do the same to use as special retention buckets...even
though not all the different departments have retentions standards as
yet...although hopefully this will be clearer to them in the next year
or
so.

My question is this..if we start creating different Policy Domains to
use
as Retention buckets could that not turn out to be potentially 10-20
domains until the data owners actually define a retention policy for all
their data?  What would be the pros and cons of doing this vs keeping
what
I have and just using different management classes?  Is there something
I'm not seeing in the big picture if we do decide to use the Policy
Domains as Retention buckets?  We have an average of 150 clients with a
mixture of
Windows, Unix and Domino TDPs.

Thanks as always for any suggestions or ideas anyone may have on this
subject.

Shannon