TSM Explorer v6.3

Siberia Software has released TSMExplorer (ver 6.3). TSMExplorer and TSMExplorer Collector are an easy and powerful product for managing and monitoring IBM Tivoli Storage Manager. The product allows you to manage many TSM servers from a single sign-on and supports Linux, Windows, and Mac OS X.

Check out the demos:

http://www.s-iberia.com/demo/demo1.html
http://www.s-iberia.com/demo/demo2.html 

or go to the main site:

http://www.s-iberia.com

TSM Symposium 2013 – Berlin

Ready, steady, TSM Symposium 2013 – Berlin

Tivoli Storage Manager Next Administrative Interface / Beta Programme

The beta test will begin next year. Can IBM make a good Admin GUI for TSM finally? What do you think? I'm still curious!!! ;-)

STORServer Console 3.0 Released

If you are looking for a TSM management console STORServer has released v3.0 of their console. I have not had the opportunity to use it, but if any reader out their has experience with the product and would like to post a review I will be more than willing to allow it. You can read more about the STORServer Console here.

Time For New Phone

My phone contract is up and I want to replace my iPhone 4 with something new. I was going to just replace it with an iPhone 5 but with TSMManager having an Android app for mobile administration I am tempted to move to a Galaxy S III. I have even considered a Galaxy Note 2. I have 3 Android tablets and I am very familiar with ColckworkMod Recovery and playing with different devs. Any suggestions are welcome.

TSM 6.2.4 Binding Issue

We've identified that our TSM 6.2.4 server is not binding files to the default management class but is assigning the node data to the management class with the highest retention setting, as if the default management class was not set. Attempts to update the policy's default management class, reactivate the policy, and rerun a backup have not yielded any rebinding on the TSM side. What does work is placing an INCLUDE * FSMGMT at the top of the include/exclude list. Pretty weird behavior and would explain why we seem to be eating through more storage than we should be. Anyone else seeing this? It might be an isolated incident, but we are checking all our TSM 6.2.x servers to verify. The best way to check is to identify the management class with the largest retention setting for backups and query a nodes backup in that domain to see if it is using it to bind the data.

SELECT * FROM BACKUPS WHERE NODE_NAME='<NAME HERE>' and CLASS_NAME='<MGMT NAME WITH HIGHEST RET IN DOMAIN>'

I have a PMR open with IBM and will post what I find.