Managing Storage Management Tivoli Enterprise Integration With Tivoli Storage Manager Sg246117

Managing Storage Management
Tivoli Enterprise integration with Tivoli Storage Manager

Centrally manage your distributed storage management environment Automatically react to storage events Benefit from practical, real-life examples
Patrick Randall Michel Baus Andrej Marencic Melinda Sangargir
ibm.com/redbooks
SG24-6117-00
International Technical Support Organization Managing Storage Management Tivoli Enterprise integration with Tivoli Storage Manager October 2000
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix A, Special notices on page 157.
First Edition (October 2000) This edition applies to Version 3.7.3 of Tivoli Storage Manager and Tivoli Management Framework 3.6.3 for use with all supported operating systems. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 2000. All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Part 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Introduction to Tivoli Management products . 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Parts and pieces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Tivoli Enterprise modules . . . . . . . . . . . . . . . . . . . . 1.2.2 Tivoli Data Protection for Applications . . . . . . . . . . 1.2.3 Other Tivoli modules for managing applications . . . 1.2.4 Tivoli Storage Manager event handling . . . . . . . . . . 1.2.5 Tivoli Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 System environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 . .3 . .4 . .4 . .8 . 12 . 16 . 16 . 17
Part 2. Using the individual modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Chapter 2. Tivoli Framework TME 10 . . 2.1 Framework architecture . . . . . . . . . . 2.2 Framework desktop . . . . . . . . . . . . . 2.2.1 Desktop window . . . . . . . . . . . . 2.3 Framework components . . . . . . . . . . 2.3.1 Tivoli Management Region . . . . 2.3.2 Policy regions . . . . . . . . . . . . . . 2.3.3 TME administrators . . . . . . . . . 2.3.4 Profile managers . . . . . . . . . . . 2.3.5 Task libraries . . . . . . . . . . . . . . 2.3.6 Scheduler . . . . . . . . . . . . . . . . . 2.3.7 Notice groups . . . . . . . . . . . . . . 2.4 Framework configuration: examples . 2.4.1 Defining administrators . . . . . . . 2.4.2 Creating tasks and jobs . . . . . . 2.5 Hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 . 21 . 22 . 23 . 24 . 25 . 25 . 25 . 26 . 27 . 27 . 27 . 28 . 28 . 33 . 39
Chapter 3. Tivoli Distributed Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1 Tivoli Distributed Monitoring concepts . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.1 Tivoli Distributed Monitoring components . . . . . . . . . . . . . . . . . . 42
Copyright IBM Corp. 2000
iii
3.1.2 Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Monitoring the status of the dsmserv daemon. 3.2.2 Custom script monitors . . . . . . . . . . . . . . . . . . 3.3 Hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4. Tivoli Software Distribution . . 4.1 Overview of Tivoli Software Distribution 4.1.1 Source host . . . . . . . . . . . . . . . . . 4.1.2 Target. . . . . . . . . . . . . . . . . . . . . . 4.1.3 Repeaters. . . . . . . . . . . . . . . . . . . 4.1.4 File package . . . . . . . . . . . . . . . . . 4.1.5 Autopack . . . . . . . . . . . . . . . . . . . 4.2 Installation . . . . . . . . . . . . . . . . . . . . . . 4.3 Setting the environment . . . . . . . . . . . . 4.3.1 Profiles . . . . . . . . . . . . . . . . . . . . . 4.3.2 Creating packages . . . . . . . . . . . . 4.3.3 Distributing packages . . . . . . . . . . 4.4 Hints and tips . . . . . . . . . . . . . . . . . . . . Chapter 5. Tivoli Inventory. . . . . . . . 5.1 Tivoli Inventory concepts . . . . . . . 5.1.1 Tivoli Inventory components . 5.1.2 Tivoli Inventory installation . . 5.1.3 Tivoli Inventory scan . . . . . . . 5.2 Examples . . . . . . . . . . . . . . . . . . . 5.2.1 Inventory profiles . . . . . . . . . 5.2.2 Queries . . . . . . . . . . . . . . . . 5.3 Hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. 44 . 44 . 47 . 51 . 54 . 55 . 55 . 55 . 56 . 56 . 56 . 56 . 57 . 59 . 59 . 60 . 64 . 67 . 69 . 69 . 70 . 70 . 71 . 73 . 73 . 80 . 84
.. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . .
Chapter 6. Tivoli Enterprise Console . . . . . . . . . . . . . . 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Overview of the Tivoli Enterprise Console . . . . . . . . . 6.2.1 Event adapters . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Handling of the messages . . . . . . . . . . . . . . . . . 6.3 How to prepare TEC for Tivoli Storage Manager . . . . 6.3.1 Importing files for Tivoli Storage Manager. . . . . . 6.3.2 Creating event group for Tivoli Storage Manager 6.3.3 Display setting of the event console . . . . . . . . . . 6.3.4 Creating an automated task . . . . . . . . . . . . . . . . 6.3.5 Setting the severity of TEC events . . . . . . . . . . . 6.3.6 Deleting rule sets . . . . . . . . . . . . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . 85 . . 85 . . 86 . . 88 . . 90 . . 90 . . 91 . . 93 . . 93 . . 96 . 100 . 102 . 106 . 108
iv
Managing Storage Management: Tivoli Enterprise Integration with Tivoli Storage Management
Chapter 7. Tivoli Plus Module for ADSM . 7.1 Components of Tivoli Plus Module . . . . 7.2 How it works . . . . . . . . . . . . . . . . . . . . . 7.3 Setting up the Tivoli Plus Module . . . . . 7.4 Hints and tips . . . . . . . . . . . . . . . . . . . .
.. .. .. .. ..
. . . . .
. . . . .
. . . . .
. . . . .
.. .. .. .. ..
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 111 . 111 . 112 . 112 . 114 . 115 . 115 . 116 . 116 . 117 . 118 . 119 . 119 . 121 . 123 . 124 . 124 . 125 . 129 . 129 . 130 . 131 . 131 . 132 . 133 . 136 . 137 . 139 . 139
Chapter 8. Tivoli Data Protection for Applications . 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Event forwarding to Tivoli Storage Manager . . . . . 8.3 Using tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Using Tivoli Software Distribution . . . . . . . . . . . . . 8.5 Hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 9. Tivoli Enterprise features of Tivoli Storage Manager . 9.1 Tivoli Storage Manager enterprise features . . . . . . . . . . . . . . . . 9.1.1 How to set up server-to-server communication . . . . . . . . . . 9.1.2 Configuring and managing the servers . . . . . . . . . . . . . . . . 9.1.3 Storing data on another server . . . . . . . . . . . . . . . . . . . . . . 9.1.4 Managing servers from any server . . . . . . . . . . . . . . . . . . . 9.1.5 Central monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Predefined items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Example of event logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 10. Tivoli Service Desk. . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Customizing Tivoli Service Desk. . . . . . . . . . . . . . . . . . . . . . . 10.2.1 Editing a Tivoli Service Desk user profile . . . . . . . . . . . . 10.2.2 Starting the Tivoli Storage Manager administrative client 10.2.3 Migrating assets from Tivoli Inventory. . . . . . . . . . . . . . . 10.2.4 Opening a call in Tivoli Service Desk . . . . . . . . . . . . . . . 10.3 Hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 3. Putting it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Chapter 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Updating the Tivoli Storage Manager backup-archive client 11.2 Extending the Tivoli Storage Manager recovery log . . . . . . 11.3 Offline backup of the Exchange server . . . . . . . . . . . . . . . . . . . . .. .. .. .. . . . . . . . . . 143 . 143 . 149 . 153
Appendix A. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Appendix B. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 B.1 IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
B.2 IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 B.3 Tivoli publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
vi
Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. Tivoli Enterprise Framework, its modules, and Tivoli Storage Manager . . . 4 Tivoli Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Tivoli desktop example of window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Desktop Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Create Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Create Administrator, Set TMR Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Create Administrator, Set Login Names . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Create Administrator, Set Resource Roles . . . . . . . . . . . . . . . . . . . . . . . . 31 Create Administrator, Set Notice Groups. . . . . . . . . . . . . . . . . . . . . . . . . . 32 Create Administrator, administrator desktop . . . . . . . . . . . . . . . . . . . . . . . 32 Task Library, acme_task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Create Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Task Library, acme_task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Create Job menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Schedule a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Schedule a job, Set Retry/Cancel/Restriction . . . . . . . . . . . . . . . . . . . . . . 39 Tivoli Distributed Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Interaction between Tivoli Distributed Monitoring and the TMR server . . . 43 Profile to monitor Tivoli Storage Manager and subscribed Endpoint . . . . . 45 Monitors inside Distributed Monitoring profile . . . . . . . . . . . . . . . . . . . . . . 46 Monitor daemon status of Tivoli Storage Manager . . . . . . . . . . . . . . . . . . 48 User and group ID to execute the monitors . . . . . . . . . . . . . . . . . . . . . . . . 50 Universal numeric monitor with custom script . . . . . . . . . . . . . . . . . . . . . . 52 Distributing a custom script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Tivoli Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Tivoli Software Distribution process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Create Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Autopack main menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Scanning the system with Autopack Control Center . . . . . . . . . . . . . . . . . 61 Build Autopack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 File Package Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Unix After Distribution Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Distribute File Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Tivoli Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Tivoli Inventory architecture when scanning Endpoints . . . . . . . . . . . . . . . 72 Profile manager with inventory profiles and subscribers . . . . . . . . . . . . . . 74 Inventory profile manager and query libraries . . . . . . . . . . . . . . . . . . . . . . 75 Inventory scan for hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Inventory scan for software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Storing configuration files as ASCII through inventory profile . . . . . . . . . . 79
vii
41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83.
Sample hardware query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Custom query TSM clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Query results of custom TSM client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Tivoli Enterprise Console event flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Components of the TEC Event Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 TEC Adapter profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Rule Bases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Tivoli Storage Manager message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Translating Tivoli Storage Manager messages into TEC Events. . . . . . . . 93 Rule Base Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Copy Rule Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Import Into Rule Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Compile Rule Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Load Rule Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Event Group Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 New Event Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Edit Event Group Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Assign Event Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Event Groups display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Sort Event Group Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Tivoli Enterprise Console Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Select Event Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Summary of the Automated Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Setup Automatic Task Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Automated Task Execution Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Tivoli Plus Module for Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . 111 ADSMPlus for Tivoli menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Set ADSM Home menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Tivoli Data Protection for Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Tivoli Data Protection for MS Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 117 Tivoli Storage Manager event forwarding . . . . . . . . . . . . . . . . . . . . . . . . 120 Server-to-server communication, enterprise administration . . . . . . . . . . 122 Server-to-server event logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Event logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Tivoli Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Tivoli Service Desk main window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Configuration of a user profile in Tivoli Service Desk . . . . . . . . . . . . . . . 133 Action groups in Tivoli Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 System actions in Tivoli Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Launching administrative client from Tivoli Service Desk . . . . . . . . . . . . 136 Tivoli Storage Manager Web administrative client. . . . . . . . . . . . . . . . . . 136 Configuring the Tivoli Inventory database into Tivoli Service Desk . . . . . 137
viii
84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94.
Importing assets from Tivoli Inventory into Tivoli Service Desk . . . . . . . . 138 Opening a call in Tivoli Service Desk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Rule sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 New Simple Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Condition in Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Actions in Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Extend log rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Extend log arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Compound Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Stop_Services parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Send_Event task parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
ix
Preface
This IBM Redbook covers the new features of Tivoli Storage Manager, which relate to the Tivoli Enterprise set of products and show how these, in return, can contribute to a traditional installation of Tivoli Storage Manager. This redbook is addressed to Tivoli Storage Manager administrators, who have little or no knowledge of Tivoli Enterprise. However, it does not cover the basic installation of the Tivoli Framework or its applications. This is covered in other books listed in Appendix B, Related publications on page 161. We focus on Tivoli Enterprise products, such as Framework, Distributed Monitoring, Inventory, Software Distribution, and Enterprise Console. We show how these modules can be used to ease daily tasks, to monitor conditions, and to report these accordingly. Additionally, we explain how to customize Tivoli Storage Manager to collaborate with the Tivoli Enterprise modules. This book is divided into three parts. Part 1 contains an introduction to the different Tivoli Enterprise modules and special features of Tivoli Storage Manager. Part 2 covers each of the modules in depth. Part 3 describes a complete scenario where all of the modules come together, therefore providing a holistic approach to an enterprise management system, including storage.
xi
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization San Jose Center. Pat Randall is a Distributed Storage Software Specialist at the International Technical Support Organization, San Jose, California. He has written eleven redbooks on ADSM and Tivoli Storage Manager, teaches IBM classes worldwide on all areas of distributed storage, and is a consultant in disaster and business recovery. Before joining the ITSO in July 1996, Patrick worked in IBM UK's Business Recovery Services as a Solutions Architect. Michel Baus is a consultant at sys Gesellschaft fuer Client/Server Loesungen mbH in Germany as an independent IT Integrator. He has five years of experience in implementing Tivoli Storage Manager/ADSM and three years in designing Tivoli Enterprise based solutions. He holds a degree in Sensor Systems Technology from Karlsruhe University of Applied Science, Germany. His areas of expertise include DCE/DFS, RS/6000 SP, ACSLS and SAN. Andrej Marencic is an IT Specialist in Nibble Data Systems. He has four years of experience in the Technical Support and Systems Management fields, and he teaches IBM courses. His areas of expertise include Windows NT and UNIX operating systems, Tivoli Storage Manager/ADSM, Tivoli Framework, and Tivoli Enterprise Console. Melinda Sangardir is a UNIX IT Specialist at IBM Denmark. She has three years of experience in implementing and supporting Tivoli Storage manager/ADSM and eight years experience in other IT areas. She holds a bachelors degree in English and an EDP diploma from EDP College in Denmark. Her areas of expertise include UNIX administration, backup systems, and Tivoli Storage Manager/ADSM. Thanks to the following people for their invaluable contributions to the project: Tetsuya Shirai International Technical Support Organization, San Jose Center Yvonne Lyon International Technical Support Organization, San Jose Center
xii
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Please send us your comments about this or other Redbooks in one of the following ways: Fax the evaluation form found in IBM Redbooks review on page 175 to the fax number shown on the form. Use the online evaluation form found at ibm.com/redbooks Send your comments in an Internet note to redbook@us.ibm.com
xiii
xiv
Part 1. Introduction
Part 1 explains the basic functions and special features of the various Tivoli products and modules that are covered in this book.
Chapter 1. Introduction to Tivoli Management products

In this chapter, we give you an overview of the different products and Tivoli modules, which are used in the other parts of the book. We explain their basic functions and their special features.
1.1 Overview
In Figure 1 you can see all the products which are mentioned in the book and their logical connections to each other. In the upper left corner, there is the Tivoli Framework underlaying most of the Tivoli modules except Tivoli Service Desk. In the lower part there is the Tivoli Storage Manager suite with the server itself and the different clients and special modules. On the right side you can see some applications, which can be managed by Tivoli Management modules and its storage managed by the Tivoli Data Protection modules for Applications. By using all these products together, you will get a closed cycle of events, management, and data flow.
Framework
Tivoli Distributed Monitoring
Tivoli Manager for Oracle
Oracle
Tivoli Inventory Tivoli RDBMS Interface Module Tivoli ADSM Plus Module
Tivoli Manager for SQL SQL Tivoli Manager for Exchange
Tivoli Software Distribution
Tivoli Enterprise Console
Tivoli Service Desk Plus Module
Tivoli Manager for Domino
Exchange
Domino Tivoli Service Desk
RDBMS
Tivoli Storage Manager
Server
Admin Client
Backup Archive Client
Tivoli Data Protection for Oracle
Tivoli Data Protection for SQL
Tivoli Data Protection for Exchange
Tivoli Data Protection for Domino
Figure 1. Tivoli Enterprise Framework, its modules, and Tivoli Storage Manager
1.2 Parts and pieces

This section is divided into the Tivoli Enterprise modules, which use the Framework, the Tivoli Data Protection for Applications modules, other Tivoli modules such as the ADSMPlus module for Tivoli Storage Manager and Tivoli Manager for Applications, and some basics for event flow in Tivoli Storage Manager itself and the Tivoli Service Desk.
1.2.1 Tivoli Enterprise modules

1.2.1.1 Tivoli Framework The Tivoli Framework provides the basic system management services, such as communications, presentation, and security, that most of the Tivoli
Management applications use, thus, ensuring consistency and integration. At its core, the Tivoli Framework provides the facilities to transfer files and execute commands on remote systems with built-in security and authorization roles. The Tivoli Management applications can use these core facilities to implement management functions, such as software distribution, resource monitoring, and system configuration. Most Tivoli systems management tasks, regardless of the application or component that is to be managed, may be performed by using the Tivoli desktop that provides a user interface consistent throughout management applications. However, you are not limited to using the Tivoli desktop, as many jobs and tasks can also be executed using the command line interface. 1.2.1.2 Tivoli Distributed Monitoring Tivoli Distributed Monitoring is an application that allows you to monitor the status of a wide range of geographically-dispersed platforms from different vendors running different operating systems, including resources that are not part of your Tivoli Environment. A monitor is an entity that controls specific aspects of a resource (percentage of disk space, status of a print queue, database process status, load average of a system, network collisions, and so on). Its definition contains threshold values and various response actions triggered upon reaching a threshold. Tivoli Distributed Monitoring uses the concept of management by subscription as the other Tivoli core applications. Monitors are defined centrally in distributed monitoring profiles and then distributed and activated on the target systems. Tivoli Distributed Monitoring provides your network computing environment with the following features: Centralized, synchronous (scheduled) monitoring of remote resources Predefined monitors for almost every resource (monitoring collections) Strong mechanism to generate events and alarms Automated decisions and actions in response to alarms or events Various responses (e-mail, triggering a program) Custom scripts for monitoring specific applications Full integration with the Tivoli Enterprise Console event server Data collection for statistical analysis and capacity planning
1.2.1.3 Tivoli Software Distribution Tivoli Software Distribution provides facilities for the distribution and installation of software to managed systems in a Tivoli environment. Tivoli Software Distribution uses the facilities provided by the Tivoli Management Framework to distribute file packages in an efficient manner. Administrators use the profile paradigm used by most other Tivoli applications to define file packages to be distributed. These file packages can include any files (executable programs, data files, and so on) and scripts that will be executed before and after the distribution for a proper installation of the files on the target system. The actual distribution process can use the Multiplexed Distribution (MDist) facility of the framework to optimize the use of the network. MDist is used to define nodes as repeaters so that they become fan-out points for the distribution. By defining an appropriate repeater hierarchy for your network environment, large file packages will only be moved once across slower links, but will still reach multiple target systems. 1.2.1.4 Tivoli Inventory One of the challenges in a network computing environment is keeping track of the hardware and software installed on each machine. Tivoli Inventory addresses this problem by providing the means to gather hardware and software information related to each system and then storing that information in a relational database. Queries and reports can be run to display the information in this database. Tivoli Inventory has three major advantages: It is based on the Tivoli Management Framework and therefore can be tightly and automatically integrated with other Tivoli applications. It stores inventory information in a Relational Database Management System (RDBMS) and therefore allows any non-Tivoli applications that can access SQL data to share the inventory information. Moreover, it benefits from the advanced features of an RDBMS system, such as scalability and performance. Tivoli Inventory has close links with other applications, such as Tivoli Software distribution and Tivoli Service Desk. 1.2.1.5 Tivoli Enterprise Console For many companies, the computing enterprise is becoming more heterogeneous in nature. It is supporting a wider variety of operating system platforms, communications methods, and a diverse set of applications and databases. Many computing enterprises are also becoming more distributed
both from a client/server and a geographical perspective. It follows, therefore, that the computing enterprise is becoming increasingly more demanding to manage and control, and it is getting more difficult to attain acceptable levels of availability. Availability or the lack of availability of the computing resources may be directly related to the bottom line of a company as well as to its competitiveness within the industry. The people who create and develop the variety of resources that make up a computing environment give the resources the ability to provide status information through the creation and transmission of alarms, messages, alerts, traps, and so on. These may be created in large quantities and may flow through the network expressing significant or insignificant changes in the status of those resources. It is up to the system support teams and operations staff to sort through the potentially large quantity of messages in order to respond appropriately to a given situation. To issue these problems, Tivoli Enterprise Console (TEC) provides a centralized point of integration and control for enterprise client/server environments. It allows administrators to monitor information about the environments for which they are responsible. TEC assists in maintaining high availability of the myriad of networks, systems, applications, and databases found within an enterprise. TEC helps detect potential problems before they cause outages. When problems are detected, TEC may be configured to take action and intervene as defined by the customer. TEC can prevent administrators from being flooded with unnecessary data that masks the real problems. For instance, it can perform automatic actions or filter out duplicate messages. By maintaining a comprehensive history of reported conditions, TEC allows handling only serious problem that happen in a particular time frame or in the context of other previously-received events. Both TEC and Tivoli Distributed Monitoring (TDM) are capable of monitoring system resources and activities. Both have the capability to respond to events. TEC is more powerful in that it can understand that events reported from different sources are related. TEC maintains a history, whereas TDM does not. The administrators have more power and flexibility to respond to events with TEC. The scope of events which TEC can monitor is broader. However, most environments use TEC and TDM. Let us distinguish each product: TDM is ideal for monitoring locally and for synchronous monitoring.
TEC is for asynchronous monitoring. Complex and persistent or unresolved problems with TDM can be forwarded to TEC for further analysis.
1.2.2 Tivoli Data Protection for Applications

