To step a little bit outside of the TSM box, have you considered using iptables (you¹re a Linux shop, right?) with a time rule on the TSM server to block these troublesome hosts/subnets from connecting to TSM during undesirable times. You can either be heavy-handed and stop any matching packet after the witching hour, or let existing connections survive (so you can more gracefully stop them using cancel session). -Ken
On 9/26/12 4:23 PM, "Zoltan Forray" <zfor...@vcu.edu> wrote: > That is my whole point of my question/this discussion. So far the only > thing to do is what I already thought of (1-disable sessions, 2-cancel > session, 3-try to lock the node in-between retries...) but that in itself > is problematic since the node will "keep banging on the door" for a while > trying to re-establish the failed connection before it gives up... > > Also, disabling sessions will effect every node on that TSM server, > including legitimate backups that run throughout the day that don't effect > network traffic since they are on their own private subnet.... > > On Wed, Sep 26, 2012 at 4:15 PM, Alex Paschal <apasch...@frontier.com>wrote: > >> > Out of curiosity, when you cancel the sessions manually, how do you stop >> > them from restarting? >> > >> > >> > On 9/26/2012 11:15 AM, Zoltan Forray wrote: >> > >>> >> All of this discussion is great but the bigger picture/issue is being >>> >> missed. >>> >> >>> >> Yes, I would like to automate it but isn't really possible since it is >>> >> subjective to which one is eligible to be canceled. >>> >> >>> >> If I (or an operator) figure out which to cancel and then cancel it, >>> >> backup >>> >> session will automatically restart and keep on going. I want to be able >>> >> to >>> >> stop it from restarting, as well! >>> >> >>> >> On Wed, Sep 26, 2012 at 1:28 PM, Ehresman,David E. >>> >> <deehr...@louisville.edu>**wrote: >>> >> >>> >> > > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > zfor...@vcu.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
