Additional considerations and caveats when upgrading

This topic lists some general guidelines to be followed as best practices when upgrading to BMC ProactiveNet 9.6.

• Do not try to upgrade all agents in mass. Work in blocks or groups of agents.
• If you choose to upgrade rather than migrate, keep in mind that there will be differences in behavior in the UI as the upgrades are carried out. Train users on these differences.
• Do not try to use Bii4Px with 9.5 PATROL Agents for extended periods of time.
• Do not use Bii4Px with Notification Servers. Instead, implement the 9.5 PATROL Agent on the Notification Servers and leverage the new architecture until you are able to upgrade the entire environment. This assumes that you are already using Notification Servers.
• As you upgrade to 9.5 PATROL Agents, you must fully leverage the new architecture and its capabilities. Plan for this and have the BMC ProactiveNet 9.6 infrastructure in place as part of the upgrade or migration so that you are not forcing the 9.5 PATROL Agents to function in the older architecture. The only exception to this is if you are doing an agent first upgrade which you must try to avoid.
• If the scheduled down time is configured for auto-synchronized devices that are monitored by agents prior to 9.5, or for groups having auto-synchronized instances, data is not recorded during the down time period for the associated auto-synchronized instances. If the scheduled down time is in the future and the upgrade is completed before the scheduled down time period starts (including upgrading the PATROL Agents to 9.5), then instances monitored by the related PATROL Agents are converted to streamed instances and the scheduled down time will not be applicable to the related devices anymore.
• You must manually create corresponding blackouts for scheduled down time settings that were previously created manually in the older system.
• If BMC ProactiveNet is integrated with BMC Remedy IT Service Management Change Management, the Change Management settings need to be deleted and recreated in IT Service Management so that the corresponding blackouts are created automatically in BMC ProactiveNet 9.6.
• You can continue to leverage BMC ProactiveNet Integration Services 9.0 and adapters if the existing behavior needs to be retained. However, BMC recommends this only in scenarios where it is required such as:
  • Where polling of the PATROL Agents provided by the p3Adapters is required and cannot be changed
  • Where PATROL Knowledge Modules are not supported in 9.6 Integration Service nodes.
  • For example, AS/400 monitoring, OpenVMS monitoring, monitoring of older operating system versions that require older PATROL Agents such as Microsoft Window 2000.
• A 9.6 Integration Service can be used with non-PATROL data adapters and native collectors. Adapters used to collect non-PATROL data are included in BMC ProactiveNet 9.6 and supported with 9.6 Integration Services. These include BMC Portal, TM ART, and so on.
• Be sure to review port numbers in the BMC ProactiveNet 9.6 documentation. Some ports are no longer used or are used differently due to architecture changes.
• A BMC ProactiveNet Server upgrade fails to install if extra event management components have been installed on the existing BMC ProactiveNet Server. No extra event management cells, adapters or any other non BMC ProactiveNet Server components must be installed on a BMC ProactiveNet Server other than a PATROL Agent for local/external monitoring.
• The BMC ProactiveNet Server upgrade process writes a lot of data and creates directories in the existing BMC ProactiveNet Server installation directory. Make sure you allocate extra disk space for the upgrade. Allocate at least the amount required for a new installation.
• On Linux and UNIX systems, if the existing BMC ProactiveNet Server installation directory is a mount point, you may have problems associated with the upgrade process when attempting to rename directories. Allocate a directory for the existing environment that is not a mount point.
• Ensure that all host names and host aliases are resolved in DNS before attempting an upgrade or a migration. In some environments where the existing event management cell HA configuration leverages virtual host names instead of physical host names, the installer does not recognize the virtual or alias host names.
• You cannot upgrade the BMC ProactiveNet 9.6 beta version (pre-GA releases) to the BMC ProactiveNet 9.6 GA version. You must install a new server and Integration Service nodes, or upgrade an older release that is supported with upgrades.
• Do not attempt to connect PATROL Agents prior to 9.5 to an 9.6 Integration Service.
• If possible, avoid using Bii4P3 or Bii4P7 with 9.5 PATROL Agents. (However they will work and have been tested.)  Use the new architecture capabilities in BMC ProactiveNet 9.6. The only exception to this recommendation is if you are upgrading the PATROL Agents first, before implementing the 9.6 BMC ProactiveNet Server(s) and 9.6 Integration Service host(s). Even in that scenario, it is better to forward events directly to an event management cell and avoid using Bii4P3 or Bii4P7 if possible.
• You must move to the 9.6 architecture and processes as completely as possible and avoid a mix-match of old/new technology. Avoid configuring the new technology to support the old technology; otherwise you will not move away from the old and realize the benefits of the new. There may be some overlap during the upgrade and migration processes, but this must be reduced as much as possible. Note the following.
• A PATROL Agent prior to version 9.5 cannot send events directly to the 9.6 Integration Service process.
• A 9.0+ PATROL Agent can send events to a 9.6 event management cell.
• A PATROL Agent prior to version 9.0 cannot send events directly to an event management cell. If you have 9.0 agents, you must already be sending events to a cell until you upgrade the agents to 9.5.
• If you have PATROL Agents prior to version 9.0 and you are not using a PATROL Notification Server, continue leveraging Bii4Px and the first tier cell that the events flow into, until you upgrade the agents to 9.5.
• If you have PATROL Agents prior to version 9.0 and you are using a PATROL Notification Server, upgrade the agent on the Notification Server to 9.5, until you upgrade the monitoring agents to 9.5.
• As you upgrade all the PATROL Agents to 9.5, you must configure them to send events directly to the 9.6 Integration Service process.
• Decommission all instances of Bii4P3, Bii4P7, and the Notification Servers after all the PATROL Agents are upgraded to 9.5.
• You cannot upgrade a BMC ProactiveNet Server with a Sybase database to a BMC ProactiveNet Server with an Oracle database or the other way round. There is also no way to migrate a BMC ProactiveNet Sybase database to an Oracle instance or the other way around.
• If you are using the 9.0 Integration Service nodes for older agents long term, install the Monitor the Monitor KM for self-monitoring of these services.
• Upgrading an HA-configured BMC ProactiveNet Server environment requires a two-part upgrade: one on the primary node and the other on the secondary node.
• There are no known issues when upgrading the BMC ProactiveNet Server with the Atrium SSO integration already in place.
• There are no known issues when upgrading the BMC ProactiveNet Server with the BMC Service Automation (BladeLogic) integration already in place.