Migrating scopes - User Guide - BlueCat Horizon

Migrating between server types

You can migrate scopes to and from the following server types:

• From MS DHCP to either ISC or Kea
• From Cisco IOS to ISC/MDDS, Kea, or MS

There are certain limitations to migrating scopes between servers of differing types:

• DHCP policies are MS-specific and are not migrated.
• DHCP exclusions on MS DHCP servers are converted to static address spaces on ISC DHCP or Kea destination servers by splitting up the pool in which the exclusions were. As a result, a warning will be generated in the migration.
• Reservations inside pools on MS servers are not migrated unless the setting to Allow reservations inside pools on ISC DHCP servers is enabled.
• User class options are MS-specific and are not migrated.
• DDNS settings are MS-specific and are not migrated.
• When migrating scopes from an MS server to an ISC or Kea server, the MS DHCP option 51 (scope lease time) becomes the following scope configurations:
  • default-lease-time and max-lease-time on ISC.
  • valid-lifetime and max-lifetime on Kea.

Migrating from unreachable servers

There are certain limitations to migrating scopes from dead or unreachable servers:

• If the server is a MS DHCP server and a backup exists (the Perform backup of MS and ISC DHCP servers system setting is enabled), DHCP options are migrated from the backup for both scope and reservations.
• DHCP policies and their options are not migrated.
• Scope configurations on ISC and Kea servers are not migrated.
• Leases are migrated, if requested, as long as DDI orchestrator has not been restarted since it last synchronized successfully with the server.
• The source scope is always left unchanged, since it isn't possible to remove or disable a scope on a dead server.

Migrating a DHCP scope

1. In the list on the IPAM page, select the scope you want to migrate.
2. Use the Action menu or the ellipses in the row to select Migrate DHCP scope.
3. In the Migrate dialog, configure the scope migration:
   
   
   1. Source server: Select the server from which you want to migrate the scope. If you select multiple scopes, the dropdown populates only with the servers on which all the selected scopes exist.
   2. Destination server: Select the server to which you want to migrate the scope.
   3. Destination failover relationship: Select a failover relationship for the destination server.
   4. Migrate leases: Check this box if you also want to migrate the leases within the scope.
   5. Enable scope on destination server: Check the box if you want to enable the scope on the destination server immediately.
   6. After migration, source scope is: Select whether the source scope will be Unchanged, Disabled, or Deleted after the scope has been migrated.
   Note: To delete the source scope after migration, you must have permissions to delete ranges.
4. Select Verify.

   A pre-flight for the migration is then run, which returns a list of any problems, such as errors or warnings. If the pre-flight returns any errors, the migration cannot proceed. Warnings are returned for non-critical issues, which typically inform you that something cannot be migrated.

   
   
   
5. If there are no errors or warnings—or you want to proceed despite a warning—select Migrate.

A progress bar is displayed in the dialog, which shows you how much is left to migrate and indicates when the migration is complete.

Results of migrating scopes

The following options defined on the source server may have these results during a scope migration:

Reservations:

• Reservations in DHCP groups on ISC DHCP servers will be migrated to a group with a matching name or, if no matching group exists, it will not be migrated to a group. In the latter case, you will receive a warning upon verifying the migration.
• Reservations with multiple addresses that span different subnets on ISC DHCP will not be migrated.

Superscopes:

• If the scope to be migrated is part of a superscope, it will be migrated to a superscope with a matching name on the destination server. If no matching superscope is found, you will receive a warning upon verifying the migration and the scope will not be added to a superscope on the destination server.

Client classifications:

• Client class associations on a Kea server will be migrated to another Kea server as long as the matching client class (matched by name, expression, and BOOTP options) is found on the destination server. If no matching client class if found, you will receive a warning informing you that the client class association will not be migrated.

Failover relationships:

• It's possible to select a new failover relationship for a migrated scope. Once you've selected the new failover relationship, or the source scope is already in a failover relationship, you must delete the source scope. Otherwise, you will receive an error and cannot proceed with the migration.
  Important: The scope being migrated cannot already exist on the primary or secondary server in the failover relationship. If it does, and only one server in the failover relationship should change, you should use DDI orchestrator's failover management features to deconfigure the old relationship and add the scope to a new failover relationship. For more information about managing failover, refer to Managing DHCP failover.

Rolling back a scope migration

If any of the following issues arise during migration and were not caught during the pre-flight, the migration will be rolled back:

• Options or scope properties could not be set.
• Address pools or exclusions could not be added.
• Reservations could not be added.
• Leases could not be created.
• Client classifications or policies could not be configured.
• Failover could not be configured.

If any of the following occur, the migration will not be rolled back:

• The source scope was not successfully disabled or removed.
• The scope could not be enabled on the destination server.