Preparing for a Windows upgrade

Upgrade overview

The following sections provide information about the latest builds and the supported upgrade paths.

Build information

The following table lists information for the most recent BMC Server Automation version 8.7 builds.

Release	Build number	EPD version number	Release date
Patch 2 for version 8.7	8.7.00.263	8.7.00.002	January 6, 2016
Patch 1 for version 8.7	8.7.00.256	8.7.00.001	December 3, 2015
Base version 8.7	8.7.00.239	8.7.00	September 15, 2015

Supported upgrade paths

BMC Server Automation supports direct upgrade from versions 8.5.xx and 8.6.xx. If you need to upgrade from a BMC Server Automation version 8.3.x. or earlier, you must first upgrade to one of the following:

• The latest 8.6 service pack, (as discussed in the Upgrading section of the BMC Server Automation 8.6 online documentation)
• The latest 8.5 service pack, (as discussed in the Upgrading section of the BMC Server Automation 8.5 online documentation)

Afterwards, you can upgrade from version 8.5.xx or 8.6.xx to 8.7.x.

The following figures illustrate the supported upgrade paths to BMC Server Automation 8.7.x.

In the above diagrams, abbreviations are defined as follows:

• BSA stands for BMC Server Automation
• SP stands for Service Pack
• P stands for Patch

 

_{Back to top}

Step 1: Review requirements and limitations

Prior to upgrading, it is important to carefully review the following requirements and limitations.

 Requirements for upgrade on Windows

Category	Requirement
Base requirements	If you are using the unified product installer on Windows to upgrade your environment, review the following key requirements. Click here to review. During an upgrade, the unified product installer automatically installs an RSCD Agent on every Application Server machine that does not already have an agent installed. If you are not interested in having PsExec installed in your environment or if you are not interested in providing details of the required credentials, you can install an RSCD Agent manually on each of the detected machines. If you have PXE servers on your setup, you must copy the PXE installers to <windows-drive>\Windows (typically C:\Windows) on Windows PXE server before starting Unified product installer. NSH must be present on each Application Server machine (that is NSH proxy server, Configuration server, Job server, or PXE server). Unified installer should be run only from a node set up as a Configuration server (for more about this type of Application Server setup, see Application Server types). During the upgrade, the installer checks the existing version of Perl. If the host computer on which you are installing the Network Shell has: A supported version of Perl installed — The Network Shell installation automatically installs the Network Shell Perl module. For information about the Perl versions that BMC Server Automation supports, see Perl support. An unsupported version of Perl installed — The installation copies files that allow you to install the Perl module after you have installed the supported version of Perl On 64-bit Windows systems, confirm that the <WINDIR>\SysWOW64 directory contains a copy of the chcp.com file. The installer uses this file to set the code page of standard output (stdout). You can obtain the file from a 32-bit version of Windows.
Supported platforms	The unified installer supports Windows 64-bit and Linux 64-bit operating systems. For a complete list of platforms support by the unified installer and also the individual component installs, see: Supported platforms for Unified Product Installer (UPI) in Supported-platforms-for-version-8-7 Supported platforms for individual component installers in Supported-platforms-for-version-8-7
Install mode	If you are using Microsoft Windows 2003 or 2008, you must upgrade in Install mode instead of Execute mode, see Using-Install-mode-instead-of-Execute-mode.
Agents	Some organizations do not upgrade all servers at the same time that they upgrade other system components. When upgrading from a previous release, you should be aware of server-based functionality that requires the presence of a certain agent version. Click here to see the list of functional areas of the product that require the presence of a particular version of an RSCD agent. Functional area Specifics Atrium integration (BMC BladeLogic Integration for Atrium) If you perform a fresh installation of a version 8.7 Application Server, Atrium integration is supported only for version 8.7 agents. If you upgrade an Application Server to 8.7 from an earlier version, Atrium Integration is supported only with agents running an earlier version if the upgrade path for the Application Server included the version on which the agents are running. BMC Decision Support for Server Automation For inventory reporting, an agent must be running version 7.6 or later. Deploy Jobs Deploy Jobs to agentless devices require the Agentless Managed Object proxy to be running an 8.1 or later version agent. BLPackage tracking requires an 8.1 or later version agent. Version 8.1 agents or later versions support spaces in staging directory names on Windows servers. Patch management AIX — Requires AIX targets to be running 8.1 or later version agents. Red Hat zSeries — Requires targets to be running 8.1 or later version agents. SLES 11 — Requires targets to be running 8.1 or later version agents. Windows and Solaris — Require agents of any version since 7.6. However, to run version 7.6, a special procedure must be performed. The procedure is described in the Upgrade Considerations section of the release notes for version 8.1. Debian, Oracle Enterprise Linux, Redhat, and SUSE — Require agents to be running version 8.0 or later. Note: To enable patch deployment on Windows servers where a version 8.2.0 agent is installed, additional steps may be required. See Enabling-deployment-on-Windows-servers. This requirement was eliminated for agents running version 8.2.1 or later. Security You must be running an 8.1 or later version agent to do the following: Disable user privilege mapping for a server. Create a unique password for the BMC Server Automation RSCD user on Windows servers. Server Discovery Requires an 8.1 or later version Atrium Discovery custom configuration object. Virtualization/VSM Citrix XenServer — Requires a Red Hat Enterprise Linux server configured as an AMO proxy, an 8.6 or later version Linux agent, and a Citrix XenServer custom configuration object. Red Hat Enterprise Virtualization (KVM) — Requires a Red Hat Enterprise Linux server running the Red Hat Kernel-based Virtual Machine (KVM), an 8.6 or later version Linux agent, and a Red Hat Enterprise Linux KVM custom configuration object. Red Hat Enterprise Virtualization (RHEV) — Requires a Red Hat Enterprise Linux server running the RHEV Manager, an 8.6 or later version Linux agent, and a Red Hat Enterprise Linux RHEV custom configuration object. IBM PowerVM — Requires an AIX server configured as an AMO proxy, an 8.6 or later version AIX agent, and an IBM Configuration custom configuration object. Solaris — Requires a Solaris Global Zone, an 8.6 or later version Solaris agent, and a Global Zone custom configuration object. VMware — Requires a vCenter host server running an 8.6 or later version of a Windows x64 agent and a VMware vCenter Server custom configuration object. Microsoft Hyper-V — Requires a System Center — Virtual Machine Manager (VMM) running an 8.6 or later version Windows x64 agent and a Microsoft VMM custom configuration object. Configuration Objects Configuration Objects such as 'Unix Users', 'Processes', 'Hardware Information' and the Virtualization objects require the RSCD agent version to match the application server version for full compatibility. For example, if you are using the VMware configuration object to manager vCenter, and your application server is 8.6.00, the RSCD agent on the vCenter server must also be 8.6.00, and the version of the configuration object deployed to the target would be 8.6.00. Built-in configuration objects (such as Unix Users, Unix Groups, Processes, or Daemons) are part of the RSCD installation.
Configuration objects	Upgrading to a new release can potentially create mismatches between the version of a custom configuration object, an agent, and any model objects that reference custom configuration objects. Therefore, as part of the upgrade process, you must distribute the latest versions of the custom configuration objects that are not included as part of an RSCD agent. The product installation is automatically upgraded to the appropriate version when you upgrade the agent. However, you must upgrade any custom configuration objects that are not included with the agent by running a Distribute Configuration Objects Job. Configure this job to target servers to which custom configuration objects need to be distributed. For a list of those objects that are included as part of an agent installation and those that are not included with the agent and require distribution, see Custom-configuration-objects. To upgrade custom configuration objects Click here to see the steps for upgrading custom configuration objects. Run an Update Server Properties Job on the agents you have upgraded. For more information, see Creating Update Server Properties Jobs. Run a Distribute Configuration Objects Job to distribute the latest version of custom configuration objects stored in the Configuration Object Dictionary. The job should target agents that you have upgraded. The system prevents you from distributing custom configuration objects to agents running an incompatible version. For more information, see Creating or modifying a Distribute Configuration Objects Job. If you are not upgrading all of your agents at this time, make copies of all component templates, BLPackages, Snapshot Jobs, and Audit Jobs that reference custom configuration objects that have dependencies on agents running earlier versions. You must maintain a version match between component templates, BLPackages, Snapshot Jobs, and Audit Jobs and custom configuration objects and agents. The objects that you copy in this step are the objects that you can use to maintain the version match. To ensure that all configuration-object-based assets within existing content are upgraded, run an Upgrade Model Objects Job that targets any component templates, BLPackages, Snapshot Jobs, or Audit jobs that you want to upgrade. For more information about the Upgrade Model Objects Job, see Creating-or-modifying-Upgrade-Model-Objects-Jobs. Note: Do not run the Upgrade Model Objects Job against the copies of objects that you created in step 3. If you open an existing component template, BLPackage, Snapshot Job, or Audit Job that references a custom configuration object and a later version of that custom configuration object exists, the system displays a message saying it will automatically upgrade the referenced custom configuration object. To maintain a version match with an earlier agent, close the component template, BLPackage, Snapshot Job, or Audit Job without saving. After executing the Upgrade Model Objects Job, display the results of the job run to see which assets were successfully upgraded and which were not. If you find that certain assets were not automatically upgraded, you must upgrade them manually. Perform the following steps: Open the object (template, package, or job). Manually remove the asset of the earlier version and add the asset of the latest version. Save the object. To upgrade virtualization configuration objects Click here to see the steps for upgrading virtualization configuration objects. The Upgrade Model Object Job is not supported for upgrading virtualization configuration objects. To upgrade configuration objects that you distributed in prior versions, complete the following steps: Import the new version of the virtualization configuration object (for example, the VMware vCenter configuration object). Restart the RSCD agent on which the configuration object is distributed. This step is a prerequisite for successful upgrade of the configuration object on the target server. Run the Distribute Configuration Objects Job to distribute the configuration objects to the target agent (see Distributing-configuration-objects). To identify the configuration objects that failed, run the Upgrade Model Objects Job on all jobs, templates, and BLPackages that reference the configuration object. After the Upgrade Model Objects Job completes, open the objects for which the job failed. Remove the parts that are marked as failed and add new ones from the upgraded configuration object. Upgrading to a new release can potentially create mismatches between the version of a custom configuration object, an agent, and any model objects that reference custom configuration objects. Therefore, as part of the upgrade process, you must distribute the latest versions of custom configuration objects for the custom configuration objects that are not included as part of an agent.  The  installation are automatically upgraded to the appropriate version when you upgrade the agent. (See Custom-configuration-objects for a list of those objects.) You should upgrade any custom configuration objects not included with the agent by running a Distribute Configuration Objects Job. The job should target servers to which custom configuration objects should be distributed.
Integrations	If your BMC Server Automation environment includes BMC BladeLogic Decision Support for Server Automation, upgrade BMC BladeLogic Decision Support for Server Automation before upgrading BMC Server Automation. If your BMC Server Automation environment includes BMC Cloud Lifecycle Management, you need to ensure that you maintain compatibility with BMC Cloud Lifecycle Management.
Certificate issue	If your certificates (id.pem, bladelogic.keystore) were created with a key size of 1024 bits (or less), you will need to regenerate them with a higher key size (2048 or higher).  This is due to java 8 limitations.
Potential issues	Click here to review a list of potential issues you can encounter during an upgrade. Upgrade to version 8.6 or later does not grant the DBMS_LOCK privilege to user - Before you start upgrading from a previous version to BMC Server Automation 8.6, ensure that the BMC Server Automation user is granted the DBMS_LOCK privilege. This privilege is required for carrying out a handshake between BMC Server Automation database and the BMC BladeLogic Decision Support for Server Automation ETL during database clean up. You can use the SYS user to grant the DBMS_LOCK privilege by entering the following command: GRANT EXECUTE on DBMS_LOCK TO <User> Upgrade to version 8.6 or later disables PropertySync - As of BMC Server Automation version 8.5, the PropertySync feature has been deprecated. During migration of the database, PropertySync is disabled and the migration results table displays the migration warning: PropertySync has been changed from true to false. Please contact BMC Support for further assistance. Upgrade to version 8.5 or later deprecates the Provision provisionDevice BLCLI command. Earlier releases supported the Provision:provisionDevice command. This command has been deprecated. BMC recommends that you use the ProvisionJob:createProvisionJob command instead. Upgrade to version 8.6 or later causes Citrix XenServer Provision Jobs to fail - After an upgrade from BMC Server Automation version 8.3 or earlier to BMC Server Automation version 8.5 or later, existing Citrix XenServer Provision Jobs fail (QM001706976). Failed jobs display the error message: com.bladelogic.om.infra.mfw .util.BlException: Proxy cannot be null, Error: Proxy cannot be null. To work around the issue, open the Provision Job in the content editor. On the Server Settings panel, browse the Server Properties option to select or create a valid agentless managed object (AMO). Audit performed with snapshots captured using earlier versions of the RSCD agent can fail - When capturing data from target servers, version 8.6.00 of BMC Server Automation skips IPv6 addresses and masks. After an upgrade to version 8.6.00 oe later from version 8.3 or earlier, an audit performed with snapshots captured using older versions of an RSCD agent can fail if the targets had IPv6 enabled.

