Milestone Management Migration with SafeKit

1. Scenario with Milestone Management and SQL in the same SafeKit cluster

1. Decide with the customer a service interruption to make the migration.
2. Check in the Windows registry of both management nodes that the connection to the SQL databases is really local to each node. According this Milestone KB, the registry key for SQL connection is HKEY_LOCAL_MACHINESOFTWAREVideoOSServerConnectionString.
3. Make a backup of the SQL databases on MGT+SQL1-PRIM for security. Default databases are according this Milestone KB: Surveillance, Surveillance_IDP, SurveillanceLogServerV2, Surveillance_IM.
4. Put the cluster in (MGT+SQL1-PRIM, MGT+SQL2-SECOND). Thus, the Milestone SQL databases are the same on both nodes (if they are correctly configured for replication in the SafeKit module).
5. Protect the nodes from an automatic start of the SafeKit module at boot during the migration (if nodes are rebooted for any reason during the migration).
   Remove the automatic start of the module at boot: in a command prompt under c:safekit, type "safekit boot -m AM off" where AM is the module name.
   Do it for on both nodes.
6. Put the cluster in (MGT+SQL1-ALONE, MGT+SQL2-STOP): there is no more replication from SQL1 to SQL2.
7. Suspend the monitoring of processes during the migration on MGT+SQL1. Use the "Disable/enable" menu in the SafeKit web console to do that. Suspend also checkers with the same menu.
8. Migrate MGT+SQL1 from Milestone version N to Milestone version N+1 with migration of the databases on node 1.
   Note: the migration requires that the management services are running, that’s why the migration is made in the ALONE state without SafeKit ckeckers.
9. Register the virtual IP of the SafeKit management cluster with the Server Configurator GUI.
10. At this step, MGT+SQL1 is migrated to Milestone version N+1 and MGT+SQL2 is in version N.
11. DO NOT START MGT+SQL2 as SECOND during the previous steps else it will resynchronize the migrated databases from SQL1 (that’s why we remove the automatic start at boot and make a backup for security reasons).
12. Stop the ALONE SafeKit module: the cluster is in (MGT+SQL1-STOP, MGT+SQL2-STOP).
13. Force start as prim the SafeKit module on MGT+SQL2 with the version N. Use the "Force start" menu in the SafeKit web console to do that.
14. The cluster is in (MGT+SQL1-STOP, MGT+SQL2-ALONE).
15. Suspend the monitoring of processes during the migration on MGT+SQL2. Use the "Disable/enable" menu in the SafeKit web console to do that. Suspend also checkers with the same menu.
16. Migrate MGT+SQL2 from Milestone version N to Milestone N+1 with migration of the databases on node 2.
17. Register the virtual IP of the SafeKit management cluster with the Server Configurator GUI.
18. At this step all nodes are migrated.
19. Stop the SafeKit module on MGT+SQL2.
20. The cluster is in (MGT+SQL1-STOP, MGT+SQL2-STOP).
21. Force start as prim the SafeKit module on MGT+SQL1 (if you want SQL1 to be the reference for the databases).
    The cluster is in (MGT+SQL1-ALONE, MGT+SQL2-STOP).
22. Force start as second the SafeKit module MGT+SQL2.
    The cluster is in (MGT+SQL1-PRIM, MGT+SQL2-SECOND); the SQL2 databases are resynchronized from SQL1.
23. Re-enable Automatic start at boot of the SafeKit module and resume the errd and checker monitoring.
24. The cluster is restarted and migrated.

2. Scenario with Milestone Management and SQL in two different SafeKit clusters

1. Decide with the customer a service interruption to make the migration.
2. Check in the Windows registry of both management nodes that the connection to the SQL databases is really external and connected to the virtual IP of the SafeKit SQL cluster. According this Milestone KB, the registry key for SQL connection is HKEY_LOCAL_MACHINESOFTWAREVideoOSServerConnectionString.
3. Make a backup of the SQL databases on SQL1-PRIM for security. Default databases are according this Milestone KB: Surveillance, Surveillance_IDP, SurveillanceLogServerV2, Surveillance_IM.
4. Put the cluster in (MGT1+SQL1-PRIM, MGT2+SQL2-SECOND). Thus, the Milestone SQL databases are the same on both SQL nodes (if they are correctly configured for replication in the SafeKit SQL module).
5. Protect the nodes from an automatic start of the SafeKit module at boot during the migration (if nodes are rebooted for any reason during the migration).
   Remove the automatic start of the module at boot: in a command prompt under c:safekit, type "safekit boot -m AM off" where AM is the module name.
   Do it for on both nodes.
6. Put the cluster in (MGT1+SQL1-ALONE, MGT2+SQL2-STOP): there is no more replication from SQL1 to SQL2.
7. Suspend the monitoring of processes during the migration on MGT1. Use the "Disable/enable" menu in the SafeKit web console to do that. Suspend also checkers with the same menu.
8. Migrate MGT1+SQL1 from Milestone version N to Milestone version N+1 with migration of the databases on SQL1.
   Note: the migration requires that the management services are running, that’s why the migration is made in the ALONE state without SafeKit checkers.
