Migration to HPOM 9 from Tivoli TEC

Note: HP renamed the product called now HP operations manager way too many times. Also it is very inconsistent with using abbreviations. Here we will assume that the term "HP Operations manager" and abbreviations HPOM, OMU, and OVO  mean the same thing :-)

TEC installation actually uses several  separately licensed Tivoli components, so there are substantial savings potential in migration to HPOM 9 which, simplifying, corresponds to Tivoli Framework, Tivoli enterprise console and Tivoli Monitoring combined. Usually a typical enterprise Tivoli deployment consists of those three components and TWS. Sometimes TCM is added to the mix. 

Here are short overviews of three key Tivoli components:

1. Tivoli Framework: provides basic client-server functionality and connectivity with endpoints ( start, stop, health readings, etc). There can be multiple servers in complex region-based hierarchy, but we use a single server. Generally this part of functionality is a part of HP Operations Manager (HPOM). As HPOM uses HTTPS, the CPU resources consumption on the central server will be higher, but we have very few nodes (around 250 ), so related number of simultaneous SSL connections is manageable on a single server. The fact that a single port is used for communication with endpoints in HPOM 9 is important advantage which makes replacing old infrastructure easier (just changing the port and target server on DMZ firewalls).
    
2. Tivoli enterprise console (TEC): provides functionality similar to HP Operations Manager with ECS Designer licensed. Event console is also a part of TEC with very similar Java implementation of approximately the same quality. There are some additional unique features like "event concentrators" (gateways) and event pre-filtering capability on gateways which are important in high volume environment for preventing event storms, but the latter can be replicated by installing correlation engine directly of selected endpoints or using several HPOM servers connected hierarchically. Operator console looks sufficiently similar for operators to move to new system without much hassle. Data storage of events is in Oracle database exactly like in HPOM 9.

   Like Operations Manager TEC provides several adaptors of "foreign" message streams. Two that we use are:

   • Logadapters which converts logs to event messages -- used for getting messages from our job scheduler (TWS)
   • Message adaptor which creates event from parameters given and sends it to the "mothership".

   This functionality exists in HPOM 9 out of the box. Actually I suspect that logadapter functionality in HPOM 9 is more usable then in TEC "out of the box" (in TEC you need to modify processing rules for various flavors of Unix manually).

   The central part of TEC is so called correlation engine, which is programmable (in Prolog) software that correlates messages. Large number of called rules sets that contains correlation rules is shipped with TEC. We did not customized the set of correlation rules that came with TEC that much, so it is difficult to say what problems we might encounter during the transition. We do know that we need to replicate functionality related to job scheduler.

   Look like HPOM 9.01 correlation engine (with ESS designer licensed) is rated in correlations capabilities similarly to TEC (if we believe Gartner judgment ;-).

   Also TEC provides IBM-supplied set of rules with some common sense correlations for job-related messages. For example: job started and takes longer then predefined mount of time - job stalled. In TEC event messages can also be auto-closed based on various criteria of closed by another (so called closing) message. I

   TEC console is often used as central enterprise event console with event streams from other product integrated. For example Oracle Enterprise Manager(EM).  Usually only critical messages from them are displayed so it need some filtering. 
    

3. Tivoli Monitoring: Many organization are still using monitoring 5.1 (please note that Tivoli monitoring 6.x is much more powerful product acquired by IBM from Candle and it itself competes with HPOM). The main usage in most organizations  is for monitoring of space of filesystems and that functionality is easy to replicate in HPOM 9.

Here are some points that might help you to understand the scope and complexity of migration:

• Large part of existing skills on administrator and operator level are reusable. In a way HPOM is more "classic Tivoli" friendly then IBM new Tivoli and migration to it is less costly. It very similar, almost identical client-server model. Both functionality and complexity are close to combination of Tivoli framework, Tivoli Monitoring 5.x and TEC in classic Tivoli.  In other words it is powerful and flexible product.  From my evaluation it looks like considerable part of Tivoli know-how can be almost instantly transferred to HPOM environment . Most concepts and administration procedures of TMF, TEC and ITM looks familiar to seasoned HPOM users and vise versa. Java-based HPOM Event Console is very similar to TEC Enterprise console, so operators need minimal retraining. It looks like TEC operator console should be: more powerful and more flexible. There is also possibility to create a dashboard directly or using SiteScope.
   
