Why does NPM store the IP rather than use DNS for polling? It's not a big deal but anytime we change an IP, we have to go into Orion to update the node with the new IP.
Orion uses the IP Address so it can continue to Poll even if the DNS Server goes down. You can have Orion update the IP Address based on the DNS Name by going into Manager Nodes> Edit Properties, and select the checkbox for Dynamic IP Address (DHCP or BOOTP).
Please make sure that the Node does resolve via DNS lookup on the Orion Server by going into Command Prompt and running a quick ping on the Hostname and that the IP Address is correct as well. This is to ensure that the Orion Server is pointing to the Correct DNS Server.
I believe it lets the MS OS take care of the name cache. And I think thats another reason Orion tends towards using IP (so there isn't any worry of the OS being dumb with name resolution).
Yes, but you cannot edit multiple nodes and Select "Dynamic IP" .....this is a horrible pain when you want to discover 400 nodes and have to edit each, individually.
Please, please, please fix this.
Yes, but you cannot edit multiple nodes and Select "Dynamic IP" .....this is a horrible pain when you want to discover 400 nodes and have to edit each, individually.Please, please, please fix this.
Marked for PM review.
I use this feature as well but it does not always work for us. We have a support call open with SolarWinds right now because we can't follow cluster resources that are DHCP instead of static. They are detected initially with correct info, but then the IP reverts to one of the cluster host nodes instead of the resource.
This was marked for PM Review, but I never heard anything more. Has a fix for this been implemented? Reviewed by PM? Anything? As with most of my questions, it gets marked, or promised to review and I never hear anything ever again. The follow ups seem to be severely lacking at Solarwinds.
Tx.
To resolve the majority of our issues, we were instructed to disable the reverse DNS lookup in Orion (in web console | Settings | Polling Settings | uncheck Perform reverse DNS lookup | Submit).
Most of our Windows hosts are using DHCP and the few that are still static are set to be changed this year. We too have had to change the setting directly in SQL to update them all at once. Since our Unix boxes still use static IP assignments, the exact query we run in SQL Server Mgmt Studio against the NetPerfmon database is:
update Nodes set DynamicIP =1 where Vendor = 'Windows'
I ran this on a small group of ~100 nodes using something other than 'vendor', just to ensure there were no adverse effects and all went well. I've also tested setting Windows nodes that currently have static IPs to DHCP and we've had no issues there either.
With the reverse DNS lookup disabled and the nodes set to DHCP, we've been far more successful in tracking nodes and/or clustered resources via name instead of IP. For the problematic nodes, SolarWinds support came up with an additional step to resolve, detailed below.
Our recurring problem was not following Server 2008 clusters using DHCP'd cluster resources. When our DNS records have multiple entries, Orion would update the resource IP to the same one as its host node, which is completely separate. Orion wasn't doing anything wrong - our DNS records are at fault, but we still needed a way to resolve this, especially since DNS records are not managed by our group.
One of our nightly reports checks Orion for duplicate IP addresses so we set up an alert when duplicate IP's are found. Then to resolve, we again need to go into SQL Server Mgmt Studio, and run the following queries against the NetPerfMon database:
select * FROM Nodes where IP_Address = 'x.x.x.x'
The query results then show both the host node and the virtual cluster resource with the NodeID number field. To fix within the database, we then run:
update Nodes set DNS = 'resource-name.domain.com' where NodeID = xxxx
Once this is set, that cluster resource will go back to it's proper IP during the next poll. It all seems a bit convoluted but so far we have had 100% success in properly monitoring our DHCP'd resources now. The updating nodes to DynamicIP=1 is a query we still need to run regularly just to ensure new discoveries are properly set. Luckily, it's a simple query and extremely fast.
