Oh, been there done that.
You can do it by copying the domain via admin cmd line instead of starting from 
scratch, less likely to miss stuff that way if there are multiple MC's in the 
domain.  

And if you are keeping the same MC names, step 4. is unnecessary because 
nothing will get changed in dsm.opt or rebound to a different MC.

But a new domain (let's call it "FROZEN")  is the best way to do it, since this 
is a "discovery" situation.  

If you try to do it by creating a new MC in the same domain, and using an 
INCLUDE stmt  to rebind that client, you will miss stuff.  Only files that are 
still on the client filesystem will get rebound, as they will be "seen" and 
processed against the INCLUDE and rebound on the next backup.   Any inactive 
files that have been deleted from the filesystem and thus are currently managed 
under the VERDELETE or RETONLY rules would not get rebound.  (Which has always 
seemed to me to be exactly the kind of things a "discovery" order would be 
looking for...)  The only way to catch those is to extend copy group rules of 
the MC the files are already bound to.

And when the "hold for discovery" order is lifted, all you have to do is 
"update node victim domain=originaldomainname", reattach him to the schedule in 
that domain, and everything goes back to normal (whatever that is!). 

Now here's another point, depending on what "greatly extend" means:

Usually when I have customers that do this, if there are (shudder) lawyers 
involved, we don't how long the situation will last.  When you move the client 
into the FROZEN domain and change the MC settings to NOLIM NOLIM NOLIM NOLIM, 
and continue to back up the client, the storage it occupies will grow until 
whoever is paying the lawyers runs out of money and they lose interest.  

If the client involved is, say, a big Exchange server, this can be very, very 
painful for the TSM admin.  In this case, we move the client into the FROZEN 
domain, rename it to client-FROZEN, re-register it by the original name in the 
original domain, and let it start backing up new.  Then normal expiration rules 
apply to it going forward, which, depending on the length of time involved, and 
the feasibility of doing a new full backup, can be a smaller hit on your 
storage. 

And you can squeeze it down even more, and reduce the pain of new backups, if 
you can isolate the "discovery" situation to a single filespace.  Then you can 
use Export/Import to move just the single filespace to the FROZEN domain.

W




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: Friday, December 14, 2012 8:50 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Better way to change management classes values for a single 
node?

I have a Policy Domain that has 10-nodes.  Due to a "discovery request", I have 
to greatly extend the Retain Only value on the sole management class of this 
PD/PS.  However, the change only needs to apply to 1-of the 10-nodes.

Unless I am missing something, the only way I know of accomplishing this change 
so it doesn't effect every node in the PD is to

1.  Create a new PD/PS
2.  Create a new MC within this  new PD/PS with the extended values but 
retaining the original MC name 3.  Change the single node to use the new PD 4.  
Bounce node service to pickup changes

Am I missing something?

--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will never 
use email to request that you reply with your password, social security number 
or confidential personal information. For more details visit 
http://infosecurity.vcu.edu/phishing.html