=> On Thu, 7 Oct 1999 08:43:29 -0500, Lisa Cabanas <CABANL AT 
MAIL.MODOT.STATE.MO DOT US> said:

> I have just entered the world of ADSM (been in this position six weeks), and
> I am now embroiled in a holy war with my current supervisor over NT admin
> rights.  I have access to all of the data that we back up-- I am the ADSM
> admin- I hold the key to the BIG DOOR, so you wouldn't think that this would
> be an issue (but it is).  My supervisor thinks that I can do my job
> efficiently without having admin rights on the NT server clients.

[ ... ]

Woo, clearly a hot-button topic.

At the University of Florida, we're nibbling on this issue too; I manage an
ADSM <smack>TSM server in a data center on campus, and we're trying to figure
out how to extend service to our fractious University constituency.

We do have a difference between us and your (apparent) situation.  When a new
unit expresses a desire to do some backups, I want there to be an admin-type
_local to the unit_ who has first responsibility for their backups.  This
person should have the rights to install the client, and the domain knowledge
to make good decisions about the unit's backup needs.  She/He gets an ADSM
admin ID, with authority over her policy domain, and we interact on the level
of "about how much space do you need", "about what time of day should I do
backups".

Of course, I'm still doing global monitoring, and poking local admins when it
appears something is going wrong.  But _my_ responsibility really only extends
to poking.

If you can establish that policy, then it's only one step further to tell
them:

"Ok, we won't run the scheduler, it's your responsiblity to configure the
client, and you can use whatever scheduling facilities your OS offers to
generate the incrementals at the right time.  You _could_ manage this all
centrally with this nice piece of enterprise-buzzword-management software we
bought, but if you feel your time is better spent duplicating schedule setups
on N machines, I respect that judgement".

And make sure they get a missive _every day_ detailing the nodes (and
filespaces!) that haven't backed up "recently enough", whatever that means in
your organization.


Allen S. Rout
I've got some PERL that can do that last bit if you like. :)