Not able to finish or cancel IP Address in IPAM using the FinishIpReservationForGroup or CancelIpReservationForGroup

[DGNetops]

So if I have two Hierarchy Groups with AutoDiscovered Scopes under one and Manual Added Scopes under another Hierarchy Group the FinishIpReservationForGroup and/or CancelIpReservationForGroup functions within the IPAM API states that the IP Reserved is not blocked or is not found. This is only an issue for the hierarchy group that is custom and not the built-in default of 'IP Networks'.

The IPAM Functions seem to ignore the hierarchyGroup on Cancel or Finish and is not actually inspecting the right group. The StartIpReservationForGroup or GetFirstAvailableIpForGroup works for either hierarchy Group as the webGUI will show it as API Blocked in either one or return the correct first available when prompted.

Now, the scopes are "duplicates" between the two Hierarchy Groups and are in reality the same scope. If I delete the auto discovered scope and use the same query then there is no issue.

At this time I have several options - I can migrate everything to using the built-in IP Networks hierarchy Group ; delete everything under the default IP Networks hierarchy Group ; or I can write a custom API query to deal with both scopes in both hierarchy Groups.

For reference, please see the below output from SWQL Studio to show the behavior.

Custom Hierarchy Group:

Default IP Networks Hierarchy Group:

[DGNetops]

For now I have created the below logic to get around this issue.

$IPAddr = IP Address that was reserved via IPAM.subnetmanagement StartIpReservationForGroup (not shown here)
$Blocked = numeric status code for API Blocked which is '16'
$IPAddrURI = output from the get-swisdata query
$IPAddrStatus = human readable status passed by user such as Available, Used, Transient, Reserved

$IPAddrURI = Get-swisdata -swisconnection $swis -Query "SELECT DISTINCT IPAddress, uri FROM IPAM.IPNode WHERE IPAddress LIKE '$IPAddr' AND Status LIKE '$Blocked'"

set-swisobject -swisconnection $swis -URI '$IPAddrURI' -Properties @{ Status = '$IPAddrStatus'}

For now this will work for my use case and I am in process of converting to an Ansible playbook for the entire workflow.