Starting from version 8.9.03, BMC Network Automation is renamed to TrueSight Network Automation. This space contains information about TrueSight Network Automation 8.9.03 and the later service packs for 8.9. For earlier releases, see BMC Network Automation 8.9.

Configuring after upgrade

This topic describes the tasks that you need to perform after the TrueSight Network Automation upgrade is complete.

Clearing the browser cache

Since there have been changes to the software, you must clear the browser cache to ensure that stale downloaded code does not interfere with the presentation of web pages. Refer to the browser's documentation for instructions on clearing the cache. If you neglect to do so, web pages might appear mangled or might behave incorrectly.

Updating ciphers in the TLS protocol

If you have modified the bna.connector.ciphers property before upgrade, follow these steps to update the list of ciphers in the TLS protocol to make the application server more secure:

  1. Stop the enatomcat service.
  2. Open the BCAN_HOME/tomcat/conf/ file with a text editor.
  3. Find the bna.connector.ciphers property in the file.
  4. Copy the latest value of this property from the Comments section of the property.
  5. Replace the existing value with the copied value.
  6. Start the enatomcat service.

Switching the authentication mechanism (SQL Server only)

Starting with version 8.9.04 for enhanced security, TrueSight Network Automation supports Windows authentication in addition to the default SQL Server authentication for the SQL Server database user. If you were using SQL Server authentication in your existing installation, and you want to switch to Windows authentication for enhanced security, you need to update the BCA-Networks Web Server service and various configuration files, as described in Switching from SQL Server authentication to Windows authentication. If you want to switch to SQL Server authentication later, see Switching from Windows authentication to SQL Server authentication.

Upgrading Cisco Wireless LAN Controller

Version 8.9.x uses the run-config command command to back up the configuration of Cisco Wireless LAN Controller devices (earlier named as Cisco 4400/2100 Wireless LAN Controller). Versions earlier than 8.6 use the running-config command.

If you use this device type, after you upgrade to version 8.9.x from versions earlier than 8.6, you must make a snapshot and mark the snapshot as trusted.

You also must check any related compliance rules and configuration profiled (CAP) dynamic fields to make sure the syntax matches that found in the new running configuration.

Updating the traceroute details for the Find Endpoint span action (Windows)

If you have modified the tracerouteLastLine property in the file before upgrade, follow these steps to update its value so that the Find endpoint job can locate the managing switch properly (see the related corrected issueDRCAN-22699):

  1. Open the BCAN_DATA/ file with a text editor.
  2. Search for the word trace.
    The following code snippet is an excerpt of the file:

    # Following are the values for Windows
    #tracerouteCmd=tracert -d
  3. Comment tracerouteLastLine by adding '#' and set its value to 3.

  4. Save the file.
  5. Restart the TrueSight Network Automation web service.

Reusing guest devices

In versions 8.5.00 and later, the <guestDeviceNamePrefix> and <guestDeviceNameBase> tags are clubbed into a single tag, <guestDeviceName> in the container blueprint. <guestDeviceName> refers to the name of an existing guest device in the system when the <useExistingGuestDeviceFlag> flag is set to trueWhen you upgrade to version 8.9.x from versions earlier than 8.5.00, and if you did not specify a value for <guestDeviceNamePrefix> in the earlier version, TrueSight Network Automation uses a default prefix value of "${}-".

To reuse guest devices, perform the following tasks as applicable:

  • Initialize <useExistingGuestDeviceFlag> to true for F5 VLBs, and also set the value of <guestDeviceName> to refer to the name of the host node's device in the relevant container instances and container blueprints.
  • Initialize <useExistingGuestDeviceFlag> to true for guest nodes where you declare a guest device in the underlying pod host node. For example, for the Fortigate containers which share VDOMs, or VMDC 2.3 copper containers, set the <guestDeviceNameBase> tags to refer symbolically to the name of the guest device in the pod in the relevant container instances and where possible in the container blueprints as well.
    You can make these changes in the blueprints if there are container instances already  provisioned which refer back to them.
  • Initialize <useExistingGuestDeviceFlag> to false for other blueprints, which might cause subsequent uses of the blueprint to provision a container to fail, if it was expecting to reuse a guest device from the pod. In such a case, the administrator must manually change this flag in the blueprint.

Regenerating and importing an SSL certificate

When you upgrade to version 8.9.x, the .keystore file located in the BCAN_DATA directory is regenerated and the key size is upgraded to 4096-bits if any one of the following conditions is satisfied:

  • The existing .keystore file was generated with a key size less than 2048-bits
  • The existing .keystore file was generated with the SHA1WithRSA encryption algorithm

If the .keystore file is regenerated, your existing certificate will not work and you need to generate and import the certificate as described in Generating and importing an SSL certificate for the application server.

Generating initial device attributes configurations

When you upgrade to version 8.9.x, BMC recommends that you perform a Refresh Device Status action to refresh only the Device Attributes Configuration on all your devices. This generates an initial version of the configurations containing your current device settings. Thereafter, the system generates a new configuration as the device settings change. The initial configurations ensure that if you begin to develop and use compliance rules against this trail, the data actually exists to make the rules useful.

Preserving the device adapter customizations

If you made any modifications to configuration trails, custom actions, device types, or external script actions located on the Admin > Network Admin > Device Adapters page, or if there are changes between your existing adapters and upgraded adapters, the adapters show up as Modified in the TrueSight Network Automation GUI.

