ADSM-L

Re: [ADSM-L] TSM & client machine renames

2011-06-02 15:49:43
Subject: Re: [ADSM-L] TSM & client machine renames
From: Robert Clark <robert.clark7 AT USBANK DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 2 Jun 2011 12:15:39 -0700
You can form a SQL query to get the nodes from a TSM instance of a given
OS platform.

If hostnames are related in some deterministic fashion to the nodenames,
and you have remote r/w access to \\nodename\c$\path\to\dsm.opt via AD,
and you have something equivalent to sed you can script the dsm.opt edits,
and someone hasn't neutered dsmcutil's ability to use the /machine: option
to start/stop remote services,
and you have a scripting language to script the filesystem renames via
dsmadmc,

You may be able do the whole thing from one central Windows running PC.

OR

If your schedulers are in prompt mode, you may be able to do similar
things with a mix of DEFINE CLIENTACTION and "at" jobs.

[RC]




From:   Paul Zarnowski <psz1 AT CORNELL DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   06/02/2011 10:59 AM
Subject:        [ADSM-L] TSM & client machine renames
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Hello all,

We are contemplating a massive Active Domain reorganization which would
involve renaming hundreds of Windows machines that we backup into TSM.  We
forsee a few problems with this, and I am looking to see if any other TSM
sites have faced a similar problem and what they did to address it.

The problems:
1. Renaming a Windows system will result in TSM making a fresh backups for
the volumes on that system (because the system name is part of the
filespace name).  Renaming the filespace on the TSM server will address
this, but timing is a problem.  If you rename the filespace a day early or
a day late, you will still end up with extra backups.

2. TSM likes to replace DOMAIN C: statements with DOMAIN \\systemname\C$.
If the systemname changes, then the TSM backup will fail, because it won't
be able to find the old systemname (unless and until the DOMAIN statement
is updated).  Again, with so many machines, updating all those DSM.OPT
files will be problematic.

3. If we have a large number of unintended extra backups, TSM server
resources (database size and stgpool capacity) will be stretched.


Having a tool that would allow our customers to rename their TSM
filespaces on-demand would be a big help.  As we do not give out policy
domain privileges, we cannot use dsmadmc to do this.  I am looking for
other solutions that any of you might have developed, or even just thought
about.  If the TSM BA client allowed a user to rename their filespace,
that would be a great solution.  But it's not there.

Thanks for any help (or condolences).

..Paul


--
Paul Zarnowski                            Ph: 607-255-4757
Manager, Storage Services                 Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu


U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



---------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>