OpenManage Enterprise version 3.4 allows automatic discovery of servers that have iDRAC firmware version 4.00.00.00 or later. The appliance can be configured to allow these servers to automatically locate the console by querying the DNS and initiate their discovery.
The instructions (and this) give the use of the TUI or manual creation for Dell Openmanage that appears to be Bind format using nsupdate to create the records, so runes are given for how to do this on Microsoft DNS.
Now in my case we have a pretty non-standard DNS configuration i’m not sure how much of an affect this would have if you just had plain Microsoft DNS (Active Directory Enabled) running, and certainly Bind appears it would be straight forward; but I’d thought i’d post this just in case as it was a bit odd and might help someone else out!
I’ve substituted in internal.turnip.co.uk instead of the real domain name by the way.
We have an InfoBlox that is authoritative for the internal.turnip.co.uk domain (and Microsoft DNS on the domain controllers is not, this is very much non-standard from a Microsoft point of view), then certain Active Directory enabled/relevant subdomains of internal.turnip.co.uk, e.g. _msdcs.internal.turnip.co.uk, _sites.internal.turnip.co.uk and so on, are delegated down to the Microsoft DNS Name Servers running on the Domain Controllers.
So in our case because we don’t have the root of the internal.turnip.co.uk domain where Microsoft DNS is authoritative and the _tcp.internal.turnip.co.uk has been delegated to the Microsoft DNS servers running on the Active Directory domain controllers. We can’t create the PTR, TXT or SRV records for the delegated domain _tcp.internal.turnip.co.uk on the InfoBlox, this needs to be created on the Microsoft DNS server directly which is authoritative for the sub-domain and this is where the GUI appears to be lacking to allow you to enter the sub-domain as you create the record, it appears pinned to wherever you are creating it at.
The Dell documentation says you need to create these 3 records for Openmanage clients to be able to auto-discover:
_dcimprovsrv._tcp.<domain> 3600 PTR ptr.dcimprovsrv._tcp.<domain> ptr.dcimprovsrv._tcp.<domain> 3600 TXT URI=/api/DiscoveryConfigService/Actions/DiscoveryConfigService.SignalNodePresence ptr.dcimprovsrv._tcp.<domain> 3600 SRV 0 0 443 <hostname>.<domain>
In our case though this would be:
_dcimprovsrv._tcp.internal.turnip.co.uk 3600 PTR ptr.dcimprovsrv._tcp.turnip.co.uk ptr.dcimprovsrv._tcp.internal.turnip.co.uk 3600 TXT URI=/api/DiscoveryConfigService/Actions/DiscoveryConfigService.SignalNodePresence ptr.dcimprovsrv._tcp.internal.turnip.co.uk 3600 SRV 0 0 443 openmanage-01.internal.turnip.co.uk
Dell Openmanage – PTR Record
So the first record is a PTR record, we create a PTR record in DNS Manager under the _tcp.internal.turnip.co.uk zone, where the IP address is actually put in as a hostname as shown in the dialogue.
Once created it appears like this:
Dell Openmanage – TXT Record
The second record is a TXT record and is actually pretty normal, so again in DNS Manager under the _tcp.internal.turnip.co.uk zone, we right click create “Other Records” then select TXT and complete the dialogue as shown:
Now here is where it gets a little weirder, we now get a folder under the zone because the .dcimprovsrv is specified as a sub-domain by the looks of it.
Dell Openmanage – SRV Record
The final record is where things get very much more odd, basically we need to create an SRV record the issue is we need to create it at the ptr.dcimprovsrv._tcp.internal.turnip.co.uk sub-domain, now the DNS Manager GUI doesn’t let you edit the Domain field when you are creating the record (and if you are creating it at the sub-domain level which we have to in this case, because we can’t create at the root domain internal.turnip.co.uk because the Microsoft DNS is not authoritative for this part of the domain).
Therefore we need to create using the CLI, in theory you can do this in PowerShell as well, but here it is in DNSCMD.
dnscmd . /RecordAdd "_tcp.internal.turnip.co.uk" "ptr.dcimprovsrv" SRV 0 0 443 "openmanage-01.internal.turnip.co.uk"
And there it is, created alongside the TXT record.
The proof is in the DNS lookups, so here are the results for each in order, all appears to be in order, in this case we are querying the InfoBlox DNS servers, which have the relevant _tcp.internal.turnip.co.uk DNS delegation configured, i.e. what any normal client would do that was using DNS to lookup these records, as you can see they appear to be as expected.
Microsoft Windows [Version 10.0.18363.1646] (c) 2019 Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>nslookup -type=ptr _dcimprovsrv._tcp.internal.turnip.co.uk Server: intdns1.internal.turnip.co.uk Address: 22.214.171.124 Non-authoritative answer: _dcimprovsrv._tcp.internal.turnip.co.uk name = ptr.dcimprovsrv._tcp.internal.turnip.co.uk C:\WINDOWS\system32>
The TXT record.
C:\WINDOWS\system32>nslookup -type=txt ptr.dcimprovsrv._tcp.internal.turnip.co.uk Server: intdns1.internal.turnip.co.uk Address: 126.96.36.199 Non-authoritative answer: ptr.dcimprovsrv._tcp.internal.turnip.co.uk text = "URI=/api/DiscoveryConfigService/Actions/DiscoveryConfigService.SignalNodePresence" C:\WINDOWS\system32>
And finally the SRV record.
C:\WINDOWS\system32>nslookup -type=srv ptr.dcimprovsrv._tcp.internal.turnip.co.uk Server: intdns1.internal.turnip.co.uk Address: 188.8.131.52 Non-authoritative answer: ptr.dcimprovsrv._tcp.internal.turnip.co.uk SRV service location: priority = 0 weight = 0 port = 443 svr hostname = openmanage-01.internal.turnip.co.uk C:\WINDOWS\system32>