Major version upgrades on IBM security software has been occupying my life for the past few months. Many of my friends have been wondering where I am, and I should refer them to SIM and SAM who could better answer that question. Of course, just a few months ago it was TIM and TAM, but the bean counters over at IBM figured it made more sense to brand their IAM (Identity and Access Management) products as “Security” instead of using the “Tivoli” name.
The trickiest part of the upgrades has been the dependency list for required software. For example, both the TFIM, TAM, and ITIM products all utilize WAS (WebSphere Application Server). However, TFIM may be compatible up to WAS 8, whereas ITIM is only compatible up to version 7 (this is only an example of course). While one can run multiple versions of WAS within their enterprise, that presents a nightmare when it comes to patching, maintenance, and training new admins. Therefore, the major products (TFIM, TAM, ITIM) and their sub-components (WAS, TDS, TDI, DB2) must be upgraded in a specific order to maintain compatibility across versions and ensure the final upgraded system is secure and maintainable.
I found the TAM->SAM upgrade to be the easiest upgrade since the SAM products have traditionally used RPMs for RHEL systems. The only gotchas I encountered doing these upgrades was a few minor things in the WebSEAL config file did not get properly set for the new version to start. Also, SMS (Session Management Server) is incredibly difficult to upgrade in place without suffering a lengthy downtime. The easiest thing was to stand up new instances of SMS on new servers, cut over to them, and remove the old servers. The other SAM components could all be done in place without an issue.
TFIM was a bit tricky due to the underlying WAS upgrade. IBM stated that TFIM WAS instances could not be upgraded in place. Note to vendors, don’t ever tell me it can’t be done. I found that by copying the TFIM configuration files to a temporary location, then uninstalling TFIM, upgrading WAS, and reinstalling TFIM, I could copy the configuration files back in their same spot on the DMgr (deployment manager), restart the DMgr, and viola! it would upgrade the configuration. This was done with minimal downtime.
The TIM->SIM upgrade has been more of a challenge. Due to the vast number of systems that tie into an enterprise identity manager, there have been a number of integration points that have to be tested and tweaked before the final production cut over. Also, the ISIM API had significant changes to the authentication mechanisms which caused a rewrite of code for any custom applications that utilize ISIM. IBM also stated that the ITIM WAS instances could not be upgraded in place. However, I found that by upgrading the WAS instances, then upgrading ISIM, that I had no issues getting the configuration working with minimal issues. I should also mention we were on the latest WAS fixpacks when this occurred, as earlier fixpacks would not perform the application migrations correctly.
I don’t typically care for in place upgrades of major product versions; however, I was given a resource and time constant for all components involved and estimated that the upgrade path would be accelerated by doing in place upgrades. Because we had several development strings to perform the upgrades on prior to production, I felt the upgrade instructions would be accurate enough to reduce the risk of performing in place upgrades. Thus far this decision has paid off in reducing the time and resources required for the upgrades.
Hopefully in the upcoming weeks I have some more tips once the ISIM system is fully upgraded. Then I need to take a much needed break to work on some personal weather projects so that I can get better data off my PWS through these summer storms.