ADSM-L

Re: [ADSM-L] TSM server scaling/sizing for lots (>20000) nodes

2008-04-29 11:25:00
Subject: Re: [ADSM-L] TSM server scaling/sizing for lots (>20000) nodes
From: "Schaub, Steve" <steve_schaub AT BCBST DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Apr 2008 11:01:46 -0400
Lisa,

I'm in a situation similar to yours - I was a TSM Server admin in a
previous life, currently admin over all Windows related B/R. The admins
here graciously granted my id unrestricted policy priv, which gives me
95% access, based on my prior knowledge.  We (Windoze folks) maintain
all our own schedules, node defs, and heavily use client option sets to
centralize all of our common include/excludes.  All of our nodes are in
their own policy domain, which helps segregate things a bit.

Overall the arrangement works well.  Good luck, hope this helps convince
your admins to "loosen the reins" a bit!

Steve Schaub
Systems Engineer, Windows
Blue Cross Blue Shield of Tennessee
423-535-6574 (desk)
423-785-7347 (mobile)



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, April 29, 2008 10:14 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM server scaling/sizing for lots (>20000) nodes

On Apr 29, 2008, at 9:43 AM, Laughlin, Lisa wrote:

> Hi Richard!
>
> How does your shop deal with departmental server admins-- do they
> have any access to the TSM server?  If they do, do you allow them
> to use their own ids for backup and restore, ISC/Admin Center, TSM
> Operational Reports,  SQL queries, etc.?
> ...

Lisa -

The administrators of our TSM clients incidentally do have access to
the TSM server, by virtue of the admin instance created along with
REGister Node, but seldom use that, being content to simply deal with
normal client administration.  They are well-behaved, and utilize B/R
for legitimate file systems.  We don't use ISC or TSMOR "middleware":
we're an IT shop with a history of writing most of the software in
use, and so use dsmadmc for administration and parse logs and
accounting records for true views of TSM activity.  We don't use GUIs
unless we absolutely have to, given that they can hide and distort
underlying reality - and have a history of reliability and
performance problems.  (As Andy says, "The command line is your
friend.")

If a TSM (or any other type of) server is well configured,
administered, and monitored, with good periodic reports to clients,
there will be little or no need for server access by client
administrators, and everyone will be happy.  I can see from your
experience that it's not always like that, unfortunately.

    Richard Sims
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm