VxUpdate Operational Notes

Operational Notes

Administration Console

• For some pre-8.0 hosts, non-policy-based upgrades started in the GUI incorrectly generate messages that packages are missing from the repository. No packages are missing from the repository.  Veritas plans to address this limitation in an upcoming release.  Known workarounds include:
  • Remove the target host from all deployment policies to which it belongs.
  • Rename the deployment policies that include the target host so that alphabetically the deployment policies appear after at least one backup policy that includes the target host.
  • Upgrade the target host to NetBackup 8.0 or later.

• Use of the 'Upgrade Host..." option from a backup policy's Clients panel is not supported for Media server upgrades.  Veritas plans to address this limitation in an upcoming release.  Please use the equivalent operation in Host Properties when targeting media servers.

Command Line Interface

• The master server may specify multiple hosts to upgrade with the nbinstallcmd command.  A client can only upgrade itself.  A media server may be able upgrade clients.  The master server can upgrade media servers.  A media server's ability to upgrade clients depends on how the master server identifies it.  If the media server is identified with a MEDIA_SERVER entry only, it cannot request client upgrades.  If the media server is identified with a SERVER entry in the master server's bp.conf file, it is permissible to use with nbinstallcmd.
• When you upgrade media servers, the -media_server option must reflect the name of the master server.  Any other specification results in job failure.

Deployment Policy Management

• VxUpdate supports precheck, staging, and install operations with and without policies.
• Pre-NetBackup 8.0 hosts show up as unknown in the selection list when editing a deployment policy in the NetBackup administration console.
• An attempt is made to filter out invalid hosts from deployment policies' hosts lists.  Trusted master servers from other NetBackup domains may, however, appear in this list.  If these trusted master servers are included in an upgrade schedule, the upgrade job fails for those servers.  

Host Roles

• Use VxUpdate to upgrade NetBackup clients and media servers only.  Upgrades for master servers and appliances are not supported.  

Job operations

• An administrator cannot restart a failed parent job for a policy-based deployment, nor a failed ad-hoc deployment job.  To restart deployment jobs, re-initiate them manually via the NetBackup administration console or the nbinstallcmd binary.  Failed child jobs started from deployment policies are restartable.
• Deployment jobs cannot be canceled.

Logging

• VxUpdate logs to the nbinstallagent folder on target hosts. This log is unaffected by changes in log verbosity ('General '2' or 'Verbose' '5' have no affect). This folder is created automatically during VxUpdate operations if it doesn't already exist. 
• The client-side nbcert log (if the Deployment job progresses that far) may be more helpful with client log verbosities of 'General '2' and/or 'Verbose' '5' and by configuring ENABLE_NBCURL_VERBOSE=1 on the client (can configure this from the Primary server via: echo "ENABLE_NBCURL_VERBOSE=1" | bpsetconfig -h remoteclientname )

Media Servers (as proxy servers)

• VxUpdate supports using a media server as a proxy between the master server and a target client.  You must use a proxy server in cases where the master server and client cannot communicate directly.  Optionally, a proxy server can be used to reduce load on the master server.
• The proxy server specification is only configurable when targeting clients.  In the case of media server upgrades, the master server and the media server must be able to communicate directly with each other.
• When using a media server as a proxy, it must be at the same version level as the master server.

Multi-Domain Hosts

• VxUpdate operations on NetBackup 8.0 hosts that are associated with multiple NetBackup domains may require additional steps.  The CA certificate and the host-ID based certificate that are issued to the host are obtained from the first server found in the host's servers list.  The server found may not be the server that initiated the VxUpdate job.  In this case, manual actions to get a CA certificate and host-ID certificate from the other master servers is required.

OpsCenter

• When applying an EEB to a client running OpsCenter, the administrator must stop the database server (dbsrv16) for VxUpdate to successfully deploy the EEB. If the database server is not stopped, the VxUpdate job ends with a partial success and the EEB is not installed.

Prechecks

• In cases where the NetBackup client package is already staged, the VxUpdate disk space check incorrectly runs during installation schedules.  Extra disk space is required as a workaround when the package was previously staged.

Scheduling

• When a schedule window with multiple deployment job types runs, the order in which these jobs run is undefined.  Because the Install type also runs a Precheck and Staging job, and the Staging job also runs a Precheck, unnecessary jobs are created.  In some cases, these extra jobs report a failure status.  As long as the Install job is successful, the installation of the new NetBackup client is successful.  Veritas recommends that you create non-overlapping schedule windows for the three types of deployment schedules.

Security and Certificates

• Master servers using the VERY HIGH security level require token delivery out of band.  VxUpdate does not support token delivery out of band.  See article 100039650 for additional information on "How to manually obtain a host ID Certificate".
• Upgrades for NetBackup hosts running 8.0 or older and hosts in a DMZ require delivery of security tokens out of band.
• External security certificates can be configured as part of VxUpdate operations.  See 'NetBackup Deployment Management with VxUpdate' in the NetBackup Upgrade Guide for details.

Status codes

• Deployment Job Exit Status Code 200.  The exit status 200 code indicates that there is no work for the deployment job.  Possible causes include the client is already at the version you want to deploy.  The error text, "scheduler found no backups due to run" applies to deployment jobs as well.  Updates to the error message are scheduled for future releases.
• Deployment Job fails with NetBackup Status Code 7226.  Exit status 7226 indicates that one of the commands executed by nbinstallagent, run on the client, failed.  This command can be a native operating system command such as rpm or gunzip, or a NetBackup command such as nbcheck, review the client's nbinstallagent log file.

Target Hosts

• Beginning in NetBackup 8.1.2, VxUpdate fully supports upgrading clients running NetBackup 7.7 and newer.
• Beginning in NetBackup 8.2, VxUpdate fully supports upgrading media servers running NetBackup 7.7 and newer.
• Upgrades from versions of NetBackup older than 7.7 may work, but are outside of the scope of support.  Upgrade these hosts at your own risk.
• Upgrades from pre 8.1.2 UNIX and Linux hosts that predate the conversion to full native packages involve the uninstallation of legacy Symantec packages.  These Symantec packages are not restored if the upgrade fails.  Manual steps are required to restore connectivity to the client. Affected versions are:
• • NetBackup 7.7.2 and older for clients on all supported versions of Linux.
  • NetBackup 7.7.3 and older for media servers on all supported versions of Linux.
  • NetBackup 7.7.3 and older for all other supported UNIX operating systems.

Target Host Configuration Changes

• VxUpdate is currently not able to explicitly update configuration options on the target host. This includes bp.conf file entries, registry entries, touch files, license keys, etc.

Troubleshooting strategies

Review the following items following a Deployment job failure for errors:

• Detailed Status of the child Deployment job. Start from top down noting errors.
• If using nbinstallcmd, obtain any output/errors from the command-line reported by nbinstallcmd. In some cases, the command output provided valuable clues that no other log held.
• nbinstallagent log on the client
• nbcert log on the client (if available). Note the job has to progress to the point of running nbcertcmd (nbcertcmdtool) commands on the client for this log to be updated.
• nbsu from the client
• for Windows clients, obtain a msinfo32 output: type Windows key + S to open Search, type msinfo32 and hit enter. Save the output as a .nfo file. This file contains a lot of Windows information such as exact Windows version, Software Environment > Windows Error Reporting (look for process crashes).

From the collected information, besides errors, note all the hostnames while considering and comparing to expected hostnames. For example, note the:

• Deployment Policy 'Server:' hostname. Is this the Primary server name the client expects per client-side Server list?
• Deployment child job note the 'Master Server:' hostname value, 'Client:' hostname value.
• Deployment child job 'Detailed Status', note 'Media Server:' hostname value.
• Client nbinstallagent log, note the hostnames for the various roles like '-server', '-media_server', and '-mediaServList' for example.
• Primary Server (and/or Media Server if a Media Server is pushing the upgrade) SERVER list topmost line hostname and CLIENT_NAME hostname.
• Client SERVER list topmost line hostname and CLIENT_NAME hostname.