Enhancement to new "decommission" command rejected

What I have recommended at a workaround to others is to create a new domain and set the default management class to what meets their needs (60 days, 6 months, a year, whatever). Then update the node to be in that new domain. When expiration run, all objects not bound to the default management class will now default to the default, since the original management class would not exist. And will expire based on the current retention in that domain. No need to copy the domain with all the management classes and update them all individually.

I tested this, and you can even change the node to a new domain after it's been decommissioned. So if you already have nodes that are decommissioned with retentions that are longer than you wish to keep them now, you can still do it.
 
What I have recommended at a workaround to others is to create a new domain and set the default management class to what meets their needs (60 days, 6 months, a year, whatever). Then update the node to be in that new domain. When expiration run, all objects not bound to the default management class will now default to the default, since the original management class would not exist. And will expire based on the current retention in that domain. No need to copy the domain with all the management classes and update them all individually.

I tested this, and you can even change the node to a new domain after it's been decommissioned. So if you already have nodes that are decommissioned with retentions that are longer than you wish to keep them now, you can still do it.

It just sucks to know that the Developers does not see this as an opportunity for advancement.

TSM is being slapped left and right as new backup software are getting better than before - some have provisions that outruns TSM capability from a data management perspective like faster DB backups and restores, ease of access to VM Ware vCenter, etc.
 
Back
Top