Migrating a KVM NFS-based Deployment In Place

Overview

In this migration method, the production FortiSIEM systems are upgraded in-place, meaning that the production 3.7.x virtual appliance is stopped and used for migrating the CMDB to the 4.2.1 virtual appliance. The advantage of this approach is that no extra hardware is needed, while the disadvantage is extended downtime during the CMDB archive and upgrade process. During this downtime events are not lost but are buffered at the collector. However, incidents are not triggered while events are buffered. Prior to the CDMB upgrade process, you might want to take a snapshot of CMDB to use as a backup if needed.

The steps for this process are:

Overview

Prerequisites

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Mounting the NFS Storage on Supervisors and Workers

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

1. Log in over SSH to your running 3.7.x virtual appliance as root.
2. Change the directory to /root.
3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
4. Untar the migration script.
5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

10. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

11. Make sure the migrated files were successfully created.
12. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance

This file will be used during the CMDB restoration process.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Mounting the NFS Storage on Supervisors and Workers

Follow this process for each Supervisor and Worker in your deployment.

1. Log in to your virtual appliance as root over SSH.
2. Run the mount command to check the mount location.
3. Change to the 3.7.x mount path location in the /etc/fstab file on the Supervisor or Workers.
4. Reboot the Supervisor or Worker.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating a KVM Local Disk-based Deployment using an RSYNC Tool

Overview

This migration process is for an FortiSIEM deployment with a single virtual appliance and the CMDB data stored on a local VMware disk, and where you intend to run the 4.2.1 version on a different physical machine as the 3.7.x version. This process requires these steps:

Overview

Prerequisites

Copy the 3.7.x CMDB to a 4.2.1 Virtual Appliance Using rsync

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

1. Log in to the 4.2.1 virtual appliance as root.
2. Check the disk size in the remote system to make sure that there is enough space for the database to be copied over.
3. Copy the directory /data from the 3.7.x virtual appliance to the 4.2.1 virtual appliance using the rsync tool.
4. After copying is complete, make sure that the size of the event database is identical to the 3.7.x system.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

1. Log in over SSH to your running 3.7.x virtual appliance as root.
2. Change the directory to /root.
3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
4. Untar the migration script.
5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

10. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

11. Make sure the migrated files were successfully created.
12. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance This file will be used during the CMDB restoration process.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor

1. In the vSphere client, power off the 3.7.x Supervisor.

The IP Address for the 3.7.x Supervisor will be transferred to the  4.2.1 Supervisor.

2. Log in to the 3.7.x Supervisor as root over SSH.
3. Run the vami_config_net

Your virtual appliance will reboot when the IP address change is complete.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating a KVM Local Disc-based Deployment In Place

Overview

This migration process is for an FortiSIEM deployment with a single virtual appliance and the CMDB data stored on a local VMware disk, and where you intend to run a 4.2.x version on the same physical machine as the 3.7.x version, but as a new virtual machine. This process requires these steps:

Overview

Prerequisites

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Use More Storage for Your 4.2.1 Virtual Appliance

Install the 4.2.1 virtual appliance on the same host as the 3.7.x version with a local disk that is larger than the original 3.7.x version. You will need the extra disk space for copying operations during the migration.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

1. Log in over SSH to your running 3.7.x virtual appliance as root.
2. Change the directory to /root.
3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
4. Untar the migration script.
5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

10. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

11. Make sure the migrated files were successfully created.
12. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance This file will be used during the CMDB restoration process.

Removing the Local Disk from the 3.7.x Virtual Appliance

1. Log in to your vSphere client.
2. Select your 3.7.x virtual appliance and power it off.
3. Open the Hardware properties for your virtual appliance.
4. Select IDE Disk 2, and then click Remove.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Adding the Local Disk to the 4.2.1 Virtual Appliance

1. Log in to Virtual Machine Manager.
2. Select your 4.2.1 virtual appliance and power it off.
3. Go the Hardware settings for your virtual appliance and select IDE Disk 3.
4. Click Remove.
5. Click Add Hardware.
6. Select
7. Select the option to use managed or existing storage, and then browse to the location of the detached 3.7.x disk.
8. Click Finish.
9. Select Use an existing virtual disk, and then click Next.
10. Browse to the location of the migrated virtual disk that was created by the migration script, and then click OK.
11. Power on the virtual appliance.

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor

1. In the vSphere client, power off the 3.7.x Supervisor.

The IP Address for the 3.7.x Supervisor will be transferred to the  4.2.1 Supervisor.

2. Log in to the 3.7.x Supervisor as root over SSH.
3. Run the vami_config_net

Your virtual appliance will reboot when the IP address change is complete.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating KVM-based deployments

This section covers migrating FortiSIEM KVM based Virtual Appliances from 3.7.x to 4.2.1. Since FortiSIEM 4.2.1 has new CentOS version, the procedure is unlike a regular upgrade (say from 3.7.5 to 3.7.6) – certain special procedures have to be followed.

Very broadly, 3.7.6 CMDB have to be first migrated to a 4.2.1 CMDB on a 3.7.6 based system and then the migrated 4.2.1 CMDB has to be imported to a 4.2.1 system.

There are 4 choices based on

NFS or a single Virtual appliance based deployment

In-place or Staging or rsync based method is chosen for data migration

The various methods are explained later, but stated simply

Staging approach take more hardware but minimizes downtime and CMDB migration risk compared to the in-place approach rsync method takes longer to finish as event database has to be copied

If in-place method is to be deployed, then a snapshot method is highly recommended for recovery purposes.

 

Note: Internet access is needed for migration to succeed. A third party library needs to access the schema website.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating an AWS EC2 NFS-based Deployment via a Staging System

Overview

Overview

Prerequisites

Create the 3.7.x CMDB Archive

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Mounting the NFS Storage on Supervisors and Workers

Change the IP Addresses Associated with Your Virtual Appliances

Registering Workers to the Supervisor

Setting the 4.2.1 SVN Password to the 3.7.x Password

In this migration method, the production 3.7.x FortiSIEM systems are left untouched. A separate mirror image 3.7.x system is first created, and then upgraded to 4.2.1. The NFS storage is mounted to the upgraded 4.2.1 system, and the collectors are redirected to the upgraded 4.2.1 system. The upgraded 4.2.1 system now becomes the production system, while the old 3.7.6 system can be decommissioned. The collectors can then be upgraded one by one. The advantages of this method is minimal downtime in which incidents aren’t triggered, and no upgrade risk. If for some reason the upgrade fails, it can be aborted without any risk to your production CMDB data. The disadvantages of this method are the requirement for hardware to set up the mirror 3.7.x mirror system, and longer time to complete the upgrade because of the time needed to set up the mirror system.

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Create the 3.7.x CMDB Archive

1. Log in to your running 3.7.x production AccelOp virtual appliance as root.
2. Change the directory to /root.
3. Copy the migration script ao-db-migration-4.2.1.tar to the /root
4. Untar the migration script.
5. Make sure that the owner of ao-db-migration.sh and ao-db-migration-archiver.sh files is root.
6. Run the archive script, specifying the directory where you want the archive file to be created.
7. Check that the archived files were successfully created in the destination directory.

You should see two files, cmdb-migration-*.tar, which will be used to migrate the 3.7.x CMDB, and opt-migration-*.tar, which contains files stored outside of CMDM that will be needed to restore the upgraded CMDB to your new 4.2.1 virtual appliance.

8. Copy the cmdb-migration-*.tar file to the 3.7.x staging Supervisor, using the same directory name you used in Step 6.
9. Copy the opt-migration-*.tar file to the /root directory of the 4.2.1 Supervisor.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Mounting the NFS Storage on Supervisors and Workers

Follow this process for each Supervisor and Worker in your deployment.

1. Log in to your virtual appliance as root over SSH.
2. Run the mount command to check the mount location.
3. Change to the 3.7.x mount path location in the /etc/fstab file on the Supervisor or Workers.
4. Reboot the Supervisor or Worker.

Change the IP Addresses Associated with Your Virtual Appliances