9. Register the virtual IP of the SafeKit management cluster (NOT the SQL virtual IP address) with the Server Configurator GUI.
10. At this step, MGT1+SQL1 are migrated to Milestone version N+1 and MGT2+SQL2 are in version N.
11. DO NOT START SQL2 as SECOND during the previous steps else it will resynchronize the migrated databases from SQL1 (that’s why we remove the automatic start at boot and make a backup for security reasons).
12. Stop SafeKit on ALONE servers: the clusters are in (MGT1+SQL1-STOP, MGT2+SQL2-STOP).
13. Force start as prim the SafeKit modules on MGT2+SQL2 with the version N. Use the "Force start" menu in the SafeKit web console to do that.
14. The cluster is in (MGT1+SQL1-STOP, MGT2+SQL2-ALONE).
15. Suspend the monitoring of processes during the migration on MGT2. Use the "Disable/enable" menu in the SafeKit web console to do that. Suspend also checkers with the same menu.
16. Migrate MGT2+SQL2 from Milestone version N to Milestone N+1 with migration of the databases on SQL2.
17. Register the virtual IP of the SafeKit management cluster (NOT the SQL virtual IP address) with the Server Configurator GUI.
18. At this step all nodes are migrated.
19. Stop the SafeKit modules on MGT2+SQL2.
20. The clusters are in (MGT1+SQL1-STOP, MGT2+SQL2-STOP).
21. Force start as prim the SafeKit modules on MGT1+SQL1 (if you want SQL1 to be the reference for the databases).
    The clusters are in (MGT1+SQL1-ALONE, MGT2+SQL2-STOP).
22. Force start as second the SafeKit modules on MGT2+SQL2.
    The clusters are in (MGT1+SQL1-PRIM, MGT2+SQL2-SECOND); the SQL2 databases are resynchronized from SQL1.
23. Re-enable Automatic start at boot of the SafeKit modules and resume the errd and checker monitoring.
24. The clusters are restarted and migrated.

3. Scenario with Milestone Management in a SafeKit cluster and an external SQL not in a SafeKit cluster

1. Decide with the customer a service interruption to make the migration.
2. Check in the Windows registry of both management nodes that the connection to the SQL databases is really external and the same for each node. According this Milestone KB, the registry key for SQL connection is HKEY_LOCAL_MACHINESOFTWAREVideoOSServerConnectionString.
3. Make a backup of databases on the external SQL for security and also for step 11. Default databases are according this Milestone KB: Surveillance, Surveillance_IDP, SurveillanceLogServerV2, Surveillance_IM.
   This step is mandatory for step 12.
4. Put the cluster in (MGT1-PRIM, MGT2-SECOND).
5. Protect the SafeKit nodes from an automatic start of the SafeKit module at boot during the migration (if nodes are rebooted for any reason during the migration).
   Remove the automatic start of the module at boot: in a command prompt under c:safekit, type "safekit boot -m AM off" where AM is the module name.
   Do it for on both nodes.
6. Put the cluster in (MGT1-ALONE, MGT2-STOP).
7. Suspend the monitoring of processes during the migration on MGT1. Use the "Disable/enable" menu in the SafeKit web console to do that. Suspend also checkers with the same menu.
8. Migrate MGT1 from Milestone version N to Milestone version N+1 with migration of the databases on the external SQL.
   Note: the migration requires that the management services are running, that’s why the migration is made in the ALONE state without SafeKit checkers.
9. Register the virtual IP of the SafeKit management cluster (NOT the SQL IP address) with the Server Configurator GUI.
10. At this step, MGT1+SQL are migrated to Milestone version N+1 and MGT2 is in version N.
11. Stop the ALONE SafeKit module: the cluster is in (MGT1-STOP, MGT2-STOP) with the external database migrated to version N+1.
12. To succeed the MGT2 migration, restore the backup of the database taken at step 3 (as a precaution before restoring, you can take a backup of the newly migrated SQL to version N+1). The cluster is in (MGT1-STOP, MGT2-STOP) with the external database restore to version N.
13. Force start as prim the MGT2 SafeKit module with the version N. Use the "Force start" menu in the SafeKit web console to do that.
14. On MGT2, if the management services do not restart after the databases restore, you may have to reset the Milestone IDP on MGT2 (reset it with the cmd iisreset /restart and register the virtual IP of the SafeKit management cluster (NOT the SQL IP address) with the Server Configurator GUI). Check with Milestone support.
15. The cluster is in (MGT1-STOP, MGT2-ALONE).
16. Suspend the monitoring of processes during the migration on MGT2. Use the "Disable/enable" menu in the SafeKit web console to do that. Suspend also checkers with the same menu.
17. Migrate MGT2 from Milestone version N to Milestone N+1 with migration of the databases on the external SQL.
18. Register the virtual IP of the SafeKit management cluster (NOT the SQL IP address) with the Server Configurator GUI.
19. At this step all nodes are migrated.
20. Stop the SafeKit module on MGT2.
21. The cluster is in (MGT1-STOP, MGT2-STOP).
22. Force start as prim the SafeKit module on MGT1.
    The cluster is in (MGT1-ALONE, MGT2-STOP).
23. Force start as second the SafeKit module on MGT2.
    The cluster is in (MGT1-PRIM, MGT2-SECOND).
24. Re-enable Automatic start at boot of the SafeKit module and resume the errd and checker monitoring.
25. The cluster is restarted and migrated.