Atrium Core :Upgrading AtriumCore to 1808

Knowledge Article

Article Number

000288753

Old Article Number

000157623

Article Type

FAQ/Procedural

Title

Atrium Core :Upgrading AtriumCore to 1808 - Need to know

Summary

What you need to know when upgrading from versions 8.1 and 7.6.04 to version 1808.

Product

BMC Atrium Core - CMDB

Component

BMC Atrium Core

Applies to

Upgrading AtriumCore CMDB from legacy versions of the product.

Question

Is there anything that I should know or do before upgrading my production environment?
The answer is yes and the following answer will explain all things that you should review before starting the upgrade to 1808.

1808 upgrade failure may trigger the Zero Down Time roll back if the upgrade fails. This is something we want to avoid because it will roll back the AR Server as well as AtriumCore.

Some of these checks are already done by the installer and you may get a Warning message about them. Below is a list of all issues we've found during the upgrade that was tested from version 8.1.

- Check for Classes in Pending or Delete status in OBJSTR:Class. Delete them if you find any, but first check to see if there is an Active "Copy" of that same Class record.
The installer detects CMDB attributes (missing fields) that are out of synch with AR metadata, but it does not detect out of the box fields and classes.

Please see this KA for understanding of AR and CMDB metadata: AtriumCore CMDB CDM break down within the ARSCHEMA database

Also please see previously known issues with upgrades prior to 9.1.04: Upgrading AtriumCore from 7.5 to 8.1 and 9.1 - What you should know to prevent upgrade failures

Prior to upgrade:

- Check for classes in Pending status in OBJSTR:Class

- The cdmchecker -m -u <username> -p <password> -s <server> -t <tcp port> produces an output
file called missing_fields.log

If there is an error of this type the upgrade will fail:
[ERROR] AR Form name BMC.CORE:BMC_BaseRelationship does not fit the valid format for class BMC.CORE:BMC_Component

To avoid the error, use the OBJSTR:Class form and search for the failing class,
such as BMC.CORE:BMC_Component. In the error given, the CategorizationSubclass field
for the BMC_Component class was set to No. It needs to be set to Yes (which is the default).

Here are additional details about the cdmchecker utility to check AtriumCore CMDB for errors
prior to running the upgrade:

https://docs.bmc.com/docs/ac91/using-the-cdmchecker-tool-679149883.html

- Disable Record-Object-Relationships if set to T (true). Change it to F (false) and restart AR Server. Having it set to True impacts the conversion of Custom forms during the upgrade. (SW00519835)
Operating-Mode setting set to a value of 1 will turn it off when AR Server is started, but that's only for AR Server. For AtriumCore the Operating-Mode needs to be 0 and also the Record-Object-Relationships needs to be set to false.
You could see this message in the arerror.log when that is enabled and AR Server Operating-Mode is still set to 1. "Server is in UPGRADE mode. Object relationships tracking is implicitly turned off"

- Check for Attributes for Pending or Delete status in Attribute Definitions form.

- Enable unqualified search and Max Query limit to 0 or at least above 50,000 records.

- Enable max attachment size to be unlimited (or above 60 Mb)

- Clear out records out of "Reconciliation Job Runs" and "Reconciliation Job Events" forms that are older than a month.

Please see KA000052300 "Reconciliation performance issues caused by too many records in the RE:Job_Runs forms" :
https://selfservice.bmc.com/casemgmt/sc_KnowledgeArticle?sfdcid=000052300

for reference.

- Clear out CMDB Logs and %TEMP% logs including Utilities before the upgrade

- Make sure to have at least 30 Gigs of free disk space.

- Check the Swap file management on Windows(*1)

- On Linux run: sudo free && sync && echo 3 > /proc/sys/vm/drop_caches && echo "" && free

- Validate Atrium Web Services before starting the installer and make sure there is enough RAM if on same system.

- Have java updated and locked down by a path, not variables. For example remove BMC_JAVA_HOME variable from armonitor where the AtriumCore plugins are loaded and replace it with the direct path to the java.exe.

- Have the AR Server DB and the VM backed up before you attempt the upgrade. ZDT (Zero Down Time) feature will roll back the entire upgrade if it fails.
This can cause more delay than restoring from backup. The task is easy, but it might require help from your DB Admin group.
Creating DB backup in MSSQL:

Although we think that the upgrade will do fine if all these precautions are taken care off.
This KA was researched and prepared by BMC Software support organization.

Answer

This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers.

We've validated this upgrade extensively and while most found issues got fixed, some issue remain open. BMC documentation has published a list for 1808 known issues which is available here:
Known and corrected issues for AtriumCore 1808

Here is what you need to know:

A. SYSTEM RESOURCES

First concern is the resources of the system on which the AR system is hosted. Older versions of the product can be hosted on systems that are under the bar for version 1808.
We've tested upgrades on systems below 16 Gigs of RAM, 2 CPUs, and limited space available for swap file. Each attempt has failed at some stage or another.
As a result of this testing our recommendation is to have a minimum of 16 Gigs of RAM, 4 CPUs and enough room for swap file(*1) and logs.

(*1)Windows Swap file should be setup to match the recommendation made by the operating system.
If the system has 16 Gigs of RAM then make sure the VM size is set recommended by the VM setting.
Make sure that the "Space available" is not lower than BMC recommendations for free disk space which
also needs to be able to accommodate the size of the swap file:
User-added image

B. UPGRADE PRE-CHECKS & KNOWN ISSUES THAT MAY COME UP DURING THE VALIDATION STAGE.

Known Issue	Impact	Action to take
AtriumCore Upgrade fails to configure the AtriumPluginSvr 9556 plugin during the upgrade. This is caused by bad log4j_configsvr.xml in 8102. Plugin ERROR with port 9556 shows up on top of the midtier page when the upgrade is done.	Minor	Create the file using the attached samples. pluginsvr_config.xml and log4j_pluginsvr.xml. Please edit the file and replace the drive letters C: with your drive letter. Also the hostname in the pluginId should be changed to match the server on which the plugin is running.
AtriumCore Upgrade to 1808 fails to detect a missing field : OfferingType.	Severe	Validate that all "Out Of the Box" fields and classes are present before the upgrade. In our test the field missing was OfferingType, however the error can be associated with any missing fields or classes. Unfortunately the "missing_fields.txt" report only looks for discrepancies between AR and CMDB metadata. It will not detect missing or overlaid fields. This will cause the upgrade to fail.
AtriumCore Upgrade Atrium WebService ERROR message is incorrect: Invalid User or Password for uddi admin if Tomcat was just started.	None	This is caused when the AWS server is not fully up and running. Make sure that you can access the http://HOST:PORT/uddi page before starting the upgrade. The Tomcat service can be running, but the web services need to be deployed first. This can take 5 minutes or so. If you're upgrading AWS on the same server where AtriumCore is installed then please make sure you can see this first:
AR and AtriumCore upgrade pre-checker fails to detect Plugin-Port	None	This error seems to be only if the Plugin-Port: is set to a value. It can be ignored. Here as an image showing that the port is in listening state, yet it shows as an error.
AtriumCore Upgrade 1808 from 8102 failure - NOE:QueryTransaction wf-RIK-SW00519835	Severe	NOE:QueryTransaction is a "Custom" form in 8.1 and gets converted during the upgrade by the installer. Delete the Custom NOE:QueryTransaction form in Best Practice mode before the upgrade and import the attached definition using the Base Development mode in dev studio (version 1808). You can import the entire NOE:QueryTransaction def file with overwrite on. File is attached to this KA. The NOE:TransactionQuery was originally installed as a custom form in 7604 when SIM extensions were installed and configured for BPPM. See screen capture below. The upgrade tries to convert it during the upgrade but it fails if the Relationship Object Recording is enabled. The conversion will fail and prevent the form from being updated at a later stage. The form is not found while in Development mode of the BMC Dev Studio. This should be detected and form converted to be a Regular non-overlaid form. It's safer to just delete the custom form and import it from the attached definition file "NOE:QueryTransaction". However, you should still disable the Relationship Object Recorder setting (uncheck it in AR Server Administration panel -> Configuration tab) before the upgrade.
Upgrade to 1808 leaves out some key files from sdk folders	Minor	ATRIUMCORE_HOME\cmdb\sdk\bin\arutil91_build005.jar is referenced in armonitor.cfg but the file is not there. Copy it from ARServer\pluginsvr folder. Check for additional missing files to be sure.

For Solaris related installs or upgrades please see: https://selfservice.bmc.com/casemgmt/sc_KnowledgeArticle?sfdcid=000159441

Attachment(s):

log4j_pluginsvr.xml
pluginsvr_config.xml
NOE:QueryTransaction