UMC DHCP: subnet view only shows pools - hosts under subnet visible in LDAP/udm but not in tree?

Hi, I’m trying Univention Corporate Server 5.2 for the first time and I’m a bit confused by the DHCP module.

When I go to All DHCP services > [service] > [subnet], the tree only seems to show pools. +Add only lets me create a Pool — there’s no option for a Host. Hosts I create with udm under that subnet, e.g:

udm dhcp/host create \
  --superordinate "cn=192.168.199.0,cn=test.lan,cn=dhcp,$(ucr get ldap/base)" \
  --set host="test-host" \
  --set hwaddress="ethernet 00:11:22:33:44:55" \
  --set fixedaddress="192.168.199.60"

show up in udm dhcp/host list and in LDAP Directory, but not in this DHCP view.

If I create a host from the UI with Add → DHCP: Host (with the service selected, not the subnet), it works — but the object sits under the service in LDAP, not under the subnet.

The migration guide (How-to: Best Practice: Migrating Standalone Microsoft DHCP to UCS) shows creating hosts with --superordinate "cn=<subnet>,cn=<service>,cn=dhcp,..." , which suggests they should live under the subnet. That’s what made me expect to see them there in UMC - so the mismatch was especially confusing.

So CLI reservations look “missing” in the main DHCP UI, while UI-created hosts live somewhere else in the tree. Is that intentional? Happy to add steps, udm output, and screenshots if that helps.

Thanks!

It is very confusing…
it does not work the way you would expect a file directory tree to work
on the left you can have a network and under it some subnets
and if you slect the top level domain server ,on the right something that looks like the subnets on the left…
but they are not the same and have radically different functions.
also the objects on the left can set high level options that totally override the options on the right, making it even more confusing.

Be aware it is possible to crash the DHCP system, if the settings on the left & right conflict on the address spaces.
and you wont get any errors, it’s all console based for error handling.

it is possible to build fully working DHCP systems from the front end.

but it is not intuitive… especially if you worked on a “real” AD server