Troubleshooting: SMS Agent Host Fails to Auto-Restart in Configuration Manager

Table of Contents

The SMS Agent Host service, known by its executable name CcmExec.exe, is a critical component on Configuration Manager client computers. This service is the core agent responsible for all client-side operations, including receiving and processing policies, executing software deployments, collecting hardware and software inventory, evaluating compliance settings, and reporting client status back to the site server. A healthy and running CcmExec.exe service is absolutely essential for any Configuration Manager client to function correctly within the management hierarchy. When this service is not running, the client effectively goes offline from a management perspective, unable to receive new instructions or report its current state.

Windows Management Instrumentation (WMI) is another fundamental service within the Windows operating system that plays a pivotal role in system management and monitoring. WMI provides a standardized way for administrators and applications to access management information and perform management tasks on local and remote computers. Configuration Manager clients heavily rely on WMI as a central data store and communication layer. The CcmExec.exe service interacts constantly with WMI to read configuration data, store inventory information, and utilize various WMI providers for specific tasks. This tight integration means that the health and availability of the WMI service are paramount to the proper functioning of the SMS Agent Host service.

Symptoms¶

A specific issue can arise involving the interaction between the WMI service and the SMS Agent Host service in certain Configuration Manager environments. Administrators or automated processes might, on occasion, need to pause or restart the Windows Management Instrumentation service for various reasons, such as troubleshooting WMI-related issues or during system maintenance operations. During the period when the WMI service is paused, the SMS Agent Host service (CcmExec.exe) loses its connection or dependency on WMI, rendering it nonfunctional. This is an expected behavior, as CcmExec cannot operate correctly without a healthy WMI service available.

The problem manifests itself after the WMI service is subsequently restarted or resumed. Under normal circumstances, a service that depends on another service is often designed to attempt reconnection or auto-restart if its dependency becomes available again. However, in this specific scenario, the CcmExec.exe service does not automatically detect that WMI is back online and does not initiate a self-restart. Consequently, despite WMI being operational again, the SMS Agent Host service remains in a nonfunctional state. This leaves the Configuration Manager client effectively unmanaged until CcmExec.exe is manually or automatically restarted through an external process.

The impact of CcmExec.exe being nonfunctional is significant and widespread across client management activities. The client will immediately stop processing new policies from the Configuration Manager site. Software deployments, whether mandatory or available, will not be received or executed. Hardware and software inventory data will not be collected or sent to the management point, leading to stale information in the Configuration Manager console. Compliance settings evaluation will cease, and state and status messages regarding client operations will not be reported, hindering visibility into client health and activity.

Furthermore, remote tools and client notification actions initiated from the Configuration Manager console (like client check, policy download, restart, remote control) will fail to reach or execute on the affected client because the CcmExec service is unresponsive. This state of being unmanaged persists until the SMS Agent Host service is returned to a running state. While the underlying operating system and basic network connectivity might be fine, the client’s ability to participate in the Configuration Manager hierarchy is completely severed due to the stalled CcmExec process. Recognizing these symptoms early is key to diagnosing the root cause of an unmanaged client.

Cause¶

The root cause of this specific failure for CcmExec.exe to auto-restart after the WMI service is paused and then restarted lies in how WMI handles active requests and dependencies when it is paused. When the WMI service enters a paused state, it effectively halts all ongoing operations and cancels any pending requests or active connections from client processes, including services that rely on it like CcmExec.exe. This termination of requests is a mechanism to cleanly stop WMI operations without crashing.

The critical point is that when the WMI service is subsequently resumed or fully restarted, it initializes itself and becomes available for new connections and requests. However, it does not inherently possess the capability or logic to automatically resume or re-establish the specific requests or dependency connections that were previously terminated when it was paused. Services like CcmExec.exe that were actively interacting with WMI or maintaining a dependency link at the moment WMI was paused do not automatically receive a signal or trigger from the restarted WMI service indicating that it is now available again and that they should attempt to reconnect or restart.

This behavior contrasts with some other service dependencies where the dependent service is designed to monitor the state of its required services and automatically attempt reconnection or restart when the dependency becomes available. In this particular interaction scenario between WMI and CcmExec.exe, the mechanism for CcmExec.exe to be notified or to proactively detect the WMI service’s return to an operational state after being paused and restarted appears insufficient or absent. Consequently, CcmExec.exe remains in its nonfunctional state, unaware that its critical dependency (WMI) is now available, and therefore does not trigger its own restart sequence. This requires an external intervention to get CcmExec.exe running again.

Workaround¶

Fortunately, there are straightforward workarounds to address this issue and restore the functionality of the SMS Agent Host service on affected clients. The most immediate way to resolve the problem is to manually restart the SMS Agent Host service. This action forces the CcmExec.exe process to shut down and then start again. Upon starting, the service initializes its components, establishes its dependencies (including connecting to the now-running WMI service), and resumes normal operations as a Configuration Manager client agent.

