I needed to implement Single Sign-On between IBM WebSphere Portal and HP Operations Dashboard (HPOD) without using a SSO product, and figured that we could do that using the LTPA token generated by WPE on login to the Portal. For LTPA token based SSO to work, we need to be able to decode the LTPA token on the HPOD front – HPOD is based on Jetspeed – in other words, we are looking at implementing SSO between WebSphere and Jetspeed. I was just getting ready to look up some info that I have from Jerry Cuomo on the LTPA token format, when I tried a quick Google search and found an even better answer. I stumbled upon a blog entry and functional code for LTPA token decoding at http://blog.offbytwo.com/2007/08/21/working-with-lightweight-third-party-authentication-ltpa/. I downloaded the code, exported the LTPA keys from a test WPE server, copied the 3DESKey and our LTPA encryption password into LtpaUtils, logged in to the WPE test server, determined the LTPA token cookie value for test purposes, and was able to decrypt it just fine using LtpaUtils. And thanks to Cosmin, all of this took about 20 minutes!

Recently I started to delve into HP OpenView Operations for Windows (OVOW) policy management from the perspective of learning how to build custom policies and determining what standard policies to apply on some WebSphere Portal related servers that I needed monitored. I skimmed through the OVO Basic Tutorial and tried to actually perform step 10 of the tutorial around creating a custom policy and step 11 around deploying a standard policy. Creating the custom policy (NotepadTest) from the tutorial was a piece of cake – 10 minutes. However getting the standard “email notification” policy to work was not so straightforward!

I followed the instructions in the tutorial to the “T” using the FwdMsgAsEmail policy as the basis, but to no avail – no email notifications. Instead, I had a critical error message – Failed to forward message as e-mail: ‘1 processes “notepad.exe” with parameter “” are running. Expected: 0 process.’ Looking at the 2 annotations on the message, I saw this -

Annotation 1:

automatic action started.
Operator : SYSTEM

Node : kingfisher-ovow.ausnq.com
Action : cscript.exe "%OvInstallDir%\bin\FwdMsgAsEMail.vbs" -MsgId 71009140-9ea4-71dc-0efe-0a0a0a850000 -to "my_email_address@xtivia.com" -from "ovow@xtivia.com" -mailsrv "mailserver" -name "HP OpenView Operations"

Annotation 2:

automatic action failed.
Result : -1

Output :

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
STDERR: Invalid argument 'Files\HP'.

On looking through the HP forums I found that there were others who had run into the same issue, but no obvious solutions. Based on the error message, it appears to me the result of a fatal flaw in Windows installs where you accept default paths that contain spaces (C:\Program Files\HP OpenView). I suspect that if you ran this tutorial with OVOW installed in a path without spaces, you would not encounter the issue. In my case, I just plowed right ahead with the existing install. Once I figured out the command that was being run to send out the script (shown in annotation 1), it was a simple matter to open FwdMsgAsEMail.vbs and see that it was trying to use OvEpMail.exe to send the email. I played with it for a bit and quickly replaced OvEpMail.exe with Blat and ran into a similar issue. Tracked that down to the email subject and was able to get the email notifications to work with a hard-coded subject of “test subject”.

Essentially I replace the following section in FwdMsgAsEMail.vbs

If IsEmpty(MailSrv) Then
Command = "OvEpMail.exe -to " & Recipient & " -from " & Sender & _
" -subject """ & Subj & """ -file """ & TmpFilename & """" & _
" -format convert -name """ & DispName & """"
Else
Command = "OvEpMail.exe -to " & Recipient & " -from " & Sender & _
" -mailsrv " & MailSrv & _
" -subject """ & Subj & """ -file """ & TmpFilename & """" & _
" -format convert -name """ & DispName & """"
End If

with

If IsEmpty(MailSrv) Then
Command = "blat.exe -to " & Recipient & " -f " & Sender & _
" -server localhost" & _
" -subject """ & Subj & """ """ & TmpFilename & """"
Else
Command = "blat.exe -log c:\temp\blat.log -to " & Recipient & " -f " & Sender & _
" -server " & MailSrv & _
" -subject """ & "test subject" & """ -bodyF """ & TmpFilename & """"
End If

Obviously, in retrospect, I could have gotten OvEpMail.exe to work as well and I am sure a production version of this policy would need to have a more useful subject, but if you like me, run into this issue while simply trying to make the basic OVOW tutorial work, then you could use the workaround that I did!

I have spent a significant part of the last couple of weeks chasing down the right solution for integrating data from HP OpenView Operations (OVO), HP Network Node Manager (NNM), HP OpenView Performance Insight (OVPI), and HP OpenView Internet Services (OVIS). And I have finally settled on the HP Operations Dashboard!

The HP Operations Dashboard consists of two modules – the Operations View (OPV) and the Real-time Health View (RHV). The OPV enables you to create a single pane view into individual domain tools such as NNM, OVO, OVSN and others by selecting any of the out of the box Portlet views for the supported products – a limitation is that each portlet can only provide a view into a single product – i.e. an OPV portlet cannot combine data from more than one domain tool. The RHV enables you to stitch end to end infrastructure service views by leveraging infrastructure models in domain tools. You can use the RHV to consolidate event and performance information from domain tools to create health indicators for the infrastructure services that are of high interest to you. It can even look across into the helpdesk activities to understand how IT is responding to infrastructure health issues. Finally you can drilldown from RHV module into OPV module for complete details.

In our particular situation, OPV provides value in case of integration with NNM and OVO; however the OVPI integration is extremely simplistic and essentially an iframe. We could do that without investing in OPV. And the OVIS integration does not seem overwhelming either. However, all in all, there is value with the OPV portlets for NNM and OVO that makes me think that it will be worthwhile investing in OPV. We see this as the first step and once we have that in place, we will look at getting RHV going. I am sure I will have updates as we work with HP OPV.

Recently I have been looking into HP Software (formerly OpenView) as we have an opportunity to create an IT dashboard for a customer that uses several management products from this HP product suite. We are looking at integrating data from HP OpenView Operations (OVO), HP Network Node Manager (NNM), HP OpenView Performance Insight (OVPI), and HP OpenView Internet Services (OVIS). Rather than tying the dashboard directly to the database, we would prefer to interface to these products at a higher level. While skimming through the HP site, I discovered HP Operations Dashboard – a product that does integrate data from all the fore-mentioned products. I have been trying to absorb as much information as I can about the dashboard product and the other underlying OpenView products so that I can make the right choices. However, HP certainly does not make it easy!

They have no website for HP Software that comes close to the IBM DeveloperWorks site nor do they have InfoCenters a la IBM products. HP is certainly doing a great job of making me appreciate IBM’s documentation! Also third-party coverage by magazines of these products is scarce to non-existent as far as I can tell.

However, after spending a significant portion of the day scrounging the web for information, I have managed to find some resources that have been useful. Hoping that I can make some sense quickly so that we can move on with scoping the dashboard project and get it rolling!