Let’s understand the ConfigMgr Client Action called Discovery Data Collection Cycle (Heartbeat Discovery) in a bit more detail. The users/admins can initiate the Discovery Data Collection Cycle to speed up the discovery cycle as part of troubleshooting scenarios from Windows 10 clients. In this post, I will cover the details of this action on the client side.
I have explained about Application Deployment Evaluation Cycle in the previous post. But, it’s also important to understand ConfigMgr Client Component Status details for troubleshooting. There are three different status details are available for each component of the client. Those are installed, disabled, and enabled.
I have seen many admins getting confused between ConfigMgr Client App and SCCM Software Center. Both are different and client actions are available with ConfigMgr Client App (a.k.a Configuration Manager Application) available in the control panel.
Discovery Data Collection Cycle | SCCM Heartbeat Discovery
There are 8 (eight) client actions available in Configuration Manager client application properties as of the ConfigMgr 2010 version. The Discovery Data Collection Cycle client action is the second one from the top.
Navigate to:
- You can launch the client app from any computer that has an SCCM client installed.
- Open Command Prompt
- Run the following command – Control smscfgrc
- Click on the Actions tab
- Select Discovery Data Collection Cycle
- Click on OK from the Discovery Data Collection Evaluation Cycle popup window
Background Processes – SCCM Heartbeat Discovery
This SCCM client action Discovery Data Collection Cycle “immediately” triggers the discovery data collection (DDR Creation?) process.
As per the Technet documents (old one), This action (Discovery Data Collection Cycle) causes the ConfigMgr client to generate a new discovery data record (DDR). When the DDR is processed by the site server, Discovery Data Manager adds or updates resource information from the DDR in the site database.
I didn’t see any traces of new DDR being generated and sent to the primary server. I have deleted a device record from the console and re-initiated the Discovery Data Collection Cycle. However, it didn’t recreate the record. More investigation is needed by enabling verbose logging?
The high-level details that I collected from the log files.
- smscliui.log
- Perform Action: Discovery Data Collection Cycle – {00000000-0000-0000-0000-000000000103}. Message sent, id={55286E99-56C2-41C6-A3E3-7322C0D517C2}
- Sensor Managed Provider [Endpoint Analytics]
- [AppUsageConfig] Detected new events that was subscribed.
- ProcessEvent() end.
- CcmSqlCE.log
- [C:\windows\CCM\InventoryStore.sdf] Initialized database session manager, session pool is NOT enabled.
- Closed database ‘C:\windows\CCM\InventoryStore.sdf’.
- Inventory Provider
- GetAllInstances – 34 instance(s) of ‘C00000000_0000_0000_0000_000000000003’ found
- DDR Provider
- This machine is Virtual Machine
- This machine’s Host is BNZ141051312028
Logs – SCCM Heartbeat Discovery
The following are the log files that recorded a few entries when I triggered this client action. Mainly those are DDR provider, CCM SQL CE, and Inventory provider.
However, I found that there won’t be much action(s) triggered when the device record is already active in the SCCM console. More details about SCCM clients logs are available here.
SensorManagedProvider.Log- CcmSqlCE.log
- DdrProvider.log
- InventoryProvider.log
- smscliui.log
Resources
- ConfigMgr Client App Vs SCCM Software Center
- About client settings in Configuration Manager
- Client Management help files (SCCM 2007)
Author
Anoop C Nair is Microsoft MVP! He is a Device Management Admin with more than 20 years of experience (calculation done in 2021) in IT. He is Blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. He writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc.