Difference between revisions of "My Notes on Server Migration"
(→General Notes and Guidelines) |
(→General Notes and Guidelines) |
||
Line 25: | Line 25: | ||
# 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. | # 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. | ||
# Custom settings that have been applied to the BigFix Server will need to be implemented again after migration | # Custom settings that have been applied to the BigFix Server will need to be implemented again after migration | ||
− | #* Typical examples include: Web Reports HTTPS configurations, Download Gather Cache Size, etc… | + | # * Typical examples include: Web Reports HTTPS configurations, Download Gather Cache Size, etc… |
# Download plug-ins and other extensions/applications will also need to be re-installed in any new installation location. | # Download plug-ins and other extensions/applications will also need to be re-installed in any new installation location. | ||
# Typical examples include: Unmanaged Asset Importer, Wake on LAN medic, Upload service, Automation Plan Engine | # Typical examples include: Unmanaged Asset Importer, Wake on LAN medic, Upload service, Automation Plan Engine |
Revision as of 20:52, 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.]
Contents
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
- The migration should first be performed and tested in a segregated test/dev environment, if possible.
- 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.
- Custom settings that have been applied to the BigFix Server will need to be implemented again after migration
- * Typical examples include: Web Reports HTTPS configurations, Download Gather Cache Size, etc…
- Download plug-ins and other extensions/applications will also need to be re-installed in any new installation location.
- 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:
- 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.
- 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 an BigFix server. In particular, the OS and database platforms should be supported for the given IEM 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.