Prior to upgrading your production system, the best practice is to first test the upgrade using a copy of the production database in another environment.
To do so, you would duplicate your production environment, and then perform some post-copy configuration changes to ensure that the duplicate environment does not conflict with your production environment. You would then upgrade the test environment and run some functional tests to test the upgrade. The steps in this topic cover the high-level steps that you must perform; the specifics will likely vary, depending on the database in use, the operating systems involved, and the particular environment details.
This topic includes the following sections:
Before moving or replicating your BMC Server Automation environment, note the following potential issues:
You might need to temporarily stop your BMC Server Automation Application Server to create a backup of your database and file server, depending on the backup mechanisms being used. This will ensure that both backups are synchronized to the same date and time. Notify any BMC Server Automation users that the system will be down during this process. The amount of time that the application server will be down depends on how quickly you are able to copy your file server and database. This time period can vary, depending on how much data is contained in each of these infrastructure pieces.
Ensure that your environment includes the following elements:
First, decide what you are going to move or replicate. In some cases, you might want to move only the file server. In other cases, you might want to replicate your entire infrastructure. The following steps assume that you are moving or replicating your entire environment, so if a particular piece does not apply to what you are moving or replicating, skip that step.
Note
If you are using BMC Decision Support for Server Automation, it is recommended that you replicate that environment as well. See Moving the BMC Decision Support for Server Automation environment.
To move the database, perform the following steps: Import the core database into the new database server w/ the corresponding import tool. An example is shown below. Note If the target environment already has working Application Servers at version 8.6 or higher and you want to preserve their configurations, then prior to the database import, export the contents of the application_server_deployments and service_config_property_value tables. These tables store the configuration data for the application servers. To move the file server, perform the following steps: Install an RSCD agent on the server that will function as a RSCD Agent. Note If you are using a non-Windows environment, you can skip this step, as the RSCD Agent is included in the Application Server installation that will be performed in the next section. To use the application server(s) in the new environment with the imported database, perform the following steps: Copy the files listed in the Files section of the Backup and Restore of the BladeLogic Environment document from the old application server to the new application server(s) except the bladelogic.keystore file. Leave the bladelogic.keystore that we created during install on the new application server. To move the provisioning environment, perform the following steps:Moving the Database
expdp [sys username]/[password]@[sid] schemas=[bladelogic schema] directory=[test_dir] dumpfile=[bladelogic schema].dmpdp logfile=expdp_[bladelogic schema]_[date].log flashback_time="\"to_timestamp(to_char(sysdate,'mm-dd-yyyy hh24:mi:ss'), 'mm-dd-yyyy hh24:mi:ss')\""
impdp [sys username]/[password]@[sid] dumpfile=[bladelogic schema].dmpdp logfile=impdp_[bladelogic schema]_[date].log transform=oid:n full=n schemas=[old schema name] directory=[test_dir] table_exists_action=replace remap_tablespace=[old bladelogic tablespace:new bladelogic tablespace],[old bladelogic index tablespace:new bladelogic index tablespace]
remap_schema=[old bladelogic schema:new bladelogic schema]
Moving the File Server
Using the Application Server(s) in the new environment
blasadmin -a set database ConnectionString <ConnectionString>
blasadmin -a set database DriverClass <DriverClass>
blasadmin -a set database UserId <user_name>
blasadmin -a set database Password <Password>update application_server_model set is_deleted = 1;
commit;
(Oracle only)Provisioning
After your environment has been moved, there are some final steps that you will want to make to ensure that there are no conflicts with your existing environment. If there are Extended Objects that reference the old file server or other location these must be updated as well using the update_extended_object_script_location included in the external-files.zip for the release. If there are Depot objects whose payload is stored on a remote NSH path and not the file server, and those payloads are also moved in the new environment, the depot_object_location.remote_path column will need to be updated as well. There are a few ways to accomplish this. One way to handle this is to generate a self-signed certificate for an Application Server in the new environment. Another way is to restrict network access between the two environments; this will prevent accidentally connecting to the original environment. If the new environment is being used for testing you will want to disable scheduled jobs so they will not run against the registered servers. This can be done with a simple query: update schedule set is_deleted = 1; commit; (Oracle only) Setting the is_deleted flag is a non-recoverable operation, the schedules will be permanently disabled in the new environment. This is typically desirable for testing environments. If the new environment is being used for testing you will want to disable any job notifications to avoid confusing when testing jobs in the new environment. This can be done with a simple query: update notification set email_to='test123@example.com'; commit; (Oracle Only) If the new environment is being used for testing or the existing repeaters, appservers and SOCKs proxies will no longer be needed, then the routing rules can be removed with a few queries: Delete SOCKS Proxy assigned in Network routing rule Delete Job Server assigned in job routing rule. update routing_policy set is_deleted = 1 where routing_policy_type_id = 2 Delete Repeater assigned in Repeater routing rule. commit; (Oracle only) If the new environment is being used for testing you may want to prevent the new application servers from talking to your existing targets. This is possible by pushing out an exports file from the original appserver/environment to all target servers that allows connections from only the original application servers and any NSH client systems you need to allow connections from. Decommission any servers that are in the development environment that you will not manage. This will prevent any confusion for anyone that might log into the duplicated environment. Note If you have an 8.x environment AND have the Licensing Portal configured, make sure that you configure the Licensing Portal to not re-claim any licenses when you decommission servers. If you do, you will need to re-license your servers in the original environment that you copied from.Updating Extended Object Locations
Updating Remote Depot Object Locations
Preventing access from the new environment to the existing Application Servers
Removing Job Schedules
Removing Notifications
Removing Routing Rules
update routing_policy set is_deleted = 1 where routing_policy_type_id = 1;
update routing_policy set is_deleted =1 where routing_policy_type_id = 3;Preventing access from the new environment to existing managed servers
Decommissioning Servers (optional)
Review the pre-requisites for upgrade:
Follow the steps in the upgrade walkthrough topic that is appropriate for your environment:
After completing the steps in the new environment, perform some representative tests, such as the following:
/etc/init.d/blappserv start
<installDir>/CM/rcp/bsaclient.sh
If the functional tests reveal issues, you may need to make some changes in the production environment prior to upgrading.
For example, you may discover from your testing that you need to make some database remediations, which you could apply at the beginning of the production upgrade outage.
Follow the steps in the upgrade walkthrough topic that is appropriate for your environment: