Additional actions after the upgrade

This topic consists of the following sections:

Where you are in the Upgrade process

Step	Task
1	Preparing-for-upgrade
2	Performing-the-upgrade
3	Additional actions after the upgrade (You are here)

Additional actions for BMC Release Process Management

The following defects require additional actions if you upgrade from the provided or earlier versions of BMC Release Process Management.

Defect	Description	Upgrade from version
DE93258	When you upgrade from version 4.6.00 on a system with a PostgreSQL database with large amounts of data, a 500 Internal server error appears when you open the Currently Running Steps sub-tab from the Dashboard or Request tab. Workaround: After patch installation, clean up old roles implementations leftover from the previous release by running the following rake task: jruby -S bundle exec rake app:update_step_frozen_owner	4.6.00
DE88874	In database, there are duplicated records for the same version tag. Workaround: To delete duplicate version tags, run the following rake task: jruby –S rake version_tags:clear_duplicates	4.4.00
DE82434	When you use LDAP for authorization, users cannot access the assigned requests and steps until you update their user roles.	4.4.00
DE88790	When you use integration with BMC Release Package and Deployment for managing NSH server and use NSH user name and password in BMC Release Process Management automation steps, the NSH user password is saved as not encrypted text in BMC Release Package and Deployment logs. Warning: The updated automation scripts work only if you integrate BMC Release Process Management version 4.4.00.03 or later with BMC Release Package and Deployment version 4.4.00.03 or later. After you install version 4.4.00.03 or later for both BMC Release Process Management and BMC Release Package and Deployment, update the automation scripts for BMC Release Package and Deployment.	4.4.00.02
DE89692	When you use automation scripts in a step, the automation keeps a reference to this step after you delete this step. Workaround: After upgrading to BMC Release Process Management version 4.4.00.04 or later, to remove references from the deleted steps to automations from your previous BMC Release Process Management version, run the following rake task: jruby –S rake app:remove_deleted_steps_automation_reference	4.4.00.03
DE89044	When in a step of a request, you use the BMC Release Package and Deployment automation script and this step fails, the step log contains link to the last successful deployment log instead of the failed deployment log.	4.4.00.04

Applying the updates

To update BMC Release Process Management, complete the following actions:

Stop the BMC Release Process Management service for the current version.
Go to RLMhome\bin and run the following executable file:
- (Windows) setenv.bat
- (UNIX) setenv.sh
  Note
  On UNIX, run the file with the following command:
  . ./setenv.sh
Go to RLMhome\releases\yourCurrentVersion\RPM\portal.war\WEB-INF\config and perform the following actions:
- To remove duplicated records for the version tag, run the following rake task:
  jruby –S rake version_tags:clear_duplicates
- To fix the access for requests and steps for the LDAP users, run the following rake task:
  jruby -S rake user:assigned_apps:update_roles RAILS_ENV=production
- To remove references from the deleted steps to automations, run the following rake task:
  jruby -S rake --verbose app:remove_deleted_steps_automation_reference
- To update automation scripts automatically, run the following rake task:
  Note
  The custom changes to the default automation scripts are not saved during the automatic scripts update.
  jruby -S rake scripts:automation:update_automation_scripts['<automation scripts category>']
  <automation scripts category> represents one of the following: BMC Application Automation 8.2, BMC Remedy 7.6.x, General, Hudson/Jenkins, RLM Deployment Engine, IBM MQ, IIS, Tibco, Local Shell, Weblogic 11G, Websphere 8, Tomcat 7, MySQL 5, Windows, DB2, jboss6, Oracle 11g, Docker, IBM MQ, MS SQL.
  Note
  Before you update automation scripts for BMC Application Automation or BMC Remedy 7.6.x, make sure the scripts do not contain any comments introduced with three or more hashes in the section between the beginning of the script and the end of the script input and output parameters. Otherwise, you receive an error message and you cannot update the automation scripts.
  For example, to update automation scripts for BMC Application Automation, run the following rake task:
  jruby -S rake scripts:automation:update_automation_scripts['BMC Application Automation 8.2']
  To update all scripts in BMC Release Process Management, run the following rake task:
  jruby -S rake scripts:automation:update_automation_scripts['All']
- To update automation scripts for BMC Release Package and Deployment manually, open the automation scripts in a text editor, change the following code lines:
  write_to("Setting value for property: #{k.gsub("DE_", "")}")
  RlmUtilities.rlm_set_q_property_value(RLM_BASE_URL, RLM_USERNAME, RLM_PASSWORD, package_id, "package property add", k.gsub("DE_", ""), v)
  with these code lines:
  write_to("Setting value for property: #{k.gsub("DE_", "")}")
  encrypt = params["#{k}_encrypt"]
  RlmUtilities.rlm_set_q_property_value(RLM_BASE_URL, RLM_USERNAME, RLM_PASSWORD, package_id, "package property add", k.gsub("DE_", ""), v, encrypt)
  and then run the following rake task:
  jruby -S rake scripts:automation:update_automation_scripts['RLM Deployment Engine']
- To clean up old roles implementations leftover from the previous release, run the following rake task:
  jruby -S bundle exec rake app:update_step_frozen_owner
- To remove groups and teams automatically created during database migration, see Using a rake task to remove groups and teams.
- To remove manual group assignments for LDAP users, see Using a rake task to remove manual group assignments for LDAP users.
Start the BMC Release Process Management service.

Using a rake task to remove groups and teams

When converting an existing BMC Release Process Management 4.4 database to 4.6, the database migration process recreates the team and role permissions that currently exist in the application. This action results in a number of teams and groups that, while accomplishing the task, do not necessarily fit into a holistic Role Base Access Control (RBAC) strategy. For a reasonably complicated BMC Release Process Management installation, this action can result in dozens or even hundreds of groups and roles to remove.

The following rake task removes all of the automatically created teams and groups from the database. This rake task is intended for BMC Release Process Management administrators and BMC consultants to assist in a structured RBAC transition. The existing users whose groups and roles are removed by the rake task will not be able to perform their duties until you create new roles and groups for them.

jruby -S rake app:remove_automatic_groups_and_teams

The rake task works entirely by the name of the object and according to the following rules:

Groups and teams that match the following criteria will be deleted completely with no recovery:
- Any group that ends with "-group" (for example, Group.where("name like '%-group%'")
- Any team that ends with "created team" (for example, Team.where("name like '%created Team%'")
Automatically created roles are left in place and have names such as Deploy, Coordinator, Deployer-admin, and so on.

Using a rake task to remove manual group assignments for LDAP users

After upgrading to BMC Release Process Management 4.8 or later with the new LDAP group mapping feature, all your manual LDAP user group assignments are saved. If you need to delete them to create new LDAP group mappings, use the following rake task:

rake user:clean_roles [-u <user>] [-g <group>] [*]

The rake task works according to the following rules:

Only one of the following options can be used:
- [-u <user>] – to delete all manual group assignments for a specified user
- [-g <group>] – to delete manual group assignments for all users of a specified group
- [*] – to delete all manual group assignments for all users
The rake task can be applied only to LDAP users.
The rake task does not remove a root user from a root group.

Adding CORS_ORIGINS property for cross-domain access

The cross-domain access from the

Some content is unavailable due to permissions.

to the BRPM server is ensured by the cross-origin resource sharing (CORS) mechanism. In BRPM 5.0.00 and 5.0.01.00, the access is allowed for any origin by default. Starting with BRPM 5.0.02.00, the cross-domain access to the BRPM server from any external system is denied by default.

While upgrading from version 4.8 to 5.0.03, the CORS_ORIGINS property is not added to the production.rb file. You must manually add the property and specify the value that matches your requirement. To add the new property, perform the following steps:

Go to RLMhome/releases/productVersion/RPM/portal.war/WEB-INF/config/environments and then open the production.rb file.
Add a CORS_ORIGINS property and specify the value that matches your requirement.
You can specify multiple origin servers, for example, if you are running the
Some content is unavailable due to permissions.
on two or more servers.
Example
If the
Some content is unavailable due to permissions.
is served from http://rlmui.yourdomain.com:9090/rlmui, you must enter the following value: CORS_ORIGINS = 'rlmui.yourdomain.com:9090'.
If you have several
Some content is unavailable due to permissions.
instances running, use the following regular expression to specify multiple origin servers: CORS_ORIGINS = /(rlmui1\.yourdomain\.com:9090|rlmui2\.yourdomain\.com:9091)/.
Save the changes.
Restart the BRPM service. For more information, see Starting or stopping product services.