Revision as of 21:07, 8 August 2018

Much of this information is taken from the IBM Document Server Migration and has been modified to suit the Environment I support at work.]

How to Migrate the IBM BigFix (Endpoint Manager) Server (Windows/MS-SQL)

This BigFix document details the steps and operational procedures necessary for migrating the BigFix Server from existing hardware onto new computer systems. Typical use cases for these steps include:

• Hardware refresh
• OS or SQL Server upgrades
• 32-bit to 64-bit architecture migration
• Remote SQL server migration

The steps below apply to the following BigFix server versions for Windows:

• 7.2
• 8.0, 8.1, 8.2
• 9.0, 9.1, 9.2, 9.5

Due to the complexity and risks of migrating BigFix Servers, it is strongly recommended that an BigFix Technician help in performing the BigFix Server Migration process. Consider engaging the assistance of Services (http://ibm.biz/PPSBigFix), or IBM Accelerated Value Program (http://www-01.ibm.com/software/support/acceleratedvalue/).

Root/Application Server Migration

General Notes and Guidelines

1. The migration should first be performed and tested in a segregated test/dev environment, if possible.
2. If leveraging BigFix Disaster Server Architecture (DSA - https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Disaster%20Server%20Architecture), the replica/secondary server should be migrated before the primary BigFix Server.
3. Custom settings that have been applied to the BigFix Server will need to be implemented again after migration
   1. Typical examples include: Web Reports HTTPS configurations, Download Gather Cache Size, etc…
4. Download plug-ins and other extensions/applications will also need to be re-installed in any new installation location.
5. Typical examples include: Unmanaged Asset Importer, Wake on LAN medic, Upload service, Automation Plan Engine

Assumptions

The following assumptions are assumed to be true prior to performing the BigFix Server migrations:

1. 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 (http://www-01.ibm.com/support/docview.wss?uid=swg21505775), 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.
2. The existing BigFix server is operating normally before the migration.
3. The new BigFix server has been built, meets the requirements of an BigFix server, and is properly configured to serve as an BigFix server. In particular, the OS and database platforms should be supported for the given IEM version being migrated.
4. 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).
5. The migration is performed off-hours to minimize potential impact or down-time.

Pre-Migration Check List

1. Ensure that a strategy has been determined to allow the Clients to continue to connect to the new BigFix Server per the GatherURL specified in the masthead (corresponding to Assumption #1 above).
2. Back up the BFEnterprise and BESReporting SQL databases.
3. Back up the site level credentials such as license.crt, license.pvk, and the masthead (http://www-01.ibm.com/support/knowledgecenter/SS63NW_9.2.0/com.ibm.tivoli.tem.doc_9.2/Platform/Adm/c_licensing_tasks.html). If using <8.1 then you should also back up user/operator credentials such as publisher.pvk and publisher.crt.
4. Document the authentication method to the MSSQL database (SQL versus NT).
   • If using NT Authentication, document the NT Domain/service account used for BigFix Server services.
   • If using SQL Authentication, document the SQL account used for SQL Authentication Registry values.
5. Document (consider taking a screenshot) the ODBC connections: bes_BFEnterprise, bes_EnterpriseServer, enterprise_setup, and LocalBESReportingServer. For 64-bit Windows systems, use the 32-bit version of the ODBC tool (C:\Windows\SysWOW64\odbcad32.exe) to configure the System DSNs.
6. If migrating the Primary BigFix Server, consider implementing the following prior to the migration to reduce downtime:
   • Change the following BigFix Client settings on all clients:
     • _BESClient_Report_MinimumInterval = 3600 *This setting will reduce the amount of incoming data from the endpoints to allow the system to recover more quickly and reduce potential downtime.
     • _BESClient_RelaySelect_ResistFailureIntervalSeconds = 21600 *This value represents the amount of time BES Clients will wait after its relay appears down before performing BES Relay selection. This can prevent unnecessary automatic relay selection during the migration.
   • Change the heartbeat in the BigFix Console to 6 hours: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Console%20Preferences * This is another way to reduce the amount of incoming data from the endpoints.
7. Carefully review the migration steps.

BigFix Server Migration Processes

1. Backup and copy the current masthead, site level credentials (license.pvk), license certificate (license.crt), and if applicable, publisher credentials (versions 7.2 to 8.1) from the original BigFix Server to the new server.
   • The license.pvk, license.crt, and publisher.pvk files are critical to the security and operation of BigFix . If the private key (pvk) files or their passwords are lost, they cannot be recovered.
2. If using Message Level Encryption (MLE - http://www-01.ibm.com/support/docview.wss?uid=swg21506127), backup the “[BigFix Server folder]\Encryption Keys” folder.

   The above files must be securely backed up!

3. To facilitate migration verification, note the current actionsite version.
   • For any BigFix server version: http://www-01.ibm.com/support/docview.wss?uid=swg21506176
   • With v8.2 and above, the actionsite version can also be obtained from the Server’s Diagnostics page (http://<iemserver: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
4. Stop and consider disabling all BES Services on the original Server.
5. For versions prior to v8.2, migrate SQL Accounts for BigFix Console Operators as needed to the new DSA Server's computer/SQL Server instance. Further information on performing this operation is available at How to transfer logins and passwords between instances of SQL Server.
6. Detach the BFEnterprise and BESReporting databases from original BigFix Server's SQL Server instance.
7. Attach the BFEnterprise and BESReporting databases to the new BigFix Server's SQL Server instance.
8. Copy the contents of the following folders from the original BigFix Server onto the new BigFix Server. Create the necessary folders, or overwrite existing data as needed:
   • [BigFix Server folder]\sitearchive (pre-8.0 only)
   • [BigFix Server folder]\BESReportsData\ArchiveData
   • [BigFix Server folder]\BESReportsServer\wwwroot\ReportFiles
   • [BigFix Server folder]\ClientRegisterData (pre-9.0 only)
   • [BigFix Server folder]\Encryption Keys (if MLE is enabled – for more information, please see: http://www-01.ibm.com/support/docview.wss?uid=swg21506127)
   • [BigFix Server folder]\Mirror Server\Inbox -- NOTE: Be sure to edit and update the paths specified in the GatherState.xml if the installation path has changed, e.g. Program Files to Program Files(x86) for example, otherwise you will receive class NotASignedMessage errors. This particularly applies when migrating the OS from 32-bit to 64-bit architectures.
   • [BigFix Server folder]\Mirror Server\Config -> DownloadWhitelist.txt
   • [BigFix Server folder]\UploadManagerData
   • [BigFix Server folder]\wwwrootbes
9. ** Run this step if you are migrating a BigFix Server with version 8.2 or later. If the version of your BigFix Server is earlier than 8.2 skip this step and go to step 10. ** Starting from version 8.2 you must decrypt the configuration keys encrypted on the old server, save them to a folder on the new server, and encrypt them on the new server. Depending on the version of the IBM BigFix Server in your environment, you must migrate:
   • The EncryptedServerSigningKey and EncryptedClientCAKey keys, if the version of the IBM BigFix Server is 8.2 or later and earlier than 9.5 Patch 3.
   • The EncryptedServerSigningKey, EncryptedClientCAKey, EncryptedAPIServerKey, EncryptedPlatKey, and EncryptedWebUICAKey if the version of the IBM BigFix Server is 9.5 Patch 3 or later.

   The encrypted keys are located, by default, in the C:\Program Files (x86)\BigFix Enterprise\BES Server\ folder.

   Use the ServerKeyTool.exe and run the steps documented in this page for each key that you are required to migrate.