How-to: Best Practice: Migrating Standalone Microsoft DHCP to UCS

Knowledge Base Community
, , , ,
1

How-to:

This article outlines the recommended strategy for migrating a standalone, non-Active Directory Microsoft DHCP server to the native ISC DHCP service on Univention Corporate Server (UCS).

Conceptual Overview: The Active Leases Myth

A common concern during DHCP migrations is how to transfer active, running dynamic leases from Microsoft DHCP to ISC DHCPD. In the vast majority of environments, migrating active dynamic leases is completely unnecessary.

DHCP clients automatically attempt to renew their leases at regular intervals (typically at 50% of the lease duration). If the old server is offline, the client will fallback, broadcast, and request a lease from the new UCS server. The critical asset to migrate is not the transient dynamic leases, but rather the static reservations (MAC-to-IP mappings) and specific DHCP options.

Architecture & Configuration in UCS

Unlike standalone Linux deployments where you manually edit /etc/dhcp/dhcpd.conf, UCS manages DHCP through its centralized OpenLDAP directory via the Univention Directory Manager (UDM).

Hint

Do not manually edit /etc/dhcp/dhcpd.conf. UCS automatically generates this file from the LDAP directory. Any manual modifications will be overwritten by the Univention Configuration Registry (UCR).

Managing Static Reservations via CLI

To create static IP reservations programmatically or via shell script during the migration, use the udm command line tool instead of direct configuration file edits:

udm dhcp/host create \
  --superordinate "cn=your-subnet,cn=your-service,cn=dhcp,$(ucr get ldap/base)" \
  --set host="clientname" \
  --set hwaddress="ethernet 00:11:22:33:44:55" \
  --set fixedaddress="192.168.1.50"

Cutover Strategy (Recommended for < 500 Clients)

For environments with fewer than 500 clients, a clean cutover method using a shortened lease window is the safest and most efficient path.

Step 1: Preparation (Several Days Before)

  1. Reduce MS DHCP Lease Time: Log into your Microsoft DHCP server and lower the lease duration of your scopes to 1 hour.
  • Why? This ensures that by the time your maintenance window starts, all clients are checking in every 30 minutes, allowing them to adapt to the new server almost immediately after the switch.
  1. Export Reservations: Document or export all existing MAC-to-IP reservations and scope options from the Microsoft server.
  2. Pre-configure UCS: Replicate the scopes, ranges, options, and static reservations inside the UCS UMC or via the udm CLI. Keep the UCS DHCP service stopped or firewalled so it does not respond prematurely.

Step 2: The Maintenance Window (Cutover)

  1. Stop Microsoft DHCP: Stop and disable the Microsoft DHCP Server service to ensure it no longer responds to discover/request frames.
  2. Update Network Infrastructure: If your DHCP server resides on a different subnet than your clients, update the DHCP Relay / IP Helper addresses on your managed switches and routers to point to the new UCS server IP.
  3. Start UCS DHCP: Start the ISC DHCP service on UCS. Clients will begin requesting new leases automatically as their 1-hour Microsoft leases expire.

Essential Migration Checklist

Ensure the following configuration points are addressed on the UCS side before flipping the switch:

  • DHCP Options: Verify that all custom vendor options are fully replicated in UDM:

  • Option 66 / 67: For PXE/TFTP Network Booting.

  • Option 43: For specialized vendor provisioning (e.g., Access Points, VoIP phones).

  • Standard Options: Domain Suffixes, NTP servers, DNS servers, and WPAD.

  • IP Range Verification: Double-check your dynamic pools to exclude ranges reserved for static infrastructure like printers, servers, and network equipment.

  • Dynamic DNS Updates: If UCS should automatically register DHCP clients in the UCS DNS, configure the appropriate Dynamic DNS properties under the dhcp/dns settings in UDM.

  • Failover & Redundancy: If high availability is required, ISC DHCP supports native failover protocol. Consider setting up two UCS systems acting as a DHCP failover peer relationship right from the start.

Pre-Cutover Validation & Testing

To minimize production impact, perform a pilot test prior to the actual maintenance window:

  1. Create an isolated test VLAN.
  2. Connect a handful of representative target devices (e.g., a standard Windows client, a VoIP phone, a network printer).
  3. Activate the UCS DHCP server inside this isolated VLAN.
  4. Verify that the devices successfully pull IP addresses and—crucially—that complex settings like VoIP provisioning or PXE boot paths function seamlessly. This reliably uncovers missing DHCP options before they impact production.

Post-Migration Monitoring

Once the cutover is complete, monitor the UCS DHCP logs closely for 24 to 48 hours. You can stream the live log outputs using the following commands:

journalctl -f -u isc-dhcp-server
# OR alternatively
tail -f /var/log/syslog | grep dhcpd

What to look for:
Look out for legacy or misconfigured devices (such as old IoT nodes, legacy printers, or industrial equipment) that might have hardcoded static leases or are attempting to renew unexpected requests. Monitoring the logs will immediately flag these outliers for manual remediation.