Security requirements

The unified product installer must be run by a super user, that is, a local Administrator or Administrator-equivalent local user. This enables the installer to install components on remote Application Servers using existing RSCD Agents and PsExec.

In a domain environment, this can be a domain user who is part of the local Administrators group. In such a case, ensure that you prepare the same local Administrator user on any remote Application Server that does not have an RSCD Agent installed.

If you have a high security level enabled in your BMC Server Automation installation, the unified installer cannot upgrade the product through the RSCD Agent on the remote host computers. Before upgrading, you must temporarily adjust the security level on the machines where you want to upgrade the Application Servers. At the beginning of the upgrade process, the unified installer checks the security setup and, if problems are detected, issues an error message. This message helps you decide on the actions that you must take to adjust the security settings. For more information, see troubleshooting instructions for security settings. After the upgrade, remember to re-adjust your security settings, based on your unique needs and the IT security policies at your organization.

Before initiating the upgrade, the installer discovers the existing Application Servers and checks whether an RSCD Agent is installed on each Application Server. For Application Servers that do not have an RSCD Agent installed, the installer prompts you for the credentials of the relevant host computers and installs a fully authorized RSCD Agent on each server. Note that if you suspend or abort the upgrade, you will need to manually uninstall the RSCD Agent on each of the servers. After the upgrade, remember to re-adjust your security settings, based on your unique needs and the IT security policies at your organization.

