The fix became available on June 3rd, but I was too fast on the draw and found out that the files were not uploaded totally. Oops. Then on the 5th, I saw that the files were now quite a bit bigger. Each of the files for the various OSs are about 1.8GB, OUCH!
For the patch information, go to http://www-1.ibm.com/support/docview.wss?uid=swg24016022&loc=en_US&cs=UTF-8〈=all
The install was quite easy and I did not see any errors. One thing to note, make sure you are logged on as the tioadmin account. This is a lesson I learned when installing FP01. I know the docs say this, but I thought that as Administrator (yes only Windows so far) I should be able to do it. Boy was I wrong. At some point the install of TPM changes the security to various files that does not even allow Administrator access.
So what is new?
Endpoint Tasks
This seemed to be something missing from GA and FP01 that was available in TCM. This allows for the creation of a Task much like we saw in TCM. In fact I think that it is much easier. The basic steps are:
1. Create a script and put it in the LocalFileRepository (and a sub-directory if you want)
2. In the TPM web interface, go to Task Management and there is a new section called Endpoint Tasks.
3. Select Edit -> Create Endpoint Task
4. Enter the task name and description
5. Select the files to send from the repository. You can define different files for different operating systems in the same task.
6. Define and parameters for the task
7. View the summary and then press Finish and the task is ready to go!
One thing to note, this only works if SOA is enabled. In my quick search of the docs, I did not see this as a requirement, but the message I saw when I tried to send without SOA enabled sort of pointed to the problem. The message was "COPDEX123E The workflow threw a NotSupportedInDE exception. The message is This workflow is a template workflow for TMF and TCA EndPointTask only."
"Automatic" agent upgrade
In previous versions, upgrading the TCA was a bit of a pain. Usually it was better just to remove the existing agent and reinstall with the new version. This would obviously be a nightmare in any real environment. So now there is a vorkflow called "TCA_Agent_Upgradeable.wkf" that can be wrapped as a Favorite Task that allows for the upgrading of agents. For the couple workstations I tried this on, the upgrade worked. For more information on the process check out Upgrading the common agent" on Info Center
Patching for HP-UX and AIX
I have not been able to try either of these, but I thought I would list them anyway. I know that AIX patching was there before, but according to people I talked to at the TTUG, it did not work. I was told that FP02 is where you have to be to make this work. HP-UX patching is new though and I am sure that people are looking for this.
Java Web Start for the Software Package Editor (SPE)
This is a nice improvement. Now you do not need to have Eclipse installed on your computer to use the SPE.
You do require Java to be install with the minimum level of 1.4.2. Once Java is installed, open your web browser and go to "https://
New SOAP commands for Packaging
Some new SOAP commands were created to allow for the creation, distribution, install and uninstall of a software package. There does not seem to be much information in the docs about this yet. The only one I have found is around creating the SPB. I will keep looking and post more later.
Unified Patch Management
You can now manage patches in TCM from TPM and be rid of that "Automation Server" that TCM used. This is a possible scenario that I can see using TPM as a first entry point. I personally think that the patch management facility works fairly well in TPM. The one that came with TCM was a real pain to install and use. So by implementing TPM and importing your TCM environment into TPM you can manage all the patches from TPM and still do all the other stuff from TCM.
Note: This is only for Windows right now.
Defects Fixed
There are around 720 defects that have been fixed! For a complete listing, go to http://www3.software.ibm.com/ibmdl/pub/software/tivoli_support/patches/patches_5.1.0/5.1.0-TIV-TPM-FP0002/5.1.0-TIV-TPM-FP0002.DEFECTS.HTM
Extra Notes
Now that I have FP02 installed, it is time to start working through some of the features in more detail. Hopefully this blog has given you a little help in seeing what is new.
I see that IBM is putting a lot of work in this product and I think they are making progress in many areas.
The one area that still needs work is the installer. Unfortunately, this cannot be addressed in a fix pack. I have heard rumors that there will be a new installer in the next version (5.2??), but these are only rumors.
Some things that I see help improve the success of an install are pre-installing the DB2 and WebSphere products. These seem to be the two trouble areas, especially if you are using machines that are not up to the minimum requirements (like a test lab).
I also think that a fully manual process should be available to install TPM. I have done this and pretty much got everything to work, but it was a fight as I was working in areas that are not even close to documented. All I can say is thank you VMWare for snapshots :)
So now you are wondering if TPM is ready for your environment. Well here is the straight answer, yes and well no.
If you are new to the Tivoli environment and you want TPM or TCM, go to TPM now. There is no point in using TCM. There are some issues with TPM, but learning TCM now and then learning TPM later is going to really hurt. Learn TPM now, get the users on it and don't look back.
If you are a current TCM user, then I would definitely have TPM in the test lab right now at least. The biggest problem for current TCM users that I have seen is that there has been so many processes built around TCM (web pages, reports, data sharing/use) that it is going to take a long time to move everything over. Also the whole push vs pull thing is a big difference to TCM people. We have spent years managing the client expectations that when we submit something, it will start almost right away. Now with TPM, this is no longer true. There is some configurations that can be done to decrease the waiting (polling) but this can severely impact the performance of the product. So there is going to be quite a bit of work to change these expectations, unless something is done to allow for a "push now" option.
Ok this is enough for now, my fingers are bleeding from all the typing. I will keep you posted on anything I find new and interesting. If you have any questions, feel free to comment or send me an email (martin dot carnegie at gulfsoft dot com)
Friday, March 14, 2008
Tivoli Provisioning Manager - Fix Pack 2
Netcool overview for Tivoli folks
Tivoli has stated that the future of event management will be Netcool/Omnibus, and TBSM 4.1 *IS* Netcool/RAD, along with some additional cool integration pieces, so I'm going to focus on those products and their prerequisites.
Netcool/Omnibus is used for event management. It consists primarily of an ObjectServer and a database (Postgres by default). The ObjectServer receives events and performs functions similar to those provided by tec_server, tec_reception, tec_task, tec_rule and tec_dispatch. Specifically, it receives events, processes them according to configurable/definable rules, and writes them to the database. The rules you define can also perform automation - sending email, instant messages, running programs, etc.
The Omnibus database itself is quite a bit nicer (in my opinion) than the TEC database. There is essentially ONE table that contains your event information: alerts.status (there are a couple of others, alerts.detail and alters.journal that may contain information about events, but alerts.status is the primary one). All of an event's slots map to columns in this table, and if you define an event that needs more slots/attributes, you need to modify this table. This makes it a little less flexible than TEC's TEC_T_SLOTS table, but that's a good tradeoff in my mind (to this day I haven't been able to find a single SQL query that will show me all of the slots for all of the events with a particular value in the 'hostname' slot, for example).
The user interface for Omnibus itself is about as basic as the TEC event viewer. But because you normally will use other products along with Omnibus, most users won't actually see the Omnibus interface - they will use something nicer (like TBSM or Impact) as a front-end.
Defining the automation for Omnibus (using the Netcool/Omnibus Administrator tool, 'nco_config'), should be familiar to all TEC administrators out there. You have to write code to perform any automated actions you want. The product doesn't have any wizard interfaces, but Netcool/Impact DOES (more on this in a bit).
TBSM (Tivoli Business Service Manager) 4.1 sits primarily on top of the Omnibus database, though it can take feeds from a large number of different sources. Whereas previous versions of TBSM required that you send specially-formatted events to TBSM, this version performs the same function in a much more straightforward manner: by reading the database. As an administrator, you need to define your different business service hierarchy, and in doing so, you need to define which events affect the status of each service. You define these filters through the web-based interface, which is based on Netcool/Webtop, which is based on the Netcool/GUI Foundation.
TBSM 4.1 also includes some functionality that was not in RAD 3.x. Specifically, there is a new TEC EIF Probe, which allows the included Omnibus ObjectServer to look EXACTLY like a TEC server. This means that you can point existing TEC adapters to your Omnibus host as the EventServer. This piece also allows you to perform attribute mapping so that your events come in correctly.
Another new feature in TBSM 4.1 is that it can import Discovery Library Adapter (DLA) books that are created by other products. Most notably, it accepts the output from the ITM 6.x DLA, and even has rules built-in to handle events from ITM. Here's what makes this so cool:
- You can generate the book in your ITM environment. This book (a file containing IDML [an XML language] data) contains information about all of the agents you've deployed in your environment.
- You then have all of your agents visible within TBSM, and they can be included in any services you define.
- If you point your TEMS to send events to the Omnibus ObjectServer being monitored by TBSM, your systems that were imported from ITM 6.x will turn yellow or red.
TBSM 4.1 ALSO has tight integration with the CDT portion of CCMDB (aka TADDM). You can pull information from TADDM using DLA books OR using direct API access. This type of integration allows you to view CI status changes directly in TBSM. Additionally, you can launch the TEP or the TADDM GUI in-context directly from TBSM.
This level of out-of-the-box integration is what a lot of us have been hoping for for a long time. Additionally, TEC event synchronization capabilities are easily configured.
If you can't tell, I REALLY like this newest version of TBSM 4.1. It doesn't have nearly the complexity of earlier versions, AND leverages your event repository directly (the Omnibus database). Additionally, it ships with robust integration with ITM and TEC, which will make the transition off of TEC very easy for the vast majority of customers. For most customers who are using TEC for complex processing, it won't take too much effort to integrate Omnibus into your event management structure.
TBSM 4.1 also has an SLA (Service Level Agreement) component that can be used to track and manage your SLAs. Tivoli is still selling the TSLA product separately, and I believe they will keep offering that product, so hopefully they will soon come out with a statement of direction in this area.
With TBSM, you also get Netcool/Impact for no additional fee. *This* is the product that many of you have seen demonstrated with the ability to define your event management rules and automation just by clicking and dragging. This is accomplished through the Wizards that are included. Those wizards will guide you through many common automation tasks (running an external command, sending email, etc.), though like any wizards, to perform complex operations, you'll need to write code directly.
The main interface for Netcool/Impact is web based, and therefore, like TBSM 4.1, requires Webtop and the GUI Foundation.
Netcool also has a very granular security structure, where you can define exactly which users can access which resources depending on which tool they use for that access.
Notice in all of the above that Netcool has no interface that competes with with the ITM 6.1 TEP interface - all of the Netcool interfaces above are based on events being generated. That's a good thing, as this (to me) clearly indicates that the TEP is *the* operational view for real-time metrics moving forward.
That's all for now. There are definitely other Netcool products that I didn't touch on (Precision IP, Reporter, Proviso and Visionary, among a few others), but we will hopefully address those in a similar article soon. I know in particular that there is lots of interest in Tivoli reporting capabilities, and that Netcool/Reporter sounds like a good product to address that. However, Tivoli has announced that their future reporting solution will be based on the open-source BIRT (Business Intelligence Reporting Tool) application, so I don't really want to touch on that until Tivoli announces a more concrete direction.
Stopping situations on Remote TEMS
The following SOAP call seems to work for me.
The key is the
ITM Events with wrong severity - A fix
There are two issues here. One, there is a new parameter that should be added to KFWENV since FP02. Without this parameter, TEPS will incorrectly store the severity field (SITINFO) inside the situation definition. Second, after setting this parameter, we still need to manually modify the existing situations to have correct severity.
Adding new parameter to KFWENV/cq.ini
Edit your KFWENV/cq.ini file, add KFW_CMW_SET_TEC_SEV=Y to it. This parameter will take care of setting correct severity within the situation definitions.
Modifying severity in existing situations
Using a simple tacmd viewsit, you can export the situation definitions, modify the SITINFO field to right severity and import it using tacmd createsit command. But it is too destructive as it involves deleting the existing situation and creating new one.
One relatively easy method is to use gbscmd. If you would like to learn more about gbscmd, please read this article. For example, the following gbscmd changes the situation severity on the fly.
gbscmd executesql --auth
The new sitinfo should be exactly like the previous sitinfo field but with the severity changed to correct one.
New SOAP Methods for ITM 6.1 - It's a summer blockbuster
Remote_System_Command and Local_System_Command. Just like they sound, they will allow system commands to be run on Remote systems.
Read the attached for usage samples and details.
Get Your KICK butt SOAP Methods here...
ITM 6.1 ????Netcool Omnibus Integration Steps
Terminology
ObjectServerOmnibus ObjectServer is the in-memory database server at the core of Netcool Omnibus. ObjectServer receives events from various sources and process/display them according to the specification. This is analogous to TEC Event server. ProbesProbe is an Omnibus component that connects to an event source, receives events from that source and forwards the events to ObjectServer. For ITM integration, we need to use Tivoli Event Adapter probe a.k.a TME10tecad probe. EventListA GUI application that shows the events received by Netcool Omnibus. You can bring up the EventList by typing nco_event in your Unix terminal. Make sure you have X-Windows server such as Exceed running.How does the integration work?
ITM uses OTEA (Omegamon TEC Event Adapter) to send events to TEC. The OTEA is very similar to a NT Event Adapter/TEC Event Adapter. To send events to Omnibus, you just need to install a TEC Event Adapter probe on a system and modify the ITM om_tec.config file to point to the server running the probe. To ITM, the probe will appear as a TEC server. The probe on receiving events from ITM, will forward them to the real Omnibus ObjectServer specified in its rules file. The following diagram shows the integration of these components.Downloads
Setting up the software from scratch requires quite a few downloads from Netcool/IBM download site. The list of products needed are given below.Integration Steps
Integrating ITM 6.1 with Omnibus involves the following major activities. 1. Install Omnibus and create an ObjectServer (if needed) 2. Install Tivoli Event Adapter Probe and point it to the ObjectServer created above. 3. Modify om_tec.config in ITM environment pointing it to the Event Adapter probe. 4. Reconfigure the Hub TEMS Server and specify the probe server as your TEC Server.Installation Steps - A Quick Overview
The following steps are needed to get ITM-Omnibus integration working right from the scratch.1. Install Netcool Omnibus V7.1
2. Install Netcool License server.
3. Install your licenses in $NCHOME/license/etc folder.
4. Create a Netcool Object Server to which events will be sent.
5. Start the license server and ObjectServer.
6. Install Omnibus Probe support on your probe server.
7. Install Netcool/Omnibus Probes library for Non-native base on the probe server.
8. Install Netcool/Omnibus Probes binary for Tivoli EIF on the probe server.
9. On the probe server, extract ITM Omnibus Integration solution that you downloaded from OPAL and copy tme10tecad.rules files to %OMNIHOME%\probes\
10. On the probe server, Create a file called %OMNIHOME%\probes\win32\tivoli_eif.props and the following lines to it.
PortNumber : 5529
Inactivity : 3600
11. Bring up Server Editor and add the entries (ObjectServer name, hostname and port number) for your Netcool server.
12. Start the Probe Service by starting the "NCO Nonnative Probe" Service.
13. Change the om_tec.conf on the ITM hub server to reflect the connectivity information of the probe server that you did in step 10.
14. Fire a test situation and ensure that the event is received by Netcool. You can verify this by bringing up Omnibus EventList (nco_event).
The screenshot of events appearing in Omnibus EventList is shown below.