1. Log in to the AWS EC2 dashboard.
2. Click Elastic IPS, and then select the public IP associated with your 4.2.1 virtual appliance.
3. Click Disassociate Address, and then Yes, Disassociate.
4. In Elastic IPs, select the IP address associated with your 3.7.x virtual appliance.
5. Click Disassociate Address, and then Yes, Disassociate.
6. In Elastic IPs, select the production public IP of your 3.7.x virtual appliance, and click Associate Address to associate it with your 4.2.1 virtual appliance.

The virtual appliance will reboot automatically after the IP address is changed.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating an AWS EC2 NFS-based Deployment in Place

Overview

In this migration method, the production FortiSIEM systems are upgraded in-place, meaning that the production 3.7.x virtual appliance is stopped and used for migrating the CMDB to the 4.2.1 virtual appliance. The advantage of this approach is that no extra hardware is needed, while the disadvantage is extended downtime during the CMDB archive and upgrade process. During this downtime events are not lost but are buffered at the collector. However, incidents are not triggered while events are buffered. Prior to the CDMB upgrade process, you might want to take a snapshot of CMDB to use as a backup if needed.

The steps for this process are:

Overview

Prerequisites

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Mounting the NFS Storage on Supervisors and Workers

Change the SVN URL and Server IP Address

Change the IP Addresses Associated with Your Virtual Appliances

Registering Workers to the Supervisor

Setting the 4.2.1 SVN Password to the 3.7.x Password

 

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

1. Log in over SSH to your running 3.7.x virtual appliance as root.
2. Change the directory to /root.
3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
4. Untar the migration script.
5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

10. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

11. Make sure the migrated files were successfully created.
12. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance This file will be used during the CMDB restoration process.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Mounting the NFS Storage on Supervisors and Workers

Follow this process for each Supervisor and Worker in your deployment.

1. Log in to your virtual appliance as root over SSH.
2. Run the mount command to check the mount location.
3. Change to the 3.7.x mount path location in the /etc/fstab file on the Supervisor or Workers.
4. Reboot the Supervisor or Worker.

Change the SVN URL and Server IP Address

Run these commands.

 

Change the IP Addresses Associated with Your Virtual Appliances

 

1. Log in to the AWS EC2 dashboard.
2. Click Elastic IPS, and then select the public IP associated with your 4.2.1 virtual appliance.
3. Click Disassociate Address, and then Yes, Disassociate.
4. In Elastic IPs, select the IP address associated with your 3.7.x virtual appliance.
5. Click Disassociate Address, and then Yes, Disassociate.
6. In Elastic IPs, select the production public IP of your 3.7.x virtual appliance, and click Associate Address to associate it with your 4.2.1 virtual appliance.

The virtual appliance will reboot automatically after the IP address is changed.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating AWS EC2 Deployments

This section covers migrating FortiSIEM AWS EC2 based Virtual Appliances from 3.7.x to 4.2.1. Since FortiSIEM 4.2.1 has new CentOS version, the procedure is unlike a regular upgrade (say from 3.7.5 to 3.7.6) – certain special procedures have to be followed.

Very broadly, 3.7.6 CMDB have to be first migrated to a 4.2.1 CMDB on a 3.7.6 based system and then the migrated 4.2.1 CMDB has to be imported to a 4.2.1 system.

There are 4 choices based on

NFS or a single Virtual appliance based deployment

In-place or Staging based method is chosen for data migration

The various methods are explained later, but stated simply, staging approach take more hardware but minimizes downtime and CMDB migration risk compared to the in-place approach.

If in-place method is to be deployed, then a snapshot method is highly recommended for recovery purposes.

 

Note: Internet access is needed for migration to succeed. A third party library needs to access the schema website.

Migrating an AWS EC2 Local Disk-based Deployment

Overview

This migration process is for an FortiSIEM deployment with a single virtual appliance and the CMDB data stored on a local AWS volume, and where you intend to run a 4.2.x version on the same physical machine as the 3.7.x version, but as a new virtual machine.

Overview

Prerequisites

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Change Local Volumes for Your AWS Instances

Change the IP Addresses Associated with Your Virtual Appliances