In addition, ensure that the following security requirements are met before initiating the upgrade:

• Ensure that you have authentication profiles of any of the following types set up at your BMC Server Automation installation: Secure Remote Password (SRP), LDAP, or Microsoft Windows Domain Authentication. 
  The upgrade to BMC Server Automation version 8.6 or later is not supported through Active Directory Kerberos, PKI, or RSA SecureID authentication profiles.
• You must disable the use of client-side certificates that secure access between Application Servers and agents or repeaters before you upgrade using the unified product installer. For more information, see TLS-with-client-side-certs-Discontinuing-use-of-client-side-certificates.
• Ensure that your firewall allows communication on all ports used by various components of BMC Server Automation. For more information on ports, see BMC-Server-Automation-ports.
• Ensure that the port number that is used by the SSH service running on all hosts is 22, which is the default port number for SSH.

Limitations when using the unified product installer

The unified product installer only supports upgrade of an homogeneous Multiple Application Server (MAS) environment, that is, either all Application Servers run on Linux 64-bit operating systems or all run on Windows 64-bit operating systems. The PXE servers in your environment must also run the same operating system as the Application Servers.  

If your environment includes hybrid PXE servers (that is, PXE servers not running Windows or Linux), see the upgrade workaround described in the "Workaround for hybrid PXE server environments" section of Walkthrough-Upgrading-to-version-8-7-for-Microsoft-Windows-and-Linux.

Additionally, the unified product installer does not support the following upgrade scenarios:

• 32-bit Windows or 32-bit Linux machines
• Solaris SPARC machines (see Walkthrough-Upgrading-to-version-8-7-for-Solaris for specific upgrade instructions)

_{Back to top}

Step 2: Prepare the database

During an upgrade process, core data is migrated to the upgraded BMC Server Automation database. To ensure that this migration completes successfully, you must prepare your database before performing the upgrade. To prepare your database, review the following list of prerequisite tasks and perform the tasks that are relevant for your environment.