The Tivoli Data Protection for Applications modules allow you to back up data in databases to a Tivoli Storage Manager server by using the module to interface directly with the Tivoli Storage Manager API. Usually, when you back up data from the database, the format of this data may need to be converted into files before backup; also, the database may be need to be offline to get a consistent backup. By using the Tivoli Storage Manager API, the underlying physical structure of the database (raw devices or files) is handled by the application (the application decides how the data is stored); so, it does not matter whether raw devices or files are used. Also, the type of backup (for example, online, offline, incremental, or table space) is determined and controlled by the application. Some products, such as IBM DB/2 can write directly to the Tivoli Storage Manager API without using Tivoli Data Protection modules. 1.2.2.1 Tivoli Data Protection for MS Exchange Tivoli Data Protection for Microsoft Exchange Server is an application that allows you to perform online backups of Microsoft Exchange Server databases to Tivoli Storage Manager storage. Tivoli Data Protection for Microsoft Exchange Server is referred to as the Exchange Application Client in this document. The Exchange Application Client helps protect and manage Exchange Server data by making it easy to do the following actions: Perform full, copy, differential, and incremental backups of the Microsoft Exchange Directory and Information Store databases. Restore a full Directory or Information Store database and any number of associated transaction logs. Delete a Directory or Information Store database backup from TSM storage. Back up the Exchange Server databases to any TSM server with drag-and-drop ease. Set TSM options regarding connection information to TSM servers. Set TSM options regarding security and performance. Obtain online context sensitive, task, and concept help. View online documentation for the Exchange Application Client.
Launch TSM and other related system applications. Automate scheduled backups. Automate deletion of old backups. Back up and restore a Microsoft Exchange Server Cluster running in a Microsoft Cluster Server (MSCS) environment. Set up seamless failover for scheduled backups in an MSCS environment. The Exchange Application Client communicates with Tivoli Storage Manager using its application program interface (API) and with an Exchange Server using the Exchange API. The Exchange Application Client must be installed on the same machine as the Exchange Server. However, the Exchange Application Client must be able to connect to a TSM server which can run on any supported operating system. The Exchange Application Client can compress Exchange data before sending it to the TSM server. The Exchange Application Client also runs in a Microsoft Cluster Server environment. 1.2.2.2 Tivoli Data Protection for MS SQL Tivoli Data Protection for Microsoft SQL Server (referred to as the SQL Application Client) is an application that allows you to perform online backups and restores of Microsoft SQL databases to Tivoli Storage Manager storage. The SQL Application Client helps you protect and manage SQL Server data by making it easy to: Perform full database and transaction log (incremental) backups. Perform a restore of a full database and any number of associated transaction logs. Delete an SQL database backup from Tivoli Storage Manager storage. Back up any SQL database to any Tivoli Storage Manager server with drag-and-drop ease. Set TSM connection information options to Tivoli Storage Manager servers. Set Tivoli Storage Manager security and performance options. Obtain online context-sensitive, task, and concept help. View online documentation for the SQL Application Client. Launch other Tivoli Storage Manager programs and related system applications. Automate scheduled backups.
Automate deletion of old backups. Back up and restore a Microsoft SQL Server running in a Microsoft Cluster Server (MSCS) environment. Set up seamless failover for scheduled backups in an MSCS environment. The SQL Application Client communicates with Tivoli Storage Manager using its application program interface (API) and with an SQL Server using the SQL DB-Library. The SQL Application Client must be installed on the same machine as the SQL Server, not the Tivoli Storage Manager server. However, the SQL Application Client must be able to connect to a Tivoli Storage Manager server (version 2 or higher) running on any supported operating system platform. The Tivoli Storage Manager server does not need to be run on Windows NT. The SQL Application Client also supports operation in a Microsoft Cluster Server environment. 1.2.2.3 Tivoli Data Protection for Oracle The Oracle Backup Agent supports these databases: Oracle7 databases with the Enterprise Backup Utility (EBU) Oracle8 databases with the Recovery Manager (RMAN) The Oracle7 EBU and Oracle8 RMAN perform backup (online and offline) and restore (online and offline) of Oracle databases. After the Oracle7 EBU or Oracle8 RMAN initiates a backup or restore, the Oracle Backup Agent acts as the interface to Tivoli Storage Manager. The Tivoli Storage Manager server then applies its storage management functions to the data, which can be done while users are working, with minimal disruption. The Oracle Backup Agent can work with any Version 3 ADSM or Version 3.7 Tivoli Storage Manager server. The Oracle Backup Agent translates the Oracle7 or Oracle8 API commands into Tivoli Storage Manager API calls. 1.2.2.4 Tivoli Data Protection for Lotus Domino The Tivoli Data Protection module for Lotus Domino is a Lotus Domino application that provides backup and restore of individual documents within a Lotus Domino database, or an entire database with folders, documents, forms, and views. Each Lotus Domino database can consist of two types of notes: Non-data notes such as forms, folders, and views Data notes such as documents
10
A Lotus Domino database is stored on a server or client workstation as a single structured file, usually with a .NSF file extension. Domino databases are complex logical structures that appear to traditional storage management tools, such as the Tivoli Storage Manager Backup-Archive Client, as single workstation files. It runs only at operating system level and will always back up the entire database. Whenever a single document is updated within a database, an incremental backup updates the entire database, because the database modification timestamp has changed. Most backup products can perform incremental backups of files, except Domino. The Tivoli Data Protection module incrementally backs up Domino databases on a document level to allow the administrator to retain a certain number of backup versions for each document. The Tivoli Data Protection module for Lotus Domino application uses the Lotus Domino API to communicate with the Lotus Domino databases. The Tivoli Data Protection module uses the Tivoli Storage Manager API to communicate with the Tivoli Storage Manager server. The Tivoli Storage Manager API is configured in a way similar to the standard backup-archive client. It has its own dsm.opt client user options file, which contains standard options such as node name, connectivity options, and include-exclude filter lists. The syntax for the include-exclude list for the Lotus Domino is different from the backup-archive client. It is highly recommended that you use a unique node name for the Lotus Domino Agent. Then the Tivoli Storage Manager server will view the application as a separate, self-contained workstation client. The Lotus Domino Agent helps you protect your Lotus Domino databases by using the backup and recovery services of Tivoli Storage Manager. Functions are available that enable you to: Incrementally back up only those portions of a database that have changed since the last back up, such as new or changed documents, forms, and views. Restore selected documents from a database (graphical user interface only). Restore documents that are deleted but not yet purged from a database. Restore an entire Lotus Domino database. Some of these tasks can be performed by using a graphical user interface (the Lotus Notes Workspace). Others can be accomplished through a command-line interface.
11
1.2.2.5 Tivoli Data Protection for SAP R/3 Tivoli Data Protection for SAP R/3 lets you manage backup storage and processing independently from normal SAP R/3 operations. Tivoli Data Protection for SAP R/3 and Tivoli Storage Manager provide reliable, high performance, repeatable backup and restore processes that let system administrators manage large volumes of data more efficiently. Tivoli Data Protection for SAP R/3 allows system administrators to follow SAP procedures and use the integrated SAP utilities for backup and restore. These utilities are SAPDBA, BRBACKUP, BRArchive and BRRestore. Other SAP files are backed up using Tivoli Storage Manager standard techniques for file backup and restore, for example, incremental backup, file filtering, and point-in-time recovery.
1.2.3 Other Tivoli modules for managing applications

Tivoli provide modules for managing appliactions. We outline those currently available below: 1.2.3.1 ADSMPlus for Tivoli module for TSM 3.7 The ADSMPlus for Tivoli module provides an integration of the TME 10 with Tivoli Storage Manager software. Note: ADSMPlus for Tivoli Version 3.7 will work only with Tivoli Storage Manager (formerly known as ADSM) Version 3.7 and not with any earlier versions of ADSM. This integration allows centralized management of the Tivoli Storage Manager application across a multi-platform network. This module provides the following features for managing the Tivoli Storage Manager application: Icons for launching the Tivoli Storage Manager application Subscription lists for clients and servers Monitors for TME 10 Distributed Monitoring Tivoli Storage Manager tasks and jobs 1.2.3.2 Tivoli Manager for MS Exchange Tivoli Manager for Exchange (Manager for Exchange) provides a centralized system management tool for Microsoft Exchange servers on the Tivoli platform. Manager for Exchange facilitates the management of Microsoft Exchange Servers on endpoints and the installation of Microsoft Exchange file packs on clients.
12
Manager for Exchange can be used with the following optional products: Tivoli Enterprise Console (TEC): Receives, filters, and forwards selected events to an event server for further processing. TEC event adapter for Windows NT (NT event adapter): Converts Microsoft Exchange events to the TEC format. Tivoli Software Distribution: Used to distribute and deploy software across multi-platform networks. Manager for Exchange provides the following features to enable you to perform system management functions for Microsoft Exchange: Tasks to control and automate Microsoft Exchange administrative activities on endpoints A selection of monitors for key performance and availability statistics for Microsoft Exchange Servers Configuration files for the NT event adapter to receive, filter, and forward selected events to the TEC Automated Microsoft Exchange client distribution Data input to Tivoli Decision Support 1.2.3.3 Tivoli Manager for MS SQL Tivoli Manager for Microsoft SQL Server complements existing Microsoft tools for Microsoft SQL Server and adds features so you can manage a large number of database servers in a distributed environment. This product concentrates on those tasks that can be defined and deployed by generic methods. It reduces the complexity of managing large distributed database environments and frees database administrators (DBAs) to concentrate on the non-generic issues associated with each of the individual servers. This product provides the ability to manage and monitor Microsoft SQL Servers by providing extensions to TME 10 Framework, Distributed Monitoring, Enterprise Console, and Global Enterprise Manager (GEM). It includes the MSSQLManagerTasks library and the MSSQLServer and MSSQLDatabase monitoring collections. These tools enable you to manage distributed Microsoft SQL Server computing resources effectively.
13
Using Tivoli Manager for Microsoft SQL Server, you can do the following: Register the Microsoft SQL Server with Tivoli. Automate repetitive DBA operations across all database servers or databases. Tivoli tasks work on multiple servers or databases in a single action. The tasks provided can: Ensure that optimal reading of data by monitoring and correcting fragmentation. Ensure that query plans are based on the correct statistics. Ensure space availability on log and data devices. Run standard maintenance commands and check for corruption. Check database and server configuration settings. Keep up-to-date recovery information. Back up databases and log files. Use the MSSQLServer and MSSQLDatabase monitoring collections for global database server and database availability and performance monitoring facilities. The monitors can be configured to respond automatically to problems. They can run tasks to perform corrective actions. Alert administrators to performance problems or serious errors and failures. Monitors can notify administrators in a number of ways. They can also send events to the Tivoli Enterprise Console (TEC). Integrate with the Tivoli Storage Manager backup tool to take advantage of features such as secure backups and backup device management. Integrate with Tivoli GEM (Global Enterprise Manager) to allow business-system views of managed servers and databases. 1.2.3.4 Tivoli Manager for Oracle With Tivoli Manager for Oracle - Framework, you can manage the tablespaces, datafiles, rollback segments, and redo logs in an Oracle database, and manage sessions and instances associated with a database. Tivoli Manager for Oracle - Framework enables you to use the other Tivoli Manager for Oracle products to manage your Oracle environment. The module consists of the following products: Tivoli Manager for Oracle - Framework Tivoli Manager for Oracle - Distributed Monitoring
14
Tivoli Manager for Oracle - User Management 1.2.3.5 Tivoli Manager for Lotus Domino The Tivoli Manager for Domino (Manager for Domino) allows the Tivoli or Domino system administrator to manage Lotus Domino within a Tivoli Management Environment (TME). That is, you can manage Domino servers from the same Tivoli Framework desktop where you control Tivoli Management Regions (TMRs). Manager for Domino Monitor Collections offer a wide range of monitoring options, including monitors for all statistics in the events4.nsf database that return numeric values. Program status monitor check the state of Domino add-in tasks. Manager for Domino makes use of Tivoli Software Distribution file packages to customize and distribute Notes client software. Manager for Domino uses TEC rules and classes to filter and manage Domino events. Using Event Server rule base functionality, you can modify or extend Manager for Domino rule sets to meet your processing requirements. You can also assign Domino events to an event group, and then view these events on one or more Event Consoles. 1.2.3.6 Tivoli Manager for SAP R/3 A typical SAP R/3 environment includes one or more R/3 systems, where each R/3 system consists of one database server and one or more application servers. The R/3 application servers run on the UNIX and Windows NT operating systems. The database servers run on the UNIX, Windows NT, and OS/390 operating systems. The Tivoli management environment consists of a Tivoli Management Region (TMR) server, a Tivoli Event Console (TEC) server, and multiple installations of the Tivoli Manager for R/3 product. Manager for R/3 operates at both the machine level and the R/3 system level. Management at the machine level is done via monitors provided with the Tivoli Distributed Monitoring product. These monitors provide status on the machines and daemons. Management at the R/3 system level is done via monitors, event adapters, and tasks provided with the Manager for R/3 product. Manager for R/3 represents each R/3 system and server as a Tivoli object. Each object is a special type of Tivoli endpoint that enables the Manager for R/3 to distribute monitors and tasks directly to the endpoint. As with any Tivoli endpoint, you
15
can run a task against one or more application servers across the R/3 systems that the TMR server manages. Manager for R/3 provides two event adapters for R/3 application servers. The event adapters are specific to each application server. You must configure each event adapter for each application server. R/3 application servers are the primary resources used in managing the R/3 system. The application servers obtain most performance metrics. Manager for R/3 obtains performance information about the R/3 database server through calls made to one of the R/3 system's application servers. This allows the Manager for R/3 to gather database information for all platforms, including DB2 on OS/390.
1.2.4 Tivoli Storage Manager event handling

1.2.4.1 Events from Tivoli Storage Manager to TEC In its current release, Tivoli Storage Manager supports the forwarding of events to the Tivoli Enterprise Console (TEC). This happens in the same way as other event receivers such as activity log or console. This includes the standard messages originating from the Tivoli Storage Manager itself and its clients. 1.2.4.2 Events from multiple Tivoli Storage Manager servers to TEC By using the central event logging feature, which is included in the enterprise features of Tivoli Storage Manager, you can use a central server to forward the events originating from all Tivoli Storage Manager servers in your organization. 1.2.4.3 Events from Tivoli Data Protection for Applications to TEC Another feature which was introduced in Version 3.7.3 is the forwarding of events originating from the Tivoli Data Protection for Applications modules to the TEC server. This finally enables you to monitor all the events related to Tivoli Storage Manager from all sources in your enterprise network.
1.2.5 Tivoli Service Desk

Service Desk is a help desk software solution whose primary goal is to improve the efficiency and effectiveness of a corporate service and support operation. It is a suite of three integrated applications: Tivoli Problem Management: This application, which is the core application of Tivoli Service Desk, addresses help desk services related to user requests for problem resolution.
16
Tivoli Change Management: This application addresses the operational changes associated with delivering IT services. Tivoli Asset Management: This application addresses issues surrounding corporate assets.
1.3 System environment

These are the products we used in our lab environment: Framework 3.6.3 (TMR on AIX 4.3.3 ML2) Tier 2 Framework for Redhat Linux 3.6.1 on Redhat Linux 6.1, including Software Distribution, Inventory, and TEC Logfile Adapter Distributed Monitoring 3.6.1 Distributed Monitoring UNIX Monitors 3.6 Distributed Monitoring Universal Monitors 3.6 TEC 3.6.2 TEC Adapter Configuration Facility 3.6.2 Inventory 3.6.2 Software Distribution 3.6 Software Distribution Historical Database 3.6 Service Desk 6.0 on NT 4.0 SP5 using MS SQL 7.0 SP1 for database Storage Manager 3.7.3 Storage Manager Clients 3.7.2 ADSMPlus for Tivoli, Version 3.7, Revision 0 Data Protection for MS SQL 1.1.1 on MS SQL server 7.0 SP1 Data Protection for MS Exchange 1.1.1.0 on MS Exchange server 5.5 SP3 Data Protection for Oracle 1.1 on Oracle server 8.1.5 Data Protection for Lotus Domino 1.1 on Domino server 5.0 DB2 5.2 on AIX 4.3.3 ML2 for TEC and Inventory database
17
These are the machines on which we installed Tivoli Endpoints and Tivoli Storage Manager Backup/Archive Clients: AIX 4.3.3 ML2 Windows NT 4.0 SP5 Server /Workstation Windows 2000 Server Solaris 7 Redhat Linux 6.1 Kernel 2.2.12-20
18
Part 2. Using the individual modules

Part 2 covers the Tivoli Enterprise products, plus modules, Tivoli Data Protection for different applications and Tivoli Storage Manager. We do not cover the installation, and expect that the system is already installed and running. We give you a description of individual modules starting with product architecture, concepts, definitions of components, how they work, and, at the end, examples of how to set them up. These examples are based on our environment and can be different from the system environment in your organization. Setting up Tivoli Enterprise requires a basic knowledge of Tivoli products, and, therefore, this may involve your Tivoli Enterprise administrator. We also discuss how to configure Tivoli Storage Manager, which requires basic knowledge of Tivoli Storage Manager administration. This part of the book will help you to get started, and, at the end, you should be able to make use of the Tivoli Enterprise features that relate to Tivoli Storage Manager.
19
20
Chapter 2. Tivoli Framework TME 10

In this chapter we give you a brief description of the Tivoli Management Environment 10 (TME 10) Framework, which is the base component for the TME 10 product line. In this chapter we cover: Framework architecture Framework components Framework configuration, with examples
2.1 Framework architecture

The TME 10 Framework provides a set of services or features used by the TME 10 applications installed on the Framework. See Figure 2.
Framework
Task Libraries Query Libraries RIM Endpoint Manager Scheduler
RDBMS interface module
communication tasks
RDBMS
Managed Node
Managed Node
gateway
communication tasks
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 2. Tivoli Framework
21
Following are some examples of the services provided by the Framework: Task Library A task library through which you can create tasks and execute them on multiple TME 10 resources. Scheduler A scheduler that enables the administrator to schedule all TME 10 operations, such as execution of the tasks created in the TME 10 task library. Relational Database Management System (RDBMS) Interface Module (RIM) This enables some of the TME 10 applications to write application specific information to a relational database. Query facility This enables an administrator to search and retrieve information from a relational database. The introduction of the Gateway and the Endpoints enables a Tivoli Enterprise installation to be three-tiered, as shown in Figure 2 on page 21. Tivoli Management servers communicate with Managed Nodes. Managed Nodes can host a Gateway to handle communication with Endpoints. Gateway controls all the communications with and operations on Tivoli Enterprise Endpoints. Using fewer Managed Nodes and more Endpoints reduces the Tivoli Management server load for the following reasons: There is a limitation of 200 Managed Nodes per TMR. Endpoints do not have a client database to synchronize with the Tivoli Management server database. There are fewer Managed Node databases to synchronize with the Tivoli Management server database.
2.2 Framework desktop

The TME 10 desktop is the user interface that provides access to TME 10 features and components. The desktop provides a central control to manage and organize the system management tasks of all modules. The desktop is available for Microsoft Windows and for other platforms having the X11 environment or a graphical interface installed. There is also a command line interface (CLI) for TME 10 that enables you to enter TME 10 commands.
22
2.2.1 Desktop window

The desktop window is a graphical representation of TME 10 and provides status information of modules, objects, and resources. Windows are used to move or copy the resources. See Figure 3.
Figure 3. Tivoli desktop example of window
2.2.1.1 Desktop Navigator The Desktop Navigator provides filtering of the resources and keyword search. By using Navigator, you can go directly to the resource you would like to see without going through other intermediate resources. Navigator can be accessed from any collection window. For an example of the Desktop Navigator dialog, see Figure 4.
23
Figure 4. Desktop Navigator
2.2.1.2 Collections A collection is a container that you can create and place on your desktop. A collection can contain shortcuts that enable you to access resources. You can populate a collection by moving and linking objects. Note: You can create a collection from the desktop only.
2.3 Framework components

This section includes brief descriptions of Tivoli Management Framework components. In addition, it guides you through examples of how to define administrators, tasks, and jobs, as well as how to make a profile and distribute it to subscribers. The basic components of TME 10 are: Policy regions Administrators Profiles Profile managers Task libraries
24
Notice groups Query libraries Endpoint manager Scheduler
2.3.1 Tivoli Management Region

A Tivoli Management Region (TMR) consists of a TME 10 server and a set of TME clients that it serves. After base installation of Framework on a system, that system becomes the TME server for the TMR. The TME server installation process automatically allocates a unique 10-digit region number that originated from the TME license key during the installation. In addition, the administrator has to specify a region name for the initial region. The most common types of TME clients are Managed Nodes and Endpoints: Managed Node A Managed Node is a client on which the complete TME 10 Framework is installed. TME server can install a Managed Node remotely and add it to the TMR. A Managed Node, which supports the majority of TME 10 management applications, occupies a disk space of 200-300 MB. Endpoints The Endpoints can execute methods sent to them by the Gateway, where they can then cache locally. Endpoints occupies a disk space of about 5 MB.
2.3.2 Policy regions

A policy is a set of rules that are applied to managed resources. A specific rule in a policy is referred to as a policy method. A policy region is a container of resources that share one or more common policies. Resources belong to the policy region in which they were created or moved to. Managed resources can be moved or linked symbolically from one policy region to another policy region, but you cannot copy managed resources.
2.3.3 TME administrators

An administrator is a user that performs administration tasks inside TME 10. For example, on AIX, the root user installs TME and becomes the TME administrator.
25
Each administrator ID is associated with certain administrator roles. Roles define administrator levels of authority. The possible authorization roles for administrator that may be defined are: Super Authority to perform any operation. Senior Authority to create TME 10 resources. The senior role is required for configuration and policy tasks such as creating an administrator or setting policy. Admin Authority to manage and create system resources, such as assign a user item to a profile or changing the message of the day. User Authority to view but not modify. Backup Authority to perform TME 10 database backup. Restore Authority to perform TME 10 database restore. Install product Authority to install new TME management applications. Install-client Authority to install new Managed Nodes within policy regions. Additional modules can define additional roles.
2.3.4 Profile managers

