ITM UA Socket data provider tips

Tips/observations I found using the UA socket data provider with perl while doing work at a customer site..

ITM 6.1 FP4, SuSE Linux 10

1. turn OFF "warn" in perl (#!/usr/bin/perl -w). I use it all the time but I was only getting data from first connection until I turned it off in my script.
2. TCP works great for scheduled (> 30 sec interval) sending of batch data, but use UDP with sporadic alert-type data that *might* be < 30 sec interval data. Using TCP with the latter scenario causes the UA to silently "miss" < 30 sec interval data.

Also, the POST data provider with UDP works great when you can't control the sending program, like with certain network devices.

ITM 6.1 Web Page to view Situations on Agents

Many times people ask to know what Situations are running on a given agent in ITM 6.1. I have written an HTML form and CGI/PERL script to query this data from the HUB and report it back in HTML. It's more convienent that CLI for casual users, but still requires a login.

The following PDF describes deployment and usage.

http://www.gulfsoft.com/downloads/blog_downloads/Viewing_Situations.pdf

UPDATE - ITM 6.1 Unix/Linux/Windows Agent Upgrades from a Windows HUB

Below is a script/batch file that will run on a Windows HUB or REMOTE TEM Server and take two arguments that will upgrade OS agents using a depot on the server where it is run.

This script has been validated in 2 separate Windows 2003 production environments as well as numerous test systems.

This may seem trivial and it is - but it's huge time saver plus I have it logging so you can track your agent upgrades. I just ran it at two customer sites and it was "set it and forget it". I came back a few hours later and my agents were upgraded.

I capture the resulting error code for troubleshooting later, I have also the timeout to 10 minutes instead of the default 5 minutes. This is a fully supportable solution because we are using the standard depot and simply putting a wrapper around the commands and changing the number of files in a depot structure.

This is a batch file, or .bat file. Copy the following text all the way down to and including the work "exit" and paste it into a new file. Save it on your Windows HUB and Remote TEMS. Before running this file, login using the tacmd login command.

Run the program with with 2 argument. The first is the agent/product code you want to upgrade - acceptable values are NT, UX and LZ for Windows, Unix and Linux OS agent. The next is the versions of those agents that you want to upgrade, acceptable values are 06.10.00.00, 06.10.02.00, 06.10.03.00, 06.10.04.00 and 06.10.01.00. Logging occurs in the directory where the program is run from.


@echo off
REM This script takes 2 input options. The first is an agent Product code. Valid options would
REM be NT UX and LZ.
REM The second option is the version of agents that you want to upgrade. Valid options are
REM 06.10.00.00, 06.10.04.00, 06.10.03.00, 06.10.02.00, 06.10.01.00


set TACMD_TIMEOUT=10
tacmd listsystems -t %1 | findstr %2 >upglist.txt

if ERRORLEVEL 0 GOTO UPGRADE
echo not upgradeing

:UPGRADE
echo do the upgrade
for /F %%f IN (upglist.txt) do ( FOR /F "TOKENS=*" %%A IN ('TIME /T') DO SET TIME=%%A
FOR /F "TOKENS=*" %%B IN ('DATE /T') DO SET DATE=%%B
echo %DATE%,%TIME%-Currently Upgrading-%%f
echo %DATE%,%TIME%,Currently Upgrading-%%f,was %2 >>agent_upgrade.txt
tacmd updateagent -t %1 -n %%f -f
echo Result Code for %%f is %ERRORLEVEL% >>agent_upgrade.txt)

:END
exit

UPDATE - Here is a shell script version that works on Unix and Linux

#!/bin/sh
LOG=agent_upgrade.log
DATE=`date`
for x in `./tacmd listsystems -t $1 | grep $2 | cut -f1 -d" "`
do
echo tacmd updateagent -t $1 -n $x -f
if [ "$?" = 0 ]
then
echo $DATE - Upgrade on $x successful >>$LOG
else
echo $DATE - Upgrade on $x failed >>$LOG
fi
done

send events using postesmg to Netcool Probe Server or Omnibus Server

send events using psotemsg to Netcool?

Has someone been able to send events using Tivoli's postemsg to Netcool Object Server or Probe Server?

We were a Tivoli implementation and were using TEC and are now migrating to Netcool Omnibus.

We were able to send events from different sources such as HP OpenView using the postesmg command to TEC.

I would like to know has anyone ever used postesmg to send the events directly to Netcool Probe or Objest Server?

If yes, how do i configure that?

TPM and DST

According to IBM, there is a fix that needs to be done for Websphere to address the DST change. This effects the 5.1 versions of TIO/TPM and TPM for Software.

For more information check out http://www-1.ibm.com/support/docview.wss?uid=swg21255724

TPM 5.1 and MS Active Directory issue

After doing a clean install of TPM 5.1 (no fixpack yet, coming soon) and using MSAD, I was unable to logon to the TPM webpage. The message displayed was "You are not authorized to access the system. Contact your system administrator. Click here to try again". This is not the message for a bad password. For that you would see bad user name or password.

So after digging around I found that only the tioappadmin user id and a few of the roles were created. None of the permission groups where created and the tioappadmin id was not added to the SuperUser group. This happened due to an issue when the first attempt was done by the Topology Installer to perform this step. On the first attempt, I had the active directory set in mixed-mode which does not allow some of the features required in the tiodata.ldif.

To solve this problem (after changing the MSAD mode), I re-imported the tiodata.ldif (most likely in C:\Documents and Settings\Administrator\Local Settings\temp) file using LDIFDE.EXE. Since some of the entries where created, the -k switch is required to ignore existing entries. The syntax is as follows:
ldifde -i -k -f tiodata.ldif.

Now it all works :)

