Migrating the BigFix Server (Linux)

This section provides basic information on migrating your BigFix Server from existing Linux hardware onto new systems.

The procedures referenced below are meant for the server components only. You must backup and restore additional applications and/or server customization in your setup, if any, separately.
Note: Due to the complexity and risks of migrating BigFix Servers, it is strongly recommended that you take assistance from a trained BigFix Technician while migrating the BigFix Server.

Before you begin

The following scenarios are assumed to be true prior to performing the BigFix Server migrations:
  • If migrating the Primary/Master BigFix server, the new BigFix server will have to leverage the same DNS name/alias or IP address that is specified in the masthead/license (https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0023184), otherwise the BigFix infrastructure will not be able to communicate with the new BigFix server. If this is not possible, a new license may need to be obtained, and an infrastructure migration be performed rather than a server migration. This is a crucial element of the migration strategy, and requires proper planning!
    • If the masthead leverages an IP address, the new Server will have to leverage the same IP address.
    • If the masthead leverages a host name, the new Server may have to leverage the same host name.
    • If the masthead leverages a DNS name/alias (per best practice), the alias will have to be re-pointed to the new BigFix server as part of the migration process as described in step 18 below.
  • The existing BigFix server is operating normally before the migration.
  • The new BigFix server has been built, meets the requirements of an BigFix server, and is properly configured to serve as a BigFix server. In particular, the OS and database platforms should be supported for the given BigFix version being migrated.
  • The installation folders are in the same location and path for the original BigFix /DSA servers and the new BigFix /DSA servers (if not, some manual modification of files will be necessary, which is outlined in the steps below).
  • The migration is performed off-hours to minimize potential impact or down-time.

Procedure

  1. To facilitate migration verification, note the current actionsite version.
    • For any BigFix server version: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0023338.
    • With v8.2 and above, the actionsite version can also be obtained from the Server’s Diagnostics page (http://<BigFixServer:port>/rd), select the ‘Get Current Version’ request type under Site Gathering Information, select the actionsite URL from the dropdown, click Submit, and note the actionsite version.
  2. Stop and consider disabling all BES Services on the original Server.
  3. Run the Server Backup procedure as described in Server Backup.
  4. Run the Server Recovery procedure as described in Server Recovery.
  5. Run the Verify restore results procedure as described in Verifying restore results.
  6. Verify that the actionsite version being hosted by the new BigFix Server matches the one noted in Step 1 using the same steps outlined in Step 1.
  7. Check the relay selection settings on all top-level Relays. If any setting points to the original BigFix Server using an IP Address or hostname, they may need to be re-pointed to the new BigFix server.
  8. Uninstall the BigFix Server software from the old BigFix Server computer. Do NOT restart the BES Services on this computer. Attempting to use the old BigFix Server may cause errors on the new BigFix Server if it is used again.
  9. Run ./BESAdmin.sh -resetDatabaseEpoch to force the consoles to refresh their cache with the new server.
  10. Reset the Client settings and heartbeat to settings prior to shutting down the BigFix Server services.