A profile manager is a container that links a collection of profiles to a set of subscribers. Subscribers can be the following managed resources: Managed Nodes Endpoints Other profile managers Profile managers are created within a policy region. Subscribers of these profiles can be from same policy region or other policy regions. An example of this situation could be Managed Nodes within a department or location which are configured as subscribers to a profile manager within a policy region. Those profile managers can be subscribers to another profile manager. 2.3.4.1 Profiles Profiles are collections of applications-specified information. A profile defines the characteristics of the function to be performed. For example, a software distribution defines the Courier file package properties. This would typically include the files to be distributed, their source locations, and any pre-distribution or post-distribution functions to be performed on the target workstation.
26
2.3.5 Task libraries

Task libraries are collections of tasks that can be run on target nodes within the TMR. 2.3.5.1 Tasks Tasks are commands or functions that can be run on a target node or workstation. Tasks can run on Managed Nodes, Endpoints, or a profile manager which contains many other subscribers. 2.3.5.2 Jobs Jobs can be created in a task library (however, you must create a task before you can create a job). A job is a task that is executed at specific managed resources. The execution information you specify when you create a job includes a list of task Endpoints on which the associated task will run and where the output will be displayed. Jobs can be run at predefined times by using the scheduler.
2.3.6 Scheduler
An administrator may need to schedule a job to begin in a specific time frame some time in the future. The scheduler allows the administrator to schedule previously created jobs, as well as to do the following: Schedule jobs to run at specific times within a specified time frame. Schedule jobs to repeat a specified number of times at specified time intervals. Schedule jobs to repeat indefinitely. Restrict scheduled jobs to run only at night, during the day, or every day, but only Monday to Friday, or on weekends. Schedule a job to run only once.
2.3.7 Notice groups

TME 10 management operations are logged and results are displayed as notices. Notices are the response mechanism for the administrators to monitor the status of management operations. Notices are sent to application or operation-specific notice groups. Notice groups stores notices sorted by function of modules. For example an administration notice group receives notices from operation such as creating a new administrator.
27
2.4 Framework configuration: examples

In this section we show you how the Framework can be configured.
2.4.1 Defining administrators

An existing administrator with a senior function role can define another TME 10 administrator. Our example is performed by a TME administrator. You can create a new administrator from the desktop or the command line. Here is an example using desktop. 1. Select Create Administrator from administrator icon pop-up menu to display the Create Administrator dialog. See Figure 5.
Figure 5. Create Administrator
2. Enter the name of the administrator (in our example, melinda). 3. Enter the administrators user login name. 4. Enter the administrators group name in the Group Name text field. 5. Then click on the Set TMR Roles.... button to set the function roles for the administrator. TMR roles are roles for the whole TMR. Resource roles are roles for specific resources which are superseded by TMR. In the Set TMR Roles dialog, it is possible to select admin, senior, user and other roles from the available Roles list. The combination of these roles is sufficient for the tasks an administrator can perform. To define an administrator, you
28
should at least have senior role; otherwise you cannot give someone else the role that you do not have yourself. After selection of a series of roles, click on Set & Close to return to the Create Administrator dialog. See Figure 6.
Figure 6. Create Administrator, Set TMR Roles
6. Click on the Set Logins... button to define the login names under which the new administrator will be able to start the TME 10 desktop or issue TME commands. The login name can be one of the following forms: username username@ManagedNode NTdomain\username NTdomain\username@ManagedNode Kerberos-name:realm
If you want more than one login name, repeat this step for each login that you wish to add. See Figure 7. The user must exist on the Managed Nodes on which you are going to run the desktop or issuing the commands. For more information, refer to the Framework Users Guide, GC31-8433.
29
Figure 7. Create Administrator, Set Login Names
7. Click on the Set Resource Roles... button to specify individual resource roles for the administrator melinda. Again, there are different roles available for different resources. For example, you can choose User, admin, and Senior for the scheduler resource and repeat this function. Click on Set & Close to return to the Create Administrator dialog. See Figure 8.
30
Figure 8. Create Administrator, Set Resource Roles
8. Click on the Set Notice Group... button to set the notice groups for this administrator. You can select a set of different notice groups. See Figure 9.
31
Figure 9. Create Administrator, Set Notice Groups
9. Click on the Create & Close button to create the administrator, melinda. The new administrators icon is displayed in the Administrators window. See Figure 10.
Figure 10. Create Administrator, administrator desktop
The preceding steps have created the administrator. This administrator desktop is now ready to start. The final step of setting up the TME administrator melinda is to add resources to its desktop. This is done by
32
dragging resource icons from an existing desktop and dropping them onto the newly created administrator icon. The new TME administrator melinda is now defined and ready to use.
2.4.2 Creating tasks and jobs

2.4.2.1 Create task library A task library enables you to create tasks and jobs that can be run on one or more managed resources in a network. You can create multiple task libraries within each policy region. Before creating the task, one or more executable files or scripts that implement the operation associated with the task must exist. We created a task library with the name acme-task within the policy region acme-region. A task library must be an enabled managed resource of this policy region before you can create it. See Figure 11.
Figure 11. Task Library, acme_task
2.4.2.2 Creating a task Example of creating a task named df (this task will run the df command on UNIX platform). See Figure 12. 1. Double-click on the icon of the task library. Select the Task... option from the task librarys Create menu to display the Create Task dialog. 2. In the Task Name field of the Create Task window, enter the name of the task. Choose the platform on which you would like to run the task. If you have a generic executable, for example, a shell script can be run on multiple architectures.
33
Figure 12. Create Task
3. Then you choose the platform you want the task to run from the available platform list. Framework displays the Executable for Task dialog for the specified platform, in which you can enter the name of the managed node that contains the executable for the chosen platform in the On Host text field, and the path name in the Path to File text field for example, IBM RS/600 /AIX 4, if your task is going to run at this platform. 4. In the Role Required to Execute Task list, select the administration role required to start this task. For example, selecting admin will permit any administrator with that authority to execute the task. 5. Under Execution Privileges, in the User Name field, insert the user ID under which the task should run on the target node. The default value for this field is *, which specifies that the task should run under the ID of the
34
administrator executing the task. In our example, we chose $root_user as user name, and $root_group as group name, as a generic substitute for administrators at different platforms. 6. Click on Create & Close button to create the task and return to the Task Library window. 2.4.2.3 Create a job 1. From the Task Library, in our example, acme_task dialog, select Job... from the Create action bar menu. See Figure 13.
Figure 13. Task Library, acme_task
2. In the Create Job dialog, enter the Job Name df-job. 3. Select the task name associated with the job from the Task Name scrolling list. 4. For execution mode choose for example, if you choose Parallel, the job would be run in parallel on all selected Managed Nodes, Endpoints, or profile manager. The other possibility is Serial, so that the job will be run serially on all selected Managed Nodes, Endpoints, or profile manager. See Figure 14.
35
Figure 14. Create Job menu
5. For output destination, you can select Display on Desktop if you want the job output to be displayed on the Tivoli desktop, or Save to a File if you want the output to be saved to a file, and enter the name of the Managed Node or Endpoints on which to save the output in the On Host text field. 6. You can run the job on one or more Managed Nodes or Endpoints by selecting them from the Available Task Endpoints list.
36
7. To run the job on all subscribers of a specified profile manager, choose the profile managers from the Available Profile Managers scrolling list. 2.4.2.4 Schedule a job To schedule a job, do the following: 1. You can schedule a job by dragging and dropping the job icon onto the scheduler icon. The Framework then displays the Add Scheduled Job dialog. 2. Enter the job Label in the Job Label text field. 3. Enter the scheduled date in the Schedule Job For field. 4. Enter the scheduled time in the Hour and Minute option menus. You can enter the number of times you wish the job to repeat, and the time interval for repeats. See Figure 15.
37
Figure 15. Schedule a job
5. Enter the action that should occur when the job is finished. 6. You can set Retry/Cancel/Restriction Options for the job. With the Retry option, you can specify that a job can retried if it is unable to start at the scheduled time. With the Cancel option, you can specify that a job should be cancelled if it does not start within a specified time period after its scheduled stat time. With the Restriction option, you can restrict a job to run during the day, at night, during the week or on weekends. See Figure 16.
38
Figure 16. Schedule a job, Set Retry/Cancel/Restriction
7. Press the Schedule Job and Close button to schedule the job and return to the desktop.
2.5 Hints and tips

When assigning authorization roles to an administrator, to ensure that senior system administrators can perform tasks at their authorization level and below, assign these administrators all authorization roles below their current level. For example, to ensure that an administrator with the senior role can perform all tasks at the senior level and below, assign this administrator the senior, admin, and user roles.
39
40
Chapter 3. Tivoli Distributed Monitoring

In this chapter, we cover the concepts of Tivoli Distributed Monitoring. We also show you, by example, how a Tivoli Storage Manager administrator could benefit from using this product.
3.1 Tivoli Distributed Monitoring concepts

Figure 17 shows how Tivoli Distributed Monitoring interacts with other Framework components. This is an application which uses Tivoli Framework to interact with target machines, which can be either Managed Nodes or Endpoints. It distributes monitors from the TMR server to the targets to monitor certain conditions. Based on trigger levels, it can execute actions such as forwarding events to the Tivoli Enterprise Console.
Framework
Tivoli Distributed Monitoring
distribute monitors
send events
RDBMS
Managed Node
Managed Node
gateway
execute monitors collect values
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 17. Tivoli Distributed Monitoring
41
Before we proceed with some examples of how to use Tivoli Distributed Monitoring, we explain what components it consists of, and how they interact with each other.
3.1.1 Tivoli Distributed Monitoring components

Tivoli Distributed Monitoring is based on the Tivoli Framework architecture. It provides fundamental tools for monitoring resources on the following targets: Managed Nodes TMA Endpoints Distributed Monitoring Proxies (DM proxies) DM proxies are non-Tivoli entities that function as subscribers for Tivoli Distributed Monitoring profiles. Since they are not related to Tivoli Storage Manager in any way, we do not cover them in this book. Tivoli Distributed Monitoring has two main install images: 1. Tivoli Distributed Monitoring package This install image must be installed on the TMR server, the Managed Nodes that need to perform the monitoring functions and the Endpoint Gateways managing the TMA Endpoints you want to monitor. This package enables the following two functions: - Distributed Monitoring engine One process on a Managed Node and TMA Endpoint that controls and oversees the resources as defined in the monitors of Distributed Monitoring profiles. It determines whether the monitor should be triggered and runs most of the automated responses. The Distributed Monitoring engine runs autonomously on each monitored system, which makes more efficient use of network resources. The Distributed Monitoring engine performs the necessary checks on behalf of the monitors at the specified intervals. - Distributed Monitoring Gateway One process on an Endpoint Gateway that communicates with the distributed monitoring engine on the TMA Endpoint. It caches the collection data, forwards the events to TEC, bundles response data from Endpoints, and handles non-local responses directly or by passing to another process. 2. Monitoring collections Monitors are grouped into monitoring collections. A monitoring source represents a specific aspect of a system that can be monitored, such as percentage of disk space used. The intelligence (code and parameters) that actually enables the performance of these monitoring functions has to be available (installed) before a monitor can be defined. Tivoli and Tivoli partners provide predefined monitoring sources that monitor common system functions.
42
Figure 18 shows the interaction of Distributed Monitoring modules with the TMR server and the targets.
Figure 18. Interaction between Tivoli Distributed Monitoring and the TMR server
Distributed Monitoring was designed to run independently of the oserv process, since not all monitored computers will be running this process. For instance, PC Managed Nodes and TMA Endpoints do not run an oserv process.
43
Since oserv implements the centralized Tivoli Framework scheduler, Tivoli Distributed Monitoring uses its own distinct scheduler.
3.1.2 Monitors
Monitors are records of a Distributed Monitoring profile, thus, multiple (usually related) monitors can be handled with one profile defined centrally on the TMR server. After distribution of the DM profiles, all the monitors activities are maintained by a local Distributed Monitoring engine. The administrator can monitor the status of monitors using an indicator collection. Within an indicator collection, you can assign an indicator icon to a Distributed Monitoring profile, and when any monitor of that profile detects a problem, the gauge on the corresponding indicator icon is raised to the appropriate warning level. An indicator collection and indicators provide an easy and centralized method of checking on all the Distributed Monitoring profiles in a policy region. However, if you have the Tivoli Enterprise Console installed in your TMR, this is where your messages should go. The following steps are required to create a monitor: 1. Create a Distributed Monitoring profile in a profile manager. (If you are using Endpoints, the profile manager must be in dataless mode.) 2. Add a monitor to the Distributed Monitoring profile. 3. Choose the targets that will be monitored and subscribe them to the profile manager that contains your monitor. 4. Send (distribute) a copy of the profile to the selected subscribers in order to monitor a target.
3.2 Examples
We now show some examples how Tivoli Distributed Monitoring can be used to monitor Tivoli Storage Manager servers. These examples are not a complete solution that fits every environment. They are customized to our given lab infrastructure and can be extended in any way. Tivoli provides a variety of predefined monitors, and there are very few constraints for extending it to your special needs. So dont ask what Tivoli Distributed Monitoring can do, ask yourself what you need! Before configuring monitors, you should take some notes on what you are going to monitor and what should happen, if these conditions are met.
44
The first thing to do is to create a Distributed Monitoring profile in a profile manager. If you are using Endpoints, be sure to have dataless mode enabled on the profile manager. Also verify that the Sentry Profile is among the managed resources of your current policy region. In our example we use just one profile which holds multiple monitors related to Tivoli Storage Manager server on the AIX platform. We named the profile dm_tsm_server_aix, as seen in Figure 19.
Figure 19. Profile to monitor Tivoli Storage Manager and subscribed Endpoint
45
In order to distribute your profile to machines, you have to subscribe them to the profile manager. Here, the monitored host is palana, which is our Tivoli Storage Manager server on AIX. The examples include four monitors to check the status of the Tivoli Storage Manager server (Figure 20): 1. Available swap space This monitor checks the remaining megabytes in the swap space. 2. Daemon status This monitor looks after the dsmserv daemon. It will trigger when the Tivoli Storage Manager application is down. 3. Load average This monitor checks the load average of the server. If it is too high, you can tell whether there are zombies or very time-consuming processes. 4. Numeric script This is an example of a complete custom monitor. It uses a command line script which polls certain conditions from Tivoli Storage Manager administrative interface (dsmadmc).
Figure 20. Monitors inside Distributed Monitoring profile
46
We will only cover in depth the daemon status and the numeric script. The other two are mainly the same and should only give you an idea of what else you can do. Again, there is almost nothing you cant monitor, so first think what makes sense in your environment, what saves you time, and which daily tasks can be automated, and then go to implementation.
3.2.1 Monitoring the status of the dsmserv daemon

Open the desired profile. If you click the button add monitor, you will be prompted for the type of monitor you want to add. Choose Unix_Sentry and then daemon status in order to monitor the Tivoli Storage Manager daemon. You have to fill in the name of the daemon in the field provided in our case, dsmserv. After clicking add empty, you will see the screen shown in Figure 21.
47
Figure 21. Monitor daemon status of Tivoli Storage Manager
You will now have to define the trigger levels and the according responses. If you are monitoring a daemon, you have only two possible conditions: up or down. 3.2.1.1 Response levels Tivoli Distributed Monitoring provides five different levels of response: 1. Critical (trigger level can be defined) 2. Severe (trigger level can be defined) 3. Warning (trigger level can be defined) 4. Normal (if none of the above conditions are met)
48
5. Always (triggers every time the monitor is executed) Additionally, you have several criteria to define these trigger levels. These depend on which kind of monitor you have for example, for daemon status, you might have the following monitor criteria: Is up/available Is down/unavailable Becomes unavailable Becomes available We prefer the criteria becomes available and becomes unavailable because these only generate an event if the status is changing. So you only get a message once. Otherwise, every time the monitor is executed, it will generate a message. Imagine a condition where the monitor is executed every minute, and the event generates an E-mail from Friday evening until Sunday morning. Your mailbox probably will not be capable of holding all the messages! So, in our case, we chose critical when the daemon becomes unavailable and warning if it becomes available again. This will give you feedback when the daemon is up again. If someone has restarted the daemon, you will still know that is was down. 3.2.1.2 Actions The available actions that can be executed if a certain condition is met are listed below: Send Tivoli notice: This will post a message into a notice group. Popup: This will create a message on the specified administrators desktop. Change icon: This will change the icon of an indicator collection. Tasks: Any defined Tivoli task can be executed. Send E-mail to: Send an e-mail to the specified address(es). Log to file: Writes the event into a log file on any host. Run program: Runs any executable on any host. Send enterprise console event: Generates a Tivoli Enterprise Console event at a certain severity level. Since we are having a Tivoli Enterprise Console server in our environment, this is the suggested way of treating events. On the TEC server these events
49
are being processed according to rules. This again can include tasks, mails and so on. See the Tivoli Distributed Monitoring Users Guide 3.6, GC31-8382. 3.2.1.3 Scheduling Additionally, you have to specify the schedule of the monitor, for example, 5 minutes. This can include exceptions on weekends, shift hours, and so on. See Chapter 6, Tivoli Enterprise Console on page 85. 3.2.1.4 User mapping Tivoli provides a user mapping facility to take care of the different platforms on which monitors can be run. There are variables which are mapped according to the platform known to the Tivoli Framework. The two predefined mapping are: 1. $root_user On a UNIX-platform, for example, this maps to root, and on a Windows NT platform, it maps to Administrator. 2. $root_group On an AIX system, for example, this maps to system, and on a Windows NT platform, it maps to Administrative users. With these mappings, you can select the user environment under which the monitors are executed on the targets. See Figure 22.
Figure 22. User and group ID to execute the monitors
If you need to customize or to add your own user/group mapping, you can do this. See the Tivoli Framework 3.6 Users Guide, GC31-8433.
50
3.2.2 Custom script monitors

The next example we want to show involves reporting a certain condition via a custom script and integrating it into a Tivoli Distributed Monitoring monitor. 3.2.2.1 Defining shell scripts In this example, we used one of the sample scripts provided by Tivoli Storage Manager. You can import these scripts to your Tivoli Storage Manager server by running: dsmserv runfile /usr/tivoli/tsm/server/webimages/scripts.smp This will provide you with some sample scripts which can be used to monitor specific conditions inside your Tivoli Storage Manager. The one we chose is q_scratch_stg, which gives back the percentage of allowed scratch volumes used in a storage pool via an SQL select statement. It returns the value in a numeric figure, which then can be monitored by setting triggers to the response levels in Tivoli Distributed Monitoring. The first step consists of writing a shell script which logs in to Tivoli Storage Manager server using the batch mode of the administrative command-line interpreter dsmadmc. For security reasons, it is suggested that you create an unprivileged operator account in your Tivoli Storage Manager for these monitoring issues. The script then passes the command to run the script, and the returned value is piped through some shell commands to get only the desired numeric figure.
#!/bin/ksh dsmadmc -id=tivoli -password=tivoli "run q_scratch_stg tapepool" \ | grep TAPEPOOL | tr -s " "|cut -d " " -f2
To test the script, execute it on the shell prompt first. It should look like this:
brazil:/ > ./monitor.sh 1.000
3.2.2.2 Using shell scripts in a monitor Now, to import this script into Tivoli Distributed Monitoring, we add a new monitor from the universal monitoring collection with the name Numeric script. Then you have to provide the full path for the script you created. After adding it, you should get a screen like the one shown in Figure 23.
51
Figure 23. Universal numeric monitor with custom script
3.2.2.3 Response levels As in the previous example, you can now set the triggers and the according response levels and actions. Note that numeric triggers have different comparative patterns than, for example, the daemon status monitor. You can define the trigger levels by these criteria: Greater/less than Equal/not equal to Increase/decrease And many more
52
Again we encourage you to use increase/decrease instead of greater/less than, to keep the number of events at a lower level.
General rule for events
The less events you generate, the more you can focus on the really important ones. You shouldnt produce as many events as you can. The skill is to extract only the information that needs (automated) action, and to report only the events that need attention from a human administrator. All others (such as informational messages) can go into the log of the application or the operating system, but should not go into Tivoli.
3.2.2.4 Distribution actions If you deploy a custom script in a monitor, this script needs to be copied to the target machine where the monitor is supposed to run. Tivoli provides a way to do this at the profile level. You can define distribution actions where you can either copy file(s) and/or run program(s). In our case, we need to distribute our script to the target machines. See Figure 24.
Figure 24. Distributing a custom script
You should be aware that these files are being copied as the user nobody, group nobody. So make sure your destination directory has write access for this user.
53
3.3 Hints and tips

Having an unprivileged, operator account on Tivoli Storage Manager for monitoring purposes makes it more secure. With custom monitors which are using dsmadmc and select commands, you can get any information out of Tivoli Storage Manager. If you have Tivoli Enterprise Console, forward your events instead of acting in TDM. Be careful when using automated tasks to resolve problems. Dont forget to use distribution actions to distribute your custom scripts to Endpoints or Managed Nodes. Scripts are being distributed under user nobody. So be sure this user can write to the directory of the target machine. Using increases/decreases beyond will generate only one event instead of every time the monitor fires when using greater/less than.
54
Chapter 4. Tivoli Software Distribution