• Agent is way too complex; the same as in Tivoli set of popular platforms is supported.  Linux is slightly better supported then in Tivoli with separate agents for 32-bit and 64-bit environments. But agent is more complex (half a dozen processes) and more capricious with it prerequisites and installation then Tivoli agent (which is just one process). Agents can be distributed to nodes using SSH or RSH. They also can be installed manually by FTPing relevant files to the nodes.  Sometimes the latest agent 8.60 refuses to install on a particular older Unix platform and older agent needs to be used (this is the case for AIX 5.2 and older, HP-UX 9.x. etc). Communication between agents and the mothership is via HTTPS. Certificates necessary for HTTPS communication used not always install correctly and resolution of such problems at the beginning is challenging. HP support in this area is weak. There is also a capability of agentless monitoring (using telnet of SSH) via a bridge to SiteScope (which is an acquired product which actually should be integrated into HPOM, but it never was. In other words HP is suffering from the same overcomplexity disease as IBM, just to a lesser extent because it implements far better architecture.
   
• Agents are capable to filter messages. Like in classic Tivoli, agent on each node is simultaneously is the repository of probes (called smart plug-ins) that send messages to the "mothership". HPOM policies determine all aspects of converting an event into operator console message provide pretty powerful capability to specify simple event processing (rewording, duplicate suppression, etc) without actual programming. THis is a strong point of HPOM -- simple processing is simple, and complex is possible, while in Tivoli everything is complex but possible.   Power of policies based filtering in HPOM is substantial and covers all typical areas were TEC was successful and more.  It is really much much better deal both from engineering perspective and, especially, from system administrator perspective: regular sysadmins can be quite productive with the tool.
   
• HP did a very good job in fault tolerance area: much better then IBM with "classic" Tivoli. The product can be installed on  two servers can be used in round-robin fashion: you can switch primary server to the secondary (from the secondary server) for maintenance. Before that you can synchronize the configurations by backuping it and importing on the second server.  There is also support for clusters and such configuration are widely used. All-in-all the ability to use backup manager for maintenance of primary and "follow the time" functionality as well as ability to send different events to different managers are better then in Tivoli.  HPOM also has the concepts of outages and service hours which are not explicitly present in Tivoli (Tivoli implicitly assumes 24x7 environment).  Planned outages of individual servers is an important feature of any datacenter. In Tivoli that can be solved using correlation engine, but HPOM provides an explicit mechanism. 
   
• HPOM is more Unix friendly then Tivoli. First of all it mixes directories for binaries and directories for data files much less then Tivoli. HPOM tries to adhere to classic Unix scheme using /etc/opt/OV tree for configuration files, /opt/OV/opc for binaries and /var/OV/opc for data). But the directory trees are as deep and as obscure as in Tivoli.  Without using Midnight Commander or similar tool they are a mess to work with even with aliases and special variables defined.
   
• Like in Tivoli most operations can be performed from the command line. Commands for most operations that can be performed via GUI are available. That created possibilities of automation for example in installation of agents on the nodes. On a negative side command syntax is, like in Tivoli, a mess with different prefixes and different options style for different commands. Here HPOM matches or even exceeds Tivoli in a very bad sense ;-)
   
• HPOM matches skills of the typical system administrator much better then Tivoli. For example probes (smart plug-ins in HPOM terminology) can be written in shell, Perl or other scripting language. In Tivoli ITM 5.x they are written in JavaScript which is the language few sysadmin know, while correlation engine uses Prolog, a non-procedural the language similar to regular expressions that requires special training to master.  In HPOM any scripting language can be used. Actually, examples supplied with HPOM are written in Born shell (disk_mon.sh, cpu_mon.sh, proc_mon.sh, mailq_l.sh, etc) and Perl (bridge to SiteScope). Sending the alert from the probe involves using the utility opcmsg   (or similar utility opcmon) which in many ways is similar to wpostemsg in Tivoli. It works only on nodes with the installed agent as communication is via HTTPS.

• Messages can be distributed between multiple "expert centers"; protection from event storms is better as agent can contain correlation engine. There is no gateways but servers are relatively cheap (~$12-18K per server license; the main cost is node licensing, which is around $400-$500 depending on volume) and can be linked hierarchically. There is also a unique capability for "horizontal" message forwarding between two or more managers on the same level of hierarchy. This is called "Message forwarding" and it can be used for implementing "Expert centers" concept, when particular group of messages is forwarded for specific group responsible for resolving it (for example network group, Unix admin group, Windows admin group, etc) from the "total message view" on operator console.  This is a clean and very powerful concept that is very useful in large organizations:  it helps to prevent infighting for  the access to the HPOM server administration capabilities.
   
