First published on MSDN on May 12, 2008
I wrote a blog post a while back detailing heartbeat discovery in SMS 2003....
http://blogs.msdn.com/steverac/archive/2006/08/03/687874.aspx
The information in that blog post equally applies to ConfigMgr. Heartbeat discovery is critical for SMS and ConfigMgr clients as it is the only user accessible discovery method that reports a client GUID - because a client actually has to be installed in order to generate a GUID (registration discovery records also show the GUID but, like the heartbeat record, they come from the client and are basically the first 'heartbeat' like record a ConfigMgr client sends at install. Registration discovery is not configurable b the user). In SMS 2003, the client GUID was THE key attribute that flags a system as being unique - no other attribute mattered as much as the client GUID. In ConfigMgr the client GUID is still important but the ConfigMgr client HARDWARE ID has now become the focus for determining whether a client is unique. From time to time, the ConfigMgr or SMS client will need to be removed and reinstalled - or a system reimaged. The resulting system will have the same attributes as before - NetBIOS name, MAC address AND hardware ID but, because of the fresh client install - the GUID will be changed. When the GUID changes but the hardware ID stays the same, ConfigMgr has to be able to figure out whether the system really is a new computer or if one of the scenarios just mentioned might have occurred and the computer actually is one that was pre-existing in the database and we need to make some adjustments. In SMS 2003, the process happened automatically - mostly without issue. In ConfigMgr we have added the ability to manually determine what will happen in these situations through 'conflicting records' management.
Lets take a look at a couple of scenarios to understand how heartbeat discovery processing is handled behind the scenes. For the following examples, we will use ConfigMgr - the items discussed here generally apply to SMS 2003 as well - just understand, SMS 2003 handles this all automatically (which is an option in the UI for ConfigMgr as you will see shortly). Before we get started - what exactly does a heartbeat discovery record look line. Below is an example of one that I captured from my lab - all discovery records appear similar but have different attributes available/reported. Remember, the heartbeat DDR is THE key discovery record and MUST be enabled for ConfigMgr to function properly....
<System>
BEGIN_PROPERTY
<8><SMS Unique Identifier><11><64> <GUID:457A82D2-164B-4563-A083-BA1C5E8BE8FB>
END_PROPERTY
BEGIN_PROPERTY
<0><Client Version><11><32><4.00.5931.0001>
END_PROPERTY
BEGIN_PROPERTY
<0><Client Type><8><8><1>
END_PROPERTY
BEGIN_PROPERTY
<0><Client><8><8><1>
END_PROPERTY
BEGIN_PROPERTY
<8><NetBIOS Name><11><64><STEVERACDC3>
END_PROPERTY
BEGIN_PROPERTY
<0><Resource Domain OR Workgroup><11><255><STARTREKE>
END_PROPERTY
BEGIN_PROPERTY
<0><AD Site Name><11><128><Default-First-Site-Name>
END_PROPERTY
BEGIN_PROPERTY
<17><IP Addresses><11><64>
BEGIN_ARRAY_VALUES
<65.53.93.1>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<25><MAC Addresses><11><18>
BEGIN_ARRAY_VALUES
<00:B0:D0:C4:B0:8A>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<17><IP Subnets><11><64>
BEGIN_ARRAY_VALUES
<65.53.92.0>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<25><Resource Names><11><256>
BEGIN_ARRAY_VALUES
<steveracdc3.startreke.com>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<17><SMS Assigned Sites><11><128>
BEGIN_ARRAY_VALUES
<CEN>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<0><Operating System Name and Version><11><128><Microsoft Windows NT Advanced Server 5.2>
END_PROPERTY
BEGIN_PROPERTY
<0><Previous SMS UUID><11><64><GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98>
END_PROPERTY
BEGIN_PROPERTY
<0><SMS UUID Change Date><12><19><05/25/2008 08:09:49>
END_PROPERTY
BEGIN_PROPERTY
<0><Hardware ID><11><64><2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65>
END_PROPERTY
BEGIN_PROPERTY
<0><SMBIOS GUID><11><38><4C4C4544-B45A-3710-8030-CAC04F473031>
END_PROPERTY
BEGIN_PROPERTY
<17><SMS Installed Sites><11><128>
BEGIN_ARRAY_VALUES
<CEN>
END_ARRAY_VALUES
END_PROPERTY
AGENTINFO<Heartbeat Discovery><CEN><05/25/2008 14:15:35>
In ConfigMgr, the first decision you have to make is whether you want the system to handle conflicting records for you, on the fly, like was done in SMS 2003 - or if you want to have direct control of the decision making. This option is configured in the UI as shown
What happens when automatic processing is enabled? To describe, let's take a couple of scenarios. Before we start the scenarios it's worth noting that the content of the log files as shown in the examples below is not this way by default. To get this level of detail you have to enable DDM verbose logging and you also have to enable SQL tracing After making the registry edits below, restart the SMS_Executive service.
DDM Verbose logging - HKLM/Software/Microsoft/Components/SMS_Discovery_Data_Manager/Verbose
logging = 1
SQL Tracing - HKLM/Software/Microsoft/Tracing/SQLEnabled=1
Scenario 1
Computer A has been installed at some point previously - as a part of normal processing, Computer A submits a heartbeat discovery record. That discovery record contains a client GUID and hardware ID that matches a record previously written to the ConfigMgr database and, since we have a match, the existing record is simply updated. Here is a recording of that transation in the DDM.LOG. A few key lines are highlighted in BOLD with comments .
Processing file N17SPZ3L.DDR
SQL>>>select d1.DiscArchKey,d1.DiscArchName,d1.BaseTableName,d1.Flags,d2.PropertyName,d2.ColumnName,d2.ValueType,d2.MaxWidth,d2.Flags,d2.ArrayTableName FROM DiscoveryArchitectures AS d1 LEFT JOIN DiscPropertyDefs AS d2 ON d1.DiscArchKey = d2.DiscArchKey where d1.DiscArchName = 'System' order by d1.DiscArchKey
SQL>>>>> Done.
SQL>>> select MachineID from MachineIdGroupXRef where GUID = 'GUID:29D11342-0534-43C7-A7A5-C1AEC17F8192' and ArchitectureKey = 5
We have the GUID reported in the hearbeat DDR - we are querying the database to see if
we have any existing record containing that GUID. Note here that it is not shown whether
we find a match or we don't - but you see in the next line that we are processing System
6 - this means that we found an existing system and are simply proceeding to update it.
The value of 6 comes from the ITEMKEY of that system in the System_DISC table of
the database - more about tables in a bit.
SQL>>>>> Done.
Processing <System> #6...
We have found an existing system so now we need to go about scanning related tables
for this system and determining whether we need to add/change any of the existing detail
of the system as compared to the new values we see in the currently processing heartbeat
record.
SQL>>>>>select convert(varchar(255),IP_Addresses0) from System_IP_Address_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IP_Subnets0) from System_IP_Subnets_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IPv6_Addresses0) from System_IPv6_Addre_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IPv6_Prefixes0) from System_IPv6_Prefi_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IPX_Addresses0) from System_IPX_Addres_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),MAC_Addresses0) from System_MAC_Addres_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),Resource_Names0) from System_Resource_N_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),SMS_Assigned_Sites0) from System_SMS_Assign_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),SMS_Installed_Sites0) from System_SMS_Instal_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_Container_Name0) from System_System_Container_Name_A where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_Group_Name0) from System_System_Group_Name_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_OU_Name0) from System_System_OU_Name_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_Roles0) from System_System_Rol_ARR where ItemKey = 6
SQL>>>>> Done.
SQL>>>select convert(varchar(255),Active0),convert(varchar(255),AD_Domain_Name0),convert(varchar(255),AD_Site_Name0),convert(varchar(255),AlwaysInternet0),convert(varchar(255),Client0),convert(varchar(255),Client_Type0),convert(varchar(255),Client_Version0),convert(varchar(255),CPUType0),convert(char(10),Creation_Date0,101) +' '+ convert(char(8),Creation_Date0,8),convert(varchar(255),Decommissioned0),convert(varchar(255),Hardware_ID0),convert(varchar(255),InternetEnabled0),convert(varchar(255),User_Domain0),convert(varchar(255),User_Name0),convert(varchar(255),Name0),convert(varchar(255),Netbios_Name0),convert(varchar(255),Obsolete0),convert(varchar(255),Operating_System_Name_and0),convert(varchar(255),Previous_SMS_UUID0),convert(varchar(255),Resource_Domain_OR_Workgr0),convert(varchar(255),SMBIOS_GUID0),convert(varchar(255),SMS_Unique_Identifier0),convert(char(10),SMS_UUID_Change_Date0,101) +' '+ convert(char(8),SMS_UUID_Change_Date0,8),convert(varchar(255),Community_Name0) from System_DISC where ItemKey = 6
SQL>>>>> Done.
SQL>>>select AgentID,AgentTime,AgentSite from DiscItemAgents where ItemKey = 6 and DiscArchKey = 5
SQL>>>>> Done.
SQL>>>set quoted_identifier off;set ansi_warnings off;set ansi_padding off;set ansi_nulls off;set concat_null_yields_null off;set arithabort on;set numeric_roundabort off;set DATEFORMAT mdy;
SQL>>>>> Done.
SQL>>>exec sp_GetPublicKeyForSMSID "GUID:29D11342-0534-43C7-A7A5-C1AEC17F8192"
SQL>>>>> Done.
Note that all you see in the block above - from where we detected we were updating an
existing system and now - is a series of select statements. This means that none of the
data items actually changed since the previous row was inserted. If there had been changes
you would also see SQL statements to update the changed values. We see this fact is true
by the highlighted section two lines below - no values have changed.
==>Name = <STEVERACDC3>
Info: The DDR contains 26 properties, but none has new values
We are almost done - now we have to update or add the record to a related table -
DiscItemAgents which is beyond the scope of this discussion. Suffice it to say that
there are multiple discovery methods that could potentially discover a system. Each
discovery method is referred to as a discovery agent - the DiscItemAgents table keeps
track of all discovery agents in operation and the last time the particular discovery
agent discovered a particular item (in this case, system). The agent info field of the
discovery record directly relates to the DiscItemAgents table.
insert agent information: DiscItemAgents : execute sql IF EXISTS (select ItemKey from DiscItemAgents where ItemKey = 6 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN') update DiscItemAgents set AgentTime = '05/25/2008 02:33:00' where ItemKey = 6 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN'~ ELSE insert into DiscItemAgents (AgentTime, ItemKey, DiscArchKey, AgentID, AgentSite) values ('05/25/2008 02:33:00', 6, 5, 9, 'CEN')
SQL>>>IF EXISTS (select ItemKey from DiscItemAgents where ItemKey = 6 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN') update DiscItemAgents set AgentTime = '05/25/2008 02:33:00' where ItemKey = 6 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN'~ ELSE insert into DiscItemAgents (AgentTime, ItemKey, DiscArchKey, AgentID, AgentSite) values ('05/25/2008 02:33:00', 6, 5, 9, 'CEN')
SQL>>>>> Done.
Database operations finished.
CDiscoverDataManager::FilterDDR - Will not create CCR. The Remote Client is already installed on this resource.
CDiscoverDataManager::ProcessDDRs_PS - finished processing file C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box\N17SPZ3L.DDR.
OK, now that we've seen what it looks like when we simply process a DDR for an existing system with no changes - lets see what happens when the GUID DOES change but the hardware ID remains the same
Scenario 2 - For this scenario we have the same Computer A that has been installed and reported a heartbeat DDR previously. In this case, however, Computer A has been reimaged by the helpdesk with the same version of the OS, etc. Nothing has changed except the client now has a new GUID because it has a new client installed. So, how does ConfigMgr handle processing this DDR? I show you below - but please note that I'm only showing you the specific portions of the DDM.log that are key to handling our record conflict. There is also now a portion of the log that records changes with client registration. Client registration is a new process in ConfigMgr and is used to ensure systems in the ConfigMgr database are valid (and approved) systems. Further discussion of client registration is beyond the scope of our purpose here...
Processing file G9M8S2YG.RDR
We are processing an RDR - this is a registration discovery record and will be submitted whenever
the client GUID changes - either a new GUID or when the client is instructed to change GUID as can
be the case using the TRANGUID utility from the resource kit (SMS 2003 TRANGUID still works with
ConfigMgr). This 'registration' process must be completed before further information from the client is
allowed into the database.
ApprovalMethod = 1
SQL>>>exec spUpdateClientRegistration "CEN", " GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98 ", NULL, NULL, NULL, 0x308201DE3082014BA003020102021011B839AE2D015EBF457B1F507C90E464300906052B0E03021D05003024311430120603550403130B5354455645524143444333310C300A06035504031303534D533020170D3038303532353037333733345A180F32313038303530313037333733345A3024311430120603550403130B5354455645524143444333310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100D10F8958A46E4A8DE9DA035CB0AD1FEF8940E4494BD7FF73B0BC398CDB676CF9F196C6AF3BFE8145EB2099A1E85ADB977779978A17A74A1B29E8EECE84EC9B728717CB00AD26D7593B0C032080AEBE9AF7486E7EE5573FAF725B1577A57329738C79FFAC11EEE44680565F852EC90B55BC656BA9BA9A67AB64F8D47DE9F4961D0203010001A317301530130603551D25040C300A06082B06010401823765300906052B0E03021D0500038181001BA7D4F85F4F998FF4C317807EB5F186141297F63D685F2A5F1FD527D60DBC19269EDBD8ED58030FA5DE52A0201474AA9CD92BA8F1F1A1C906E98506BCAAF89D63BABE256848D8F7152CFA5FAE0A7C36D3BE341134DEDE525F02EB4B4B286C90F8C73BC494574C30AD53EF409AFA4F88959E13E69D0D184337D90CB11CC396C5, 0x11CA61CC5F39A12B5E998494C82511C77E7429C6, 0x308201DF3082014CA003020102021003808D6BDD102BA3480FCDC554F2C99D300906052B0E03021D05003024311430120603550403130B5354455645524143444333310C300A06035504031303534D533020170D3038303532353037333733345A180F32313038303530313037333733345A3024311430120603550403130B5354455645524143444333310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100B54E77AA1A4C909FA022DE0A76C14FB2459644874E5D8547A0157E12BF90893E23082437DABC28A8D01485EE6867BF73CF260D2E7A7CDF79F678A6DA143CEE64F411B62B154286C3864D998EB023E15AAF91EB528BD34A557D6C2AAA071F9BA85B2F39AACAF0AE983A43C8FBC5BAD01A3E8FBECB3EEE089B5C3FD30B36629E2F0203010001A318301630140603551D25040D300B06092B0601040182376502300906052B0E03021D050003818100A1FECE4BED86EA848E84E9ACA4ACDCA93C1CBA98F0A582583755022619D31A3EAC900969E2623A3674BE509BA9EE0E358A68C753BE2A7E743FE73976C62DC7EF1FA222B547A1DAA8E7BE4C6EDA86BA4F8B78000BFED61C58E9E2A45442B7CB61236EFF763DDC8D21F52A621D9B321A8E1AB7151B3B677FED4F1B5395FF205F32,0xAA10604544FB7A32B7A419E416953A16C3776DFB,1, 0x06020000002400005253413100040000010001001D96F4E97DD4F864AB679ABAA96B65BC550BC92E855F568046E4EE11ACFF798C732973A577155B72AF3F57E57E6E48F79ABEAE8020030C3B59D726AD00CB1787729BEC84CEEEE8291B4AA7178A97797797DB5AE8A19920EB4581FE3BAFC696F1F96C67DB8C39BCB073FFD74B49E44089EF1FADB05C03DAE98D4A6EA458890FD1, "2008-05-25 07:37:34.000", "2108-05-01 07:37:34.000", 0,NULL ,NULL ," 2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65 ",NULL ,0,0,0,1,0, 1, "4.00.5931.0001","STEVERACDC3","steveracdc3.startreke.com", 0
Note that the first bolded entry above is the new GUID of the system being registered. The
second bolded entry is the hardware ID for the system. The hardware ID should be the same
as it was before - we just have a new GUID. This will come into play shortly.
exec spUpdateClientRegistration "CEN", "GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98", NULL, NULL, NULL, 0x308201DE3082014BA003020102021011B839AE2D015EBF457B1F507C90E464300906052B0E03021D05003024311430120603550403130B5354455645524143444333310C300A06035504031303534D533020170D3038303532353037333733345A180F32313038303530313037333733345A3024311430120603550403130B5354455645524143444333310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100D10F8958A46E4A8DE9DA035CB0AD1FEF8940E4494BD7FF73B0BC398CDB676CF9F196C6AF3BFE8145EB2099A1E85ADB977779978A17A74A1B29E8EECE84EC9B728717CB00AD26D7593B0C032080AEBE9AF7486E7EE5573FAF725B1577A57329738C79FFAC11EEE44680565F852EC90B55BC656BA9BA9A67AB64F8D47DE9F4961D0203010001A317301530130603551D25040C300A06082B06010401823765300906052B0E03021D0500038181001BA7D4F85F4F998FF4C317807EB5F186141297F63D685F2A5F1FD527D60DBC19269EDBD8ED58030FA5DE52A0201474AA9CD92BA8F1F1A1C906E98506BCAAF89D63BABE256848D8F7152CFA5FAE0A7C36D3BE341134DEDE525F02EB4B4B286C90F8C73BC494574C30AD53EF409AFA4F88959E13E69D0D184337D90CB11CC396C5, 0x11CA61CC5F39A12B5E998494C82511C77E7429C6, 0x308201DF3082014CA003020102021003808D6BDD102BA3480FCDC554F2C99D300906052B0E03021D05003024311430120603550403130B5354455645524143444333310C300A06035504031303534D533020170D3038303532353037333733345A180F32313038303530313037333733345A3024311430120603550403130B5354455645524143444333310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100B54E77AA1A4C909FA022DE0A76C14FB2459644874E5D8547A0157E12BF90893E23082437DABC28A8D01485EE6867BF73CF260D2E7A7CDF79F678A6DA143CEE64F411B62B154286C3864D998EB023E15AAF91EB528BD34A557D6C2AAA071F9BA85B2F39AACAF0AE983A43C8FBC5BAD01A3E8FBECB3EEE089B5C3FD30B36629E2F0203010001A318301630140603551D25040D300B06092B0601040182376502300906052B0E03021D050003818100A1FECE4BED86EA848E84E9ACA4ACDCA93C1CBA98F0A582583755022619D31A3EAC900969E2623A3674BE509BA9EE0E358A68C753BE2A7E743FE73976C62DC7EF1FA222B547A1DAA8E7BE4C6EDA86BA4F8B78000BFED61C58E9E2A45442B7CB61236EFF763DDC8D21F52A621D9B321A8E1AB7151B3B677FED4F1B5395FF205F32,0xAA10604544FB7A32B7A419E416953A16C3776DFB,1, 0x06020000002400005253413100040000010001001D96F4E97DD4F864AB679ABAA96B65BC550BC92E855F568046E4EE11ACFF798C732973A577155B72AF3F57E57E6E48F79ABEAE8020030C3B59D726AD00CB1787729BEC84CEEEE8291B4AA7178A97797797DB5AE8A19920EB4581FE3BAFC696F1F96C67DB8C39BCB073FFD74B49E44089EF1FADB05C03DAE98D4A6EA458890FD1, "2008-05-25 07:37:34.000", "2108-05-01 07:37:34.000", 0,NULL ,NULL ,"2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65",NULL ,0,0,0,1,0, 1, "4.00.5931.0001","STEVERACDC3","steveracdc3.startreke.com", 0
SQL>>>>> Done.
SQL>>>select d1.DiscArchKey,d1.DiscArchName,d1.BaseTableName,d1.Flags,d2.PropertyName,d2.ColumnName,d2.ValueType,d2.MaxWidth,d2.Flags,d2.ArrayTableName FROM DiscoveryArchitectures AS d1 LEFT JOIN DiscPropertyDefs AS d2 ON d1.DiscArchKey = d2.DiscArchKey where d1.DiscArchName = 'System' order by d1.DiscArchKey
SQL>>>>> Done.
SQL>>> select MachineID from MachineIdGroupXRef where GUID = 'GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98' and ArchitectureKey = 5
You will recall this SQL statement. In the previous log snip we executed this statement and then
proceeded with our updates - because we had found an existing record with the GUID in the
database. In this case, the GUID has changed and we will have no existing entry - so see what
statement is executed next....
SQL>>>>> Done.
SQL>>> select top 1 t1.ItemKey, convert(varchar(255),t1.Netbios_Name0), convert(varchar(255),tbla.Resource_Names0)~ from System_DISC t1~ join DiscItemAgents dia on t1.ItemKey=dia.ItemKey ~ left join System_Resource_N_ARR tbla on t1.ItemKey=tbla.ItemKey ~ where t1.SMS_Unique_Identifier0 is NULL~ and (~t1.Netbios_Name0="STEVERACDC3"~ and (tbla.Resource_Names0 in ("steveracdc3.startreke.com") or tbla.Resource_Names0 is NULL)~~) group by t1.ItemKey, convert(varchar(255),t1.Netbios_Name0), convert(varchar(255),tbla.Resource_Names0), t1.Obsolete0~ order by t1.Obsolete0 asc, MAX(dia.AgentTime) desc
In short, we are trying to decide whether we are dealing with a completely NEW system or
just a changed system. When we don't match the GUID we may still match enough of the other
attributes to be flagged as the same system as one currently in the database. If the later is true,
we simply introduce changes to the database to accomodate and make adjustment.
SQL>>>>> Done.
Processing NEW <System>...
So, we flag this as a NEW system - but don't interpret this as the total decision yet.
==>Name = <STEVERACDC3>
SQL>>>set quoted_identifier off;set ansi_warnings off;set ansi_padding off;set ansi_nulls off;set concat_null_yields_null off;set arithabort on;set numeric_roundabort off;set DATEFORMAT mdy;
SQL>>>>> Done.
SQL>>> exec sp_SMSGetNextID 'NextMachineID',1
SQL>>>>> Done.
SQL>>>set quoted_identifier off;set ansi_warnings off;set ansi_padding off;set ansi_nulls off;set concat_null_yields_null off;set arithabort on;set numeric_roundabort off;set DATEFORMAT mdy;
SQL>>>>> Done.
SQL>>> declare @nObs int~select @nObs=count(*) from System_DISC where Hardware_ID0="2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65" and Obsolete0=0~if (@nObs=1)~begin~ update System_DISC set Obsolete0=1, Active0=0 where Hardware_ID0="2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65" and Obsolete0=0~ select @@ROWCOUNT~end~else~ select 0
Aha - so here is the key area where we see that we actually did detect an existing system and
are starting the process of making database adjustments to accomodate. Essentially, we are
taking the previous system - that had the same hardware ID - and marking it as obsolete - and
creating a new record that will become the active record for the machine. Obsolete records
will still show in the collection but will be marked as obsolete - no software distributions will be
sent to any machine that is marked obsolete.
SQL>>>>> Done.
1 records with Hardware ID 2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65 were obsoleted by STEVERACDC3.
And here we see the result of our obsolete processing and send a status message indicating
what was done
STATMSG: ID=2639 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_DISCOVERY_DATA_MANAGER" SYS=STEVERACCEN SITE=CEN PID=3148 TID=2708 GMTDATE=Sun May 25 07:38:08.914 2008 ISTR0="STEVERACDC3" ISTR1="2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65" ISTR2="GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98" ISTR3="1" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
So, now that we have obsoleted the old record we have to fill out the new record with the same
information we had for the old. That takes place in the next few lines.
SQL>>>insert into MachineIdGroupXRef (MachineID, ArchitectureKey, GroupKey, GUID) values (7, 5, 1, 'GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98')
SQL>>>>> Done.
SQL>>>insert into System_Resource_N_ARR (ItemKey, Resource_Names0) values (7, 'steveracdc3.startreke.com')
SQL>>>>> Done.
insert base table: System_DISC : execute sql insert into System_DISC (ItemKey, DiscArchKey, SMS_Unique_Identifier0, Client_Version0, Client0, Netbios_Name0, Hardware_ID0, Client_Type0, InternetEnabled0, AlwaysInternet0, Name0, Creation_Date0, Active0, Obsolete0, Decommissioned0) values (7, 5, 'GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98', '4.00.5931.0001', 1, 'STEVERACDC3', '2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65', 1, 0, 0, 'STEVERACDC3', '05/25/2008 02:38:08', 1, 0, 0)
SQL>>>insert into System_DISC (ItemKey, DiscArchKey, SMS_Unique_Identifier0, Client_Version0, Client0, Netbios_Name0, Hardware_ID0, Client_Type0, InternetEnabled0, AlwaysInternet0, Name0, Creation_Date0, Active0, Obsolete0, Decommissioned0) values (7, 5, 'GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98', '4.00.5931.0001', 1, 'STEVERACDC3', '2:696CE24FCE01B66DC350470BC4FAEB3F96BC9B65', 1, 0, 0, 'STEVERACDC3', '05/25/2008 02:38:08', 1, 0, 0)
SQL>>>>> Done.
insert agent information: DiscItemAgents : execute sql insert into DiscItemAgents (ItemKey, DiscArchKey, AgentID, AgentTime, AgentSite) values (7, 5, 8, '05/25/2008 02:38:06', 'CEN')
SQL>>>insert into DiscItemAgents (ItemKey, DiscArchKey, AgentID, AgentTime, AgentSite) values (7, 5, 8, '05/25/2008 02:38:06', 'CEN')
SQL>>>>> Done.
Database operations finished.
CDiscoverDataManager::FilterDDR - Will not create CCR. The Remote Client is already installed on this resource.
CDiscoverDataManager::ProcessDDRs_PS - finished processing file C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box\regreq\G9M8S2YG.RDR.
Now, notice that all of this was done simply in response to a registration discovery record - the
heartbeat discovery record hasn't shown up yet - it will show up right after the client gets
'approval' back from the registration process and it knows it is clear to proceed.
Now we see the first DDR processed after the registration record completed. Note that we
continue to make adjustments to the database and end up with one system showing as
obsolete and one not - as noted in the screenshot following the log snip
Processing file BR1XW68G.DDR
SQL>>>select d1.DiscArchKey,d1.DiscArchName,d1.BaseTableName,d1.Flags,d2.PropertyName,d2.ColumnName,d2.ValueType,d2.MaxWidth,d2.Flags,d2.ArrayTableName FROM DiscoveryArchitectures AS d1 LEFT JOIN DiscPropertyDefs AS d2 ON d1.DiscArchKey = d2.DiscArchKey where d1.DiscArchName = 'System' order by d1.DiscArchKey
SQL>>>>> Done.
SQL>>>select MachineID from MachineIdGroupXRef where GUID = 'GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98' and ArchitectureKey = 5
SQL>>>>> Done.
Processing <System> #7...
SQL>>>select convert(varchar(255),IP_Addresses0) from System_IP_Address_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IP_Subnets0) from System_IP_Subnets_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IPv6_Addresses0) from System_IPv6_Addre_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IPv6_Prefixes0) from System_IPv6_Prefi_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),IPX_Addresses0) from System_IPX_Addres_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),MAC_Addresses0) from System_MAC_Addres_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),Resource_Names0) from System_Resource_N_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),SMS_Assigned_Sites0) from System_SMS_Assign_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),SMS_Installed_Sites0) from System_SMS_Instal_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_Container_Name0) from System_System_Container_Name_A where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_Group_Name0) from System_System_Group_Name_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_OU_Name0) from System_System_OU_Name_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),System_Roles0) from System_System_Rol_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>select convert(varchar(255),Active0),convert(varchar(255),AD_Domain_Name0),convert(varchar(255),AD_Site_Name0),convert(varchar(255),AlwaysInternet0),convert(varchar(255),Client0),convert(varchar(255),Client_Type0),convert(varchar(255),Client_Version0),convert(varchar(255),CPUType0),convert(char(10),Creation_Date0,101) +' '+ convert(char(8),Creation_Date0,8),convert(varchar(255),Decommissioned0),convert(varchar(255),Hardware_ID0),convert(varchar(255),InternetEnabled0),convert(varchar(255),User_Domain0),convert(varchar(255),User_Name0),convert(varchar(255),Name0),convert(varchar(255),Netbios_Name0),convert(varchar(255),Obsolete0),convert(varchar(255),Operating_System_Name_and0),convert(varchar(255),Previous_SMS_UUID0),convert(varchar(255),Resource_Domain_OR_Workgr0),convert(varchar(255),SMBIOS_GUID0),convert(varchar(255),SMS_Unique_Identifier0),convert(char(10),SMS_UUID_Change_Date0,101) +' '+ convert(char(8),SMS_UUID_Change_Date0,8),convert(varchar(255),Community_Name0) from System_DISC where ItemKey = 7
SQL>>>>> Done.
SQL>>>select AgentID,AgentTime,AgentSite from DiscItemAgents where ItemKey = 7 and DiscArchKey = 5
SQL>>>>> Done.
SQL>>>set quoted_identifier off;set ansi_warnings off;set ansi_padding off;set ansi_nulls off;set concat_null_yields_null off;set arithabort on;set numeric_roundabort off;set DATEFORMAT mdy;
SQL>>>>> Done.
SQL>>>exec sp_GetPublicKeyForSMSID "GUID:9EDC312A-62D1-42F1-85B5-4BAE2B2EEF98"
SQL>>>>> Done.
==>Name = <STEVERACDC3>
SQL>>>set quoted_identifier off;set ansi_warnings off;set ansi_padding off;set ansi_nulls off;set concat_null_yields_null off;set arithabort on;set numeric_roundabort off;set DATEFORMAT mdy;
SQL>>>>> Done.
SQL>>>update System_DISC set Obsolete0=1, Active0=0 where SMS_Unique_Identifier0="GUID:29D11342-0534-43C7-A7A5-C1AEC17F8192" and IsNULL(Obsolete0,0)=0; select @@ROWCOUNT
SQL>>>>> Done.
SQL>>>delete System_IP_Address_ARR from System_IP_Address_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>insert into System_IP_Address_ARR (ItemKey, IP_Addresses0) values (7, '65.53.93.1')
SQL>>>>> Done.
SQL>>>delete System_MAC_Addres_ARR from System_MAC_Addres_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>insert into System_MAC_Addres_ARR (ItemKey, MAC_Addresses0) values (7, '00:B0:D0:C4:B0:8A')
SQL>>>>> Done.
SQL>>>delete System_IP_Subnets_ARR from System_IP_Subnets_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>insert into System_IP_Subnets_ARR (ItemKey, IP_Subnets0) values (7, '65.53.92.0')
SQL>>>>> Done.
SQL>>>delete System_SMS_Instal_ARR from System_SMS_Instal_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>insert into System_SMS_Instal_ARR (ItemKey, SMS_Installed_Sites0) values (7, 'CEN')
SQL>>>>> Done.
SQL>>>delete System_SMS_Assign_ARR from System_SMS_Assign_ARR where ItemKey = 7
SQL>>>>> Done.
SQL>>>insert into System_SMS_Assign_ARR (ItemKey, SMS_Assigned_Sites0) values (7, 'CEN')
SQL>>>>> Done.
Update base table: System_DISC : execute sql update System_DISC set ItemKey = 7, DiscArchKey = 5, Resource_Domain_OR_Workgr0 = 'STARTREKE', AD_Site_Name0 = 'Default-First-Site-Name', Previous_SMS_UUID0 = 'GUID:29D11342-0534-43C7-A7A5-C1AEC17F8192', SMS_UUID_Change_Date0 = '05/25/2008 07:39:07', SMBIOS_GUID0 = '4C4C4544-B45A-3710-8030-CAC04F473031', Operating_System_Name_and0 = 'Microsoft Windows NT Advanced Server 5.2' where ItemKey = 7
SQL>>>update System_DISC set ItemKey = 7, DiscArchKey = 5, Resource_Domain_OR_Workgr0 = 'STARTREKE', AD_Site_Name0 = 'Default-First-Site-Name', Previous_SMS_UUID0 = 'GUID:29D11342-0534-43C7-A7A5-C1AEC17F8192', SMS_UUID_Change_Date0 = '05/25/2008 07:39:07', SMBIOS_GUID0 = '4C4C4544-B45A-3710-8030-CAC04F473031', Operating_System_Name_and0 = 'Microsoft Windows NT Advanced Server 5.2' where ItemKey = 7
SQL>>>>> Done.
insert agent information: DiscItemAgents : execute sql IF EXISTS (select ItemKey from DiscItemAgents where ItemKey = 7 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN') update DiscItemAgents set AgentTime = '05/25/2008 02:39:21' where ItemKey = 7 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN'~ ELSE insert into DiscItemAgents (AgentTime, ItemKey, DiscArchKey, AgentID, AgentSite) values ('05/25/2008 02:39:21', 7, 5, 9, 'CEN')
SQL>>>IF EXISTS (select ItemKey from DiscItemAgents where ItemKey = 7 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN') update DiscItemAgents set AgentTime = '05/25/2008 02:39:21' where ItemKey = 7 and DiscArchKey = 5 and AgentID = 9 and AgentSite = 'CEN'~ ELSE insert into DiscItemAgents (AgentTime, ItemKey, DiscArchKey, AgentID, AgentSite) values ('05/25/2008 02:39:21', 7, 5, 9, 'CEN')
SQL>>>>> Done.
Database operations finished. SMS_DISCOVERY_DATA_MANAGER 5/25/2008 2:39:23 AM 2708 (0x0A94)
CDiscoverDataManager::FilterDDR - Will not create CCR. The Remote Client is already installed on this resource.
CDiscoverDataManager::ProcessDDRs_PS - finished processing file C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box\BR1XW68G.DDR.
Now that we have gotten finished with all of this processing, here is what we see as a result in the UI - all systems collection....
If we look at the properties of the obsolete entry we will see that it displays with a grey background, meaning that this is basically just a historical record....
The properties of the active record display normally
OK, all of that and we haven't even talked about the manual options yet!!!! Don't worry, I won't make you go through more log files. Basically, if you choose the manual option you will have to make the choice when a conflicting record is detected. Any conflicts will be displayed in the 'conflicting records' node. When you right-click on a record you will have three choices - merge, new or block - as shown below...
If you choose new, the process you have just seen will take place. If you choose merge, ConfigMgr will attempt to merge the new data onto the old record - this may be the option of choice if you KNOW the system is the same and you want to preserve all historical records associated with the old record. The third option of block will create a new record in the database but block it from further use until the block is removed (done through any collection that might contain the blocked record).
So, in ConfigMgr, you have complete control over how all of this works. Now, just a bit more and we will be done.
It's cool that we know how all of this works, but where would I see this in practice? One clear example is through our collections. All of the work we've just described is happening on the System_DISC and related tables. This table is the source for all collection membership based on systems - but updates to the System_DISC table do not immediately show up in collections. To see the changes in a collection it is necessary that the collection go through an update and a refresh cycle (assuming it is query based) to have the changes in the System_DISC table reflected in the list - and this assumes that the query criteria are designed so that the changes will be picked up appropriately. For static membership collections you may have to go back through the wizard and pick the new system before it shows up in the collection - it's important to understand how all of this works together.
If all of this is of interest, take some time in your lab and work through various scenarios of interest - working through a few examples will definately help this become more clear! Hope this was helpful.