Tivoli Software Distribution is the key component used to install, configure, and update software on network systems. It can be used for distributing and deploying software across multi-platform networks.
4.1 Overview of Tivoli Software Distribution

Tivoli Software Distribution is part of the Tivoli Framework. It uses its components to distribute software and to report the results back to the Framework and other modules. The Tivoli Software Distribution module uses several objects for distributing software. See Figure 25.
Framework
Tivoli Software Distribution
distribute packages
RDBMS
Managed Node
Managed Node
gateway
distribute packages
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 25. Tivoli Software Distribution
4.1.1 Source host

An object from which software is updated is called the source host. You can use any UNIX or Windows NT Managed Node in the same management region, after installation of Framework and Software Distribution.
55
4.1.2 Target
Tivoli Software Distribution supports the distribution of file packages and autopacks on Managed Nodes, PC Managed Nodes, Netware Managed Sites, and Endpoints. Endpoints are connected to an Endpoint Gateway to the rest of the Tivoli environment. The Endpoint Gateway uses multiplexed distribution (MDist) for distributing the software to Endpoints.
4.1.3 Repeaters
A repeater is an object in Tivoli Software Distribution used for multiplexed distribution service. The TMR server itself is, by default, the repeater distribution server for all hosts in the TMR. Endpoint Gateways are automatically repeaters for their Endpoints. For performance-effective software distribution, you need to create a repeater hierarchy that reflects the network topology. By default, the TMR server is automatically set as a repeater. Endpoint Gateways are also repeaters for their Endpoints. To minimize network and server loads, also consider putting a Managed Node as a repeater on each side of a slow network link. This allows you to avoid copying binaries across slow links multiple times. If you are always using specific servers as source hosts, from a performance point of view, it is desirable to use repeaters. Also, if the repeater contains too many clients, you need to distribute the load among multiple repeaters, according to our network topology.
4.1.4 File package

A file package is a Tivoli Software Distribution object that contain references to the files and directories for distributing, and rules on how to apply these files and directories. Nested file package: In a file package, you can include another file package, which creates a nested file package. You use this option for distributing files from more than one source host, to run different configuration programs for different parts of a single distribution, or to distribute sets of files with different properties. There is no limit on the number of nested file packages.
4.1.5 Autopack
Autopack is a similar object as a file package. It provides a faster and easier way for creating a file package on Windows platforms. With the autopack utility, you automatically create a list of files, which needs to be distributed, and you can record registry changes, desktop icons, and profile changes.
56
4.2 Installation
Using Tivoli Software Distribution, first you prepare the package to be distributed; and second, you distribute the package (possibly multiple times). For detailed steps, refer to Figure 26.
1
The administrator creates the autopack files on Prep machines.
2 3
The administrator transfers the autopack file to the Source Host.
The administrator: Creates the SD profiles, identifies the targets, and distributes the SD profiles to the targets.
4 6
Connection to Source Host and transfer of data
3 6
7 3
3 4 4 8 8
Figure 26. Tivoli Software Distribution process
57
The numbers in Figure 26 refer to the numbered steps below: 1. Depending on your requirements, you first prepare a file package or an autopack. For an autopack, we recommend that you select a machine with a clean installation of the operating system. In the picture this machines are labeled as Prep Machines. You will be installing the Autopack Control Center on these machines and building an autopack of files, which must be included in a software distribution profile. The machine on which you build an autopack is not necessary a part of the Tivoli environment. 2. You now transfer the autopack files to the source host. 3. The next step is creating a software distribution profile. For this, you need a policy region which has the file package, autopack, and profile manager set as managed resources. In this policy region, you choose an existing profile manager or are creating a new one. A profile manager is a collection of profiles and subscribers. You create an autopack or a file package profile and distribute the profile immediately or schedule the distribution of profile. The profile manager can also be distributed or scheduled. The profile itself does not contain data, only references and rules for files which reside on the source host. A part of the profile properties are actions which can be executed before or after distribution or upon a commit request. The notification options are set on that level as well. 4. Actions before distribution are executed on the targets. 5. The Managed Node communicates directly with the source host, and the transfer of data from the source host to the Managed Node takes place. Upon distributing, actions (if defined) are performed on the Managed Node. 6. The Endpoint Gateway hosting the TMA Endpoint communicates directly with the source host and the transfer of data to the Endpoint Gateway occurs. Then the Endpoint Gateway uses the MDist mechanism to distribute the data to its associated target TMA Endpoints. Actions upon distributing (if defined) are performed on the TMA Endpoint. 7. Acting as a resource host for the PC, the Managed Node, where the PC Managed Node object resides, communicates directly with the source host and the transfer of data to the Managed Node takes place. Then the Managed Node uses the MDist mechanism to distribute the data to its associated PCs designated as targets for the software distribution. Actions upon committing (if defined) are performed on the PC. 8. Actions upon commit (if defined) are performed on the targets.
58
4.3 Setting the environment

For Tivoli Software Distribution, you must first install Tivoli Software Distribution Server. This package is installed on the TMR server, where software distribution profiles are defined; and on any Managed Node, where you will create software distribution profiles, or where you want to run software distribution commands from the command line. This package must also be installed on any Tivoli NetWare repeater if the distribution target is a NetWare PC hosted by a NetWare Managed Site. The Tivoli Software Distribution Gateway package contains the software distribution methods and needs to be installed on all Managed Nodes that you will configure as Endpoint Gateways. A machine running a Tivoli Management Agent needs to communicate to its assigned Gateway in order to download any methods necessary to execute management operations.
4.3.1 Profiles
For distributing software, you must first create a software distribution profile, which can be a file package or an autopack profile. See Figure 27.
Figure 27. Create Profile
59
4.3.1.1 File package properties Additionally, you must set the properties of the software distribution package. Selecting the source host and the files and directories is the first step. Then you select any nested file packages. These packages must exist before you can import them to a profile. You cannot create circular nested packages. Under the general options section, you can choose whether the distribution should stop if an error occurs. For transferring complete directory structures, you check Descend into directories. In case you do not select this option and distribute directories, an empty one is created on the target. Append source path to remote path allows you to append complete structures from the source to the target directory. Otherwise, only files or directories are created in the destination directory of the target. With Perform compression on distribution, the data is compressed on the source host before it is transferred to the target and decompressed on target. The next option is File Mode at Destination. By default, Preserve mode of the source files is selected. You can override this by selecting Change mode of source files to, and writing an octal chmod number. For PCs only, valid values are 4 for read, and 6 for read and write. In the Log Information Options section, you can choose to send information about software distribution to a notice group, e-mail, or to a log file. In the edit menu are platform specific options. Depending on our distribution targets, you can set actions Before Distribution, After Distribution, Upon removal or During Commit. See Figure 31 on page 63.
4.3.2 Creating packages

We show below how to create packages ready for distribution. 4.3.2.1 Autopack For autopack, you select Prep Machine and install Autopack Control Center from Tivoli Software Distribution CD. See Figure 28. In the next step you create a baseline snapshot of our operating system. The system is being scanned for files, directories and registry entries. See Figure 29.
60
Figure 28. Autopack main menu
Then you install the software you want to include in Autopack. After software is installed, you start Autopack Control Center again, and choose Build AutoPack.
Figure 29. Scanning the system with Autopack Control Center
61
The system is being scanned again and changes are written to a set of files in the destination directory. You might change some values in those files manually, especially in the .chg file, which contains a list of changes for this Autopack. After that, you select build Autopack to create Autopack. Autopack Control Center then creates a .pak file, which contains all binaries, directories and registry entries in the directory that was specified as staging directory. See Figure 30.
Figure 30. Build Autopack
The next step is creating an Autopack profile. In the previously created profile manager under Type, you select Autopack. In options for this profile, you select from where the Autopack file should be copied and the directory and file name on the source host. 4.3.2.2 Linux client For installation of the Tivoli Storage Manager backup-archive client for Linux, you use a file package. The client software is distributed as an .rpm file. You create a profile in a profile manager and under Properties select Source Host and names of the files you want to distribute. See Figure 31.
62
Figure 31. File Package Properties
For installation, you can set different scenarios, for our requirements. With the Linux client, you want to distribute files to the target and execute an installation script. After the Backup/ Archive Client files are on the target machine, you execute the installation script. For the Linux platform, you select Unix Options. In Run a Program section you select After Distribution and in After Distribution Program Options type the name of the script and select where to get this program from. Because the .rpm format already includes the installation script, our script only needs to execute the .rpm. See Figure 32.
#!/bin/sh /bin/rpm -i --force /tmp/TIVsm-BA-3.7.2.0-1.i386.rpm
63
Figure 32. Unix After Distribution Options
In the commit stage of the software distribution is the task to create the dsm.opt and dsm.sys files for our requirements. You enter the commit script in the Commit Distribution Program Options section. During the upgrade of the clients, you can skip the commit stage, because those files already exist.
4.3.3 Distributing packages

After you create a file package, and set all options for all platforms, you can distribute the package. The package can be distributed directly to targets or
64
profile managers. Using drag and drop is the same, as is distribution of all files with Distribute Only options on all selected targets. With File Package and Distribute, you open the distribution options window. Our first choice is Distribution Type, where you can choose between Distribution Only, Distribution & Commit, and Commit Only. The first two options are running together with pre-installation and post-installation scripts, while Commit Only runs only commit programs. In the Available Subscribers section, you select the subscribers. Under File Package Distribution Preview, you can observe the list of files and directories that you selected to distribute. In case the source files are corrupt or missing, they are not shown on the preview list. For distributing files later, you can use the Tivoli Framework scheduler. See Figure 33.
65
Figure 33. Distribute File Package
66
4.4 Hints and tips

If you want to browse files on Endpoint, you must first enter the Endpoint name manually. If the Endpoint platform is Windows, then you must change the default browse path from root (/) to the drive letter you want to browse (c:/).
67
68
Chapter 5. Tivoli Inventory

In this chapter, we explain the Tivoli Inventory product in more detail. Again, we provide samples to show what can be done to help the Tivoli Storage Manager administrator to get more work done in less time.
5.1 Tivoli Inventory concepts

Figure 34 shows the Tivoli Inventory as part of the Framework, interacting with the RIM, the RDBMS, and the target machines. Inventory collects information about hardware and software that can be reviewed by inventory queries.
Framework
Tivoli Inventory
RDBMS
distribute inventory profiles

Managed Node
collect inventory data
Managed Node
gateway
distribute inventory profiles collect inventory data
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 34. Tivoli Inventory
In order to better understand the examples, we first cover the components of Tivoli Inventory and how they interact with each other.
69
5.1.1 Tivoli Inventory components

The Tivoli Inventory application can be viewed as having two main components: The collection engine The database interface and query facility Tivoli Inventory consists of the collection engine and some Tivoli Inventory specific views for the query facility. The Relational Database Interface Module (RIM) and the query facility are part of the Tivoli Framework. What we have called the collection engine is divided into two install images: 1. Tivoli Inventory Server Package This package is installed on the TMR server, where profiles are defined. These profiles contain instructions for scanning target machines. The machine where this package is installed is called the Tivoli Inventory Server. 2. Tivoli Inventory Gateway Package A machine running a Tivoli Management Agent needs to communicate to its assigned Gateway in order to download any methods necessary to execute management operations. The Tivoli Inventory Gateway Package contains these inventory methods and needs to be installed on all Managed Nodes that you will configure as Endpoint Gateways. A scanning agent is part of this package and is downloaded to the TMA Endpoint when needed.
5.1.2 Tivoli Inventory installation

During the installation of Tivoli Inventory, the following happens: An instance of the RIM object is created and is called inventory. This instance of the RIM object defines the connection between the Tivoli Inventory application and the RDBMS server via an RIM host. The RIM host is a machine where an RDBMS client is installed and which is enabled to communicate with an RDBMS server, or is the RDBMS server itself. The RIM host must be a Managed Node in the TMR. The configuration repository defines all of the tables and fields where the inventory information is stored. The relational database containing these tables can reside either on the same machine as the Tivoli Inventory Server or even on a machine outside the TMR, whereas the RIM host where the RDBMS client is installed must be a Managed Node in the TMR. The data can be queried using the Tivoli desktop menus or the query facility.
70
Some scripts and files are also installed with Tivoli Inventory: Database vendor-dependent scripts to create the schema of the inventory database. The schema determines the structure of the tables of the inventory database. Inventory query scripts create queries that return general information about the machines in your TMR. Subscription query scripts to create queries that return lists of possible subscribers for profiles based on various scan results. A software signature file: A software signature is a set of information that defines a software package. This information is used to determine which software packages are installed on the machines you scan. Inventory 3.6.2 has over 10,000 software signatures available in a file. Additionally, tools are provided that allow a customer to add their own software signatures to the database.
5.1.3 Tivoli Inventory scan

The following describes a typical order of events involved in an inventory scan. By initiating a scan, the administrator activates a scanning software residing on every system from which information is to be collected. This can be anything from a single system to every system in the enterprise. On each scanned system, the hardware and software scanners create a DMTF-compliant, industry-standard, Management Information Format (MIF) formatted flat file containing the results of the scan. Depending on the resources which you have selected to scan, the following will happen:
Scanning TMA Endpoints () Figure 35 illustrates the Tivoli Inventory architecture when scanning Endpoints. The scanners running on the TMA Endpoints produce MIF files. On the TMA Endpoint, the MIF files are parsed, archived, and differentiated if this option is selected in the scan profile. Then, the files resulting from parsing MIF files are converted to a format that can be saved in an RDBMS database and sent to the Endpoint Gateway.
The Endpoint Gateway sends these files in RDBMS format to the TMR server. These data are used to populate the configuration repository via the Relational Database Interface Module (RIM). The RIM object on the TMR server calls the RIM host where the RDBMS client resides and the RIM host contacts the RDBMS server.
71
During a scan, you can specify if you want to save configuration files such as the autoexec.bat or /etc/hosts, or the Tivoli Storage Manager related dsm.opt or dsm.sys. If you have chosen this option and are scanning TMA Endpoints, the configuration files copied during the scan are sent to the Endpoint Gateway, which sends them back to the TMR server. These configuration files are stored in the TMR servers database.
Figure 35. Tivoli Inventory architecture when scanning Endpoints
Scanning the machines in your environment for the first time can be time-consuming, because data has yet to be collected. After you have done a full scan on the machines once, you can use the inventory profile that is set to compare the results of the current scan with the results of the previous scan; so, it will occur faster.
72
Note
Inventory scans target machines in parallel, but writes the collected information to the configuration repository serially; so, it is important that the network connectivity between the TMR, Inventory server, RIM host, and the RDBMS is sufficient and configured for optimum operation. Also, inventory does not save the information to the configuration repository until all targets of the distribution are scanned.
5.2 Examples
These examples are designed to stimulate your imagination they arent intended to be taken as-is. If you go through them and find yourself thinking: I would do this in another way, then the lesson is already learned.
5.2.1 Inventory profiles

In this section we show three examples of inventory profiles: 1. Hardware scan 2. Software scan 3. Saving of configuration files In Figure 36 you can see a screen showing this three inventory profiles and their subscribers. As with other modules, you have to set subscribers to the profiles in order to distribute them to the target machines. There is only one default Inventory scan profile, so upon creation, a default one will appear. You then have to customize it to the designated function.
73
Figure 36. Profile manager with inventory profiles and subscribers
5.2.1.1 Hardware scan To create an inventory profile which scans the hardware of your machines, open the profile manager which is supposed to house your inventory profiles. If you are using Endpoints as subscribers, make sure that this profile manager is in dataless mode, and that Inventory Profile is a managed resource of your current policy region. See Figure 37.
74
Figure 37. Inventory profile manager and query libraries
Create an inventory profile and open it for customizing. You will get the following screen (Figure 38).
75
Figure 38. Inventory scan for hardware
76
When you are scanning only for hardware, then only the upper part of the screen is important. Be sure that only hardware scan is selected, and that the appropriate MIF files are created. For more about MIF files, see the Tivoli Inventory Users Guide, GI10-8048. Then save and close, and you can now distribute this inventory profile to the target machines. It will scan for all hardware which is known to inventory. This includes processors, memory, file systems, hard disks, BIOS information, and so on. To keep up-to-date with changes made to the machines, you should schedule these scans with the Tivoli Framework scheduler. 5.2.1.2 Software scan In order to create an inventory profile for scanning software, create another profile called sw_scan and open it for customizing (Figure 39). The execute on target should be software scan and read results to Software MIF file. The save results in database section is for incremental (update with differences) or replace all collected information. End user access relates to Tivoli Userlink which we dont cover in this book. See the Tivoli Inventory Users Guide, GI10-8048. When you are not having separate inventory profiles for each platform, it is recommended that you scan all files with all extensions. Thats because executables in UNIX platforms dont need extensions, but on Windows platforms, extensions are required. After changing the values, you can save and exit. To run the software scan, distribute the profile to the subscribers. This scan normally takes a while for each machine to perform, and your database will be quite busy. Although the scans run parallel on all targets, the results are being written to the database serially after all scans have finished. So no updates are visible as long as the scan is running.
77
Figure 39. Inventory scan for software
5.2.1.3 Saving config files (dsm.opt/sys, recovery plan) In addition to hardware and software scans, you can save information about configuration files with Tivoli Inventory. In normal environments, this will be /etc/hosts or autoexec.bat, and so on.
78
However, you can also save the contents of the dsm.opt/sys file and your Tivoli Storage Managers recovery plan file. This is especially useful when these files have been altered or deleted, since you cant access the Tivoli Storage Manager server to restore them, if they dont exist. If you choose Store as ASCII they will be copied to the database directory of your TMR server ($BINDIR/inventory/ objectid/...). See Figure 40.
Figure 40. Storing configuration files as ASCII through inventory profile
In order to keep track of changes to these files, you can schedule the distribution of the scanning profiles.
79
5.2.2 Queries
The previous section showed how to retrieve information into the repository database. Now, we will consider how to make use of this collected data. Tivoli Inventory provides a wealth of predefined inventory queries to retrieve information from the repository. This can be machine specific or information specific. To issue machine specific queries, you can right-click on the target specifying hardware, software or generic query. 5.2.2.1 Hardware queries See Figure 41 for a hardware inventory of a four-way RS/6000 on AIX (partially displayed).
Figure 41. Sample hardware query
The following list provides some examples of queries that might provide useful information regarding a Tivoli Storage Manager administrators clients: Harddisks Size (for capacity planning). Logical Volumes Size of file systems (for bare metal restore, capacity planning). Network cards Full or incremental backups, additional bandwidth needed.
80
Processor, memory, paging space Determine if compression should be on or not. 5.2.2.2 Software queries For Tivoli Inventory to recognize which software products are installed on a target (rather than just knowing which files are on), you have to provide Software Signatures. They consist of stanzas for each Software product which include a filename, its size, the name of the product and its version. With this unique combination, Tivoli Inventory recognizes a software product which then can be queried. For standard products, these signature files are provided by Tivoli and are updated regularly. They can be downloaded from the Tivoli support Web site http://www.tivoli.com/support. Note that special products (including Tivoli products), are not provided. However, if you add them manually, they are especially useful for Tivoli Storage Manager administrators. The command wfilesig is used to import software signatures into Tivoli Inventory. The syntax is:
wfilesig [-a|-r] [-n name -s size -d description -v version]
The parameters are -a for adding and -r for removing certain products. Here is a sample of creating a custom signature:
wfilesig -a -n dsmc.exe -s 1036288 \ -d Tivoli Storage Manager Backup/Archive-Client Win32 -v 3.7.2
An explanation of how to use the wfilesig command can be found by typing man wfilesig or in the Tivoli Inventory Users Guide, GI10-8048. This will make Tivoli Inventory recognize the Tivoli Storage Manager Backup/Archive client version 3.7.2 on the Windows platforms. With this information stored in the repository database, you can create a custom query to list all the Tivoli Storage manager clients and versions on all client machines. To create such a custom query, open a query library (for example, INVENTORY_QUERIES). Create a query and change it, using the values in Figure 42.
81
Figure 42. Custom query TSM clients
The where clause, which is hard to see in the figure, should be: SW_COMP_NAME like Tivoli Storage Manager Backup/Archive-Client % The % is the wildcard character of SQL. This will select from the table SW_COMP_NAME all the entries that begins with the above pattern.
82
This will give you the client names which have the Tivoli Storage Manager backup-archive client installed in any version on any platform. If you run this query, you should get output similar to that shown in Figure 43.
Figure 43. Query results of custom TSM client
Then you can conveniently view the software levels of your Tivoli Storage Manager Clients and decide which eventually have to be upgraded and so on. Additionally, using the predefined software queries, you can identify the client machines which have special applications installed, like MS SQL or Exchange, and which need special treatment to backup their data (Tivoli Data Protection). Again, use your imagination to extend these examples to your needs in your environment. Since the possibilities are so widespread, we can only make suggestions. Tivoli Enterprise and its modules are so universal, almost anything can be realized customizing is the key.
83
5.3 Hints and tips

If you are running multiple scans on multiple machines, make sure your database log is big enough. Queries over multiple views or tables can take a significant amount of time and CPU to proceed. If you have large fileservers, dont scan all files. Search only specific directories. If your company is developing software, create software signatures for these products as well. There are queries and signatures for fix-levels and PTFs.
84
Chapter 6. Tivoli Enterprise Console

This chapter explains basic Tivoli Enterprise Console components and how to set them for the Tivoli Storage Manager Enterprise environment.
6.1 Introduction
Tivoli Enterprise Console (TEC) is a management product that allows you to apply customized actions on different events from different sources, such as operating systems, network management data, databases, or applications events. In TEC, all these events from the IT environment are brought together in one place, which offers the administrators a centralized and filtered view of the enterprise-wide events. See Figure 44.
Framework
Task Libraries
actions
send events
RDBMS
Managed Node
gateway
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 44. Tivoli Enterprise Console
85
6.2 Overview of the Tivoli Enterprise Console

