One cause of NS/SMP computer resource merging is DNS scavenging. When DNS scavenging times are less frequent than the DHCP lease times, it is possible for a reverse nslookup to get stale data from a DNS cache rather than the 'live' data. In such a DNS environment, the NS/SMP system is truly a victim of the DNS environment and is reacting as designed to the data, albeit incorrect data, provided by the DNS cache.
Following is a sample scenario:
Suppose there are two computers, compa and compb. The NS system has assigned them resource guids '1' and '2', respectively.
Computer 'compa' gets ip address 184.108.40.206. The DNS system gets updated, accordingly. The NS resource for guid 1 has a computer name of compa.
Computer 'compb' gets ip address 220.127.116.11. The DNS system gets updated, accordingly. The NS resource for guid 2 has a computer name of compb.
All is good.
At the end of Day 1: both computers disconnect from the network.
All is still good.
At the beginning of Day 2:
Computer 'compa' has not yet connected.
Computer 'compb' does connect to network. The ip lease for 'compa' has expired and 'compb' gets the ip address of 18.104.22.168, which was previously assigned to 'compa'.
Due to lease time vs. scavenging time differences, scavenging has not yet taken place when 'compb' connects. This means that stale data is in the DNS cache.
After 'compb' connects, the SMP agent on compb gathers basic inventory data, including a reverse lookup of the newly assigned ip address of 22.214.171.124. The DNS cache returns a computer name of 'compa' since scavenging has not yet occurred and that is still in the cache.
All is not good. The result is:
- Basic inventory now thinks that 'compb' has a new network name of 'compa', since that is what the DNS cache returned.
- The NS updates the 'compb' resource with the new name of 'compa'.
- Now, both resource guid 1 and 2 have the same name and are eventually merged into a single resource.