• Correlation engine is different. Provided by defulat capabilities include deduplication available directly from policies and Correlation composer which provides six predefined correlation templates (event suppression, transient states, duplicate events, event timing, event create and annotation).  This is much weaker the Prolog capabilities in TEC but for most organizations this is not the problem as they never used advanced capabilities of TEC (few organizations have capable Prolog programmers).  For more powerful correlation capabilities you need to buy ECS Designer which permits defining your own correlation templates.  In other words each HPOM installation contains fully fledged correlation engine, capabilities of which are hidden by HP, which supplies ECS Designer as a separate product.   An interesting feature is that correlation engine exists on node level, not on the server level, which improves tremendous scalability (at the risk of hosing the node the agent is running on ;-).   Unlike programming in Prolog-like rules language used in TEC, the correlation engine is of "click and enjoy" type which has major negative aspects as without programmability the system is "half-baked", even if rich  functionality is provided out of the box. IF you looks at discussion at HPOM forums it is clear that people lack a systematic approach of dealing with correlation and are slaves of the provided GUI style "click and enjoy" approach.  But one positive aspect of this approach is that elementary tasks can be performed by people with minimal or no programming skills. Again, the fact that there is no algorithmic language in which to program correlation rules  is a weakness, but truth be told Prolog was mostly ignored in a typical Tivoli deployment. Often no custom rules were used or only a few (often outdated and not well maintained) rules developed by IBM or external Tivoli consultants were used.   As with enough trust pigs can fly you probably can get some API and thus programmability using add-in correlation engine called OMi Topology Based Event Correlation which is installed on a separate box and is a Windows-only product that HP recently acquired.
   
