Agreed.  No reason to create different domains due to platform, TSM doesn't 
care.

I always tell my new customers to stick with minimal domains until they have a 
reason to add more.  Start simple.  It's easier to get more complex later, not 
as easy to merge/simplify.  

The primary reasons to create more domains:

a) different default retention requirements or storage hierarchies that make 
sense in your organization
b) the ability to give a different group of administrators control of "their" 
systems to define nodes, change passwords, set schedules (always outsource the 
work if you can!)
c) different reporting requirements  (this isn't strictly necessary, but sure 
makes it easier to segregate reporting.)
d) domain for "Frozen" or "litigation hold" clients

W  



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Bill Smoldt
Sent: Tuesday, May 07, 2013 4:23 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Domain, Management Class and Copy Group Best Practices

Sergio,

Having developed some of the early training, way before V5, I can tell you that 
the rationale for platform domains was strictly organizational.  In those days, 
most IT shops were organized by platform and had retention control over their 
own systems.  

Free of the organizational restriction it makes sense to create and populate 
domains specific to common retention parameters so that you aren't stuck with a 
lot of include <mgmtclass> statements.
___________________________
Bill Smoldt
President
www.storserver.com
719-266-8777 x7103


On May 7, 2013, at 1:58 PM, Sergio O. Fuentes <sfuentes AT UMD DOT EDU> wrote:

> Hello all,
> 
> Back in the early TSM 5 days, or at least once when I went to training,  it 
> was advised that each individual platform had its own DOMAIN for retention 
> and destination control.  Now, since I'm evaluating a TSM v6 environment, I'm 
> rethinking whether that is necessary across the board.  Sure, it's advisable 
> to have platform domains for TDP or NDMP type nodes, because of the way those 
> platforms handle retention settings for backups.  However, have any of you 
> decided to 'squish' each of the standard OS B/A client domains into one 
> singular domain?  I'm imagining having just one domain for standard B/A 
> client nodes.    (In reality, I'll have many domains for standard B/A client 
> nodes, but that's for other reasons, i.e. different stgpool hierarchy).
> 
> Is there any reason not to do this?  Domain definitions have a default 
> management class that defines a copy group with retention, destination and 
> serialization parameters.  I can see serialization getting in the way, but 
> that has only happened ONCE in 8 years of TSM 5.  Other domain specific 
> options like frequency, and mode don't really impact us much.  For Windows, 
> the system state mgmt class is non standard, but since it's not the default, 
> I don't see why I can't just add it as a non-default Management Class.  I'm 
> already moving away from a directory management class, how about moving away 
> from the platform-specific domain?
> 
> Thoughts, ideas?  Gotchas, that I might be missing?
> 
> As always, thanks,
> 
> Sergio
>