FileServer software distribution in ITCM 4.2.x

One of the disadvantages of Software distribution architecture is depots can be hosted only from managed nodes and you will have to install a managed node at each slow-link to eliminate redundant data transfer across WAN. But, this may not be possible in an enterprise with large number of slow networks especially when each network hosts only a handful of systems. ITCM provides a FileServer based Software Distribution feature that permits any Windows system to act as a Fileserver for Software packages and this article describes my experiences with this feature.

Methodology

In this method, any Windows system can act as a File Server as long as you are able to map a network drive to the system. You can create an image of the Software Package SPBs using "wdepot image" command and transfer the image files (*.toc and *.dat) to the file server share directory using any standard file copy operations including software distribution data movement operations.

On each endpoint that receives the file server distribution, create a file (if it doesn't exist already) named remote.dir on the LCF_DATDIR directory that lists the file server shares. You can designate multiple fileserver shares by listing one share per line and each will be tried until the image is found. One important thing is each endpoint must have TRAA account enabled.

Distribution method is same except that you have to check the "From Fileserver" check box in GUI or set from_fileserver=y option in winstsp command. Activity Planner also has an XML tag to enable this feature. When distributed this way, ITCM transfers only the informataion about the package being distributed to the endpoint and NOT the actual content of the SPB. The endpoint consults the remote.dir file for shares and uses TRAA account to access the remote shares and install the package. The final status is relayed back using the usual MDist2 communication path.

Maintenance

By default, the "wdepot image" command creates two files named nnnnnnnn.toc and nnnnnnn.dat, where nnnnnnnn is the serial number. If you have large number of packages, it is difficult to keep track of this number and its associated packages and it is wise to setup a lookup table preferably using an automation script.
Keeping track of which fileserver has which package is a complex process as well and scripts could be developed to maintain this information. Also, you could use software distribution/activity planner to deploy the packages to remote fileservers.

FAQs

Would Check Point Restarts work?

No. Please understand that when you do FileServer distribution, the packages are transferred from file share using Windows SMB protocol and MDist2 is no way involved in the transfer. So, check point restarts will NOT work.

Will I see a progress of data transfer?

For normal distributions, you will see a progress of data transfer using wmdist command. But, again this is a MDist2 feature and you will NOT see the progress of data transfer in wmdist -I command while using file server distribution.

Can I change the contents of remote.dir dynamically?

Yes. It is just a text file that will be consulted during fileserver distribution.

What are the package formats supported?

SPB only.

Can I distribute to non-Windows endpoints?

No. Again this features relies on TRAA and SMB protocols.

Can I host the fileserver on a Unix box running Samba?

Good question. Worth testing :)

Hope you find it useful.