• Documentation is frustrating and minimal; manpages lack examples and often are sketchy. This is huge deficiency but:
   
  • First of all this is so typical for enterprise software products that should not probably even be mentioned as a shortcoming,
  • For those who got used to Tivoli documentation it is OK and conciseness might be seen as an improvement over IBM-style when a 300+ pages document can carry almost no useful information.
  • Taking "Essentials" course provide aspiring HPOM admins with two volumes of relatively well written and really useful documentation (and only idiotic IT managers prevent the staff attending at least Essential course after buying this complex and rather expensive, product). 

  At least documentation does reflect the current version of software. An interesting nuance is that HP provides a separate set of documentation for each platform (Windows, Linux, Solaris and HP-UX on Itanium).  There is just a half-dozen books that you need to read  ( Installation Guide, Concepts Guide, Administrator's Reference,  HTTPS Agent Concepts and Configuration Guide, UI installation and admin guides). For people with the multi-year training in reading obscure IBM documentation, deciphering main ideas, extracting typical operations procedures from HP documentation presents the same challenges as before. It's not an improvement, but they are not much worse either.  As usual you can compensate for the incompleteness of documentation with training.  In essence, all HPOM personnel needs training as many aspects of the system are not covered in documentation and man pages often does not have useful examples or have no examples at all.
   

• Training is better organized, better structured and cheaper then outsourced training that IBM provides, which, based on my experience, is a mixed blessing despite generally good curriculum and manuals.  Two major HPOM admin courses are $7.5K per person (3750*2).  HP virtual rooms software is used, which is adequate for the purposes. Students are supplied with own private network of several virtual linux (including two Linux HPOM servers and a client) and Windows servers. That makes possible to use identical IPs for all students and simplifies instructor life.
   
• License cost consists of the cost of server license (deployment can consist of multiple hierarchically interconnected servers) and the flat cost of agent for each server (the cost of agent does not depend on the number of cores or number of CPUs.  HP is more reasonable then IBM and does not resort to cheap tricks like charging per CPU core ;-).  So both the initial acquisition cost and the annual maintenance cost are lower. Not dramatically (the product is still expensive), but lower.  If intelligent IT staff was outsourced you still can get a prepackaged offering of installation of the server plus 50 nodes from HP Professional services for approx $50K. Otherwise taking two telecourses is enough to get you to the level when you can install the server and configure several agents with some basic probes. Migration from Tivoli TEC is more complex issue and here a good consultant can be tremendous help (but only a good one, which is difficult to find). 
   
• Integration with scheduler is on the same level as in Tivoli and several different schedulers can be integrated. ORSYP, UC4 and probably several other enterprise scheduler vendors have (outdated, if we judge from versions on HP site) Smart Plug-Ins for HP Operations Manager. For example ORSYP has a smart plug-in for HPOM 8.x, but hopefully a new version exists or is at work that works with 9.x. It also lists plug-in on its site (Enterprise Scheduler for HP Operations Manager)

  Dollar Universe Manager for HP Operations Manager is a fully integrated, out-of-the-box solution for HP OM systems. The tight integration makes Dollar Universe the natural choice for HP, integrating and scheduling all IT & business processes and further augmenting the value of the HP suite for customers. Dollar Universe is a certified HP OM Smart Plug-In.

  There some positive stories about successful integration of UC4 with HPOM by large organizations on HP website.

  In most cases you can use SNMP for basic integration even if no smart plug-in exists or supplied smart plug-in is of low quality.

• During the planning phase, the key issue are event processing and implementation of filesystems monitoring.

  Event processing usually does not represent too big a problem as facilities of HPOM are adequate for "imitating" useful part of TEC. Please note that most firms use TEC in extremely primitive way so they can actually benefit form more user friendly event processing and correlation infrastructure that HPOM provides.

  Situation with filesystem monitoring is more complex. As a minimum you need to create infrastructure for regular filesystems monitoring and Oracle archive filesystem monitoring. While primitive, Tivoli Monitoring 5.x  does provide ability to create hierarchical set of filesystem monitoring profiles. Say one "universal" profile is used for monitoring standard Unix filesystems such as /usr/, tmp. /var and then individual profiles are used to monitoring filesystems that are critical for the particular box or particular set of boxes (for example, Oracle servers).

  During the planning phase, the key issue is how to implement filesystems monitoring. As a minimum you need to create infrastructure for regular filesystems monitoring and Oracle archive filesystem monitoring.

  HP does not provide any useful monitoring scripts with HPOM and the sample script that it provides for monitoring root filesystem is a joke. So here you need to write some custom scripts, which in my view is a good thing.  In a way, while HPOM does not requires from sysadmin knowledge of JavaScript and Prolog like Tivoli, it does require a very good knowledge of shell and Perl (and other similar scripting language).  Quality of probes determines the quality of monitoring and if your sysadmin is of garden know-nothing variety as for scripting, the results can be very disappointing.

Actually one additional typical Tivoli component that is not included in HPOM is TWS -- Tivoli Workload scheduler and migration from it is a separate topic; it will not be discussed here. Many TEC installations also have Tivoli configuration manager (TCM) installed. The latter provides upgrades of endpoints and execution of scripts on multiple endpoints as well as delivery of files to multiple endpoints. This is important functionality for most IT organizations (very convenient for distribution of some configuration changes, scripts, etc to set of endpoints and gathering information from endpoints). It can work with arbitrary selection of endpoints (for example all, only Linux, only AIX, etc). HPOM provides basic capability with ovdeploy utility, but generally due to universal availability of SSH some package on top of SSH is a better deal and usually pretty cheap solution to the migration of TCM problem. 

Paradoxically, despite selling a superior product, HP does not have any documentation on migration from Tivoli to  HPOM 9.0. The best published methodology for migration from TEC is, paradoxically, IBM's redbook Best Practices for IBM Tivoli Enterprise Console to Netcool/Omnibus Upgrade. While devoted to transition from "classic" TEC to Netcool/Omnibus considerable part of content is valuable as a guide for migration from TEC to HPOM 9 as new Tivoli like is essentially an acquired products that has nothing to do with old "classic" Tivoli. 

There are two strategies for migration from TEC:

• Parallel installation, with all-at-once switchover. This is never a good strategy for large installations, but it is OK for small and medium installations, especially if HP professional services are helping you.
• Installation in phases, with coexistence during gradual switchover. In this case you can migrate endpoints one by one and if you have difficulties you still have a breezing space.

The Linux platform is becoming increasingly popular for hosting ESM solution as Intel based servers are much cheaper that equivalent RISK-based servers from IBM, Sun, etc. The only realistic alternative is Solaris on Intel.

Recently much work has been done in the Linux kernel to ensure that it has the functionality suitable for enterprise deployment.

Please note that default installation of HPOM does not include HP Operations Smart Plug-ins for Windows, UNIX, and web servers. Those need to be downloaded and installed separately. They are extremely primitive that the only real purpose they can serve and as prototypes for something better: 

Pre-defined management policies for Windows, UNIX, and Web Servers, complimentary with HP Operations:

• Windows NT, XP, 2000, 2003
• HP-UX, Tru64, Linux, Solaris, AIX • MS IIS, Apache, Stronghold, Netscape/iPlanet/SunONE
• Work standalone or in combination with HP Performance Agent

HP Smart Plug-ins (SPIs) are fully integrated, out-of-the-box solutions for managing specific IT elements, mostly applications. They work seamlessly with HP Software products.

HP Operations provides complimentary Smart Plug-Ins for Windows, UNIX and Web Servers. Pre-defined management policies for the OS and web server layer enable you to quickly gain control of the essential elements of your IT infrastructure.

Smart Plug-ins for Windows and UNIX re-use operating system data collected by HP Performance Agent, if deployed, and allow for central configuration of alarm setting in a large-scale IT environment. But they also work standalone.

Features

• Pre-defined management policies, representing best practices for OS and web server monitoring
• Service discovery and service model creation for key OS elements
• Performance data logging and visualization
• Support local and global configuration settings, for example in process or file system monitoring
• Smart Plug-in for Windows OS only: light-weight management policies for key Windows applications and tools

It make sense to document what are you doing. Actually migration dramatically improves understanding of Tivoli if not HP Operations Manager :-).

