Configuration Manager Client Reinstallation Loop? Investigate Frequent 5-Hour Cycles

Table of Contents

Configuration Manager, formerly known as System Center Configuration Manager (SCCM), is a powerful tool used by organizations to manage large numbers of computers and devices. Its core functions include deploying applications, managing updates, deploying operating systems, and ensuring compliance across the enterprise. Central to its operation is the Configuration Manager client software, which must be installed and functioning correctly on each managed device. The client facilitates communication between the device and the Configuration Manager infrastructure, allowing it to receive policies, deploy software, and report status.

Maintaining the correct version of the Configuration Manager client is crucial for ensuring compatibility with the site server and leveraging the latest features and fixes. Administrators typically manage client upgrades through controlled processes, such as phased rollouts or client piloting, to minimize disruption and test compatibility. However, sometimes unexpected behavior can lead to uncontrolled client reinstallation or upgrade cycles, which can negatively impact both the managed devices and the Configuration Manager infrastructure itself.

Understanding the Issue: Frequent Client Reinstallation¶

In older environments utilizing Microsoft System Center 2012 Configuration Manager or System Center 2012 R2 Configuration Manager, a specific issue could arise that resulted in clients unexpectedly reinstalling themselves on a recurring schedule. This problem becomes particularly noticeable and problematic when these environments are upgraded to a newer Configuration Manager version, such as a Configuration Manager current branch or long-term servicing branch (LTSB) build, but the clients are not immediately upgraded through the standard, controlled process. The core of the problem lies in a mechanism intended to ensure client installation resilience.

When the initial installation attempt of the Configuration Manager client (performed by CCMSetup.exe) fails for any reason, the installation process is designed to be resilient. To handle transient issues or dependencies that might be missing, CCMSetup registers a scheduled task. The purpose of this task is to periodically retry the client installation process until it succeeds. This is generally a helpful feature, ensuring that clients eventually get installed even if there are temporary network issues or other short-lived problems during the initial deployment phase.

The problem discussed here occurs because, in specific circumstances within System Center 2012 and 2012 R2, the scheduled task created for retrying the installation was not registered in the expected location within the Windows Task Scheduler library. Due to this misplacement, even after the client installation subsequently succeeds on a later retry, the CCMSetup process that should normally clean up and delete this retry task is unable to find it. The task persists, configured to run repeatedly.

Symptoms of the Reinstallation Loop¶

The most prominent symptom of this issue is the observable behavior of the Configuration Manager client on affected machines. Clients will repeatedly execute the CCMSetup.exe process. This activity typically occurs on a fixed interval, which is observed to be every five hours in the context of this specific bug. This frequent reinstallation is often logged within the ccmsetup.log file located on the client machine, providing a clear indication of the recurring installation attempts.

Beyond the log files, administrators can directly identify the root cause by inspecting the Windows Task Scheduler on the affected client machines. Navigating through the Task Scheduler Library folders will reveal a specific scheduled task that should not be present after a successful installation. The task is typically named Configuration Manager Client Retry Task. Crucially, the task will be found in an incorrect folder path within the Task Scheduler hierarchy. Instead of residing in the standard location where Configuration Manager tasks are typically placed, it will be found in a deeper, incorrect subfolder.

Furthermore, in scenarios where the Configuration Manager infrastructure has been upgraded to a Current Branch or LTSB version while the clients remain on the older 2012/R2 version, this recurring reinstallation task triggers an uncontrolled client upgrade. Each time the task runs CCMSetup, the client process connects to the upgraded infrastructure (e.g., a Management Point or Distribution Point). The updated infrastructure provides the newer client source files, prompting CCMSetup to perform an upgrade to the current Configuration Manager version. This means clients are upgraded outside the administrator’s planned schedule and potentially bypasses client piloting stages, leading to unexpected version deployments across the environment every five hours.

Deep Dive into the Cause: The Misplaced Scheduled Task¶

The fundamental cause of this persistent reinstallation loop is a defect in the way CCMSetup.exe registered its retry task in System Center 2012 and System Center 2012 R2 under certain conditions. Windows Task Scheduler organizes scheduled tasks within a library, using folders to categorize and manage them. Standard practice dictates that applications create their tasks within logical folder structures, often under \Microsoft\ and then a specific application name folder. For Configuration Manager, the intended location for tasks is typically \Microsoft\Configuration Manager.

