Data Discovery Record (DDR) Retention
After
installing a ConfigMgr site, you add clients and resources to the site.
These objects are added using a discovery method. (The only required
discovery method is the heartbeat discovery method.) Various discovery
methods can be used that search Active Directory or the network for
resources. Those resources include computers, Active Directory (AD)
objects, site systems, routers, hubs, printers, and Internet Protocol
(IP)-addressable devices.
As ConfigMgr 2007
discovers resources, it creates records in the Configuration Manager
database and files with a .DDR extension. These discovery records are
called data discovery records (DDRs), which refer to the .ddr file
format and the actual file used by ConfigMgr to report discovery data to
a Configuration Manager site database. You can use these DDRs to
target installations for client deployment. DDRs are the main method to
tell a ConfigMgr site crucial details about clients. Without DDRs, no
clients would be in the database for your administrators to manage!
DDRs are generated based
upon the type of discovery method used and based upon a polling schedule
that indicates when ConfigMgr performs the actions required to execute
the discovery, such as querying Active Directory for systems in the
container specified within the discovery method. Heartbeat discovery is
unique because the ConfigMgr server does not poll these systems; the
discovery configuration only specifies how frequently the clients send
their heartbeats to ConfigMgr. The specific information contained in
each record can vary depending on the particular resource.
Here are the different discoveries available in ConfigMgr 2007:
Active Directory System Discovery— Not enabled by default; default polling schedule is daily.
Active Directory Security Group Discovery— Not enabled by default; default polling schedule is daily.
Active Directory System Discovery— Not enabled by default; default polling schedule is daily.
Active Directory User Discovery— Not enabled by default; default polling schedule is daily.
Heartbeat Discovery—
Enabled by default; default polling schedule is once a week. Heartbeat
discovery is unique in that it is the only discovery method that returns
a client Globally Unique Identifier (GUID) as part of the discovery
record; it also is the only discovery method to dictate whether clients
are displayed as “installed” in the ConfigMgr console. Heartbeat
discovery is responsible for letting the site know a client is still
healthy.
Network Discovery— Not enabled by default; no default schedule.
Data collected can include
things such as the NetBIOS name of the computer, the IP address, the MAC
(Media Access Control) address, and the IP subnet of the discovered
computer or device.
You can configure each
type of discovery method on its own custom schedule. When ConfigMgr runs
discoveries, it generates resource DDRs to keep discovery data current
in the database and inform ConfigMgr that the resource is still valid
for the site.
DDRs are not intended for
use as extended inventory; they contain basic information that gives the
ConfigMgr site enough information to place the client in the database
and determine if it were reported previously.
The following is a
sample of a heartbeat DDR file created for the Alamo server shown in
eXtensible Markup Language (XML) format. Note the NetBIOSName
information for the Alamo server, IP Address information, AD Site,
ConfigMgr Site, and Domain information:
<?xml version="1.0" encoding="UTF-16" ?>
- <Report>
- <ReportHeader>
- <Identification>
- <Machine>
<ClientInstalled>1</ClientInstalled>
<ClientType>1</ClientType>
<ClientID>GUID:F35CA434-E9FE-41D0-870A-EF7712F3A63A</ClientID>
<ClientVersion>4.00.6221.1000</ClientVersion>
<NetBIOSName>ALAMO</NetBIOSName>
<CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID>
</Machine>
</Identification>
- <ReportDetails>
<ReportContent>Inventory\x0020Data</ReportContent>
<ReportType>Full</ReportType>
<Date>20090322125813.000000-300</Date>
<Version>62.0</Version>
<Format>1.1</Format>
</ReportDetails
- <InventoryAction ActionType="Predefined">
<InventoryActionID>{00000000-0000-0000-0000-000000000003}</InventoryActionID>
<Description>Discovery</Description>
<InventoryActionLastUpdateTime>20081223140235.000000+000
</InventoryActionLastUpdateTime>
</InventoryAction>
</ReportHeader>
- <ReportBody>
- <Instance ParentClass="Win32_NetworkAdapterConfiguration" Class="Win32_NetworkAdapterConfiguration" Namespace="\\ALAMO\root\cimv2" Content="New">
- <Win32_NetworkAdapterConfiguration>
<Index>8</Index>
<IPAddress>192.168.0.184</IPAddress>
<MACAddress>00:15:5D:00:BF:10</MACAddress>
</Win32_NetworkAdapterConfiguration>
</Instance>
- <Instance ParentClass="Win32_ComputerSystemProduct" Class="Win32_ComputerSystemProduct" Namespace="\\ALAMO\root\cimv2" Content="New">
- <Win32_ComputerSystemProduct>
<IdentifyingNumber>3461-0380-3136-6267-8632-1958-27</IdentifyingNumber>
<Name>Virtual\x0020Machine</Name>
<UUID>84910F83-3948-451E-9A58-A970C2ADC908</UUID>
<Version>5.0</Version>
</Win32_ComputerSystemProduct>
</Instance>
- <Instance ParentClass="CCM_Client" Class="CCM_Client" Namespace="\\ALAMO\ROOT\ccm" Content="New">
- <CCM_Client>
<ClientIdChangeDate>12/26/2008\x002020:55:41</ClientIdChangeDate>
<PreviousClientId>Unknown</PreviousClientId>
</CCM_Client>
</Instance>
- <Instance ParentClass="CCM_DiscoveryData" Class="CCM_DiscoveryData" Namespace="\\ALAMO\root\ccm\invagt" Content="New">
- <CCM_DiscoveryData>
<PlatformID>Microsoft\x0020Windows\x0020NT\x0020Server\x00205.2</PlatformID>
</CCM_DiscoveryData>
</Instance>
- <Instance ParentClass="SMS_Authority" Class="SMS_Authority"
Namespace="\\ALAMO\ROOT\ccm" Content="New">
- <SMS_Authority>
<Name>SMS:DAL</Name>
</SMS_Authority>
</Instance>
- <Instance ParentClass="CCM_ExtNetworkAdapterConfiguration" Class="CCM_ExtNetworkAdapterConfiguration" Namespace="\\ALAMO\root\ccm\invagt" Content="New">
- <CCM_ExtNetworkAdapterConfiguration>
<FQDN>alamo.SCCMUNLEASHED.COM</FQDN>
</CCM_ExtNetworkAdapterConfiguration>
</Instance>
- <Instance ParentClass="CCM_ClientIdentificationInformation" Class="CCM_ClientIdentificationInformation" Namespace="\\ALAMO\ROOT\ccm" Content="New">
- <CCM_ClientIdentificationInformation>
<HardwareID1>2:268C7D8FEBAD3A8AABAAA8A66BDC4B622B917EB6</HardwareID1>
</CCM_ClientIdentificationInformation>
</Instance>
- <Instance ParentClass="Win32_ComputerSystem" Class="Win32_ComputerSystem" Namespace="\\ALAMO\root\cimv2" Content="New">
- <Win32_ComputerSystem>
<Name>ALAMO</Name>
<UserName>SCCMUNLEASHED\\Administrator</UserName>
</Win32_ComputerSystem>
</Instance>
- <Instance ParentClass="CCM_ADSiteInfo" Class="CCM_ADSiteInfo"
Namespace="\\ALAMO\root\ccm\invagt" Content="New">
- <CCM_ADSiteInfo>
<ADSiteName>Default-First-Site-Name</ADSiteName>
</CCM_ADSiteInfo>
</Instance>
- <Instance ParentClass="CCM_ComputerSystem" Class="CCM_ComputerSystem" Namespace="\\ALAMO\root\ccm\invagt" Content="New">
- <CCM_ComputerSystem>
<Domain>SCCMUNLEASHED</Domain>
</CCM_ComputerSystem>
</Instance>
- <Instance ParentClass="CCM_NetworkAdapterConfiguration" Class="CCM_NetworkAdapterConfiguration" Namespace="\\ALAMO\root\ccm\invagt" Content="New">
- <CCM_NetworkAdapterConfiguration>
<IPSubnet>192.168.0.0</IPSubnet>
</CCM_NetworkAdapterConfiguration>
</Instance>
</ReportBody>
</Report>
Tip: Capturing Heartbeat Discoveries
If
you want to preserve the data collected in the discovery record for
troubleshooting purposes, create an empty folder named
archive_reports.sms on the agent system at the ccm\inventory\temp
directory (stored at c:\windows\system32 on x86 systems and
c:\windows\syswow64 on x64 systems). You can verify this location by
checking the registry entry setting located at
After this file is
created, the discovery and other inventory records are stored in XML
format in this temp folder as they are processed.
The following section
shows a sample of an Active Directory system discovery DDR file created
for the Wildflower server. (Note the sample includes the NetBIOS name,
domain of SCCMUNLEASHED, Active Directory site name, IP address, the
discovery method used, and other fields that would be relevant to
discovery on a Windows-based server.)
MFV : <System>
BEGIN_PROPERTY
<8><NetBIOS Name><11><32><WILDFLOWER>
END_PROPERTY
BEGIN_PROPERTY
<1><Operating System Name and Version><11><32><Microsoft Windows NT Server 5.2>
END_PROPERTY
BEGIN_PROPERTY
<0><Resource Domain OR Workgroup><11><32><SCCMUNLEASHED>
END_PROPERTY
BEGIN_PROPERTY
<0><AD Site Name><11><32><Default-First-Site-Name>
END_PROPERTY
BEGIN_PROPERTY
<16><IP Addresses><11><64>
BEGIN_ARRAY_VALUES
<192.168.0.183>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<24><Resource Names><11><256>
BEGIN_ARRAY_VALUES
<wildflower.SCCMUNLEASHED.COM>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<0><Primary Group ID><8><4><515>
END_PROPERTY
BEGIN_PROPERTY
<0><User Account Control><8><4><4096>
END_PROPERTY
AGENTINFO<SMS_AD_SYSTEM_DISCOVERY_AGENT><DAL><02/06/2009 16:51:47>
FEOF FV
The
retention period for obsolete records is defined by settings in the
Delete Obsolete Client Discovery Data task. The retention periods of
DDRs are a function of whether the system is a current system, meaning
that it is sending heartbeats. If the system is not current, the
settings are defined in either the Delete Aged Discovery Data task
(assuming that the system is not discovered by another method) or the
Delete Inactive Client Discovery Data task.