During the planning phase, the key issue are

• event processing
• implementation of filesystems monitoring.

Event processing usually does not represent too big a problem as facilities of HPOM are adequate for "imitating" useful part of TEC. Please note that most firms use TEC in extremely primitive way so they can actually benefit form more user friendly event processing and correlation infrastructure that HPOM provides.

Situation with filesystem monitoring is more complex. As a minimum you need to create infrastructure for regular filesystems monitoring and Oracle archive filesystem monitoring. Tivoli Monitoring 5.x while primitive does provide ability to create hierarchical set of filesystem monitoring profiles. Say one "universal" profile is used for monitoring standard Unix filesystems such as /usr/, tmp. /var and then individual profiles are used to monitoring filesystems that are critical for partial box or set of boxes.

HP does not provide any useful monitoring scripts with HPOM and sample that it provides for monitoring root filesystem is a joke. So here you need to do write some custom scripts. 

Multiple HPOM servers cam be placed strategically throughout your enterprise. Typically, you can use one servers per large datacenter.  If necessary they can be placed behind firewall as the

The most time consuming task is configuration of nodes. This includes defining Node Groups, Message Groups,  Operators

HPOM corrective actions can be automated and/or manual. For example in case of Oracle archive files automatic response is better.

In large installation there can be several types of HPOM users

• Administrator— Responsible for the overall configuration.

• Template Administrator— Responsible for template creation and modification.

• Operator— Responsible for the day-to-day operation of the environment, using the Message Browser as the central monitoring component.

Operator view of environment may exclude non-essential servers.

The following is a list of questions that may help in the HPOM planning phase:

1. How many HPOM servers are required?

2. Which OS will the server run on?

3. Where will the server be located?

4. Do firewalls exist between the HPOM server and client?

5. Which systems/apps need to be monitored?

6. Which systems/ apps are mission critical?

7. What service levels are required? (Platinum, Gold, Silver, Bronze)

8. Which templates need to be assigned?

9. Who will deal with the problems?

10. Will HPOM be linked to a external helpdesk?

11. Which SPIs are available to monitor applications?

12. How many operators views are required?

13. What node groups should be configured?

14. What message groups should be configured?

15. Which applications require template and/or application development?

The Applications

HPOM can monitor applications. Many applications have custom monitoring packages of high quality and in such cases all you need to forward messages to HPOM .  Typical enterprise applications include:

• Oracle

• SAP R3

• WebSphere

• Lotus Notes or Microsoft Exchange

SPIs exist for the three applications: SAP R3, WebSphere, and Microsoft Exchange Server.  Quality is low so you might be better off with alternative solutions.

NEWS CONTENTS

• 20100807 : HP Tech Installation and Startup services for HP OpenView ( HP Tech Installation and Startup services for HP OpenView, Aug 07, 2010 )
• 20100807 : Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus Upgrade ( Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus Upgrade, Aug 07, 2010 )
• 20100728 : OMiDeepDive2009Jul ( OMiDeepDive2009Jul, Jul 28, 2010 )
• 20100728 : GroundWork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS) ( GroundWork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS), )

Old News

[Aug 07, 2010] HP Tech Installation and Startup services for HP OpenView

