Discovering systems as IP's instead of hostnames

[NMCI Group]

I have always discovered systems using the short hostname and it has been working fine. The "network name" shows up as the FQDN and the "preferred system name" shows up as the short hostname.

Normally I would discover 1 system at a time using a new task in SIM 5.3 to discover a single system. A couple of days ago I decided to see if I could discover more than 1 at a time. So I created a new task to discover multiple systems and just listed 3 different short hostnames in the list. After I ran that discovery they all showed up in the All Servers list as IP addresses instead of hostnames. The "network name" and "preferred name" both show up as the IP.

I removed that task and create a discover single system task again and tried to discover another system and now that one also shows up as the IP address.

I have not made any other changes and I have verified that both forward and reverse DNS works from both the CMS and the client machines.

Does anyone have any idea how to fix this? I know I can simply change the "preferred name" but I would rather it work right and I don't know of any way to change the "network name".

Thanks
Aaron

[Rob Buxton]

I just use the IP Range in the Discover section to add new servers. I just add the IP Address range in there.

DNS is used to give names instead of IP Address. But you say you've checked that. Does the FQDN returned by the IP Address lookup match the FQDN you then re-use in the lookup - they do need to match.

The other thing to check is that there aren't multiple names for an address, try running nslookup a couple of times.

[NMCI Group]

Everything appears to match and there don't appear to be multiple entries. This is very strange.

And I do have SIM set to use the FQDN just in case you were going to ask.

[Mike EvansCengageLearni]

We are experiencing the same issue in both our production and test ICE environments. Production is an upgrade and Test is a fresh install. I can properly resolve the NetBIOS and FQDN of the systems I am trying to add.

[Doug Hafley]

I had this issue. For me to fix it, I had to make sure in DNS that I not only had the FQDN associated to the correct IP address, but I also had to have the reverse DNS set up right. It is important that your reverse look up zones are correct and you don't have any duplicates. It took a while for me to clean out all of DNS to get my servers and ILO connections to show up via name instead of DNS. Many instances, I had to create a reverse Lookup Zone subnet and then manually add in the server. Verify that on your DC and let us know.

d

[Mike EvansCengageLearni]

DNS is not the problem here. I am trying to add systems that were properly discovered in SIM 5.2. Both forward and reverse DNS entries are correct for the systems I am trying to discover

[NMCI Group]

My problem is fixed but I'm not exactly sure why.

Apparently SIM is using similar functionality to "ping -a IPADDRESS". When I would run a ping -a on the IP it would fail to resolve it to a name on the systems that were not working even though DNS looked fine, both forward and reverse. Another way to test is "mxgethostname -i -n $HOSTNAME" from the CMS.

The problem was still occuring yesterday afternoon but this morning when I tried it was suddenly fixed. Of course nobody says they changed anything.

If you just have a few problem systems you can add them into the windows hosts file to fix it.

[Mike EvansCengageLearni]

I believe I have been able to resolve the discovery issue. I found the following post when searching for "ping -a and nslookup" using google.



http://groups.google.com/group/microsoft.public.windows.server.dns/browse_thread/thread/59c5d0eb21e6bc3b



The last post is what I am referring to. I did what this user described and I have been able to discover the systems that I was having trouble with before. I just tested this on our production SIM installation as well and it seems to have resolved the issue there too. I guess what I am still wondering, is what changed in 5.3 to cause this behaviour? I have our production install on Windows Server 2003 and our test install on Windows Server 2008. The production install was working just fine up until I upgraded to 5.3