Re: TSM client machine renames
Paul, Regarding the characteristic where the TSM Scheduler remembers the nodename. For Windows: The service seems to remember the node name in effect when the service was created, even in the absence of a 'nodename' option in dsm.opt. I don't know whether there is a way to change the node name the service uses; we advise client system administrators to remove the service and create a new one when a Windows system is renamed. ** Your way of fixing this is best; uninstalling then reinstalling the scheduler. ** There is a registry entry for the TSM Scheduler service that contains the node name. I used to have a problem with some of the new Windows servers that came into TSM MISSing their backup for authentication reasons. A Windows admin eventually told me why and their way to fix it. In our case, the servers were all built from the same image. They all had the same machine name. When TSM was installed and the Scheduler set up and tested, it was under the standard build nodename. Subsequently, before the machine went into production, it was renamed. Sometimes the nodename in the dsm.opt file was changed, but authentication still failed. The Windows folks used to edit the Registry entry for the TSM Scheduler service...but your method is much safer. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 02, 2011 3:20 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM client machine renames -Paul Zarnowski wrote: - IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
Re: TSM client machine renames
Thank you for all of your suggestions. To answer some of your questions: - The nodename is usually specified in the dsm.opt, not defaulted from the machine name; - Our nodenames are generally NOT related to the machine name (but this may change as a result of our AD reorg); - We do not have central administration of all of our desktop systems, so we cannot reach in to each system from one central location (again, this will likely change AFTER the AD reorg, but that doesn't help me now); - Most of our systems use Scheduler Service, with a smaller percentage using CAD; - We have no standard disk configuration, so cloptsets are probably not a solution. Here is what I think we need to do: For each machine being renamed: 1. On TSM server, rename filespaces at same time period as machine rename (before the next daily backup runs); Preferably have tool that will allow us to trigger this rename remotely, in a secure manner; 2. On client system, edit the dsm.opt file and change any references to machine names to have the new machine name (e.g., in DOMAIN, INCLUDE, or EXCLUDE options); 3. IF the TSM nodename is being renamed, also on client system modify the registry entries to change the old nodename to the new nodename; Uninstalling and re-installing the scheduler will be cumbersome, so we will be looking for a script that can do this quickly; I'm also hoping to avoid a password re-seed. I don't know (yet) if we will be renaming TSM nodes as part of this exercise or not, but suspect we might be. ..Paul At 12:22 PM 6/7/2011, Huebschman, George J. wrote: Paul, Regarding the characteristic where the TSM Scheduler remembers the nodename. For Windows: The service seems to remember the node name in effect when the service was created, even in the absence of a 'nodename' option in dsm.opt. I don't know whether there is a way to change the node name the service uses; we advise client system administrators to remove the service and create a new one when a Windows system is renamed. ** Your way of fixing this is best; uninstalling then reinstalling the scheduler. ** There is a registry entry for the TSM Scheduler service that contains the node name. I used to have a problem with some of the new Windows servers that came into TSM MISSing their backup for authentication reasons. A Windows admin eventually told me why and their way to fix it. In our case, the servers were all built from the same image. They all had the same machine name. When TSM was installed and the Scheduler set up and tested, it was under the standard build nodename. Subsequently, before the machine went into production, it was renamed. Sometimes the nodename in the dsm.opt file was changed, but authentication still failed. The Windows folks used to edit the Registry entry for the TSM Scheduler service...but your method is much safer. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 02, 2011 3:20 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM client machine renames -Paul Zarnowski wrote: - IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you. -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu
Re: TSM client machine renames
What happens if you don't rename the filespaces at the same time period of a machine rename? regards -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, June 07, 2011 2:31 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM client machine renames Thank you for all of your suggestions. To answer some of your questions: - The nodename is usually specified in the dsm.opt, not defaulted from the machine name; - Our nodenames are generally NOT related to the machine name (but this may change as a result of our AD reorg); - We do not have central administration of all of our desktop systems, so we cannot reach in to each system from one central location (again, this will likely change AFTER the AD reorg, but that doesn't help me now); - Most of our systems use Scheduler Service, with a smaller percentage using CAD; - We have no standard disk configuration, so cloptsets are probably not a solution. Here is what I think we need to do: For each machine being renamed: 1. On TSM server, rename filespaces at same time period as machine rename (before the next daily backup runs); Preferably have tool that will allow us to trigger this rename remotely, in a secure manner; 2. On client system, edit the dsm.opt file and change any references to machine names to have the new machine name (e.g., in DOMAIN, INCLUDE, or EXCLUDE options); 3. IF the TSM nodename is being renamed, also on client system modify the registry entries to change the old nodename to the new nodename; Uninstalling and re-installing the scheduler will be cumbersome, so we will be looking for a script that can do this quickly; I'm also hoping to avoid a password re-seed. I don't know (yet) if we will be renaming TSM nodes as part of this exercise or not, but suspect we might be. ..Paul At 12:22 PM 6/7/2011, Huebschman, George J. wrote: Paul, Regarding the characteristic where the TSM Scheduler remembers the nodename. For Windows: The service seems to remember the node name in effect when the service was created, even in the absence of a 'nodename' option in dsm.opt. I don't know whether there is a way to change the node name the service uses; we advise client system administrators to remove the service and create a new one when a Windows system is renamed. ** Your way of fixing this is best; uninstalling then reinstalling the scheduler. ** There is a registry entry for the TSM Scheduler service that contains the node name. I used to have a problem with some of the new Windows servers that came into TSM MISSing their backup for authentication reasons. A Windows admin eventually told me why and their way to fix it. In our case, the servers were all built from the same image. They all had the same machine name. When TSM was installed and the Scheduler set up and tested, it was under the standard build nodename. Subsequently, before the machine went into production, it was renamed. Sometimes the nodename in the dsm.opt file was changed, but authentication still failed. The Windows folks used to edit the Registry entry for the TSM Scheduler service...but your method is much safer. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 02, 2011 3:20 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM client machine renames -Paul Zarnowski wrote: - IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you. -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu
Re: TSM client machine renames
You get a second new filespace on the server. Confusion waste. At 03:06 PM 6/7/2011, Hughes, Timothy wrote: What happens if you don't rename the filespaces at the same time period of a machine rename? regards -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, June 07, 2011 2:31 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM client machine renames Thank you for all of your suggestions. To answer some of your questions: - The nodename is usually specified in the dsm.opt, not defaulted from the machine name; - Our nodenames are generally NOT related to the machine name (but this may change as a result of our AD reorg); - We do not have central administration of all of our desktop systems, so we cannot reach in to each system from one central location (again, this will likely change AFTER the AD reorg, but that doesn't help me now); - Most of our systems use Scheduler Service, with a smaller percentage using CAD; - We have no standard disk configuration, so cloptsets are probably not a solution. Here is what I think we need to do: For each machine being renamed: 1. On TSM server, rename filespaces at same time period as machine rename (before the next daily backup runs); Preferably have tool that will allow us to trigger this rename remotely, in a secure manner; 2. On client system, edit the dsm.opt file and change any references to machine names to have the new machine name (e.g., in DOMAIN, INCLUDE, or EXCLUDE options); 3. IF the TSM nodename is being renamed, also on client system modify the registry entries to change the old nodename to the new nodename; Uninstalling and re-installing the scheduler will be cumbersome, so we will be looking for a script that can do this quickly; I'm also hoping to avoid a password re-seed. I don't know (yet) if we will be renaming TSM nodes as part of this exercise or not, but suspect we might be. ..Paul At 12:22 PM 6/7/2011, Huebschman, George J. wrote: Paul, Regarding the characteristic where the TSM Scheduler remembers the nodename. For Windows: The service seems to remember the node name in effect when the service was created, even in the absence of a 'nodename' option in dsm.opt. I don't know whether there is a way to change the node name the service uses; we advise client system administrators to remove the service and create a new one when a Windows system is renamed. ** Your way of fixing this is best; uninstalling then reinstalling the scheduler. ** There is a registry entry for the TSM Scheduler service that contains the node name. I used to have a problem with some of the new Windows servers that came into TSM MISSing their backup for authentication reasons. A Windows admin eventually told me why and their way to fix it. In our case, the servers were all built from the same image. They all had the same machine name. When TSM was installed and the Scheduler set up and tested, it was under the standard build nodename. Subsequently, before the machine went into production, it was renamed. Sometimes the nodename in the dsm.opt file was changed, but authentication still failed. The Windows folks used to edit the Registry entry for the TSM Scheduler service...but your method is much safer. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 02, 2011 3:20 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM client machine renames -Paul Zarnowski wrote: - IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you. -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu
TSM client machine renames
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 ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu
Re: TSM client machine renames
We have on occasion created a batch job that runs on the TSM servers that users can feed a few parameters to then have our operations group run it through the enterprise scheduler. This allows a user to run a command of higher privilege but still be under control. Also the users may have the job run at a time of their choosing and not bother us with details. As long as you build in good error checking it should be relatively safe. Hope that helps and I send my condolences. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Thursday, June 02, 2011 12:52 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM client machine renames 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 ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: TSM client machine renames
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 p...@cornell.edu To: ADSM-L@VM.MARIST.EDU Date: 06/02/2011 10:59 AM Subject:[ADSM-L] TSM client machine renames Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.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 ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.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. -
Re: TSM client machine renames
-Paul Zarnowski wrote: - 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. Do you use the 'nodename' option or let the clients default to using the machine name as the node name? If the machine name is used as the node name, you many not need to worry about extra backups because the 'rename filespace' operations were mistimed; the backups will not run at all until the appropriate 'rename node' operation is also done. On the other hand, our experience indicates that a node name change invalidates the TSM password saved on the client system. We think this happens because the process the client uses to retrieve saved passwords links each password to a specific node name. How do you start client backups? We use the client scheduler service without the client acceptor. The service seems to remember the node name in effect when the service was created, even in the absence of a 'nodename' option in dsm.opt. I don't know whether there is a way to change the node name the service uses; we advise client system administrators to remove the service and create a new one when a Windows system is renamed. Could you address problem 2 by using a client option set with 'force=yes' to force selected clients to used 'domain c:' rather than whatever is specified in dsm.opt?
Re: TSM client machine renames
i used dsmadmc has a backend for a CGI script. used perl modules DBD::TSM and
DBI, but you can call dsmadmc directly. Access was controlled thru clear text
file that was no way related to TSM access and deleted after we were done.
Timing was key but well documented for users to follow. Hope this helps.
#!/usr/bin/perl -w
use CGI qw(:standard);
use CGI::Carp qw(warningsToBrowser fatalsToBrowser);
use strict;
use DBI;
print header;
print start_html(Rename TSM Node);
print end_html;
my $nodename = uc(param('nodename'));
my $rename = uc(param('rename'));
my $userid = param('userid');
my $passwd = param('passwd');
open READ, /rename/userid.txt;
my $autherr = 1;
while (READ) {
$_ =~ /(\w+)\s(\w+)/;
if($1 eq $userid $2 eq $passwd){
$autherr = 0;
}
}
close READ;
my ($sec,$min,$hour,$day,$mon,$year,$wday,$yday,$isdst)=localtime;
$year+=1900;
$mon+=1;
my $str = $mon/$day/$year $hour:$min:$sec $userid;
open OUT, /rename/logs/$mon$day$hour$min$sec-$userid.log;
if ($autherr){
print Wrong User ID and/or Password!br\n;
print OUT $str Wrong User ID and/or Password!\n;
exit;
}
my ($dbh1,$dbh2,$sth1,$sth2,$fs1,$fs2);
print Renaming $nodename to $rename\n;
print OUT $str Renaming $nodename to $rename\n;
$dbh1=DBI-connect(DBI:TSM:tsm-1,tsmadmin,tsmpw,
{RaiseError = 0,
PrintError = 0}) or die $DBI::errstr;
$dbh2=DBI-connect(DBI:TSM:tsm-1,tsmadmin,tsmpw,
{RaiseError = 0,
PrintError = 0}) or die $DBI::errstr;
$sth1=$dbh1-prepare (q node $nodename)
or die $dbh1-errstr;
if (!$sth1-execute()){
print brbrNode $nodename Not Found!br;
print OUT $str Node $nodename Not Found!\n;
exit;
}
$sth1=$dbh1-prepare (rename node $nodename $rename)
or die $dbh1-errstr;
if ($sth1-execute()){
print brbrRenamed node $nodename to $renamebr\n;
print OUT $str Renamed node $nodename to $rename\n;
}else{
print brbrFailed to rename node $nodename to $renamebr\n;
print OUT $str Failed to rename node $nodename to $rename\n;
exit;
}
$sth1=$dbh1-prepare (update node $rename synovus1)
or die $dbh1-errstr;
if ($sth1-execute()){
print brChanged node $rename password to synovus1br\n;
print OUT $str Changed node $rename password to synovus1\n;
}else{
print brFailed to Changed node $rename passwordbr\n;
print OUT $str Failed to Changed node $rename password\n;
}
$sth1=$dbh1-prepare (select FILESPACE_NAME from filespaces where
node_name='$rename')
or die $dbh1-errstr;
$nodename = lc($nodename);
$rename = lc($rename);
if ($sth1-execute()){
while (($fs2) = $sth1-fetchrow_array) {
$fs1 = $fs2;
if ($fs2 =~ s/$nodename/$rename/){
$sth2=$dbh2-prepare (rename filespace $rename $fs1 $fs2 namet=uni)
or die $dbh2-errstr;
if ($sth2-execute()){
print brRenamed filespace $rename $fs1 $fs2br\n;
print OUT $str Renamed filespace $rename $fs1 $fs2\n;
}else{
print brFailed to rename filespace $rename $fs1 $fs2br\n;
print OUT $str Failed to renamed filespace $rename $fs1 $fs2\n;
}
}
}
}
$dbh1-disconnect;
$dbh2-disconnect;
close OUT;
From: Paul Zarnowski p...@cornell.edu
To: ADSM-L@VM.MARIST.EDU
Date: 06/02/2011 10:59 AM
Subject:[ADSM-L] TSM client machine renames
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.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