Registering Workers to the Supervisor

Setting the 4.2.1 SVN Password to the 3.7.x Password

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

1. Log in over SSH to your running 3.7.x virtual appliance as root.
2. Change the directory to /root.
3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
4. Untar the migration script.
5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

10. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

11. Make sure the migrated files were successfully created.
12. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance This file will be used during the CMDB restoration process.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Change Local Volumes for Your AWS Instances

1. Log in to AWS EC2 dashboard and power off your 4.2.1 virtual appliance.
2. In the Volumes table, find your production 3.7.x volume and tag it so you can identify it later, while also making a note of its ID.

For instance, 3.7.x_data_volume.

3. Detach the volume.
4. In the Volumes tab, find your 4.2.1 volume, and Detach
5. Power on your 4.2.1. virtual appliance.

• Stop all back-end processes and change the SVN URL and Server IP address in database by running these commands.

Change the IP Addresses Associated with Your Virtual Appliances

1. Log in to the AWS EC2 dashboard.
2. Click Elastic IPS, and then select the public IP associated with your 4.2.1 virtual appliance.
3. Click Disassociate Address, and then Yes, Disassociate.
4. In Elastic IPs, select the IP address associated with your 3.7.x virtual appliance.
5. Click Disassociate Address, and then Yes, Disassociate.
6. In Elastic IPs, select the production public IP of your 3.7.x virtual appliance, and click Associate Address to associate it with your 4.2.1 virtual appliance.

The virtual appliance will reboot automatically after the IP address is changed.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating an ESX NFS-based Deployment via a Staging System

Overview

In this migration method, the production 3.7.x FortiSIEM systems are left untouched. A separate mirror image 3.7.x system is first created, and then upgraded to 4.2.1. The NFS storage is mounted to the upgraded 4.2.1 system, and the collectors are redirected to the upgraded 4.2.1 system. The upgraded 4.2.1 system now becomes the production system, while the old 3.7.6 system can be decommissioned. The collectors can then be upgraded one by one. The advantages of this method is minimal downtime in which incidents aren’t triggered, and no upgrade risk. If for some reason the upgrade fails, it can be aborted without any risk to your production CMDB data. The disadvantages of this method are the requirement for hardware to set up the mirror 3.7.x mirror system, and longer time to complete the upgrade because of the time needed to set up the mirror system.

The steps in this process are:

Overview

Prerequisites

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Mounting the NFS Storage on Supervisors and Workers

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Create the 3.7.x CMDB Archive

1. Log in to your running 3.7.x production AccelOp virtual appliance as root.
2. Change the directory to /root.
3. Copy the migration script ao-db-migration-4.2.1.tar to the /root
4. Untar the migration script.
5. Make sure that the owner of ao-db-migration.sh and ao-db-migration-archiver.sh files is root.
6. Run the archive script, specifying the directory where you want the archive file to be created.
7. Check that the archived files were successfully created in the destination directory.

You should see two files, cmdb-migration-*.tar, which will be used to migrate the 3.7.x CMDB, and opt-migration-*.tar, which contains files stored outside of CMDM that will be needed to restore the upgraded CMDB to your new 4.2.1 virtual appliance.

8. Copy the cmdb-migration-*.tar file to the 3.7.x staging Supervisor, using the same directory name you used in Step 6.
9. Copy the opt-migration-*.tar file to the /root directory of the 4.2.1 Supervisor.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Mounting the NFS Storage on Supervisors and Workers

Follow this process for each Supervisor and Worker in your deployment.

1. Log in to your virtual appliance as root over SSH.
2. Run the mount command to check the mount location.
3. Change to the 3.7.x mount path location in the /etc/fstab file on the Supervisor or Workers.
4. Reboot the Supervisor or Worker.

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor

1. In the vSphere client, power off the 3.7.x Supervisor.

The IP Address for the 3.7.x Supervisor will be transferred to the  4.2.1 Supervisor.

2. Log in to the 3.7.x Supervisor as root over SSH.
3. Run the vami_config_net

Your virtual appliance will reboot when the IP address change is complete.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!