However, due to the bug, the Configuration Manager Client Retry Task was sometimes erroneously created in the path \Microsoft\Microsoft\Configuration Manager. Notice the duplicated \Microsoft\ segment in the path. This seemingly minor path discrepancy has significant consequences. When a standard, successful CCMSetup process completes, it includes steps to locate and unregister (delete) the retry task it previously created. However, the cleanup routine is hardcoded or configured to look for the task in the expected location, \Microsoft\Configuration Manager. Since the task was placed in the incorrect location, \Microsoft\Microsoft\Configuration Manager, the cleanup process fails to find the task and consequently leaves it behind.

Left behind, the task continues to execute according to its schedule, triggering a new CCMSetup run every five hours. This explains the recurring nature of the reinstallation. This issue is not necessarily triggered by every client installation failure in 2012/R2, but it was a potential outcome that could lead to this problematic state. Once the infrastructure is upgraded to a newer Configuration Manager branch, the effect of this orphaned task changes from merely retrying an installation to forcing an upgrade, as the client source files available from the updated infrastructure are for the newer version.

Visualizing the Problem¶

We can represent this issue with a simple diagram showing the task creation and deletion process:

mermaid graph TD A[Initial CCMSetup Failure] --> B{Create Retry Task}; B --> C[Task Created in \\Microsoft\\Microsoft\\Configuration Manager]; C --> D{Retry Task Runs Every 5 Hours}; D --> E[CCMSetup Runs Again]; E --> F{CCMSetup Succeeds}; F --> G{Attempt Task Cleanup}; G --> H{Look for Task in \\Microsoft\\Configuration Manager}; H -- Task Not Found --> I[Task Remains in \\Microsoft\\Microsoft\\Configuration Manager]; I --> D; {{ Loop }} E -- Infrastructure Upgraded --> J[CCMSetup Finds Newer Client Source]; J --> K[Client Upgraded]; K --> F; {{ Loop Continues, Forcing Upgrades }}
This diagram illustrates how the task, once created in the wrong location (C), is not found during the cleanup attempt (H) after a successful installation (F), leading to the task persisting (I) and continuing to run (D), which in turn causes CCMSetup to run again (E), perpetuating the cycle. When the infrastructure is upgraded (E leads to J), the same loop then forces repeated client upgrades (K).

Impact of Frequent Client Reinstallations¶

The continuous reinstallation of the Configuration Manager client, even if successful each time, is far from harmless. It imposes unnecessary load on both the client machines and the Configuration Manager infrastructure. On the client side, running CCMSetup every five hours consumes CPU, memory, and disk I/O resources. While a single installation might not be resource-intensive, this frequent activity can contribute to performance degradation, especially on older or less powerful machines. It can also potentially interfere with other scheduled tasks or user activities.

For the Configuration Manager infrastructure, these repeated client reinstallation/upgrade attempts generate significant network traffic as clients download the setup files from Distribution Points. Management Points experience increased load from clients registering or updating their information after each apparent “installation” cycle. Database activity also increases to process this repetitive client status information. In large environments with many affected clients, this cumulative impact can strain the infrastructure, potentially affecting the performance and responsiveness of the Configuration Manager system for all clients, not just the affected ones.

Furthermore, this uncontrolled upgrade behavior bypasses the standard client management processes. Administrators lose control over which clients are upgraded and when. This can disrupt planned client piloting phases, where a small group of clients is tested with a new version before broader deployment. It also makes troubleshooting difficult, as client versions might change rapidly and unpredictably across the environment. Compliance reporting based on client version can become inaccurate or challenging to maintain. Essentially, the issue undermines the administrator’s ability to manage the client lifecycle effectively.

Workarounds to Address the Issue¶

Fortunately, there are effective workarounds to stop the recurring reinstallation loop. The core principle of these workarounds is to locate and remove the misplaced Configuration Manager Client Retry Task from the affected client machines. Two primary methods can be employed: manual removal for individual machines or automated removal via scripting for widespread application.

Workaround 1: Manual Task Removal¶

For situations involving only a few affected clients, or as a method to verify the issue on a specific machine, manually removing the scheduled task using the Windows Task Scheduler interface is a viable option. This method requires interactive access to the client machine and administrative privileges.

Here are the steps for manual removal:

1. Log on to the affected client computer with an administrator account.
2. Open the Task Scheduler. This can typically be found by searching for “Task Scheduler” in the Start menu or by running taskschd.msc.
3. In the left-hand pane of the Task Scheduler window, navigate through the Task Scheduler Library hierarchy. Expand Task Scheduler Library.
4. Navigate to the path where the misplaced task is located: Expand Microsoft, then expand the second Microsoft folder within it, and finally select the ConfigurationManager folder. The full path you are navigating to is Task Scheduler Library\Microsoft\Microsoft\Configuration Manager.
5. In the central pane, you should see a list of tasks located in this folder. Look for the task named Configuration Manager Client Retry Task.
6. Right-click on Configuration Manager Client Retry Task and select Delete.
7. Confirm the deletion when prompted.

Once deleted, the scheduled task will no longer run, stopping the automatic reinstallation cycle. This manual process must be repeated on every affected client machine.

Workaround 2: Automated Task Removal via Scripting¶

Manually addressing the issue on a large number of computers is impractical. For enterprise environments, deploying a script to automatically locate and remove the misplaced task is the recommended approach. This method leverages the power of automation to resolve the issue efficiently across many machines. PowerShell is an excellent tool for this task, given its capabilities for managing Windows systems and interacting with the Task Scheduler.

A simple PowerShell script can be created to achieve this. The script needs to target the specific task name and path and then unregister it.

Example PowerShell Commands:

# Define the task name and the incorrect folder path
$TaskName = "Configuration Manager Client Retry Task"
$TaskPath = "\Microsoft\Microsoft\Configuration Manager" # Note the duplicated Microsoft folder

# Check if the task exists in the incorrect path
# The -ErrorAction SilentlyContinue prevents the script from stopping if the task doesn't exist
$Task = Get-ScheduledTask -TaskName $TaskName -TaskPath $TaskPath -ErrorAction SilentlyContinue

# If the task is found, unregister it
if ($Task) {
    Write-Host "Found task '$TaskName' in path '$TaskPath'. Attempting to unregister..."
    try {
        Unregister-ScheduledTask -TaskName $TaskName -TaskPath $TaskPath -Confirm:$false
        Write-Host "Task '$TaskName' successfully unregistered."
    } catch {
        Write-Error "Failed to unregister task '$TaskName'. Error: $($_.Exception.Message)"
    }
} else {
    Write-Host "Task '$TaskName' not found in path '$TaskPath'. No action needed."
}

This script first defines the task name and the incorrect path. It then attempts to retrieve the task from that specific path. If the task is found ($Task is not null), it proceeds to unregister (delete) the task using Unregister-ScheduledTask. The -Confirm:$false parameter is used to prevent the command from prompting for confirmation on each task deletion, making it suitable for automated execution. Error handling is included using a try-catch block to report any issues during deletion.

How to Deploy the Script:

This PowerShell script can be deployed to target client machines using various methods available in a Configuration Manager environment or other management tools:

1. Configuration Manager Package and Program: Create a package containing the PowerShell script. Configure a standard program that executes the script using powershell.exe -ExecutionPolicy Bypass -File YourScript.ps1. Deploy this program to a collection of potentially affected clients. Configure it to run with administrative rights.
2. Configuration Manager Compliance Settings: Create a Configuration Item that uses a PowerShell script to detect the presence of the task in the incorrect path. If detected, a remediation script (the unregister command) can be run to delete the task. This method allows for continuous monitoring and remediation.
3. Group Policy Startup Script: Deploy the PowerShell script as a computer startup script via Group Policy. This ensures the script runs with system privileges when the computer starts.
4. Other Management Tools: If you use other endpoint management tools or scripting frameworks, you can adapt the PowerShell script for deployment using those systems.

Using an automated method ensures that the task is removed efficiently across the entire environment, stopping the reinstallation loop and preventing uncontrolled client upgrades. It is advisable to target this script only to machines running System Center 2012/R2 clients or machines known to have previously run them and potentially encountered this issue before upgrading to the Current Branch/LTSB infrastructure.

The Resolution in Newer Versions¶

It is important to note that Microsoft addressed this specific issue in later versions of Configuration Manager. In Configuration Manager current branch version 1602 and subsequent versions, as well as in Configuration Manager LTSB version 1606, the CCMSetup process was fixed. The updated CCMSetup correctly registers the client retry task in the proper location (\Microsoft\Configuration Manager). Crucially, it also correctly finds and removes this task upon successful client installation.

