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:[email protected]] On Behalf Of Zoltan Forray Sent: Friday, December 14, 2012 8:50 AM To: [email protected] 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 [email protected] - 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
