Article ID: 814750
Article Last Modified on 7/24/2007
APPLIES TO
- Microsoft Systems Management Server 2.0 Standard Edition
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. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next service pack that contains this hotfix.
To resolve this problem, submit a request to Microsoft Online Customer Services to obtain the hotfix. To submit an online request to obtain the hotfix, visit the following Microsoft Web site:
Note If additional issues occur or any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. To create a separate service request, visit the following Microsoft Web site:
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:
- CLIENT1 obtains an IP address lease for 3 days.
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.
- CLIENT1 is then turned off. (For example it may be a notebook computer.)
- 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.
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
- 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.
Additional query words: Duplicate GUID
Keywords: kbqfe kbhotfixserver kbdiscovery kbfix kbbug KB814750
