Are you an IT professional looking to manage a large number of Windows devices in your organization? If so, you may already be familiar with the Configuration Manager – a powerful tool for automating software deployment, security patch management, and device configuration. However, to ensure that your ConfigMgr deployment is running smoothly, you need to be well-versed in the client actions that ConfigMgr offers.
In this blog post, we’ll take a deep dive into each ConfigMgr client action, including when to use them, what they do, and which log files you need to pay attention to. Whether you’re a seasoned administrator or just getting started, this guide will provide you with the essential knowledge you need to manage your ConfigMgr clients effectively.
Table of Contents
What are the ConfigMgr Client Actions
Application Deployment Evaluation Cycle
Discovery Data Collection Cycle
Machine Policy Retrieval & Evaluation Cycle
Software Metering Usage Report Cycle
Software Updates Scan & Software Updates Deployment Evaluation cycles
User Policy Retrieval & Evaluation Cycle
What are the ConfigMgr Client Actions
Firstly, what are the ConfigMgr client actions? Microsoft defines them as “cycles which can be run to take immediate action on remote clients”.
Basically, running the action cycle will allow you to sync the changes you make and download them on the client side or have the clients send data back.
They can be performed manually or on a schedule, on individual or a collection of devices.
On the client side, you will find them under Control Panel –> Configuration Manager
Now that we know what the actions are, let’s discuss about each cycle, what it will do, how to manage it and the various ways to run it. A lot of information is made available by Microsoft on this topic, but it’s difficult to find information about each cycle in the same place. The cycles are alphabetically ordered; therefore, we will discuss them with the same approach.
Application Deployment Evaluation Cycle
1. What is it?
When this cycle runs, the client will evaluate the detection method of all applications deployed to it. If the application is not detected, the installation will take place if the deployment purpose is Required.
2. When to trigger it?
Running this action is useful when you would like to:
- Deploy a new application as required, and you want it to install.
NOTE: If the policy of the new deployment is not yet synced, the deployment will not be enforced, as the client is not yet aware of it.
- Re-evaluate the deployed application after you have made changes to the detection criteria.
- Retry a failed installation of a required deployment.
- Reinstall an application – if an app is deployed as Required, but was uninstalled manually, running the cycle will get the application re-installed.
- Make the Install button available in the Software Center – if you deployed an application as Available, but the software was uninstalled manually, Software Center will still show the Uninstall button, as it will not be aware immediately that the software was removed.
More details about this action, including examples on application detection and evaluation, can be found documented by Microsoft here.
3. Relevant logs to monitor on the client side.
If you’d like to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- AppIntentEval.log – Records details about the current and intended state of applications, their applicability, whether requirements were met, deployment types, and dependencies.
- AppDiscovery.log – Records details about the discovery or detection of applications on client computers.
- AppEnforce.log – Records details about enforcement actions (install and uninstall) taken for applications on the client.
- CIAgent.log – Records details about the process of remediation and compliance for compliance settings, software updates, and application management.
- DCMAgent.log – Records high-level information about the evaluation, conflict reporting, and remediation of configuration items and applications.
Discovery Data Collection Cycle
1. What is it?
When this ConfigMgr Client action runs, the client will essentially perform a heartbeat discovery. This type of discovery is the only one that will provide details about the client installation status.
2. When to trigger it?
Running this action will maintain the database record of ConfigMgr clients. Run it if you would like to:
- maintain the database record of ConfigMgr clients. For instance, if you manage a new computer, the Heartbeat Discovery will automatically run on it and add it to the database as a new resource record.
- re-add the record of a still active computer which is deleted by accident to the database.
- collect data about newly added devices or users to the managed environment, if you don’t want to wait for the scheduled sync to take place.
- collect updated data from a device on which the ConfigMgr client was broken for a long period of time.
According to Microsoft: When heartbeat discovery runs, it creates a DDR (Data Discovery Record) that has the client’s current information. The client then copies this small file to a management point so that a primary site can process it. The file is about 1 KB in size and has the following information:
- Network location
- NetBIOS name
- Version of the client agent
- Operational status details
3. Relevant logs to monitor on the client side.
If want to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- InventoryAgent.log – Records activities of hardware inventory, software inventory, and heartbeat discovery actions on the client.
- InventoryProvider.log – More details about hardware inventory, software inventory, and heartbeat discovery actions on the client.
File Collection Cycle
1. What is it?
This action ties into Configuration Manager inventory. More specifically, software inventory. There are two inventory-related client actions in ConfigMgr: Hardware and Software inventory cycles – they will be covered later in this article.
To give a brief introduction, if enabled, the Hardware Inventory will contain any client system information (CPU, disk size, Installed Applications, and so on).
The Software Inventory, if enabled, will collect files from a client device, as well as details about those files.
With file collection, you can also specify a set of files to be copied from the clients to the ConfigMgr site the clients are assigned to. It can be useful to gather logs remotely.
2. When to trigger it?
It is useful running this action when you would like to:
- collect a fresh set of files from the client (EXEs, DLLs, INI, logs and so on)
- collect a set of files after a configuration change in which it was specified to gather other files.
- collect updated files from a device on which the ConfigMgr client was broken for a long period of time.
3. Relevant logs to monitor on the client side
If you want to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- InventoryAgent.log – Records activities of hardware inventory, software inventory, and heartbeat discovery actions on the client.
- InventoryProvider.log – More details about hardware inventory, software inventory, and heartbeat discovery actions on the client.
- FileSystemFile.log – Records the activity of the Windows Management Instrumentation (WMI) provider for software inventory and file collection.
Hardware Inventory Cycle
1. What is it?
This ConfigMgr client action will collect the client hardware configuration details. By default, this action will be disabled. It will have to be enabled from the Client Settings.
When the Hardware Inventory Cycle runs on the device for the first time, it always returns a full inventory. Subsequent runs will contain only delta inventory information.
In addition to the default information gathered by default, the hardware inventory can be extended to collect additional information.
Various SSRS Dashboard reports can be used to query the database for a list of computers with specific software installed, for instance. A query can be done on a specific device as well, to show all the installed software.
The information collected by this cycle can be used for a lot more, however, like asset management, compliance reporting, and many other purposes.
NOTE: A common misconception is that the Software Inventory Cycle collects data on installed software from the client device. This is incorrect. The Hardware Inventory Cycle is the one collecting this information.
2. When to trigger it?
It is useful running this action when you would like to:
- Collect the latest hardware details from a client and for that you initiate the hardware inventory collection cycle outside the scheduled polling interval.
- Collect installed app information that will allow you to build dynamic collections (all devices with PuTTY installed, as an example).
This will give a lot of possibilities. Target the collection with updates, or with an uninstall.
EXAMPLE: Target the device with the uninstall of PuTTY. As we created a dynamic collection (as shown in the screenshot above), every time a user will manually install PuTTY, as soon as the hardware inventory cycle will run, the device will fall in this collection. Then the uninstall deployment will take effect to remove the software again.
3. Relevant logs to monitor on the client side.
If you want to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- InventoryAgent.log – Records activities of hardware inventory, software inventory, and heartbeat discovery actions on the client.
- InventoryProvider.log – More details about hardware inventory, software inventory, and heartbeat discovery actions on the client.
Machine Policy Retrieval & Evaluation Cycle
1. What is it?
When this action is initiated, the client device will connect to the Management Point and download the latest policy applicable to the device. The policy update can apply to software deployments, configuration changes, and more.
2. When to trigger it?
It is useful running this action when you would like to:
- Install an application you’ve just deployed to a device collection.
- Apply configuration changes made in the Client Settings.
- Apply any other changes which should apply to the device after adding or modifying policies.
3. Relevant logs to monitor on the client side.
If you’d like to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- LocationServices.log – Records the client activity for locating management points, software update points, and distribution points. It can also be checked to see if the client can communicate with the Management Point and download policy updates.
- PolicyAgent.log – Records requests for policies made by using the Data Transfer Service.
- PolicyAgentProvider.log – Records policy changes.
- PolicyEvaluator.log – Records details about the evaluation of policies on client computers, including policies from software updates.
Software Inventory Cycle
1. What is it?
The Software Inventory is another cycle that will need to be enabled in Client Settings. When enabled, the ConfigMgr client agent collects information on files from the client device. In conjunction with the File Collection Cycle, it has the ability to also collect files.
The data can be used for software asset management or compliance reporting, for instance.
This information can then be viewed, for instance, using Resource Explorer.
It is important to note that this data will not be available in real-time, like CMPivot for instance. By default, the Software Inventory cycle runs every 7 days, unless a more aggressive schedule is configured.
2. When to trigger it?
When this action is initiated, the ConfigMgr client agent will inventory file information from the device.
It can be useful to initiate it manually when new configuration is done, and you’d like to have the data collected as soon as possible.
3. Relevant logs to monitor on the client side.
If you want to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- InventoryAgent.log – Records activities of hardware inventory, software inventory, and heartbeat discovery actions on the client.
- InventoryProvider.log – More details about hardware inventory, software inventory, and heartbeat discovery actions on the client.
- FileSystemFile.log – Records the activity of the Windows Management Instrumentation (WMI) provider for software inventory and file collection.
Software Metering Usage Report Cycle
1. What is it?
The Software Metering Usage Report Cycle is an action which collects information on how much specific software was used on a specific client(s).
At the time of writing this article, I could not find any documentation on the Microsoft website about this cycle.
2. When to trigger it?
By default, like pretty much all other cycles, this one will also run every 7 days. When it runs, it will retrieve data about the software used on clients.
It is useful to run it manually when you’d like the client to collect updated usage data.
3. Relevant logs to monitor on the client side.
If want to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- mtrmgr.log – Monitors all software metering processes.
- SWMTRReportGen.log – Generates a use data report that is collected by the metering agent. This data is logged in mtrmgr.log.
Software Updates Scan & Software Updates Deployment Evaluation cycles
1. What is it?
TL;DR When these cycle run, the client will run a scan to evaluate if the Windows or third-party updates available on the Software Update Point are Required, Not Required or already Installed.
If the update(s) is/are Required and deployed, subsequent actions will take place to download the content from the Distribution Point and install the updates.
On a longer note, Microsoft documented this action very well in its Introduction to software updates article.
If you are like me and don’t like to go to other websites when reading an article, I’ve got some good news and some bad news. The bad news is that I’m about to quote another article, as it is useful information. The good news is that it’s from Microsoft, no need to worry that it’s from some shady corner of the internet with questionable pop-up ads.
QUOTE: When the scan is started, a Software Updates Client Agent process clears the scan history, submits a request to find the WSUS server that should be used for the scan, and updates the local Group Policy with the WSUS server location.
A scan request is passed to the Windows Update Agent (WUA). The WUA then connects to the WSUS server location that is listed in the local policy, retrieves the software updates metadata that has been synchronized on the WSUS server, and scans the client computer for the updates.
A Software Updates Client Agent process detects that the scan for compliance has finished, and it creates state messages for each software update that changed in compliance state after the last scan. The state messages are sent to the management point in bulk every 15 minutes. The management point then forwards the state messages to the site server, where the state messages are inserted into the site server database.
After the initial scan for software updates compliance, the scan is started at the configured scan schedule. However, if the client has scanned for software updates compliance in the time frame indicated by the Time to Live (TTL) value, the client uses the software updates metadata that is stored locally. When the last scan is outside the TTL, the client must connect to WSUS running on the software update point and update the software updates metadata stored on the client.
2. When to trigger it?
When new updates are published, their status will be Unknown.
If you’d like to know whether the updates are Required / Not Required / Installed on your client devices, running Software Update Scan cycle will make the clients check whether the updates apply to them or not.
If the updates are deployed, running the Software Update Deployment Evaluation cycle will evaluate the deployment purpose (available / required), schedule (available date, deadline) and install the updates accordingly.
It can also be useful to trigger this cycle manually when you’d like to retry the install of failed updates.
Basically, it’s useful to trigger them to:
- Ensure devices have up to date software and patches
- Enforce the installation after new (software) updates are released.
3. Relevant logs to monitor on the client side.
There are A LOT of components with many different log files which tie into Software Updates. A list of all of them can be found here.
However, the log files specific to information generated from running these scan cycles would be:
- UpdatesDeployment.log – Records details about deployments on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.
- UpdatesHandler.log – Records details about software update compliance scanning and about the download and installation of software updates on the client.
- UpdatesStore.log – Records details about compliance status for the software updates that were assessed during the compliance scan cycle.
- WUAHandler.log – Records details about the Windows Update Agent on the client when it searches for software updates.
- WindowsUpdate.log – although not a ConfigMgr log, it will contain detailed information about the Windows Update process on the device.
The software update deployment process in ConfigMgr is very complex. Tracking it can be excruciating at times. Microsoft documented the entire process and how it will look like behind the scenes, all the relevant logs from the all the other processes which tie into this, here, in a very useful and comprehensive article.
User Policy Retrieval & Evaluation Cycle
1. What is it?
When this action is initiated, the client device will connect to the Management Point and download the latest policy applicable to user objects.
2. When to trigger it?
It is useful running this action when you want to:
- Install an application you’ve just deployed to a user collection.
- Apply other changes configured for the logged-on user.
3. Relevant logs to monitor on the client side
If you’d like to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- PolicyAgent.log – Records requests for policies made by using the Data Transfer Service.
- PolicyAgentProvider.log – Records policy changes.
- PolicyEvaluator.log – Records details about the evaluation of policies on client computers, including policies from software updates.
Windows Installer Source List Update Cycle
1. What is it?
This is the final ConfigMgr client action. Before we dive into what this cycle can do, some background information is in order.
Have you ever had deployments fail with System Error 1612 – the installation source for this product is not available?
This issue applies to MSI-based products. During an update or uninstall of an MSI-based software, the previous installer (.msi) must be available to complete the operation.
During the installation of an Application or Package, the ConfigMgr client caches the installer under C:\Windows\ccmcache.
This folder, however, has a size limit. If the size grows to exceed that limit, the oldest installers will be automatically removed (first in, first out).
Windows Installer also caches a copy of the MSI file to C:\Windows\Installer, or at least, it should.
As documented in the article linked above, if the original MSI file doesn’t exist under C:\Windows\Installer, nor in the original path used to perform the install, the installation will fail.
This is where the Windows Installer Source List Update Cycle comes into play, as it was introduced to fix this issue. With properly configured ConfigMgr Applications / Packages, whenever an update or uninstall takes place on the client side, the Windows Installer Source Location Manager will automatically search the Distribution point for the original source files if the original MSI file no longer exists on the device.
For this to work, a few things need to be kept in mind:
- For Applications, the Product Code of the MSI needs to be specified in the Deployment Type to enable installation source management.
- For Packages, the Product Code needs to be specified in the Windows Installer tab of the Program.
But no one uses Packages anymore, right? Well, hang tight, it gets better.
NOTE: For this feature to work, your clients will need to communicate with the Distribution Point using HTTP and you must allow clients to connect anonymously.
If you have HTTPS configured, you will have to apply a workaround. See Windows Installer source list update fails when distribution points are configured for HTTPS.
2. When to trigger it?
This cycle cannot be configured to run on a specific interval. It automatically runs when an Application or a Package with associated Windows Installer information runs, for instance.
It is useful to run it manually when a repair for a newly packaged Application needs to be performed. You will have to enable the Allow end users to attempt to repair this application option in the Deployment Settings.
3. Relevant logs to monitor on the client side.
If you’d like to monitor the evaluation of this action, it can be done using these logs located on the client side in the %windir%\CCM\Logs folder:
- SrcUpdateMgr.log – Records activity for installed Windows Installer applications that are updated with current distribution point source locations.
Summary
Now that we have reviewed all ConfigMgr client actions, and put all the pieces of this puzzle together, let’s summarize all this information in a table.
As a note, the logs mentioned in this article only scratch the surface of all the log files you can review to troubleshoot various issues. For a complete list, see this Configuration Manager Log file reference guide.
Client Action | What Does it Do? | Relevant Log Files |
Application Deployment Evaluation Cycle | Evaluates the discovery or detection of applications on client computers | AppIntentEval.log AppDiscovery.log AppEnforce.log CIAgent.log DCMAgent.log |
Discovery Data Collection Cycle | The client will perform a heartbeat discovery. This type of discovery is the only one that will provide details about the client installation status | InventoryAgent.log InventoryProvider.log |
File Collection Cycle
| It will tell the client which files need to be collected as part of the Software Inventory Cycle | InventoryAgent.log InventoryProvider.log FileSystemFile.log |
Hardware Inventory Cycle | Allows you to collect information about the hardware configuration of client devices. It will also collect information on installed applications | InventoryAgent.log InventoryProvider.log |
Machine Policy Retrieval & Evaluation Cycle | The client device will connect to the Management Point and download the latest policy applicable to the device | PolicyAgent.log PolicyAgentProvider.log PolicyEvaluator.log |
Software Inventory Cycle | The ConfigMgr client agent will collect the files specified as part of the File Collection Cycle | InventoryAgent.log InventoryProvider.log FileSystemFile.log |
Software Metering Usage Report Cycle | Collects information on how much specific software was used on a specific client(s) | mtrmgr.log SWMTRReportGen.log |
Software Updates Scan & Software Updates Deployment Evaluation cycles | When these cycle run, the client will run a scan to evaluate if the windows / third party updates available on the Software Update Point are Required, Not Required or already Installed. If the update(s) is/are Required and deployed, subsequent actions will take place to download the content from the Distribution Point and install the updates | UpdatesDeployment.log UpdatesHandler.log UpdatesStore.log WUAHandler.log WindowsUpdate.log |
User Policy Retrieval & Evaluation Cycle | The client device will connect to the Management Point and download the latest policy applicable to the user | PolicyAgent.log PolicyAgentProvider.log PolicyEvaluator.log |
Windows Installer Source List Update Cycle | Allows the client to search the Distribution Point for source files, in case MSI installers are not found locally during an uninstall or upgrade.
It can also be triggered to ensure installation sources are available | SrcUpdateMgr.log |
| Client Action | What does it do? | Relevant log files |
| Application Deployment Evaluation Cycle | Evaluates the discovery or detection of applications on client computers |
|
| Discovery Data Collection Cycle |
The client will perform a heartbeat discovery. This type of discovery is the only one that will provide details about the client installation status |
|
| File Collection Cycle | It will tell the client which files need to be collected as part of the Software Inventory Cycle |
|
| Hardware Inventory Cycle | Allows you to collect information about the hardware configuration of client devices. It will also collect information on installed applications. |
|
| Machine Policy Retrieval & Evaluation Cycle | The client device will connect to the Management Point and download the latest policy applicable to the device |
|
| Software Inventory Cycle | The ConfigMgr client agent will collect the files specified as part of the File Collection Cycle |
|
| Software Metering Usage Report Cycle | Collects information on how much specific software was used on a specific client(s) |
|
| Software Updates Scan & Software Updates Deployment Evaluation cycles | When these cycle run, the client will run a scan to evaluate if the windows / third party updates available on the Software Update Point are Required, Not Required or already Installed. If the update(s) is/are Required and deployed, subsequent actions will take place to download the content from the Distribution Point and install the updates |
|
| User Policy Retrieval & Evaluation Cycle | The client device will connect to the Management Point and download the latest policy applicable to the user |
|
| Windows Installer Source List Update Cycle | Allows the client to search the Distribution Point for source files, in case MSI installers are not found locally during an uninstall or upgrade. It can also be triggered to ensure installation sources are available |
|