Task	Description
Back up the BMC Server Automation database.	You must back up before beginning the data upgrade process. The data upgrade occurs in place. If, for any reason, it should become impossible to complete the upgrade, the only way to restore the database to its pre-upgrade state is from the backups.
(Oracle only) Checking for temp space (when upgrading from 8.3 or earlier only)	Note: If you are upgrading from version 8.5 or later, you do not need to perform this step. If you are upgrading from version 8.3 or earlier, you must first upgrade to the latest 8.5 or 8.6 service pack. Prior to this interim upgrade, you must ensure that your Oracle database has the free space required for successful data migration. To determine those requirements, use the sizing_8x_temp_undo.sql script provided by BMC Server Automation.  For details see Determining sizing requirements for Oracle databases in the online technical documentation for BMC Server Automation version 8.5. (This task is not required if upgrading from version 8.5 or later).
Remove unnecessary deployments	The migration process uses the database system ID information in the _template deployment to identify the database to migrate. In addition, the configurations from each existing deployment are processed, so each deployment present in the Deployments directory should have the correct configuration. Certain deployments are transitory and can be removed before an upgrade as they are not needed for normal operation. _install, _postmig, and _util can be removed from the deployments directory if present, and provided that an installation, postmigration process, or blcontent process is not being run. _launcher is for the Application Server Launcher.  This does not include database configuration information.  Both _spawner and _pxe include database configuration information.  The _template deployment is used to create new deployments, including those used during migration.
Ensure that the database configuration information on the deployments of the Application Server is up-to-date	Before upgrading the Application Server, ensure that the database configuration information on the deployments of the Application Server is up-to-date. You can use the blasadmin utility to check the database related and file server related information for each of the deployments (except _launcher). You can use the following blasadmin commands. If either of these commands returns an error, you can use the blasadmin utility to correct the configuration information and proceed with the upgrade. blasadmin -s <deloyment name> show database all (for the _pxe deployment use blasadmin -s _pxe show pxe all) blasadmin -s <deployment name> show file all If these commands return an error, use the blasadmin utility to correct the configuration so that those commands do not return an error.
(Oracle only) Grant privileges explicitly to the user account	For an Oracle database, you must grant certain privileges explicitly to the user account (typically BLADELOGIC) that will be used during the upgrade. Some of the privileges can be revoked after database migration is performed during the upgrade. For the complete list, see List-of-required-database-permissions.

_{Back to top}

Step 3: Prepare the automation environment

Perform these tasks in order. Many steps are prerequisites for other steps that occur later in the process.

1. Back up the BMC Server Automation database. The data upgrade occurs in place. If, for any reason, it should become impossible to complete the upgrade, the only way to restore the database to its pre-upgrade state is from the backups.
2. Depending on the upgrade method that you plan to use, ensure that the appropriate product components are running or stopped.
   
   • If you plan to use the unified product installer, ensure that Application Server and PXE server are up and running.
   • If you plan to run the configurator utility and then perform the upgrade using individual component installers, shut down the BMC Server Automation environment:
     
     1. Stop the Application Server. 
     2. Stop the PXE server. See Starting-and-stopping-a-PXE-server.

3. Back up the installation directories for all Application Servers and PXE servers. Note that the user who installed the earlier version of the product might have changed the installation directory from the default location, so ensure that you have the right location. If your current installation is already an upgrade from a previous version, the paths might be different, due to differences in these locations in earlier versions of BMC Server Automation. If you do not know the installation location for BMC Server Automation components view the contents of the %WINDIR%\rsc\HOME file.

   The default installation locations are:

   • Application Server: C:\Program Files\BMC Software\BladeLogic\NSH
   • PXE Server: C:\Program Files\BMC Software\BladeLogic\PXE
     If you are upgrading the PXE server, follow the upgrade instructions for Windows or UNIX, to prevent loss of configuration settings.
4. Ensure that there is an agent installed on the Application Server. Similarly, if an RSCD agent and NSH are not already installed on the PXE server, install them now.
   If you are upgrading using individual component installers, copy the configuration data on the database. See Migrating-the-database-and-persisting-configuration-data-to-the-database. (This step is performed automatically by the unified product installer.)
   The Configurator utility reads all existing configuration files and populates the database schema with configuration values present in the user environment. This configuration data is saved in the database for the proper function of BMC Server Automation.

5. Ensure that you have disabled the NSH proxy on all Application Servers in the environment to avoid failure during upgrade. To disable the NSH proxy, run the following command on the NSH client:
   secadmin -m default -p 5 -T encryption_only -e tls -appserver_protocol clear
   This command temporarily removes the appserver_protocol=ssoproxy entry from the default line in the secure file (in the rsc folder).

   Note: After the upgrade completes, remember to add this entry back into the secure file. You can use the following command:
   secadmin -m default -p 5 -appserver_protocol ssoproxy
    

    

_{Back to top}

Where to go from here

Test the upgrade in a duplicated environment and then proceed to one of the following topics, depending on your upgrade method:

Upgrading-using-the-unified-product-installer

Upgrading-using-individual-component-installers