This is a a pre-packaged service from HP Professional services which in modified form is available for HPOM 9.0. They charge approximately $40K for installation of the server and 50 clients.

[Aug 07, 2010] Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus Upgrade

The acquisition of Micromuse® Inc. brings new opportunities for all involved in IBM® Systems Management discipline, and the development of a new and exciting strategy.

This IBM Redbooks® publication should be used when planning and implementing an integration and upgrade strategy from TEC to OMNIbus. In this book we provide recommended best practices and describe strategies for upgrading existing installations in a way that should best suit the needs of existing TEC-based environments.

The audience for this book is anyone involved in the Systems Management discipline, but it applies primarily to both those with a Tivoli or Netcool background, and is aimed at customers with an existing Tivoli Enterprise Console® investment who are looking to evaluate the comparative characteristics of TEC and Netcool/OMNIbus™ , so that they can perform a system upgrade.

Depending on the complexity of the existing environment and the depth of the requirements, this upgrade could be a significant project, but we aim with this book to make it as straightforward and as successful as possible.

We have structured the book to first introduce a quick overview of the products, highlighting the key benefits of Netcool/OMNIbus so that both audiences can become familiar with the different concepts. Then the architectures of both products are discussed in more detail, concluding with some typical scenarios.

Part 2, "Strategies" on page101, reviews planning and strategy. It begins with detailed guidelines on assessing the existing customer environment in order to identify how TEC is currently deployed. We discuss considerations to make and how to plan the activities required to upgrade. Then different upgrade scenarios are presented with a best practice recommendation that the reader can adapt to his environment.

At this point we would like to stress that this book builds on the utilities provided by the Tivoli and Netcool Integration Event Flow package (downloadable from the IBM OPAL Web site), and the recommendations from the Tivoli & Netcool Event Flow Integration white paper. The main distinction is that they cover various event integration scenarios, whereas we, in addition, map out a complete upgrade path to OMNIbus in our recommended strategy.

The implementation of the suggested strategy is then covered in Chapter 2, "Configuring the event sources" on page277. We describe in detail the steps required to achieve the upgrade with the core components, and discuss other tasks to also keep in mind. A wide range of different rule processing examples are provided, giving comparative and practical guidance, providing a valuable asset for the rule programmer.

Finally, additional technical details on configurations and scripts used and other valuable references can be found in Appendix 2, "Lab configuration" on page367.

Table of contents

Part 1. Overview
Chapter 1. Introduction
Chapter 2. Architecture
Part 2. Strategies
Chapter 3. TEC environmental assessment and planning guidelines
Chapter 4. Upgrade strategies
Part 3. Implementation
Chapter 5. Upgrading to an IBM Tivoli Netcool environment
Chapter 6. Event processing
Chapter 7. Configuring the event sources
Appendix A. Lab configuration
Appendix B. Additional material

[Jul 28, 2010] OMiDeepDive2009Jul

Presentation that provides some information about OMi and event correlation.

GroundWork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS)

In 2007, a whopping $4.3 billion was spent on availability, performance, and network management-33% of the total budget for IT Operations Management. 70% of this was spent on the Big-Four solutions, BMC, CA Unicenter, HP Operations Manager (formerly OpenView), and IBM Tivoli.

Curious about just how much HP monitoring solutions cost, line item by line item?

This twelve-page paper provides a head-to-head cost comparison of GroundWork Monitor, HP Operations Manager, and associated products, finding that GroundWork provides an 82% cost savings over three years.

Recommended Links

Best Practices for IBM Tivoli Enterprise Console to Netcool/OMNIbus Upgrade

Table of contents

Part 1. Overview
Chapter 1. Introduction
Chapter 2. Architecture
Part 2. Strategies
Chapter 3. TEC environmental assessment and planning guidelines
Chapter 4. Upgrade strategies
Part 3. Implementation
Chapter 5. Upgrading to an IBM Tivoli Netcool environment
Chapter 6. Event processing
Chapter 7. Configuring the event sources
Appendix A. Lab configuration
Appendix B. Additional material

[PDF] Migrating to BMC Event Manager from IBM Tivoli Enterprise Console -- contains some useful recommendation for migration.

[PDF] TEC to Netcool Migration By Andy Bentley

Vivit Worldwide - Deep Dive HP Operations Manager i

HP OMi TBEC concepts and operation HP Enterprise TV Online Videos and Podcasts

HP Operations Manager i software - HP - BTO Software

Downloads

Download Center - HP - BTO Software

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019