The Tivoli Enterprise Console collects, processes, and sets actions based on predefined rules. It allows you to effectively process events in a distributed environment with setting the level of importance of events, filtering out less important, correlations on events from other sources, setting the limits on view and action possibilities for specific administrators, and reacting automatically, when this is needed. The main components of Tivoli Enterprise Console are: Event Adapters Event Server Event Consoles See Figure 45. To facilitate implementation of the Tivoli Enterprise Console, the following tools are provided: Tivoli Event Integration Facility (EIF) for customizing and creating new event adapters Tivoli Adapter Configuration Facility (ACF) for graphical configuration and distribution method of event adapters
Client
Adapter
Event Source Raw Events Formatted Events
Event Server
Formatted Events
Rules
Event Console
Filter
Filter
Processed Events
RDBMS
Figure 45. Tivoli Enterprise Console event flow
Every system has integrated mechanisms for monitoring the state of the components. Those informations are usually collected in log files, where they are filtered by the system itself. In our schematic overview, we will call this an event source. The filtered event source is monitored by the event adapter. In a log file scenario, the event adapter is a small portion of code running on the system and parsing informations out of the system or application log file. Devices incapable to host programs, like routers, have their adapters on nearby systems. Raw events collected by the event adapter are then filtered again. With this filter you can limit the data flow through the network. Those
86
filtered events are formatted by the event adapter into a form, the event server can understand. Filtered and formatted events are sent to the event server. When the event server receives events which does not fit in the correct format, they are discarded. See Figure 45. The server reception engine is responsible for reception of events. When an event arrives, the reception engine validates and gives a unique identifier, which is the composite of time stamp and serial number. If the reception engine is busy, it stores events in a reception buffer. All events are recorded in a reception log, so you can check for discarded events. The next stop for events is the rules engine. It applies rules on events. A part of the rules engine is the rules cache. Events are temporarily stored in the rules cache in case of correlation with other events, for updating event values (called slots) or to reapply and process the rules on events again. The rules are made of a unique name, description, conditions and actions. There are three types of rules. Plain rules are evaluated against all incoming events, change rules for changing specific slot values and timer rules for redo analysis. From the rules engine events are passed to the dispatch engine, which updates the event consoles. The dispatch engine also communicates with the task engine and the event repository. The task engine executes tasks and scripts, and returns the status of actions back to the dispatcher engine. The event repository stores all processed events in its RDBMS. Synchronization of all processes is done by the master process. Events are then displayed on the event console. See Figure 46.
87
Figure 46. Components of the TEC Event Server
Event console is the administrators interface for communication with TEC. Each of administrators have their own console. When the console is started, it displays two windows. The first is a collection of source groups. In the second event groups are displayed. For each administrator we have assigned event groups and upon those, event sources are displayed. With assigning of event groups you can set access and view priority. The event console allows administrators to select the events by severity and status, to sort events by parameters like date, host name severity and so on and setting the fields which are displayed for each event. The administrators can use manual tasks or create automatic responses on specific events.
6.2.1 Event adapters

The event adapter is the portion of code which runs on the client system and captures formats and sends the event to TEC. Already provided event adapters are: AS/400 Alert adapter
88
AS/400 Message adapter Logfile Event adapter Netview for OS/390 adapter NetView/6000 adapter OpenView adapter SNMP adapter Spectrum Enterprise Manager adapter Sun Solstice/SunNet Manager adapter Tandem NonStop Kernel adapter Windows NT Event Log adapter The adapters can be different, but they have some common files. Communication between the adapter and TEC server is configured via the adapter configuration file (.conf). Error logging and tracing is configured with the error file (.err). Logfile adapters are using format files (.fmt) for parsing informations from the log files. Format files must be consistent with the event definition file (.baroc). This files are provided and can be distributed as a profile. In graphical environment you can set parameters like filters, environment or location of files. See Figure 47.
89
Figure 47. TEC Adapter profile
6.2.2 Event classes

Formatted events are received by the event server and are checked against the event definition file. The type of events is defined with the event class. Events which do not match any of the event classes, are discarded by the event server. The event class definition file contains, beside class definitions and hierarchical structure, also slot definitions. Slots are names for possible values, the adapter can receive. In the class definition, you can set default values for the slots.
6.2.3 Rules
Received events are now ready to be processed by the rules engine. The rules are grouped together in rule sets. On the server each rule set is one file (.rls). A rule base is made of multiple rule sets and class definition files. Rules, described in the rule set files, must match class definitions. The order of loading rules is described in a file called rule_sets, and the class order in load_classes. See Figure 48.
90
Figure 48. Rule Bases
Rules are written in the TEC rule language and then compiled together with the class definitions. With TEC, you can also use the graphical rule builder. After installation of the TEC server you have a Default rule base and you can copy it into a new one, together with rule sets and class definitions. You can have multiple rule bases, but only one can be active.
6.2.4 Handling of the messages

In the Tivoli Storage Manager server messages are in form of three letters called prefix which explains source of the message followed by four numbers which is actual message number and one letter for message type. See Figure 49.
91
Figure 49. Tivoli Storage Manager message
With Tivoli Storage Manager server is provided class definition file with name ibmtsm.baroc. In this file type and default severity of events are defined. For getting the correct level of severity you must translate Tivoli Storage Manager severity to TEC severity (Figure 50). Forwarding those messages to TEC is controlled by putting the information about TEC event server in opt file and enabling or disabling specific messages. For easier setting of messages you have script called ibmtsm.mac. In this script first all messages are disabled, than enabled severity types error and severe, followed by enabling messages from other severity types, which could be important for Tivoli Storage manager administrator. In next section a series of different syntax errors are disabled. In the end of this script is the client section. For clients info and warning severity messages are disabled and enabled with severity error and severe for all nodes. This is first filtering level of events. All enabled messages are forwarded to TEC, where they are mapped into events.
92
Message mapping
Messages

UNKNOWN
Tivoli Storage Manager server

INFO WARNING ERROR SEVERE
HARMLESS WARNING MINOR CRITICAL FATAL
ppp nnnn I ppp nnnn W ppp nnnn E ppp nnnn S
Figure 50. Translating Tivoli Storage Manager messages into TEC Events
Default severity of all events which do not have value for severity in IBMBACKUP class is set by ibmtsm.baroc file on CRITICAL. For changing that setting, you must change this file, replace existing event class definition file with new one, compile the rule base, import rule base and restart the event server.
6.3 How to prepare TEC for Tivoli Storage Manager

To integrate Tivoli Storage Manager into the Tivoli Enterprise, you have to execute a few tasks and prepare TEC for Tivoli Storage Manager.
6.3.1 Importing files for Tivoli Storage Manager

The latest maintenance level of Tivoli Storage Manager server ships with a class definition file and a rule set file, which need to be imported into the active rule base. Since you can not modify the Default rule base, you create a new rule base and copy the class definition files and rule sets you need. In the Tivoli Desktop main window, you select event server and with a right click select Rule Bases. In the Event Server Rule Bases window, you then select Create Rule Base and type in the name and the directory of the new rule base. See Figure 51.
93
Figure 51. Rule Base Properties
To make a copy of the Default rule base you right click on Default rule base and select Copy, select new rule base as destination and check boxes for class definitions and rule sets. See Figure 52.
Figure 52. Copy Rule Base
We created a new rule base with a copy of the default class definitions and rule sets. In case that you dont want to have some of those files, you must delete unwanted entries from rule_sets and load_classes files, except root.baroc and tec.baroc in that order, because there are slot definitions for inheriting classes. Now you can import the Tivoli Storage Manager files. You select Import with right click on our rule base. See Figure 53.
94
Figure 53. Import Into Rule Base
Into this dialog window you type the name of the file, you want to import. In our case under rule set is ibmtsm.rls and select position of this rule set with selecting the existing rule set and Insert Before and Insert After radio buttons. You repeat this with class definition file, which is called ibmtsm.baroc. You have to position at least after root.baroc and tec.baroc and finish the procedure with Import & Close click. After importing of files, you have to compile our modified rule base. With right click you select Compile from the menu. In dialog window you select Compile. See Figure 54.
95
Figure 54. Compile Rule Base
In case that event definitions and rules are inconsistent or their are syntax errors in files, compile will fail. The last step of import is loading the rule base. You again right click on rule base and select Load. See Figure 55.
Figure 55. Load Rule Base
In this window you have two choices. First one is Load and activate the rule base. You must choose Load, but activate only when server restarts, because event definition files are loaded only with server restart and if you make any change in class definitions, then you have to restart the event server.
6.3.2 Creating event group for Tivoli Storage Manager

For filtering out Tivoli Storage Manager events you need to create separate event group and assign this group to the appropriate administrators. With
96
right click on the event server icon you select Event Groups. In Event Group Management window you have list of existing event groups. See Figure 56.
Figure 56. Event Group Management
In this window you open new event group creation dialog with Event Group, New. In next dialog window you type in the name of the new event group and select an icon. You can import new icons with Import Bitmap option. See Figure 57.
97
Figure 57. New Event Group
After you created new event group, it does not contain any filters. Filters are set for selecting type of events, you want to see in the specific event group. To set the filters you have to select Edit and Edit Filters. In this dialog window you select appropriate filters. For all events which are generated by Tivoli Storage Manager you click Event Class button in Filter Values section and from list of available event classes select IBMBACKUP. With Set Class Value and Add Filter buttons you add this filter to event group. In case that you want to add additional information to this event group, you can set additional filters or if you want to distribute information on several event groups, then you must replace this filter with subsided. For getting the events from only selected nodes you type in or select appropriate node in origin section. See Figure 58.
98
Figure 58. Edit Event Group Filters
After creating of an event group or more of them, you have to assign this event groups to administrator. You can assign one event group to multiple administrators, but you must ensure that administrative rights are logically set. Assign is done by selecting with the right mouse button administrators event console option Assign Event Groups. In this dialog window you select event groups for each administrator and security privileges on these groups. Event sources are selected automatically based on event groups event classes selection. See Figure 59.
99
Figure 59. Assign Event Groups
In case that you need to change event group name or to delete it, we recommend that you first unassign event group from all administrators.
6.3.3 Display setting of the event console

Administrators event console is used for displaying event to administrator and as tool for responding manually or automatically to the events. When you open event console two windows with title TME 10 Enterprise Console are automatically opened. One is for displaying the source groups. There are options to display source groups in text mode and to sort source groups vertically. Second one displays event groups. See Figure 60. In this window you can choose: Severity Display for setting text colors, background colors and icons or different severities Event Group Display for setting the event group icons and enable or disable display of event group title, severity text, date and time Rearrange Groups for setting the order of the event and source groups Message Time Limits for setting time limits for displaying and keeping open or closed messages. This dialog box enables option to view some old events Netview Connections to establish connection between TEC and Netview server and Netview maps
100
Figure 60. Event Groups display
When you open event group, the list of events is displayed. In View menu you have first Sort Messages. In this dialog box you set the sort keys and order. By default the events are sorted first by status and than by severity. In the last column you select row header. You can choose any of available slots. To sort events first by the date you must move the date in the Sort By window and shift it to the top. See Figure 61.
Figure 61. Sort Event Group Messages
101
With selecting Display Message Field you set the fields of events which are displayed out of the event slots. In the event window of the event group you have list of events, sorted by our criteria. On the top is Update ON button which enable or disable live updating of events in that event group. Below you have check marks for including types of events by severity and status. Status is when event arrives open. Administrator can either acknowledge or close event. To acknowledge the event user privileges in that event group are required and for closing admin rights. When administrator acknowledge or close the event, the administrator slot gets value of the administrators desktop login.
6.3.4 Creating an automated task

With Tivoli Enterprise Console you can set task which run automatically, when the selected event is received. To create automated task, you have to go to the enterprise console events window and select Automated Task from menu. You can select the event first and than in menu New with Selected Event if you already received event on which you want to react. See Figure 62.
102
Figure 62. Tivoli Enterprise Console Events
Option without selecting the event class, prompt you for this with pop up window. You select event class, upon which you want to have automated task. See Figure 63.
103
Figure 63. Select Event Class
With Select & Close button or with New with Selected Event from main menu, you open Summary of the Automated Task window. Here there are two main windows. In the left are filters for this event and in the right window there is a list of the actions you have set. You can set the order of execution for actions with buttons on the right side of the window. See Figure 64.
Figure 64. Summary of the Automated Task
104
With Edit Criteria button, you invoke window in which you set the filters for this event. Filters are set on the event slot values. You select slot from the Available Slots and with double click or with right arrow on the top add filter. Then you select operator with pull down menu. Available options are: Equals Less than Less then or equal Greater then Greater then or equal Contain Does not contain In the value field you type in the criteria value. Values from the last selected event are automatically fill in. With Enter or click on check mark sign you add filter to the events automated task. After you are finished with adding the filters, you add those filters with Set & Close button. See Figure 65.
Figure 65. Setup Automatic Task Execution
105
With Add Task button in Summary of the Automated Task window you open the dialog for adding and configuring task. You must select the task first. Selection list is made of all existing task in our framework. In the left list you have list of task libraries and with double click you fill the right window with tasks available within this task library. With selecting the task the area bellow is filled with tasks configuration parameters you have to fill in. See Figure 66.
Figure 66. Automated Task Execution Setup
With selecting where to execute the task between Execute on Event or Execute on select Managed Nodes from the pull down menu and button Add or Add & Close you add task to the Summary of the Automated Task window. With saving of the automated task you finish the configuring.
6.3.5 Setting the severity of TEC events

Setting of the default severity for the event class sets severity for all events in that event class without severity slot value. In example you will set default severity of class IBMTSM_BASE_SERVER to warning and IBMTSM_BASE_CLIENT default severity which maps all client messages to harmless. You already created rule base named itso with default directory in: /usr/local/Tivoli/bin/aix4-r1/custom/TEC_CLASSES. First step is to edit the
106
necessary sections in ibmtsm.baroc. The sections of this file after editing will look similar to this:
TEC_CLASS : IBMTSM_BASE_SERVER ISA IBMBACKUP DEFINES { severity: SEVERITY, default= "WARNING"; source: default = "TSM"; tsm_message_severity: INTEGER; tsm_message_number: INTEGER; sub_source: default = "TSM_SERVER"; tsm_server_platform: STRING; }; END TEC_CLASS : IBMTSM_BASE_CLIENT ISA IBMBACKUP DEFINES { severity: SEVERITY, default= "HARMLESS"; source: default = "TSM"; tsm_message_severity: INTEGER; tsm_message_number: INTEGER; sub_source: default = "TSM_BACKUP_ARCHIVE_CLIENT"; policy_domain: STRING, default = "STANDARD"; schedule_name: STRING, default = "none"; session_id: INTEGER, default=0; comm_method: STRING, default = "TCP/IP"; owner_name: STRING, default = "none"; }; END
We changed default = values of these sections. In our example you already have working environment with imported ibmtsm.baroc class definition file, so you must delete existing on from the rule base:
wdelrbclass ibmtsm.baroc itso
Than you have to import new file into the rule base:
wimprbclass /usr/tivoli/tsm/server/bin/ibmtsm.baroc itso
In the next step you compile edited rule base:

wcomprules itso
Compilation of the rule base will fail with the message Compilation Failed, if you make any errors in syntax or in order of loaded classes. Screen output allows you to pinpoint the error. Then load the compiled rule base:
wloadrb itso
107
Stop and start the event server:

wstopesvr wstartesvr
The last step is necessary, because TEC loads event classes only at server start. For testing purposes you can generate events on TEC to test severity of these events:
wpostemsg -m 'Test of severity settings' IBMTSM_BASE_SERVER TSM wpostemsg -m 'Test of severity settings' IBMTSM_BASE_CLIENT TSM
6.3.6 Deleting rule sets

For better performance during the processing of the rules and compilations of the rule set it is recommended that you remove all unnecessary rule set and class definition files. First you list rule sets and class definition files in the rule base:
wlsrbrules itso Rule Set files -------------log_default.rls sentry.rls ibmtsm.rls do_something.rls
This command list the rule set files in rule base. For class definition files you must use Tivoli Desktop or list the content of the configuration file for classes. You must find out, where the configuration file of our rule base are. Command which list directories of rule bases is:
wlsrb -d Rule Base Name -------------Default itso Directory ------------------------------------brazil:/usr/local/Tivoli/bin/aix4-r1/TME/TEC/default_rb brazil:/usr/local/Tivoli/bin/aix4-r1/custom
In home directory of the rule base there are three more subdirectories: TEC_CLASSES TEC_RULES TEC_TEMPLATES. This directories includes classes, rules and templates for the rule base. In the TEC_CLASSES subdirectory, you can find file .load_classes. This file has the
108
list of the class definition files for our rule base. The list of the contents of this file should look like this:
brazil:/ > cat .load_classes root.baroc tec.baroc tecad_logfile.baroc tecad_nt.baroc Sentry.baroc universal.baroc tivoli.baroc tecad_sd.baroc ibmtsm.baroc
We edited the file and removed the entries which were not needed. When you are changing the rule base, you have to take care, that class definition files are defining all event classes which are used in rules. Also, the order of the class definition files must be in the order which classes are built. After changing the event classes or rules, you have to compile and load the rule base. For changing the classes, starting and stoping the TEC event server is required.
109
110
Chapter 7. Tivoli Plus Module for ADSM

The Tivoli Plus module for ADSM is a collection of predefined tasks and jobs for additionally managing the ADSM and Tivoli Storage Manager servers in Tivoli Enterprise. See Figure 67.
7.1 Components of Tivoli Plus Module

Figure 67 shows the components of the Tivoli Plus module for ADSM.
Framework
Plus Module for TSM

- Tasks - Jobs - Profile Managers - Indicator Collections - Monitors
Managed Node
gateway
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 67. Tivoli Plus Module for Tivoli Storage Manager
Tivoli Plus for ADSM creates a generic collection for managing Tivoli Storage Manager servers and clients. In this collection you can find icons for launching servers, clients, and administrative clients. Subscription lists are predefined for ADSM Servers, ADSM Clients, HSM Recall Servers, and HSM Space Monitor Servers. Distributed Monitoring profiles are added with monitors for host availability, network collisions per packet, database, and log utilization percentage.
111
The Tivoli Plus module provides tasks and jobs for backup and archive operations on Tivoli Storage Manager clients and for administrative clients. See Figure 68.
Figure 68. ADSMPlus for Tivoli menu
7.2 How it works

The Tivoli Plus module for ADSM extends integration between Tivoli Enterprise and Tivoli Storage Manager servers and clients by adding already defined organizational structure of monitors, indicator collections, tasks, and jobs. You must install this module on every node from which you want to perform TSM tasks, and on the TEC server. Nodes can be Managed Nodes or Endpoints, including TMR and TEC servers.
7.3 Setting up the Tivoli Plus Module

After installation of the Tivoli Plus Module for ADSM on all nodes, you must first check and modify subscription lists in the provided profile managers. These lists must be synchronized with the Tivoli Storage Manager environment. These profile managers are not in dataless Endpoint mode.
112
The graphical environment does not allow changing of the profile manager setting, and you must use the command: wsetpm [-d | -D]. For example:
wsetpm -d @ProfileManager:ADSM Clients
This example sets the provided profile manager ADSM Clients in dataless mode, so you can set Endpoints as subscribers. Another option is to set other custom-created profile managers as subscribers. The next step is setting the correct home setting for the server, client, and administrative client files. The home directory should point to the directory where binaries for specific clients are located. See Figure 69.
Figure 69. Set ADSM Home menu
To monitor the state of the servers, you must customize distributed monitors. You check each profile manager and populate them with the monitors that you consider useful. The Tivoli Plus module provides an additional monitor in numeric script format for database and log size. Then you set limits, severity, and response values for each of those monitors. Parameters vary, and depend heavily on the production environment. After setting the monitors, you need to set their schedules. Again, you must consider the environment, setting timers that will get meaningful results and that will not overload systems and network connections. The next step is distribution of the prepared monitors. For this, you can use an already-prepared profile manager called ADSM Servers. Distribution can be scheduled or executed immediately. The final task is to check subscribers for the jobs, especially in multiple Tivoli Storage Manager server environments. There are some limitations using the Plus Module with Endpoints, especially during the installation.
Chapter 7. Tivoli Plus Module for ADSM
113
Note: The majority of the tasks in the ADSM Plus Module will be integrated into the next server release, and the product will be discontinued.
7.4 Hints and tips

The default path for the Tivoli Storage Manager client in Windows NT is C:\Program Files\Tivoli\TSM\baclient. Because of the fields in this path, you must use directory names without extended attributes. In this case you must set the path C:\Progra~1\Tivoli\TSM\baclient. In Set ADSM Home task for Admin Client parameter on Windows NT, the task fails because the script expects the dsmadm.exe file, which no longer exists in the TSM administrative clients. The workaround is to create a file with that name in the same directory as dsmadmc.exe, and set the home parameter again. Another possibility is to modify the script (setadsmhome.sh) for setting parameters. You must set all parameters of Set ADSM Home task, otherwise the scripts are not executed.
114
Chapter 8. Tivoli Data Protection for Applications

This chapter briefly covers some possible integration scenarios with Tivoli Enterprise. Although the Tivoli Data Protection for Applications modules are not directly connected to the Framework, they are a substantial part of Tivoli Storage Manager, thus necessitating their integration in system management applications. Application servers are usually widespread in various departments; however, they need to be monitored and managed centrally.
8.1 Overview
Figure 70 shows the interaction of the Tivoli Data Protection for Applications modules with the rest of the modules.
Framework
Task Libraries
events
Managed Node
RDBMS
data events
Managed Node
gateway
Application
TDP
tasks
Endpoint
RDBMS
Figure 70. Tivoli Data Protection for Applications
115
8.2 Event forwarding to Tivoli Storage Manager

