Newly discovered computers overwrite existing client discovery records (814750)


The information in this article applies to:

  • Microsoft Systems Management Server 2.0

SYMPTOMS

When you use Network Discovery to obtain discovery information for computers that are not Systems Management Server (SMS) 2.0 clients, new discovery data records (DDRs) are incorrectly merged with existing client records in the SMS database. For example, the new discovery record for CLIENT1 incorrectly overwrites the database record for CLIENT2.

CAUSE

This problem occurs when you use Dynamic Host Configuration Protocol (DHCP) to dynamically assign IP addresses to client computers and the DHCP lease expires more frequently than Network Discovery runs. The Discovery Data Manager (DDM) uses key properties in DDRs, such as the IP address, to select the client record to update. The DDM then matches the IP address in the new DDR to an existing record in the database. When a match is found, the IP address is preserved, but all other information, including the computer name, is updated.

RESOLUTION

A supported hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Only apply it to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Systems Management Server 2.0 service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the hotfix. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=support

Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.
   Date         Time   Version  Size     File name                        Service pack
   -----------------------------------------------------------------------------------
   19-Mar-2003  16:15  2.0.4.1  252,691  Sms2.0-kb814750-sp5-x86-enu.exe  Post-SP5
   20-Feb-2003  13:06  2.0.4.1  253,190  Sms2.0-kb814750-sp4-x86-enu.exe  Post-SP4
After the hotfix is installed, these files will have the following file attributes or later:Post-SP5
   Date         Time   Version         Size    File name    Platform
   -----------------------------------------------------------------
   25-Feb-2003  14:10  2.0.1493.5103   80,656  Netdisc.dll  Alpha
   25-Feb-2003  14:10  2.0.1493.5103   49,648  Netdisc.dll  x86
   25-Sep-2001  23:14  2.0.1250.7     762,688  Preinst.exe  x86
Post-SP4
   Date         Time   Version         Size    File name    Platform
   -----------------------------------------------------------------
   01-May-2002  19:45  2.0.1493.4185   80,656  Netdisc.dll  Alpha
   01-May-2002  19:45  2.0.1493.4185   49,648  Netdisc.dll  x86
   01-May-2002  17:10  2.0.1493.4154  830,224  Preinst.exe  x86
After the fix is installed, you can configure Network Discovery with a Registry key on the SMS site server to treat the IP address field as low priority. As a result, the IP address will not be used when DDR information is matched to existing client records in the database. The IP subnet field is also flagged as "full-replace" to make sure that it remains synchronized with the IP address that was discovered.

After this fix is applied, DDM will then look for the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Components\SMS_NETWORK_DISCOVERY\Disable IP Addresses as Key Fields

Note Systems Management Server 2003 already contains this fix and supports the registry key.

This key does not exist by default and is not created automatically after the fix is applied. This key and its value must be manually created by the Administrator. If the (type REG_DWORD) key Disable IP Addresses as Key Fields exists and is set to a value of 1, the IP address field will not be processed as a key field, and the IP subnet field will be processed as full-replace.

Note This fix only affects Network Discovery DDRs that are processed by the immediate site. Discovery information forwarded to parent sites may still cause inconsistent results, because the rules in the Discovery Property Definitions designate the IP address field as a key field and use it for potential matching. Additionally, when this fix is enabled, be aware that when some IP-only devices, such as routers, are discovered by Network Discovery, the only key property or value that is present in the DDR is the IP address. (The fix is enabled when "Disable IP Addresses as Key Fields" =1.) This scenario may leave the DDR with no key property and may cause a duplicate database record to be created for each device of this type, every time Network Discovery runs.

Other discovery methods, such as Logon and Heartbeat Discovery, will still consider the IP address as a key property.

WORKAROUND

To work around this problem, increase the lease length of IP addresses beyond the interval for Network Discovery. This will help reduce the occurrence of this problem because the clients will keep their assigned IP addresses for a longer period of time. Another possible workaround for this issue may be to increase the frequency of Heartbeat Discovery so that a full DDR from each client is processed more frequently.

MORE INFORMATION

The DDM places higher priority on the IP address field as a key field in DDRs. The clients will obtain a new IP address after the current IP lease expires. If a new IP address is assigned before the next Network Discovery cycle, the new DDR for the client will report a different IP address for the discovered computer. The DDM will merge the discovery data against the wrong system when the DHCP IP address is reallocated between Network Discovery cycles. As a result, systems that use the same IP address at different times may appear as one record in the site database. Here is an example of this scenario:
  1. CLIENT1 obtains an IP address lease for 3 days.
  2. CLIENT1 is connected to the network during a Network Discovery cycle, and the following information is obtained and reported in a DDR:
    Netbios name*		CLIENT1
IP address*		192.168.1.1
IP subnet		192.168.0.0
Operating system	Windows NT
MAC address*		00A0CC68CED2
    * Indicates a key field.
  3. CLIENT1 is then turned off. (For example it may be a notebook computer.)
  4. After 3 days, CLIENT2 connects to the network and receives an IP address lease. Because the IP leases in this example are short-term, the lease from CLIENT1 is reused by CLIENT2.
  5. CLIENT2 is on the network during a network discovery cycle, and the following information is obtained and reported in a DDR:
    Netbios name*		CLIENT2
IP address*		192.168.1.1
IP Subnet		192.168.0.0
Operating system	Windows NT
MAC address*		00A0CC39ECA4
  6. When the DDR is processed by the DDM, a match is found on the IP address key field and the record is merged with the existing record for CLIENT1, even though none of the other key fields match.
Modification Type:MinorLast Reviewed:4/14/2006
Keywords:kbQFE kbHotfixServer kbDiscovery kbfix kbBug KB814750 kbAudITPRO
©2004 Microsoft Corporation. All rights reserved.