Performing Surgery on the CMS after SAP BI4 Patch Installations

[Former Member]

In, SAP BusinessObjects BI4, the CMS has become an integral part of the installation and maintenance process for any SAP BI or Data Services system. Details on the patch level and installed components are stored in the CMS database and the only way to check and update the CMS information is to have the CMS up and running.

On the face of it that is a “good thing” in that there is now a central place where installs (and uninstalls) can keep a record of the state of your B.I. Platform. As long as all installs are performed cleanly and your CMS database is maintained in sync with your platform this works very well. In practise this reliance on a clean operational CMS can give you problems that require some quickly thought out workarounds when installations and database restores don’t go to plan.

The worst example I’ve had to contend with is from a company that didn’t keep a record of which patch level had been applied to their system and a number of different people were responsible for maintaining the system. One of their people was tasked with upgrading to the latest patch level but they didn’t know which service pack had been applied. They managed to apply a patch applicable to a different service pack which resulted in a system where the CMS couldn’t start because some of the software components failed because of the different patch and service pack levels.

At this point there was no going back because, as we noted before, the misapplied patch could not be uninstalled due to the requirement for an operational CMS. I eventually found two methods of recovering the situation (three if you include a complete OS reinstall). The first method, which I actually used on the environment that had been broken, was to manually back out the software components that had been updated that were preventing the CMS from starting. To do this I examined the log files, noted the failing component and then copied it from a clean install that was available at the same service pack and patch level as the original system. It was lucky that such a system was available but the installation does maintain a history of previously installed components so you could use that for the recovery. The start up/fail/check log/recovery process was repeated until all of the failing components had been recovered and the CMS started. At this point the other BI services failed but it was possible to uninstall the offending patch which restored the system completely.

I found a second method after recreating the problem on a test bed. I discovered that the install/uninstall process does not actually care which CMS it signs onto to maintain the install history. So the easy answer would have been to point the uninstall process at a CMS running on a different machine and then let it run on the broken machine to roll back the problem patch. Of course after that you would have a donor system which would report the wrong patch level until a new service pack or patch was applied.

There is a step in the install that checks whether the patch being installed is applicable to the target system but this sometimes reports as an optional failure which means you can continue with the install anyway. Rather than relying on this check we advise that you always check the installed software listed in the Windows control panel. This will show a list of all the service pack and patches already applied which you can use to confirm that you are applying the correct software package.

References:

• SAP BI4 CMS down after patch install
• SAP BI4 Patch rollback

If you have any queries requiring this post or require further information please call IT Performs Support on 0121 323 1066.