This fix means that environments running these newer site versions and deploying clients using their respective CCMSetup binaries will not encounter this specific misplaced task and the resulting reinstallation loop originating from this bug. This highlights the importance of keeping the Configuration Manager infrastructure updated to benefit from bug fixes, performance improvements, and new features. While workarounds are necessary to fix the issue on clients affected by the bug in older CCMSetup versions, upgrading the site to a fixed version prevents new clients from falling into this state.

Even after applying the workaround script, administrators should continue to follow standard Configuration Manager client upgrade procedures when moving clients from older versions to newer ones to ensure a smooth transition and maintain control over the client lifecycle.

General SCCM Client Troubleshooting Tips¶

While the specific issue discussed here relates to a misplaced scheduled task, troubleshooting Configuration Manager client issues often involves examining various components and logs. Here are some general tips for troubleshooting SCCM client problems:

1. Check CCMSetup.log: This is the primary log file for the client installation process. It provides details about command-line parameters used, installation progress, errors encountered, and return codes. It’s the first place to look when CCMSetup fails or runs unexpectedly.
2. Review Client Logs: After successful installation, other client logs (located in C:\Windows\CCM\Logs) provide insights into specific client components like policy retrieval (PolicyAgent.log), software distribution (CAS.log, ContentTransferManager.log, Distmgr.log), software updates (WUAHandler.log, UpdatesDeployment.log), and client health (CcmEval.log).
3. Verify Prerequisites: Ensure that the client machine meets the necessary operating system requirements, has the correct version of .NET Framework, WMI is healthy, and BITS is enabled and functioning.
4. Check Network Connectivity and Boundaries: The client needs to communicate with Management Points and Distribution Points. Verify network connectivity, name resolution, and ensure the client is correctly assigned to a boundary group allowing it to find local resources.
5. Examine WMI Health: Configuration Manager relies heavily on Windows Management Instrumentation (WMI). WMI corruption can cause numerous client issues. Tools like the WMI Diagnosis Tool or simple winmgmt /verifyrepository commands can help diagnose WMI problems.
6. Review Site Server and Role Logs: Sometimes, client issues stem from problems on the site server or specific roles (like Management Points, Distribution Points). Check relevant server logs to identify potential backend issues affecting client communication or functionality.
7. Utilize Client Notification and Client Health: Configuration Manager’s built-in client notification features (e.g., “Check Client Status,” “Notify Client”) and the Client Health evaluation can help identify clients with issues and attempt automatic remediation.

While these general tips are useful, the specific reinstallation loop discussed in this article is uniquely identified by the presence of the orphaned scheduled task and the recurring CCMSetup activity at a specific interval.

Summary Table¶

Feature	Description
Issue	Recurring client reinstallation/upgrade loop every 5 hours.
Affected Versions	System Center 2012 Configuration Manager Client, System Center 2012 R2 Configuration Manager Client.
Cause	CCMSetup creates a retry task in the incorrect Task Scheduler path (\Microsoft\Microsoft\Configuration Manager) which is not deleted after installation succeeds.
Symptoms	CCMSetup.log shows frequent installation activity; Configuration Manager Client Retry Task exists in \Microsoft\Microsoft\Configuration Manager in Task Scheduler. If infrastructure is upgraded, clients force upgrade to the new version.
Impact	Increased resource usage on clients/servers, network traffic, uncontrolled client upgrades, bypasses piloting.
Workaround 1	Manually delete the task from \Microsoft\Microsoft\Configuration Manager using Task Scheduler.
Workaround 2	Deploy a script (e.g., PowerShell) to automatically find and unregister the task from the incorrect path.
Resolution	Fixed in Configuration Manager current branch version 1602+ and LTSB version 1606.

This table provides a concise overview of the problem and its solutions.

Conclusion¶

The Configuration Manager client reinstallation loop caused by a misplaced scheduled task in System Center 2012/R2 environments can be a frustrating issue, leading to unexpected client behavior, uncontrolled upgrades, and unnecessary load on infrastructure. Understanding the root cause – the failure of CCMSetup to clean up a retry task created in an incorrect Task Scheduler folder – is key to addressing it. While manual removal is feasible for a small number of clients, automating the deletion process via scripting is essential for resolving this issue across a large enterprise. The good news is that this specific bug has been resolved in newer versions of Configuration Manager, emphasizing the benefits of keeping your management infrastructure updated.

Have you encountered this specific Configuration Manager client reinstallation loop in your environment? How did you identify and resolve the issue? Share your experiences and tips in the comments below! Your insights can help the broader community grappling with similar challenges in managing Configuration Manager clients.