During an upgrade, the latest versions of all the supported device adapters are loaded into your TrueSight Network Automation system. These might include enhancements and corrections to adapters that you might have previously customized. Your customized version will be active after an upgrade, which will be missing those enhancements and corrections. You must manually merge the two sets of changes.

BMC recommends that you perform the following steps before you start using the system with scheduled job actions:

  1. Navigate to Admin > Network Admin > Device Adapters.
  2. In the State column, filter the adapters in the Modified state.
  3. Expand the hierarchy and find any adapters that contain a Requires Merge  flag in the State column, as shown in the following figure:

  4. If an adapter has the Requires Merge flag, perform the following actions:
    1. Export the Baseline version of the adapter.
    2. Export the Previous Baseline version of the adapter.
    3. Export the Modified version of the adapter.
    4. Merge your customized changes into the new baseline by performing the following substeps:
      1. Compare your Modified version with the Previous Baseline version to see your changes.
      2. Re-do those changes to the new Baseline version. Now you have the latest Baseline version with your customizations.
    5. Import the updated adapter.

The following video (4:32) demonstrates how to reconcile device adapters after upgrading TrueSight Network Automation.

Back to top

Enabling the Alternate Addresses dynamic field

The find endpoint algorithm uses the traceroute command to find the IP address of the managing router for the endpoint. If the router has multiple IP addresses defined within it, and the IP address output of the traceroute command does not match the IP address stored in the TrueSight Network Automation server database for the device, the algorithm fails.

To avoid this problem, TrueSight Network Automation has a Configuration Profiled dynamic field, Alternate Addresses. This field captures additional IP addresses from the configuration of Cisco IOS-based routers.

The alternate addresses are checked during endpoint actions, in addition to the primary address of the device, when searching the database for the router.

The Alternate Addresses dynamic field is created automatically during the installation of the TrueSight Network Automation application server. However, the field is not created when performing an upgrade on the application server. After the application server upgrade is complete, you need to add this field if it does not exist, and manually enable it.

To add and enable the Alternate Addresses dynamic field

  1. In the TrueSight Network Automation GUI, open the Add Dynamic Field dialog box: Admin > System Admin > Dynamic Fields > Add.
  2. On the Details tab, enter or select the following values:

    • Component: Select Device.
    • Assignment Mechanism: Select Configuration Profiled.
    • Value Type: Select Capture Attribute Values.
    • Name: Enter Alternate Addresses.
    • Enable: (Optional) Select this option to enable the feature.
  3. On the Spans tab, select Entire Network.
  4. On the Queries tab, enter or select the following values:

    • Device Type: Select Cisco, and then select Cisco IOS Switch/Router.
    • Minimum OS Version: Use the default *. *. *
    • Maximum OS Version: Use the default *. *. *
    • Applicable Trails: Select Running.
    • Subject: Select Pattern.
    • Pattern: Enter the following string:
      ^\s+ip\s+address\s+(\d+\.\d+\.\d+\.\d+)\s+\d+\.\d+\.\d+\.\d+$ s
    • Domain: Select Selected Blocks.
    • Begin: Select Pattern, and then enter the following string:
    • End: Select Pattern, and then enter the following string:
  5. Click Enter, and then click Save.

Back to top

Deleting duplicate auto-groups

In version 8.7.00, the Cisco Nexus Switch device adapter has been renamed to Cisco Nexus. After you upgrade to version 8.9.02 or earlier from versions 8.7.00 or earlier, duplicate auto groups are created, one with the old device type name and other with the new name. You need to delete the groups with the old names manually.

When you upgrade to version 8.9.03 or later, no duplicate auto groups are created. In addition, auto groups which have been referenced in other components are renamed with the following suffix, DELETE ME.

To find and delete these dupliate auto groups:

  1. Go to Network -> Groups.
  2. Click Filter.
  3. Select the Show Empty Auto Groups option.
  4. In Name, enter *Cisco Nexus Switch* (for versions 8.9.02 and earlier) or *Nexus* (for versions 8.9.03 and later).
  5. Click Submit.
  6. Locate and delete the empty auto groups containing Cisco Nexus Switch (for versions 8.9.02 and earlier) or DELETE ME(for versions 8.9.03 and later) in their names, as follows:
    • If you do not get any error while deleting an auto group, delete it.
    • If you get an error that this group is being referenced, switch to the components that refer to this group, and modify the components to use new groups. Then, delete the auto-group.
  7. Run the Refresh Device Status action for the compliance violation status and configuration attribute profiles on the correctly-named auto groups.

Updating device import task formats

Starting with version 8.9.04, the device import task no longer supports the following mapping formats for the BMC Discovery versions that are End of Life (EOL): 

  • BMC Atrium Discovery and Dependency Mapping 8.2+
  • BMC Atrium Discovery and Dependency Mapping 7.5
  • BMC Foundation Discovery 1.5

After upgrade to version 8.9.04, any device import tasks referring to above formats are automatically upgraded to use the BMC Discovery 11.0+ (XML API) format. If you do not want the automatic upgrade, edit your device import tasks to use any other format other than the above mentioned formats before you start upgrading. If you have not edited these tasks, validate whether these tasks are working as expected after upgrade.

Configuring enhanced security

After upgrading to version, if your environment requires more restricted security as would be the case for federal customers, and the file contains certain set of cipher suites (described in step 3), perform the following steps:

  1. Open the BCAN_HOME/tomcat/conf/ file in a text editor.
  2. Find the bna.connector.ciphers property in the file.
  3. If the property value contains the following cipher suites, delete them:

Was this page helpful? Yes No Submitting... Thank you