By doing backups and restores of your data from the applications, events are logged against the Tivoli Storage Manager event receivers. By default, these events are activity log and server console. For example, by setting up the Tivoli event receiver, events are forwarded to the Tivoli Enterprise Console. This includes messages from the server itself and client messages from the Tivoli Data Protection modules. The latest versions of Tivoli Storage Manager and the Tivoli Data Protection modules are enabled for enhanced TEC event forwarding. This means that there are special TEC classes for messages originating from the Tivoli Data Protection modules. When these messages arrive at the Tivoli Storage manager, they are translated into unique TEC messages, such as TSM_TDP_EXCHANGE_ACN####. This feature allows for faster filtering and more efficient rule generation within the TEC server. Additionally, individual TDP messages can be enabled or disabled for the TEC event receiver on an individual node basis.
8.3 Using tasks

Since all the Tivoli Data Protection modules are able to use scripts for automating backup/restore actions, they are ideal for using Tivoli tasks. If the machine where the application and its TDP module resides is a Tivoli Endpoint or Managed Node, you are able to run tasks against it. Some Tivoli managers for applications, for example, Tivoli Manager for Microsoft SQL server, are shipping with predefined tasks to execute full or incremental backups of the application. This enables you to respond to certain events with backup action (event triggered backup). For example, when you get the event indicating that the mirror or the RAID array where your application data resides is degraded, you can make a full backup of your application. Another situation that concerns most administrators is offline backup of an application. You can determine if your application is down, by using TEC events, and then make your backup. After the backup is completed, which is again determined by TEC events, you can start the application again. An example of this situation is provided in Part 3 of this redbook. Tivoli Storage Manager and Tivoli Enterprise, together with Tivoli Data Protection and Tivoli Managers, enable you to automate whatever you want.
116
8.4 Using Tivoli Software Distribution

In order to deploy the Tivoli Data Protection for Application modules to your clients, you can use Tivoli Software Distribution. Figure 71 shows the main screen of Tivoli Data Protection for MS Exchange.
Figure 71. Tivoli Data Protection for MS Exchange
As an example, we show you how to create a file package for the MS Exchange TDP client. 1. Copy the files from your TDP CD onto your hard disk, for example, to a directory like this: c:\temp\tdp_exch.
Chapter 8. Tivoli Data Protection for Applications
117
2. Create an unattended installation file. This is done by running the setup.exe from the TDP installation path with parameter -r.
setup.exe -r
This will create a file called setup.iss in your winnt directory. Copy this file to c:\temp\tdp_exch. 3. Create an installation batch file called setup.bat. It should include the following lines:
c: cd c:\temp\tdp_exch c:\temp\tdp_exch\setup.exe -SMS -s
4. Copy all the files and subdirectories within c:\temp\tdp_exch to your TMR server or any Managed Node in our example, /swd_stag/tdp_exch on the TMR server. 5. Create a Software Distribution Profile in a profile manager (for example, tdp_exch). 6. Go to Properties of the Software Distribution Profile. Enter Source Host and Directory and check the button Descend into Directories. 7. Edit Platform specific Options for Windows NT. 8. Point the Destination Directory Path to c:/temp. 9. In the After Distribution dialog, enter the path to the installation batch file c:/temp/tdp_exch/setup.bat. 10.Set and close. Now you are ready to distribute this software package to your Exchange servers.
8.5 Hints and tips

Exclude database files from normal backup (because they are always open). If you are involving all modules, events, and tasks, documentation is crucial. Make diagrams, flow charts, and so on, for every event/action cycle, and test everything thoroughly. Make sure that your network is stable, or better yet, fault tolerant. If the events are not getting through, there can be no action. Find out from your application administrators what they want to monitor. The Tivoli Managers for Applications come with many predefined monitors, tasks, and possibilities for managing the application itself.
118
Chapter 9. Tivoli Enterprise features of Tivoli Storage Manager

Tivoli Storage Manager is an enterprise-wide product integrating highly automated network backups, restore, archive, storage management, and disaster recovery. Tivoli Storage Manager is fully functional without Tivoli Enterprise, but added benefits such as monitoring and software distribution are attained when Tivoli Storage Manager is integrated with Tivoli Enterprise and other Tivoli products.
Tivoli Storage Manager integration with various Tivoli products The following points are the important issues that enable an organization to customize their solutions according to their organizational needs and growth:
Integration with Tivoli Disaster Recovery Manager to provide intelligent, automated disaster recovery for business continuance Integration with Tivoli Space Manager to make the most efficient and economical use of distributed storage resources by migrating rarely-accessed files. Integration with Tivoli Decision Support for historical trending analysis. Integration with Tivoli Data Protection for Applications to enable backups of major ERP applications, email, and databases. Integration with Tivoli Enterprise to enable additional monitoring capabilities. In this chapter, we cover the Enterprise features of Tivoli Storage Manager.
9.1 Tivoli Storage Manager enterprise features

The essential information about Tivoli Storage Manager enterprise is diagrammed in Figure 72.
119
Framework
events
RDBMS
data
Operating system
Tivoli Storage Manager Backup/Archive Client
events
Figure 72. Tivoli Storage Manager event forwarding
We must emphasize that we do not cover all of the Tivoli Storage Manager concepts in this book. In order to integrate Tivoli Storage Manager with Tivoli Enterprise, and to monitor and manage the system centrally, it is necessary to set up the following: Server-to-server communication Event server for central logging Forwarding of events to Tivoli Enterprise Console
120
Tivoli Storage Manager provides capabilities for managing a network of servers. Server-to-server communication is part of the base Tivoli Storage Manager component that gives servers the capability to communicate with each other. Server-to-server communication is enabled by a series of definitions made on the servers. Configuring server-to-server communications is a prerequisite for the following Tivoli Storage Manager Enterprise features: Configuring and managing multiple servers with an enterprise configuration. Storing data on another server using virtual volumes. Managing servers from any server: distributing a consistent configuration for Tivoli Storage Manager servers through a configuration manager to managed servers. By having consistent configurations, you can simplify the management of a large number of servers and clients. Central logging: monitoring many servers and clients from a single server. Enterprise logon and command routing: performing tasks on multiple servers by using command routing, enterprise logon, and enterprise console. Enterprise event logging: sending server and client events to another server for logging.
9.1.1 How to set up server-to-server communication

In this example, we use the following terminology, as shown in Figure 73: Master server (ACMEMASTER) The server on which server definitions are created. Slave server (ACMESLAVE) The server or servers defined by the master server.
121
ACM EM A STER 9.1.151.61
AC M ES LAV E 9.1.15 0.113
9.1.150.113:1500
crossdefine
Figure 73. Server-to-server communication, enterprise administration
Slave server setup

Slave server definitions: Example:
set servername ACMESLAVE set serverpassword secret_pswd set crossdefine on
To check that the server definitions are correct, issue query status command.
q status Server Name: ACMESLAVE Server Low Level Address: Server URL: Crossdefine: On Server Password set: Yes
122
Master server setup

Master server definitions: The following four definitions on the master server are passed to the slave server and used by that server to perform crossdefined operation of the master server on the slave server. Example:
set set set set servername ACMEMASTER serverpassword serverpasswd serverhladdress 9.1.151.61 serverlladdress 1500
To check that the server is defined correctly, issue the query status command:
q status Server Name: ACMEMASTER Server High Level Address: 9.1.151.61 Server Low Level Address: 1500 Server URL: Crossdefine:off Server Password Set: Yes
Server definitions Define the slave servers on the master server. This is done with the crossdefine option set on the slave server, which allows a server definition for the slave server on the master server, and a server definition for the master server on the slave server.
Server definitions on master server example:
define server ACMESLAVE serverpassword=secret_pswd hladdress=9.1.150.113 lladdress=1500 crossdefine=yes
9.1.2 Configuring and managing the servers

The enterprise configuration functions of the Tivoli Storage Manager enterprise administration feature make it easier to consistently set up and manage a network of Tivoli Storage Manager servers. You can set up configurations on one server and distribute the configurations to the other servers. You can make changes to configurations and have the changes automatically distributed.
123
To use enterprise configuration, you first select the Tivoli Storage Manager server that is to act as the configuration manager. You may want to dedicate a new server for this purpose. At the configuration manager, you define the details of the server configurations that you want to distribute. For example: You set up backup and archive policies and client option sets. You designate one or more administrators to have access to the servers, and control their authority levels. You define the servers that you want the configuration manager to manage or communicate with, and you set up communications among the servers.
9.1.3 Storing data on another server

Tivoli Storage Manager lets one server store data in and retrieve data from a storage pool of another server. This data, stored as virtual volumes, can include database and storage pool backups, disaster recovery plan files, and data that is directly backed up, archived, or space managed from client nodes. The data can also be a recovery plan file created by using Tivoli Disaster Recovery Manager (DRM). The source server (slave server) is a client of the target server (master server), and the data for the source server is managed only by the source server. In other words, the source server controls the expiration and deletion of the files that comprise the virtual volumes on the target server. This function is available through a licensed feature, server-to-server virtual volumes.
9.1.4 Managing servers from any server

Enterprise management allows you to manage the servers in your network from many locations. For example, suppose you are an administrator responsible for servers located in different departments within your company. The servers have some requirements in common, but also have many unique client requirements. You can set up the environment as follows: Set up an existing or new Tivoli Storage Manager server as a configuration manager. Set up communications so that commands can be sent from any server to any other server. Define any configuration that you want to distribute by defining policy domains, schedules, and so on, on the configuration manager. Associate the configuration information with profiles. Have the managed servers subscribe to profiles as needed.
124
Activate policies and set up storage pools as needed on the managed servers. Set up enterprise logging by setting up one server as an event server. The event server can be the same server as the configuration manager or a different server. After setting up in this way, you can manage the servers from any server. You can do any of the following tasks: Use Tivoli Enterprise Console to monitor all the servers in your network. Perform tasks on any or all servers using the Tivoli Enterprise Console and command routing. Manage the group of servers from anywhere in the network. Allow local administrators to monitor and tune their own servers.
9.1.5 Central monitoring

Tivoli Storage Manager provides you with several ways to centrally monitor the activities of a server network: Enterprise event logging, in which events are sent from one or more of servers to be logged at an event server. Allowing designated administrators to log in to any of the servers in the network with a single user ID and password. Routing query commands to one or more servers in the network. Enterprise logon and command routing Enterprise logon allows administrators to seamlessly access multiple Tivoli Storage Manager systems. The administrative IDs and passwords to be used must be the same on all servers that will be accessed. The password expiration period for the servers should be set to the same value through the SET PASSEXP command. Command routing allows an administrator to send commands from one Tivoli Storage Manager server to one or more Tivoli Storage Manager servers that the administrator is authorized to access. The following configuration must be performed to enable administrative command routing: Crossdefined server definition must exist between the server where the commands will be issued and the server to which the commands are routed. The administrative ID and password on the server issuing the commands must also be valid on the server where commands are to be routed.
125
Command syntax:
servername:administrative command
Example:
acmemaster:q db
Enterprise event logging This feature enables a server to route the events from a server and its clients to another server defined as event server. Tivoli Storage Manager server and client messages provide records of events of Tivoli Storage Manager activity, which Tivoli Storage Manager administrators can use to monitor Tivoli Storage Manager. See Figure 74.
Tivoli Storage Manager (Slave)
Tivoli Storage Manager Event Server (Master)

Activity Log
Client Messages
Server Console
Event Rules Server Messages
Events
Event Rules
File
User Exit
Tivoli Event Console
Figure 74. Server-to-server event logging
9.1.5.1 How events are routed to the master server One or more servers can send events to the master server for central logging. Tivoli Storage Manager provides an event receiver at the sending/slave server to receive the enabled events from clients and slave server and then routes them to the designated event server. At the event server, administrators can enable one or more receivers for the events being routed from slave server.
126
This is an example of how event logging works. The administrator at each sending/slave server does the following: Identifies the event server:
define eventserver ACMEMASTER
Enables the logging of severe, errors and warning server messages from the sending/slave server and also error messages from all clients to the event server receiver:
enable events eventserver severe,error,warning enable events eventserver severe,error nodename=*
Tivoli Storage Manager installation package includes a macro ibmtsm.mac. You can modify this macro for your requirements and run it in Tivoli Storage Manager to enable or disable the events you wish to monitor. The following is an example of ibmtsm.mac. This is part of the original file ibmtsm.mac:
/* -----------------------------------------------------------------/* macro to enable recommended messages to Tivoli event receiver /* TSM Server Development, 17 Dec 1999 /* -----------------------------------------------------------------/* server events /* start with no info or warning and all error and severe events /* -----------------------------------------------------------------DISABLE EVENTS TIVOLI ALL ENABLE EVENTS TIVOLI ERROR ENABLE EVENTS TIVOLI SEVERE /* -----------------------------------------------------------------/* enable more important info or warning events /* -----------------------------------------------------------------ENABLE EVENTS TIVOLI ANR0400 /* begin client session ENABLE EVENTS TIVOLI ANR0403 /* end client session ENABLE EVENTS TIVOLI ANR1400 /* mount denied - canceled DISABLE EVENTS TIVOLI ANR0572 /* export/import syntax/value errors DISABLE EVENTS TIVOLI ANR0574 /* export/import syntax/value errors DISABLE EVENTS TIVOLI ANR0575 /* export/import syntax/value errors */ */ */ */ */ */ */
*/ */ */ */ */ */ */ */ */
In the following example, we have changed the file (Tivoli is replaced with eventserver) in order to forward events to the event server.
/*------------------------------------------------------------------ */ /* macro to enable recommended messages to eventserver event receiver */ /* TSM Server Development, 17 Dec 1999 */ /* ------------------------------------------------------------------ */ /* server events */
127
/* start with no info or warning and all error and severe events */ /* ------------------------------------------------------------------ */ DISABLE EVENTS eventserver ALL ENABLE EVENTS eventserver ERROR ENABLE EVENTS eventserver SEVERE /* ------------------------------------------------------------------ */ /* enable more important info or warning events */ /* ------------------------------------------------------------------ */ ENABLE EVENTS eventserver ANR0400 /* begin client session */ ENABLE EVENTS eventserver ANR0403 /* end client session */ ENABLE EVENTS eventserver ANR1400 /* mount denied - canceled */ DISABLE EVENTS eventserver ANR0572 /* export/import syntax/value errors */ DISABLE EVENTS eventserver ANR0574 /* export/import syntax/value errors */ DISABLE EVENTS eventserver ANR0575 /* export/import syntax/value errors */
Logging events to Tivoli Event Console Tivoli Storage Manager includes the Tivoli receiver, a Tivoli Enterprise Console (TEC) adapter for sending Tivoli Storage Manager events to the TEC.
In the server option file (dsmserv.opt), specify the location of the host on which the TEC is running and begins the event logging for the Tivoli receiver.
techhostname 9.114.11.236
Begin event logging for the Tivoli receiver. You do this in one of two ways: To begin event logging automatically at server start up, specify the following server option:
tecbegineventlogging yes
Or enter the following command (this is a one-time command, so we recommend taking the first choice and defining it in a server option file):
begin eventlogging tivoli
Then the administrator enables the events by issuing the ENABLE EVENTS command for each sending server. For example, for enabling events for ACMESLAVE, the administrator enters:
enable events tivoli all servername=ACMESLAVE
128
9.2 Predefined items

The file ibmtsm.baroc, which is distributed with the server, defines the Tivoli Storage Manager event classes to the TEC. Before the events are displayed on a TEC, you must import ibmtsm.baroc into an existing rule base or create a new rule base and activate it.
9.3 Example of event logging

In Figure 75, we show you an example of event logging for an event from slave server to master server and then to TEC.
Tivoli Storage Manager (Slave)
Tivoli Storage Manager Event Server (Master)

Activity Log
Client Messages
Server Console
Event Rules Server Messages
Events
REC
Event Rules
File
Server Messages
User Exit
Tivoli Event Console
Figure 75. Event logging
To forward an event ANR1400 mount denied/canceled from server ACMESLAVE to event server ACMEMASTER and then to TEC, do the following: On server ACMESLAVE, enable the event ANR1400 by issuing following command:
enable events eventserver ANR1400
On event server ACMEMASTER, enable events receiving and forwarding to TEC by issuing the following command:
enable events tivoli ANR1400 servername=acmeslave
129
When event receiver on server ACMESLAVE receives an event with event number ANR1400, it checks it with event rules to see if this event is enabled or not. The event ANR1400 will be routed to the master server. On the master server Receiver Engine REC receives the event ANR1400 and forwards the event to TEC, where it will be handled in order the rules set for each specific event.
Testing event logging You can test that the event logging is working as it should by issuing the EVGEN command.This command generates an event with the event number specified by you. By querying the activity log, you can see if your event is generated.
For example:
evgen 1400 q actlog ANR2017I Administrator ADMIN issued command: EVGEN 1400 ANR1400W Mount request denied for volume - mount canceled.
9.4 Hints and tips

Most of the manual checks can be automated and monitored centrally by TEC. Make a list of events you find useful to monitor and enable these events for event logging. For example, check if backup is missed, event number ANR2578.
130
Chapter 10. Tivoli Service Desk

The Tivoli Service Desk application is designed to handle all issues concerning its three components throughout the enterprise. These can be of special interest for a Tivoli Storage Manager administrator. Tivoli Service Desk can contribute especially in supporting customers, who have problems with their installation or operation of Tivoli Storage Manager clients. In this chapter we show how to customize Tivoli Service Desk enhancements to integrate with Tivoli Storage Manager and other Tivoli products like Tivoli Inventory. However, we do not cover the components of Tivoli Service Desk, or its structure. The complete suite of products is too extensive to fit in the scope of this redbook. Therefore, our starting point will be a complete and functional installation of Tivoli Service Desk. If you need additional information on setup or structure, refer to other documentation mentioned in Appendix B, Related publications on page 161.
10.1 Overview
Tivoli Service Desk (Figure 76) is a standalone product, because: It does not require any Framework components. In its operation, it does not require any other products. However, it can be configured to interoperate in the following ways: You can start the Tivoli Storage Manager administrative Web client. You can gather asset information from Tivoli Inventory. You can generate problem records triggered by TEC events (not covered).
131
Framework
Tivoli Inventory
data migration
events
RDBMS
launch web admin client
Tivoli Service Desk

RDBMS
Figure 76. Tivoli Service Desk
10.2 Customizing Tivoli Service Desk

In order to access the features mentioned above, you must customize the Tivoli Service Desk profile for your administrative user. For these examples, we use the built-in user EXAV. After logging in to Tivoli Service Desk, you will see a window similar to the one shown in Figure 77.
Figure 77. Tivoli Service Desk main window
After a standard installation of Tivoli Service Desk, there will be no menu entries for starting the Tivoli Storage Manager administrative Web client, nor
132
for the integration of Tivoli Inventory. In order to add these entries to the menus, the steps described in the following sections are required.
10.2.1 Editing a Tivoli Service Desk user profile

In the Edit pull-down menu, you will find the entry Profiles. This starts the profile editor of Tivoli Service Desk. See Figure 78.
Figure 78. Configuration of a user profile in Tivoli Service Desk
You will need to choose the Profile Name you wish to edit. In our example for the user EXAV, this would be Tivoli Service Desk Administrator. Then, in the General tab of this screen, you must Add new action groups. Here you need Tivoli Framework Integration and Data Utilities. After this, you must add the specific action to either the tool bar or the menu. For adding this to
133
the menus, choose the Menu Items tab and click the Menu Bar button. The current menu bar appears, and you need to insert the action where you want it. We chose the Configuration drop-down menu. Finally, you need to add the system actions ADSM Web Administration and Tivoli Inventory Migration Utility. Choose an appropriate name to display the menu entries (for example, TSM Web Administration). An action group consists of system actions. The Tivoli Framework Integration action group includes the ADSM Web Administration system action (Figure 79).
Figure 79. Action groups in Tivoli Service Desk
As you can see in the lower end of the picture, the Tivoli Framework Integration action group is defined in the file tivint. Tivoli Service Desk builds its components from scripts, which are parsed to binary files. This enables you to modify each component and customize your environment.
134
Customizing functions
For example, the system action ADSM Web Administration starts only the server component on port 1580. You could add a procedure to the file tivint.kb to start the Tivoli Storage Manager Backup-Archive Web Client on port 1581. This would enable your helpdesk staff to help customers directly by restoring or backing up their files on their client machines. A system action, for example, ADSM Web Administration, calls a subfunction in the tivint file called ADSMInterface (Figure 80).
Figure 80. System actions in Tivoli Service Desk
If you want to know more about parsing scripts and customizing Tivoli Service Desk, see the Tivoli Service Desk Users Guide, GC31-5205.
135
After you have finished editing the profile, you must close the Tivoli Service Desk interface and restart it in order to see the changes you made.
10.2.2 Starting the Tivoli Storage Manager administrative client

Now you should see the menu item you added. Choose starting the Web client and you should see the following dialog box (Figure 81) on launching the Tivoli Storage Manager Web administrative client from Tivoli Service Desk.
Figure 81. Launching administrative client from Tivoli Service Desk
Enter the name of the Tivoli Storage Manager to which you want to connect, and your default browser should come up (Figure 82).
Figure 82. Tivoli Storage Manager Web administrative client
136
10.2.3 Migrating assets from Tivoli Inventory

