After lengthy discussion, a decision was made that we are not going to add any functionality to ISC DHCP to make it 'safe' to reconfigure pools that have already been created and established between failover partners without going through a process that involves:

a)  Deleting the pools from both partner configurations
b)  Restarting both failover partners (one at a time) to reload the leases file, thus removing any leases already granted from the two pools
c)  Reconfiguring the pools again in their new partnerships
d)  Restarting the (new) failover partners

The underlying issue is around what happens to 'sort out' the anomalies during the transition:

- which server is responsible for leases already allocated (particularly if that server becomes no longer responsible for that pool after the reconfiguration)
- how pool balancing is managed when the servers are being rebooted, when instead of deleting and re-adding the pools to 'clean up' first, they are simply edited, so you end up with a transient mis-match between DHCP servers as the partners are restarted to load the new configuration/topology.

The same constraints would also apply to alterations to the range of addresses handled by a failover pair, for example if one a pool becomes exhausted and needs to be extended.  Again it is the pool balancing during the transition where the outcome is unpredictable because the two partners have a different view of the size of the pool.

----

Instead, we will document our recommendations for safely making this type of ISc DHCP configuration change.