You can manually restart the service through several methods. One common method is using the Services management console (services.msc). Locate the “SMS Agent Host” service in the list, right-click on it, and select “Restart”. Alternatively, you can use the command prompt or PowerShell. From an elevated command prompt, you can use the commands net stop ccmexec followed by net start ccmexec. In PowerShell, the equivalent commands are Stop-Service CcmExec and Start-Service CcmExec, or simply Restart-Service CcmExec. Any of these methods will effectively perform the necessary restart to fix the nonfunctional agent.

For scenarios where manual intervention is not immediately feasible or to handle clients automatically, Configuration Manager has a built-in mechanism called Client Health Evaluation. This task is a scheduled activity on each client designed to periodically check the operational status of critical client components and dependencies, including the SMS Agent Host service itself. The client health evaluation runs on a predefined schedule, typically daily by default, although this schedule can be configured through client settings in the Configuration Manager console.

During the client health evaluation cycle, the client attempts to detect issues that might prevent it from being properly managed. One of the checks performed is verifying if the SMS Agent Host service (CcmExec.exe) is running. If the evaluation detects that the service is stopped or nonfunctional, it includes logic to attempt automatic remediation, which includes restarting the service. Therefore, even if you do not manually restart the service, the periodic client health check will eventually detect the issue and attempt to restart CcmExec.exe, restoring the client’s functionality. While this automatic remediation provides a safety net, it relies on the schedule of the health evaluation task, which might mean the client remains unmanaged for some time until the next scheduled check occurs. Manual restart offers immediate resolution.

Detailed Manual Restart Steps¶

Performing a manual restart of the SMS Agent Host service is a quick and effective way to restore client functionality immediately. Here are detailed steps using common Windows tools:

Method 1: Using the Services Console

1. Press Windows Key + R to open the Run dialog box.
2. Type services.msc and press Enter or click OK. This opens the Services management console.
3. Scroll down the list of services to find “SMS Agent Host”.
4. Check the “Status” column. If the service is not listed as “Running”, it is stopped or nonfunctional.
5. Right-click on “SMS Agent Host”.
6. Select “Restart” from the context menu. If Restart is greyed out, select “Start” if the status is “Stopped”.
7. Wait a few moments for the service to stop and then start again.
8. Verify that the Status column now shows “Running”.

Method 2: Using Command Prompt (Elevated)

1. Click the Start button, type cmd in the search bar.
2. Right-click on “Command Prompt” in the search results and select “Run as administrator”.
3. To stop the service, type the following command and press Enter: net stop ccmexec
4. You will be prompted if you want to stop dependent services. Type Y and press Enter. Wait for the service to stop.
5. To start the service, type the following command and press Enter: net start ccmexec
6. Wait for the service to start successfully.
7. You can verify the status by typing sc query ccmexec and pressing Enter. Look for STATE : 4 RUNNING.

Method 3: Using PowerShell (Elevated)

1. Click the Start button, type powershell in the search bar.
2. Right-click on “Windows PowerShell” or “PowerShell” and select “Run as administrator”.
3. To stop the service, type the following command and press Enter: Stop-Service CcmExec
4. You might be asked for confirmation. Confirm if necessary.
5. To start the service, type the following command and press Enter: Start-Service CcmExec
6. Wait for the service to start.
7. Alternatively, you can restart the service in a single command: Restart-Service CcmExec
8. You can verify the status by typing Get-Service CcmExec and pressing Enter. Look for Status : Running.

After successfully restarting the SMS Agent Host service using any of these methods, the Configuration Manager client should reconnect to the site and resume its normal management activities. This includes applying pending policies, uploading collected data, and becoming responsive to console actions.

Understanding the Client Health Evaluation¶

The Configuration Manager Client Health Evaluation is a sophisticated mechanism designed to proactively monitor and maintain the operational status of the client agent without requiring constant administrator intervention. It runs as a scheduled task on the client, often named something like “Configuration Manager Health Evaluation” or similar depending on the version. This task executes periodically, by default once every 24 hours, to perform a series of checks.

The checks performed by the client health evaluation are extensive and cover various aspects of the client’s health. These checks include verifying the presence and integrity of core client files, ensuring required Windows services like BITS (Background Intelligent Transfer Service) and WMI are running and healthy, checking for issues with client certificates, validating network connectivity to management points, and critically, verifying the state of the SMS Agent Host service itself. The evaluation process is logged on the client, typically in the CcmEval.log file, allowing administrators to see which checks were performed and their results.

If the evaluation process detects that the CcmExec.exe service is not running, it is designed to attempt remediation steps. The primary remediation for a stopped CcmExec service is to attempt to start it. If a simple start attempt fails, the health evaluation might log a failure but the core function is to try and get the service back online. In the scenario where CcmExec is nonfunctional after a WMI restart, the health evaluation’s check for the CcmExec service state will find it not running (or not responsive), and its remediation logic will trigger an attempt to start the service. Because WMI is now available, this start attempt will typically succeed, resolving the issue.

While the client health evaluation provides an automated recovery method, it’s important to remember its scheduled nature. If a client’s WMI service is paused and restarted just after the health evaluation has completed, the client might remain unmanaged for nearly a full evaluation cycle (e.g., up to 24 hours) until the next scheduled run. For critical clients or immediate troubleshooting, a manual restart is often the preferred approach. However, for widespread issues affecting many clients, relying on the client health evaluation as a background remediation task can be effective for eventual recovery. Client settings can be used to adjust the frequency of this health evaluation if needed, balancing resource usage against the desire for quicker automatic remediation.

Deeper Troubleshooting and Prevention¶

While the workarounds effectively resolve the symptom (CcmExec not restarting), it’s also valuable to understand how to perform deeper troubleshooting if this issue occurs frequently or if clients remain unmanaged despite the workarounds. This often involves examining relevant log files and checking the health of the underlying WMI service itself.

Relevant logs on the Configuration Manager client include:
* CcmExec.log: Located in C:\Windows\CCM\Logs. This is the main log for the SMS Agent Host service. Look for entries around the time the WMI service was paused and restarted. You might see messages indicating loss of connection to WMI, service termination, or failures during startup attempts if it tried to restart.
* CcmEval.log: Located in C:\Windows\CCM\Logs. This log records the activities and results of the Client Health Evaluation task. You can see when the evaluation ran, which checks were performed, and whether it attempted to restart the CcmExec service and the outcome of that attempt.
* Windows Event Logs:
* System Log: Accessible via Event Viewer (eventvwr.msc). Look for Service Control Manager events around the time of the WMI pause/restart and the CcmExec issue. Events related to the “SMS Agent Host” service (source: Service Control Manager) and the “Windows Management Instrumentation” service (source: Service Control Manager or WMI) can provide clues about start, stop, or failure events.
* Application Log: Also in Event Viewer. Look for events from sources like “CcmExec”, “WMI”, or “Microsoft-Windows-WMI-Activity” that might indicate errors or issues encountered by these services.

Analyzing these logs chronologically can help pinpoint the exact sequence of events and any error codes or messages associated with the CcmExec service failure to restart. For instance, the System log might show the WMI service stopping and starting, followed by no corresponding start event for CcmExec until a manual or health check restart occurs.

Another area for deeper investigation, especially if WMI issues seem to be recurring, is the health and integrity of the WMI repository. The WMI repository is the database that stores management information. Corruption in the WMI repository can cause WMI to behave erratically, fail to start, or require frequent restarts, indirectly increasing the chances of encountering the CcmExec auto-restart problem.

Basic WMI repository checks can be performed from an elevated command prompt:
* winmgmt /verifyrepository: Checks for inconsistencies in the repository.
* winmgmt /salvagerepository: Attempts to rebuild the repository from registered MOF files if corruption is detected. Note: This is a more aggressive step and should be used cautiously as it effectively rebuilds the repository, which might require re-registering WMI providers afterward.

If WMI itself is frequently unstable, addressing the root cause of the WMI issues is paramount. This could involve identifying conflicting software, troubleshooting system resource problems, or addressing underlying operating system corruption. However, the scope of this article is specifically the CcmExec auto-restart failure after a WMI restart, assuming WMI itself is capable of restarting.

Preventative measures against this specific CcmExec auto-restart issue primarily involve minimizing unnecessary pauses or restarts of the WMI service on client machines. While sometimes unavoidable during specific troubleshooting or update scenarios, routine administrative tasks should ideally not involve manipulating core system services like WMI unless explicitly required. Implementing robust monitoring solutions that alert administrators when the SMS Agent Host service is detected as stopped or nonfunctional can also help identify affected clients quickly, allowing for prompt manual intervention. Additionally, ensuring that the Configuration Manager Client Health Evaluation task is enabled and configured with an appropriate schedule ensures that a level of automatic remediation is in place. Keeping the Configuration Manager client agent and the underlying Windows operating system updated with the latest patches can also mitigate potential service interaction issues or bugs.

In summary, while the immediate workaround of restarting CcmExec.exe or waiting for the client health evaluation effectively resolves the nonfunctional state, understanding the cause and knowing how to perform deeper troubleshooting using logs and WMI tools are valuable skills for managing Configuration Manager clients effectively. Proactive monitoring and careful management of system services contribute to a more stable client environment.

Conclusion¶

The issue where the SMS Agent Host service (CcmExec.exe) fails to automatically restart after the Windows Management Instrumentation (WMI) service is paused and then restarted is a known behavior stemming from how WMI handles request termination upon pausing. This leaves the Configuration Manager client unmanaged until CcmExec.exe is explicitly restarted. While the built-in Client Health Evaluation provides an automated safety net, manually restarting the SMS Agent Host service offers the most immediate solution. Administrators can achieve this easily through the Services console, Command Prompt, or PowerShell. Understanding the role of WMI and CcmExec, knowing where to look in logs for troubleshooting, and being aware of the client health evaluation process are key to effectively managing and maintaining Configuration Manager clients when encountering such service interaction issues. Proactive monitoring and minimizing unnecessary manipulation of critical system services like WMI contribute to a healthier client environment.

Have you encountered this specific issue in your Configuration Manager environment? What methods have you found most effective for resolving it on your clients? Share your experiences and troubleshooting tips in the comments below!