To import information from the Tivoli Inventory database to Tivoli Service Desk Asset Management, you must set up an additional database connection. Since Tivoli Service Desk is not a part of the Tivoli Management Framework, it cannot use the RIM object to access the Inventory database. In our example, we are running the Tivoli Service Desk on a Windows NT server on Microsoft SQL server. The Tivoli environment is running on an AIX machine with DB2 as database. In order to access the DB2 Inventory database from the NT machine, you must install a DB2 client and configure it as an ODBC source. After this, you must start the TSDBuild application on Tivoli Service Desk and add the second database to the list of available databases (Figure 83).
Figure 83. Configuring the Tivoli Inventory database into Tivoli Service Desk
Then go to the main menu and, in the Asset Management pull-down menu, choose the Configure Asset Management entry. Go to the Migration tab and choose Tivoli Inventory and select the database source.
137
After that, from your previous added entry, choose the Tivoli Inventory Migration Utility. This will open a dialog box as shown in Figure 84.
Figure 84. Importing assets from Tivoli Inventory into Tivoli Service Desk
After you have clicked the Find button, the machines from your Tivoli Inventory repository should be displayed, and can be added to your Tivoli Service Desk database by choosing Migrate.
Note
Since this procedure is a migration, you should schedule it to keep track of the changes made to the Inventory database.
138
10.2.4 Opening a call in Tivoli Service Desk

Now, with the changes in place, you can respond to incoming problem records (Figure 85) by instantly opening the administrative Web client of Tivoli Storage Manager and by directly accessing asset information from your repository of machines.
Figure 85. Opening a call in Tivoli Service Desk
10.3 Hints and tips

Add your own actions to Tivoli Service Desk. Schedule the migration from Tivoli Inventory to keep track of changes. Post status messages from your Tivoli Storage Manager server environment to Tivoli Service Desk to allow the helpdesk staff to quickly resolve problems occurring from server outages, and so on.
139
140
Part 3. Putting it all together

Part 3 provides examples of using the various Tivoli products and modules to show how they can all work together to ease the load of the storage management staff.
141
142
Chapter 11. Examples

Here are few examples to show what can be done using tools provided by Tivoli Storage Manager and Tivoli Enterprise. Examples are written for specific scenarios, but with minor modifications, can be used in many situations. In the examples, some steps refer to procedures described in the previous chapters.
11.1 Updating the Tivoli Storage Manager backup-archive client

Let us consider an example of operating the Tivoli Storage manager in Tivoli Enterprise. In our scenario, the code for one of the Tivoli Storage Manager backup-archive clients is not up-to-date, and this produces an error. The administrator of TEC has created a rule which increases the severity of this event if there are more than two events within one week. At the same time, a message is sent to the Tivoli Service Desk (TSD) administrators for Problem Management, requesting that they open a Change Request to update the software code. The event is displayed on the administrators event console, and Tivoli Inventory can be used for querying the current software level data. After the Change Request from the Tivoli Service Desk is approved, an administrator performs an upgrade of the Tivoli Storage Manager backup-archive client with Tivoli Software Distribution. The result, a successful upgrade, is also sent to TSD. After software distribution has been accomplished, a software inventory scan is performed to update the clients data.
Implementation In a situation where a client has software code that is much older than the code on the server, it cannot access the server. This gives the error message ANR0428W:
ANR0428W Session session number for node node name (client platform) refused - client is down-level with this server version.
The explanation of this message shows that the client needs new software code for operating. The message type is W, which maps into Warning on Tivoli Storage Manager. Our first task is to make sure that this event is recorded by TEC. You need to check whether event logging on eventserver is on, what severity types are forwarded, and to which receivers.
143
To query the rules, you can use the following commands:

tsm: ACMESLAVE>query eventrules Date/Time Server Event Rules -------------------------------------------------------------------------06/01/00 17:29:12 DISABLE EVENTS EVENTSERVER ALL 06/01/00 17:29:12 ENABLE EVENTS EVENTSERVER ERROR 06/01/00 17:29:12 ENABLE EVENTS EVENTSERVER SEVERE 06/01/00 17:29:13 ENABLE EVENTS EVENTSERVER ANR5216 06/01/00 17:29:13 ENABLE EVENTS EVENTSERVER ANR5217
The result is the list of currently active rules. By default, messages with severity type warning are not included in supplied macro ibmtsm.mac. You can enable just this event, or the whole severity warning range of events. The commands for these tasks may only apply to this message:
ENABLE EVENTS TIVOLI ANR0428
Or, they can apply to all messages with severity type warning:
ENABLE EVENTS TIVOLI WARNING
The next checkpoint is the TEC event class definition file. You must list the class defined in our rule base. The list of all class definitions can be long, so it is better to grep out just our message:
brazil:/ > wlsrbclass itso | grep ANR0428 TSM_SERVER_ANR0428
To test that this message really comes to the TEC, you can simulate the message on Tivoli Storage Manager server with the command:
tsm: ACMESLAVE>evgen 0428
This should produce an event in TEC within TSM_SERVER_ANR0428 event class and warning severity. The next step is to create the rules and tasks for increasing severity and notifying Tivoli Service Desk operators. You need to open the rule base and edit or add a new rule set. With a right-mouse click, you select Edit Rules in the Event Server Rule Bases window. In the rule set window, you select Rule Set, New Ruleset, replace name new_set with another one, and click Enter to add this rule set to the rule base (Figure 86). Next, you select this rule set and open it with Rule Set, Edit Ruleset. Into this window, you must fill in rules for the event. With the graphical rule builder, you can create two types of rules. A simple rule is a rule in which you can use one event class. With a compound rule, you can correlate events from different classes.
144
Figure 86. Rule sets
First you create a rule for increasing severity, if an event repeats multiple times in a limited time window, and there is no response from administrators. You select New Rule, Simple. In the Description field, you type the description of the rule. With the Event Class button, you invoke a list of available event classes, and select the class for the rule. In our scenario, the correct class is TSM_SERVER_ANR0428. See Figure 87.
145
Figure 87. New Simple Rule
With the Conditions button, you open a window in which you can set conditions for this rule on each of the slots of the selected event class. In our scenario, you are going to apply this rule only on events which are not closed or acknowledged. In the condition window, you select status as an attribute. In the Relation pull-down list, you select Not in list, and in the Attribute Value(s) section, from the Select Value menu, you select CLOSED and ACK. With Add, you fill in the values after each selection. You can set multiple conditions. See Figure 88.
146
Figure 88. Condition in Rule
The next step is to set the actions. With the Actions button, you open this window, and select from the Add pull-down list: When frequency exceeds the limit. In the Actions section, you select Set severity from the menu, and under Set severity to, you enter the value MINOR. In the Edit When to Run section, you set the wanted frequency. You type in 3 under When frequency exceeds and 10080 under within a min. period. Click Enter to add this value to the action. The action can be observed in the Action Synopsis section of the window. See Figure 89.
147
Figure 89. Actions in Rule
Click OK for actions, and you have finished creating this rule. Next, you will add two more rules for sending e-mail to the TSD operators for opening the problem and placing a Change Request. For those rules, you do not need to set conditions, and actions can be from the TEC tasks library send e-mail. With Tivoli Service Desk and Enterprise Console integration, you can automate this task. Now you have three rules in your rule set. With Rule Set, Close, you go back to the rule base window, and you need to save the modified rule base with Rule Base, Save. What remains is to compile, load, and activate the rule base. This is explained in Chapter 6, Tivoli Enterprise Console on page 85. In this scenario, the administrators responsibility also includes importing the correct software signature to the inventory tables, distributing the scan profile, and executing software and hardware scans with Tivoli Inventory. These procedures are described in Chapter 5, Tivoli Inventory on page 69. After authorization or request from the Tivoli Service Desk operator, Tivoli Software Distribution can be used to upgrade the client. This example is covered in Chapter 4, Tivoli Software Distribution on page 55.
148
11.2 Extending the Tivoli Storage Manager recovery log

The next example is a scenario when the log is becoming full. You are going to observe the log with Distributed Monitors and events in the TEC console. When one of those conditions is fulfilled, then you want to create an additional Tivoli Storage Manager security log file and extend the log automatically.
Implementation You have the Distributed Monitoring monitor, provided by the Plus Module for ADSM, which measures occupancy of the Tivoli Storage Manager log, and you have event forwarding to the TEC. When the log is full, Tivoli Storage Manager posts a message to the activity log, which is forwarded to the TEC. Tivoli Distributed Monitoring monitors measure certain parameters in our scenario percentage of log full. When log occupancy exceeds the limits you set in the monitor, severity is changed. In the monitor, TEC forwarding must be enabled to display this event at the TEC console.
Both of these events will generate a new event, which will drop all events from those event classes in a specific time window, execute the necessary tasks, and after successful correction, close the event. This is necessary because you dont know which one of these events is going to trigger the action. First, you have to create a new event. For this, you need a new event class. You can add this class into the existing file or create a new one. Also, you have to consider where this event class is going to be in the event class structure. The new file could look like this:
brazil:/ > more custom.baroc TEC_CLASS: tsm_log_full_cust ISA EVENT DEFINES { msg: default = "Custom message for the log full event"; }; END
You must to import this file into the active rule base, compile the rule base, and restart the event server. The next task is creation of the rules. You need to create two rules, one for each original event. This rules should generate a new event from the previously defined event class. The monitoring data is mapped into the universal_ncustom class, and the Tivoli Storage Manager activity log message is mapped into the TSM_SERVER_ANR0130 class. The events must have critical severity and must not be closed.
149
You control the triggering level of distributed monitoring with mapping into severity. In our scenario, an event becomes critical if the log is more than 95% full. After generating a new event, the original ones are dropped. You set the severity of the new generated event to minor and drop any other event from this class, which the event server receives in a 15-minute time window. The frequency of monitoring probes is set by the parameter in the monitor itself. The rules could look like this:
brazil:/ > cat custom.rls rule: trigger_monitor: ( event:_event of_class 'universal_ncustom' where [ status: outside ['CLOSED'], severity: equals 'CRITICAL', hostname:_host ], action: ( generate_event('tsm_log_full_cust',[severity='MINOR', hostname=_host]), drop_received_event ) ). rule: trigger_log: ( event:_event of_class 'TSM_SERVER_ANR0130' where [ status: outside ['CLOSED'], severity: equals 'CRITICAL', hostname:_host ], action: ( generate_event('tsm_log_full_cust',[severity='MINOR', hostname=_host]), drop_received_event ) ). rule: drop_events: ( event:_event of_class 'tsm_log_full_cust' where [ status: outside ['CLOSED'] ], action: ( first_duplicate(_event, event:_dup_event where [status: outside ['CLOSED']],
150
_event - 900 - 900 ), add_to_repeat_count(_dup_event, 1), drop_received_event ) ).
For the action, you can create another rule manually or with the graphical rule builder, or you can use an automated task. Rule sets made by the graphical rule builder cannot be edited with the manual one. You will use the graphical rule builder for creating a rule that extends the Tivoli Storage Manager recovery log when the event server receives a generated event. You create a new rule set, and in this one, a new rule. In the Tivoli Plus Module for ADSM, you have a task for extending the log. So this rule could read: if the log is full or an event is not closed, then extend the log. See Figure 90.
Figure 90. Extend log rule
Besides the user name and password, this task requires the file name of the log file. You are going to use the date_reception value for the file name, because this parameter generates a number which represents the time. In this case, you get a unique file name for the recovery log file. In the rule builder, below the Select Task button, you have Edit Arguments. This button invokes the window for the parameters which are required for the specific task. In the Format string (optional) section, you type the tasks parameters.
151
Variables are invoked from the event slot values, which you must select. In our scenario you need to select the task itself and pass to the task information about task library, host name, where to execute the task, login parameters, and the name of the log file. If the file name already exists, the task will fail. See Figure 91.
Figure 91. Extend log arguments
The last step is closing the events. When log volume is added to the Tivoli Storage Manager, the message with code ANR2017I is generated. You are going to use this message to close previous warning for log full. For this, you can again use the graphical rule builder. You are going to close all events from this class in a 5-minute time window, if they are generated by the same host. See Figure 92.
152
Figure 92. Compound Rule
After successful creation of the recovery log files and extension of the recovery log, you get two confirmation messages. The first one is for successful creation of the log file, and the second one is for extend itself, so you must create a similar rule for that situation too. With this last rule, you close all events except information about the successful extend of the log with harmless severity, to notify the Event Console administrator.
11.3 Offline backup of the Exchange server

Periodically, you may want to make an image of your system, by stopping the database or groupware servers and then making a backup by file. In this example, you are going to use Microsoft Exchange 5.5 server, with Tivoli Manager for MS Exchange. In this scenario, you first stop the Microsoft Exchange server. When the server is stopped, you start the backup, and when the backup is finished, you start the Exchange server.
153
Implementation You begin the procedure with stopping the server. For managing the MS Exchange services, you can use already configured tasks and jobs from the Exchange Server Tasks task library. You have to schedule the Stop_Services_Job to run at a specific time, periodically. To add the job to the scheduler, you have to drag and drop the job icon in the scheduler icon, and you get the job parameters dialog window, where you need to select the services you want to stop. See Figure 93.
Figure 93. Stop_Services parameters
The next window with which you are prompted is the scheduler window. In this window, you need to fill in the time parameters of the scheduled job. For information about scheduler parameters, you can refer to Chapter 2, Tivoli Framework TME 10 on page 21. Tivoli Manager for Exchange with setup enables monitors to report the status of the event server. See Figure 94.
154
To separate the automated and planned stop of the Microsoft Exchange services from the manual stop or failures, you make a reference event. You schedule to post this event at the same time as stopping of the services. The event must be in its own event class, in order to have a clear message that the scheduled service stop occurred. You must create a new event class, create a job wit the send_event task from the T/EC Tasks task library, and schedule the job.
Figure 94. Send_Event task parameters
Our backup should start when the Exchange server stops, and only when it is scheduled. In order to avoid unnecessary triggering of the backup, you create a rule which starts the backup when the event you scheduled to be posted and the Exchange stop come in a 10-minute time window. Backup is done by posting the immediate client action to the client schedule. First you create a script for adding the immediate client action. A simple script is:
#!/bin/ksh /usr/tivoli/tsm/client/ba/bin/dsmadmc -id=admin -passw=admin def clienta aral act=i opt="-subdir=yes" obj="d:\exchsrvr"
From this script, you create a task for the Microsoft Exchange server backup. With trigger, condition and action you create a rule for backup:
155
rule: do_backup:( event:_event of_class 'exchg_sched_serv_stop' where [ status: outside ['CLOSED']], action: (all_instances(event:_exchg_ev of_class 'MSExchange_Event' where [ status: equals 'OPEN'], _event - 600 - 600 ), exec_task(_exchg_ev,'exch_back','-l "acme_task" -h "palana" -m "3600"',[],'NO')) ).
You will be using immediate client action because you need confirmation that the backup job has finished. When the backup job is finished, the Tivoli Storage Manager server forwards the event to the TEC console. This event is in the NT_Base event class, so you must first create a separate event class for this event and modify the Windows NT adapter file. Here is an example of class definition file modification:
TEC_CLASS: tsm_back_succ ISA NT_Base; END
For the Windows NT adapter format file, you take a file which is already modified by Tivoli Manager for Exchange and add a separate instance for a new event class:
FORMAT tsm_back_succ FOLLOWS NT_Base %t %s %s %s %s %s AdsmClientService %s %s %s Successfully Completed. category $3 eventType $4 id $7 END
Now you have information on when the Exchange backup is completed. When event from the tsm_back_succ event class is posted on the TEC event console, you execute the task from the Exchange Server Tasks task library Start_Services. The simple example of the rule could look like this:
rule: start_exchg:( event:_event of_class 'tsm_back_succ' where [ status: outside ['CLOSED']], action: (exec_task(_event,'Start_Services','-l "Exchange Server Tasks" -h "@MSExchange:Exchange_Server_aral" -m "3600" -a "Y" -a "Y" -a "N" -a "N" -a "N" -a "Y" -a "N" -a "Y" -a "N" -a "Y"',[],'NO')) ).
When starting the Microsoft Exchange server, you can close all remaining messages.
156
Appendix A. Special notices

This publication is intended to help storage administrators to understand how the features of Tivoli Enterprise can help them in their day-to-day activities and responsibilities. The information in this publication is not intended as the specification of any programming interfaces that are provided by Tivoli Storage Manager or Tivoli Enterprise products. See the PUBLICATIONS section of the IBM Programming Announcement for Tivoli products for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee
157
that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
IBM 400 Domino Lotus Lotus Notes Notes Redbooks Redbooks Logo S/390 SP SP1 SP2
The following terms are trademarks of other companies: Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything. Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems Inc., an IBM company, in the United States, other countries, or both. In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli A/S. C-bus is a trademark of Corollary, Inc. in the United States and/or other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group.
158
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
Appendix A. Special notices
159
160
Appendix B. Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
B.1 IBM Redbooks publications

For information on ordering these publications see How to get IBM Redbooks on page 165.
Book Title Publication Number Tivoli Enterprise Performance Tuning Guide SG24-5392 Tivoli Storage Manager Version 3.7: Technical Guide SG24-5477 A Project Guide for Deploying Tivoli Solutions SG24-5310 ADSM Operation and Management with TME 10 SG24-2214 ADSM Server for Windows NT Configuration and Recovery Examples SG24-4878 ADSM Server-to-Server Implementation and Operation SG24-5244 ADSM/6000 on 9076 SP2 GG24-4499 All About Tivoli Management Agents SG24-5134 An Industry Around the Tivoli Framework: Examples from the 10/Plus Association SG24-2122 An Introduction to Tivoli Enterprise SG24-5494 An Introduction to Tivoli's TME 10 SG24-4948 Backup, Recovery, and Availability with DB2 Parallel Edition on RISC/6000, SG24-4695 ADSM Client Disaster Recovery: Bare Metal Restore SG24-4880 Creating Custom Monitors for Tivoli Distributed Monitoring SG24-5211 Deploying a Tivoli Infrastructure in Large-Scale Environments SG24-5210 Designing Tivoli Solutions for End-to-End Systems and Service Management SG24-5104 Developing Plus Modules for Tivoli with the TME 10 Integration Toolkit SG24-2007 Getting Started with Tivoli Storage Manager: Implementation Guide SG24-5416 High Availability Scenarios for Tivoli Software SG24-2032 Implementing Tivoli Manager for Windows NT SG24-5519 Implementing Tivoli Remote Control in Large Enterprises SG24-5125 Laying the Foundation for Tivoli Modules SG24-5379 Managing Domino/Notes with Tivoli Manager for Domino, Enterprise Edition, Version 1.5 SG24-2104 Managing RDBMS Servers With Tivoli SG24-5240 Managing SAP R/3 with Tivoli SG24-5298 New Features in Tivoli Software Distribution 3.6 SG24-2045 Problem Management Using Tivoli Service Desk and the TEC SG24-5301 TEC Implementation Examples SG24-5216 Tivoli Enterprise Internals and Problem Determination SG24-2034 Tivoli Enterprise Management Across Firewalls SG24-5510 Tivoli Service Desk V6.0 - IT Infrastructure Planning Guide SG24-5312 Tivoli Storage Management Concepts SG24-4877 TME 10 Cookbook for AIX: Systems Management and Networking Applications SG24-4867 TME 10 Deployment Cookbook: Courier and Friends SG24-4976 TME 10 Deployment Cookbook: Inventory and Company SG24-2120 TME 10 Framework Version 3.2: An Introduction to the Lightweight Client Framework SG24-2025
161
Book Title
TME 10 Inventory 3.2: New Features and Database Support Using ADSM to Back Up and Recover Microsoft Exchange Server Using ADSM to Back Up Databases Using Databases with Tivoli Applications and RIM Using Tivoli Software Installation Service for Mass Installation Using Tivoli Storage Manager to Back Up Lotus Notes Using Tivoli to Manage a Large-Scale SAP R/3 Environment Using TSM in a Clustered Windows NT Environment Windows NT Backup and Recovery with ADSM
Publication Number SG24-2135 SG24-5266 SG24-4335 SG24-5112 SG24-5109 SG24-4534 SG24-5500 SG24-5742 SG24-2231
B.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs button at ibm.com/redbooks for information about all the CD-ROMs offered, updates and formats.
CD-ROM Title Collection Kit Number SK2T-6022 SK2T-8038 SK2T-8039 SK2T-8044 SK2T-8046 SK2T-8043 SK2T-8037 SK3T-3694
IBM Networking Redbooks Collection IBM Transaction Processing and Data Management Redbooks Collection IBM Lotus Redbooks Collection Tivoli Redbooks Collection IBM Netfinity Hardware and Software Redbooks Collection IBM RS/6000 Redbooks Collection (PDF Format) IBM Application Development Redbooks Collection IBM Enterprise Storage and Systems Management Solutions
B.3 Tivoli publications

These publications are also relevant as further information sources:
Book Title Publication Number GC31-5204 GC32-0288 GC31-5195 GC31-5194 GC31-5188 GC31-5190 SH26-4095 SH26-4088
Tivoli Asset Management Inventory Integration System Administration Tivoli Asset Management Inventory Integration Users Guide Tivoli Asset Management System Administrators Guide Tivoli Asset Management Users Guide Tivoli Change Management System Administrators Guide Tivoli Change Management Users Guide Tivoli Data Protection for Informix V3R7: Installation and Users Guide Tivoli Data Protection for Lotus Domino for UNIX V1R1: Installation and Users Guide
162
Book Title
Tivoli Data Protection for Lotus Domino for Windows NT V1R1: Installation and Users Guide ADSMConnect Agent for Lotus Notes on AIX Installation and Users Guide ADSMConnect Agent for Lotus Notes on Windows NT Installation and Users Guide ADSMConnect Agent for Microsoft Exchange Server Installation and Users Guide ADSMConnect Agent for Microsoft SQL Server Installation and Users Guide ADSMConnect Agent for Oracle Backup on AIX Installation and Users Guide ADSMConnect Agent for Oracle Backup on HP-UX Installation and Users Guide ADSMConnect Agent for Oracle Backup on Sun Solaris Installation and Users Guide ADSMConnect Agent for Oracle Backup on Windows NT Installation and Users Guide Tivoli Decision Support 2.1 Administrator Guide Tivoli Decision Support 2.1 Installation Guide Tivoli Decision Support 2.1 Users Guide Tivoli Distributed Monitoring 3.6 Collection Reference Tivoli Distributed Monitoring 3.6 Release Notes (supplied with the product) Tivoli Distributed Monitoring 3.6.1 Release Notes (supplied with the product) Tivoli Distributed Monitoring for OS/390 V3.6.1 Tivoli Distributed Monitoring Users Guide 3.6 Tivoli Framework 3.6 Users Guide Tivoli Framework 3.6.1 Release Notes (supplied with the product) Tivoli Inventory 3.6.1 Release Notes (supplied with the product) Tivoli Inventory for OS/390 V3.6.1 Release Notes (supplied with the product) Tivoli Problem Management Distributed Data Manager System Administrators Guide Tivoli Problem Management System Administrators Guide Tivoli Problem Management Users Guide Tivoli Service Desk Administration Users Guide Tivoli Service Desk Installation Guide Tivoli Software Distribution 3.6 Release Notes (supplied with the product) Tivoli Software Distribution 3.6.1 Release Notes (supplied with the product) Tivoli Software Installation Service 3.6.1 Release Notes (supplied with the product) Tivoli Software Installation Services 3.6 Users Guide Tivoli Storage Manager for AIX Version 3.7 Administrators Guide Tivoli Storage Manager for AIX Version 3.7 Administrators Reference Tivoli Storage Manager for AIX Version 3.7 Quick Start Tivoli Storage Manager for AS/400 Version 3.1.2 Administrators Guide Tivoli Storage Manager for AS/400 Version 3.1.2 Administrators Reference Tivoli Storage Manager for AS/400 Version 3.1.2 Quick Start Tivoli Storage Manager for HP-UX Version 3.7 Administrators Guide Tivoli Storage Manager for HP-UX Version 3.7 Administrators Reference
Publication Number GC26-7320
SH26-4067 SH26-4065 SH26-4071 SH26-4069 SH26-4061 SH26-4073 SH26-4063 SH26-4086 GC32-0437 GC32-0438 GC32-0436 SC31-5118 GI10-3023 GI10-8021 GI10-8043 GC31-8382 GC31-8433 GI10-8014 GI10-8018 GI10-8048 GC31-5184 GC31-5173 GC31-5175 GC31-5205 GC31-5167 GI10-3014 GI10-8019 GI10-8015 GC31-5121 GC35-0368 GC35-0369 GC35-0367 GC35-0315 GC35-0316 GC35-0317 GC35-0371 GC35-0372
Appendix B. Related publications
163
Book Title
Tivoli Storage Manager for HP-UX Version 3.7 Quick Start ADSTAR Distributed Storage Manager for MVS Version 3.7 Administrators Guide ADSTAR Distributed Storage Manager for MVS Version 3.7 Administrators Reference ADSTAR Distributed Storage Manager for MVS Version 3.7 Quick Start ADSM for OS/2 Version 3.1 Messages Tivoli Storage Manager for Sun Solaris Version 3.7 Administrators Guide Tivoli Storage Manager for Sun Solaris Version 3.7 Administrators Reference Tivoli Storage Manager for Sun Solaris Version 3.7 Quick Start Tivoli ADSM for VM Version 3.1 Quick Start Tivoli Storage Manager for Windows NT Version 3.7 Administrators Guide Tivoli Storage Manager for Windows NT Version 3.7 Administrators Reference Tivoli Storage Manager for Windows NT Version 3.7 Quick Start Tivoli Storage Manager Version 3.7 AFS/DFS Backup Clients Tivoli Storage Manager Version 3.7 Installing the Clients Tivoli Storage Manager Version 3.7 Messages Tivoli Storage Manager Version 3.7 Reference Cards for the Backup-Archive Clients Tivoli Storage Manager Version 3.7 Trace Facility Guide Tivoli Storage Manager Version 3.7 Using the Application Programming Interface Tivoli Storage Manager Version 3.7 for NetWare Using the Backup-Archive Client Tivoli Storage Manager Version 3.7 for UNIX Using the Backup-Archive Client Tivoli Storage Manager Version 3.7 for Windows Using the Backup-Archive Client TME 10 Enterprise Console 3.6.1 Release Notes (supplied with the product) TME 10 Enterprise Console Adapters Guide Version 3.6 TME 10 Enterprise Console Rule Builders Guide Version 3.6 TME 10 Enterprise Console Users Guide Version 3.6 TME 10 Framework 3.6 Planning & Installation Guide TME 10 Framework 3.6 Reference Manual TME 10 Framework Release Notes Version 3.6 TME 10 Inventory 3.6 Release Notes (supplied with the product) TME 10 Inventory 3.6 Users Guide TME 10 Software Distribution 3.6 AutoPack Guide TME 10 Software Distribution 3.6 Reference Manual TME 10 Software Distribution 3.6 Users Guide TME 10 Tivoli/Plus ADSM User's Guide Tivoli Framework Version 3.7 Users Guide
Publication Number GC35-0370 GC35-0277 GC35-0278 GC35-0276 SH35-0133 GC35-0374 GC35-0375 GC35-0373 GC35-0351 GC35-0380 GC35-0381 GC35-0379 SH26-4106 SH26-4102 GC35-0382 SX26-6021 SH26-4104 SH26-4107 SH26-4100 SH26-4105 SH26-4101 GI10-8020 SC31-8507 SC31-8508 GC31-8506 SC31-8432 SC31-8434 GI10-3028 GI10-3011 GC31-8381 GC32-0294 SC31-8331 GC31-8330 GC31-8405 GC31-8433
164
How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about IBM Redbooks, redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided. Redbooks Web Site ibm.com/redbooks Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site. Also read redpieces and download additional materials (code samples or diskette/CD-ROM images) from this Redbooks site. Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows. E-mail Orders Send orders by e-mail including information from the IBM Redbooks fax order form to: In United States or Canada Outside North America Telephone Orders United States (toll free) Canada (toll free) Outside North America 1-800-879-2755 1-800-IBM-4YOU Country coordinator phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
e-mail address pubscan@us.ibm.com Contact information is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
Fax Orders United States (toll free) Canada Outside North America 1-800-445-9269 1-403-267-4455 Fax phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
This information was current at the time of publication, but is continually subject to change. The latest information may be found at the Redbooks Web site.
IBM Intranet for Employees
IBM employees may register for information on workshops, residencies, and Redbooks by accessing the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.
165
IBM Redbooks fax order form

Please send me the following: Title Order Number Quantity
First name Company Address City Telephone number Invoice to customer number Credit card number
Last name
Postal code Telefax number
Country VAT number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
166
Abbreviations and acronyms

ACC ACF ADE ADSM API ARS CLI EIF IBM INV ITSO LAN MDist MN OS RDBMS RIM SQL SWD TCP/IP
AutoPack Control Center Adapter Configuration Facility Application Development Files ADSTAR Distributed Storage Manager Application Programming Interface Action Request System Command Line Interface Event Integration Facility International Business Machines Corporation Tivoli Inventory International Technical Support Organization Local Area Network Multiplexed Distribution services Managed Node Operating System Relational Database Management System RDBMS Interface Module Structured Query Language Tivoli Software Distribution Transmission Protocol/Internet Protocol
TDM TDP TEC TMA TMR TRIP TSD WAN
Tivoli Distributed Monitoring Tivoli Data Protection for Applications Tivoli Enterprise Console Tivoli Management Agent (Endpoint) Tivoli Managed Region Tivoli Remote Execution Service Tivoli Service Desk Wide Area Network
167
168
Index D A
action synopsis 147 activity log 116 add filter 98 administrator 88 ADSM Web Administration 134 ADSMInterface 135 ADSMPlus for Tivoli module for TSM 3.7 12 alarms 7 alerts 7 append source path 60 application servers 115 AS/400 alert adapter 88 AS/400 Message adapter 89 asset information from Tivoli Inventory 131 asynchronous monitoring 8 automated task 102 Autopack 56 Autopack Control Center 58 available subscribers 65 data collection for statistical analysis 5 database files excluding from normal backup 118 database servers 15 database servers in a distributed environment 13 defining policy domains 124 deleting rule sets 108 determining if your application is down 116 differential backups 8 dispatch engine 87 Distributed Monitoring 149 distributing packages 64 distribution profile 59 DMTF 71 Domino databases, document level backup 11 dsm.opt 64 dsm.sys 64 duplicate messages 7
E
Edit Filters 98 Edit Rules 144 Endpoint 67, 112 Endpoint Gateway 58, 59 enhanced TEC event forwarding 116 Enterprise Console Events 103 Enterprise event logging 125, 126 Enterprise logon 121, 125 enterprise-wide events 85 event 15 event adapters 15, 88 event becoming critical 150 event class 149, 156 event console 15, 86, 88, 100 event console administrator 153 event forwarding to Tivoli Storage Manager 116 event group 15 assigning 99 display 100 for Tivoli Storage Manager 96 event recording by TEC 143 event server 13, 86, 150 for central logging 120 Rule Bases 144 event slot values 152 event sources 99
B
BRArchive 12 BRBACKUP 12 BRRestore 12 business continuance 119
C
centralized point of integration and control 7 change mode 60 client action 155 command line interface, alternative to desktop 5 command routing 121 communications methods 6 communications services 4 complex logical structures 11 components of Tivoli Plus module 111 compound rule 144 compression on distribution 60 configuration manager 124 configuration repository 70 configuring and managing TSM servers 123 create rules manually 151 creating packages with Autopack 60
169
event triggered backup, response 116 events multiple Tivoli Storage Manager servers to TEC 16 Tivoli Data Protection for Applications to TEC 16 Tivoli Storage Manager to TEC 16 EVGEN command 130, 144 Exchange Application Client 8 Exchange Server Tasks task library 154, 156 extending the log 151 extending Tivoli Storage Manager recovery log 151 example 149 extension of the recovery log 153
inventory information 6 INVENTORY_QUERIES 81 profiles 73 scan profile 73
L
lab environment 17 levels of availability 7 Linux client 62 loading the rule base 96 log information options 60 logfile event adapter 89 logging events to Tivoli Event Console 128 logical volumes 80 Lotus Domino API 11
F
file package 6, 58, 65 properties 60 filter values 98 filtered event source 86 format files 89 Framework, Tivoli Inventory 69 frequency of monitoring probe 150
M
managed node 58, 70, 112, 116 management by subscription 5 Management Information Format (MIF) 71 Manager for R/3 15, 16 managing multiple servers 121 managing TSM servers from any server 124 master server definitions 123 MDist mechanism 58 menu entries none for starting the Tivoli Storage Manager client 132 none for the integration of Tivoli Inventory 132 message time limits 100 messages 7 Microsoft Cluster Server (MSCS) 10 Microsoft Exchange 5.5 server 153 Microsoft Exchange Directory 8 Microsoft SQL server 13 Service Desk 137 migrating assets from Tivoli Inventory 137 monitoring capabilities 119 monitoring manual checks centrally by TEC 130 MS Exchange 8 MS SQL 83 multiplexed distribution 6
G
generic query 80 geographically-dispersed platforms 5 graphical rule builder 151, 152
H
hardware queries 80 hardware scan 77 historical trending analysis 119
I
IBM DB/2 8 IBMBACKUP class 93 ibmtsm.baroc 92 ibmtsm.mac 92 import bitmap option 97 information about task library 152 integration between Tivoli Enterprise and Tivoli Storage Manager 112 scenarios 115 Tivoli Inventory with Service Desk 133 TME 10 with Tivoli Storage Manager 12
N
nested file packages 56, 60 Netview for OS/390 adapter 89
170
Netview maps 100 NetView/6000 adapter 89 network cards 80
O
offline backup of the Exchange server 153 online backup and restore of Microsoft SQL 9 OpenView adapter 89 Oracle Backup Agent 10 Oracle7 10 Oracle8 10
P
package distribution 57 platform specific options 118 Plus Module for ADSM 149 posting a message to the activity log 149 problem management 143 problem records, triggered by TEC events 131 profile manager 58, 112 ADSM Servers 113 profile paradigm 6 putting it all together 141
Q
querying the activity log 130
R
R/3 application servers 16 RDBMS 69, 87 reception engine 87 recovery log files 153 registry changes, autopack 56 relation list 146 remote systems management 5 repeater hierarchy 6 responding to incoming problem records 139 RIM 69 RMAN 10 rule bases 91 Rule Sets deleting 108 Edit Ruleset 144
SAPDBA 12 scanning TMA Endpoints 71 send_event task 155 server console 116 server definitions 121 server reception 87 server-to-server communication 121 set class value 98 severity, setting 147 of TEC events 106 simple rule 144 slave server 121 definitions 122 SNMP adapter 89 software distribution process 57 profile 118 Software Distribution Gateway 59 software levels 83 software scan 77 software signature 81 file 71 source host 58, 118 Spectrum Enterprise Manager adapter 89 SQL application client 10 SQL server data 9 status messages from Tivoli Storage Manager server 139 storing data on another server 124 subscription lists 112 Tivoli Plus 111 Sun Solstice/SunNet Manager adapter 89 synchronous monitoring 7 system environment used in our lab 17 system management 13 services 4
T
T/EC Tasks task library 155 Tandem NonStop Kernel adapter 89 targets for software distribution 58 TEC console 149 event class definition file 144 event server 92 preparation for Tivoli Storage Manager 93 rule language 91 rules 15
S
SAP R/3 15 and Tivoli Storage Manager 12
171
server 89, 91 testing event logging 130 time window for Exchange stop 155 Tivoli 8, 12, 14 Tivoli Adapter Configuration Facility 86 Tivoli Asset Management 17 Tivoli Change Management 17 Tivoli Data Protection 8, 83 for Lotus Domino 10 for Microsoft Exchange Server 8 for Microsoft SQL Server 9 for Oracle 10 for SAP R/3 12 MS Exchange 117 Tivoli Data Protection for Applications 8, 115 deploying 117 modules 3 overview 115 Tivoli Decision Support, data input to 13 Tivoli desktop 5 Tivoli Disaster Recovery Manager 119 Tivoli Distributed Monitoring 7, 149 description 5 features 5 Tivoli Endpoints 18 Tivoli Enterprise 83 features of Tivoli Storage Manager 119 Framework modules 4 Tivoli Enterprise Console components 85 using to monitor all the servers 125 Tivoli Enterprise Console (TEC) 6, 13, 85 adapters 86 Tivoli Event Console (TEC) 15 Tivoli Event Integration Facility 86 Tivoli event receiver 116 Tivoli Framework 3 Tivoli Framework scheduler 65 Tivoli Framework TME 10 21 Tivoli Inventory 6 collection engine 70 concepts 69 database interface and query facility 70 installation 70 migration utility 138 scan 71 Tivoli Management Agent 59 Tivoli Management products, overview 3 Tivoli Management Region (TMR) 15
Tivoli Manager for Lotus Domino 15 for MS SQL 13 for Oracle 14 for SAP R/3 15 Tivoli Manager for MS Exchange 12, 153 Tivoli Manager for Oracle Distributed Monitoring 14 Framework 14 User Management 15 Tivoli Manager for R/3 15 Tivoli Plus module components 111 for ADSM 111, 151 setting up 112 Tivoli Problem Management 16 Tivoli Service Desk 3, 16, 131, 143 customizing 132 enhancements 131 user profile 133 Tivoli Software Distribution 143 description 6 server 59 using 117 Tivoli Storage Manager activity log message 149 administrative Web client 136 backup-archive client for Linux 62 enterprise 119 event handling 16 log 149 messages 93 updating the backup-archive client 143 Tivoli Storage Manager and Tivoli Enterprise examples 143 TMA Endpoint 58 TME 10 Framework 13 traps 7 triggering level of distributed monitoring, controlling 150 TSDBuild application 137 tsm_back_succ event class 156
U
unnecessary triggering of the backup 155
V
virtual volumes 121
172
W
wfilesig 81 Windows 89 Windows NT adapter format file 156
173
174
IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook "made the difference" in a task or problem you encountered. Using one of the following methods, please review the Redbook, addressing value, subject matter, structure, depth and quality as appropriate. Use the online Contact us review redbook form found at ibm.com/redbooks Fax this form to: USA International Access Code + 1 914 432 8264 Send your comments in an Internet note to redbook@us.ibm.com
Document Number Redbook Title Review
SG24-6117-00 Managing Storage Management: Tivoli Enterprise integration with Tivoli Storage Manager
What other subjects would you like to see IBM Redbooks address?
Please rate your overall satisfaction: Please identify yourself as belonging to one of the following groups: Your email address: The data you provide here may be used to provide you with information from IBM or our business partners about our products, services or activities. Questions about IBMs privacy policy?
O Very Good
O Good
O Average
O Poor O Solution Developer
O Customer O Business Partner O IBM, Lotus or Tivoli Employee O None of the above
O Please do not use the information collected here for future marketing or promotional contacts or other communications beyond the scope of this transaction.
The following link explains how we protect your personal information. ibm.com/privacy/yourprivacy/
175
(0.2spine) 0.17<->0.473 90<->249 pages

Tivoli Enterprise integration with Tivoli Storage Manager
Centrally manage your distributed storage management environment Automatically react to storage events Benefit from practical, real-life examples
This IBM Redbook covers the new features of Tivoli Storage Manager, which relate to the Tivoli Enterprise set of products and show how these, in return, can contribute to a traditional installation of Tivoli Storage Manager. This book is addressed to Tivoli Storage Manager administrators, who have little or no knowledge of Tivoli Enterprise. It does not cover the basic installation of the Tivoli Framework or its applications. We focus on Tivoli Enterprise products, such as Framework, Distributed Monitoring, Inventory, Software Distribution and Enterprise Console. We show how these modules can be used to ease daily tasks, to monitor conditions, and to report them accordingly. Additionally, we explain how to customize Tivoli Storage Manager to collaborate with the Tivoli Enterprise modules. This book is divided into three parts. Part 1 contains an introduction to the different Tivoli Enterprise modules and special features of Tivoli Storage Manager. Part 2 covers each of the modules in depth. Part 3 describes a complete scenario, where all of the modules come together, therefore providing a holistic approach to an enterprise management system, including storage.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6117-00 ISBN 0738418218

Managing Storage Management Tivoli Enterprise Integration With Tivoli Storage Manager Sg246117

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Managing Storage Management Tivoli Enterprise Integration With Tivoli Storage Manager Sg246117

Загружено:

Авторское право:

Доступные форматы

Managing Storage Management

Tivoli Enterprise integration with Tivoli Storage Manager

Patrick Randall Michel Baus Andrej Marencic Melinda Sangargir

Copyright IBM Corp. 2000

. . 85 . . 85 . . 86 . . 88 . . 90 . . 90 . . 91 . . 93 . . 93 . . 96 . 100 . 102 . 106 . 108

Copyright IBM Corp. 2000

Copyright IBM Corp. 2000

The team that wrote this redbook

Copyright IBM Corp. 2000

Chapter 1. Introduction to Tivoli Management products

Copyright IBM Corp. 2000

Tivoli Manager for Oracle

Tivoli Manager for SQL SQL Tivoli Manager for Exchange

Tivoli Software Distribution

Tivoli Enterprise Console

Tivoli Service Desk Plus Module

Tivoli Manager for Domino

Domino Tivoli Service Desk

Tivoli Storage Manager

Backup Archive Client

Tivoli Data Protection for Oracle

Tivoli Data Protection for SQL

Tivoli Data Protection for Exchange

Tivoli Data Protection for Domino

1.2 Parts and pieces

1.2.1 Tivoli Enterprise modules

Chapter 1. Introduction to Tivoli Management products

Chapter 1. Introduction to Tivoli Management products

1.2.2 Tivoli Data Protection for Applications

Chapter 1. Introduction to Tivoli Management products

Chapter 1. Introduction to Tivoli Management products

1.2.3 Other Tivoli modules for managing applications

Chapter 1. Introduction to Tivoli Management products

Chapter 1. Introduction to Tivoli Management products

1.2.4 Tivoli Storage Manager event handling

1.2.5 Tivoli Service Desk

1.3 System environment

Chapter 1. Introduction to Tivoli Management products

Part 2. Using the individual modules

Copyright IBM Corp. 2000

Chapter 2. Tivoli Framework TME 10

2.1 Framework architecture

RDBMS interface module

Figure 2. Tivoli Framework

Copyright IBM Corp. 2000

2.2 Framework desktop

2.2.1 Desktop window

Figure 3. Tivoli desktop example of window

Chapter 2. Tivoli Framework TME 10

Figure 4. Desktop Navigator

2.3 Framework components

Notice groups Query libraries Endpoint manager Scheduler

2.3.1 Tivoli Management Region

2.3.2 Policy regions

2.3.3 TME administrators

Chapter 2. Tivoli Framework TME 10

2.3.4 Profile managers

2.3.5 Task libraries

2.3.7 Notice groups

Chapter 2. Tivoli Framework TME 10

2.4 Framework configuration: examples

2.4.1 Defining administrators

Figure 5. Create Administrator