- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
A few years ago, we published a detailed guide on managing inactive clients in SCCM 2012. With two SCCM Current Branches (1511 and 1602) under our belt, now is the perfect time to revisit this topic, learn some new tricks, and ensure a healthy SCCM client environment. Let’s start this guide by finding out how clients become inactive and learn about the changes introduced in SCCM 1602.
Inactive vs active vs online clients in SCCM
Clients will fall into either an inactive or active state. If you remember the SCCM 2007 world, you can appreciate the simplicity of these two categories. By default, a client is marked as inactive if they haven’t completed one of the following within seven days:
- Requested a policy update
- Sent a hardware inventory
- Sent a heartbeat message
Essentially, a client will become inactive if it fails to do all three of the above tasks within a week. Further down in this guide, we’ll see how to adjust these settings.
The hardware inventory cycle action on a SCCM client
SCCM 1602 introduces a slightly different (but still relevant) check known as Client Online Status. This new feature provides near real time indications on the machine’s connection to its assigned management point.
Online vs Offline icons in SCCM 1602
An online machine will have a green checkmark over the computer icon. This can be seen in Assets and Compliance\Devices or when looking at members of a device collection.
Changing inactive client settings in SCCM
When you think about it, SCCM is a huge piece of software. In one console, you’re managing OS upgrade, app deployments, updates, etc. Finding your way around this console can be a bit frustrating.
This is particularly true for the client status settings. If you want to change inactive client settings in your SCCM infrastructure, you actually have to navigate to Monitoring\Overview\Client Status. You can then right click on Client Status and select Client Status Settings. You should now see something similar to the screenshot below:
The default client status settings in SCCM 2012 and SCCM 1602
If your environment is very mobile, you may want to loosen up these evaluation periods. For example, you could change the default 7-day value to 14 days. Environments with predictable client schedules could tighten up this schedule. Generally, 3 days is the tightness functional schedule when weekends/holidays are taken into account.
When you expand the Client Status node, you can see a detailed view of the client health in your environment. Charts are available for Client Activity, Client Check, and Client Deployment. In the general statistics pane, you can target specific collections and see the top client check errors that were reported. By default, the All Desktop and Server Clients collection is targeted.
The top client errors as reported in the SCCM console.
By default, this information is only refreshed once per day. You can get an up-to-date view by right clicking on Client Status (in the navigation pane on the left) and selecting Refresh Client Status. You can also configure the client status to update on a more regular basis. To do this, select the Schedule Client Status Update button in the ribbon or in the menu when right clicking on the Client Status node.
Automatic client remediation in SCCM Current Branch
SCCM 2012 and above have two main methods to repair SCCM clients built in. The first occurs on the client OS (which can include servers). When the SCCM client is installed, a scheduled task named Configuration Manager Health Evaluation is created on the machine.
The Health Evaluation task for SCCM client remediation
This task calls the ccmeval.exe (located in %WINDIR%\CCM). When desired, CCMeval can be manually executed from an administrative command prompt. A log file of the client health evaluation can be found in %WINDIR%\CCM\Logs. You can view CcmEval.log in CMTrace or notepad. The log file is cumulative.
If any problems are found with the SCCM client or any dependencies, CCMeval will attempt to repair those problems and will submit a report. At times, you may wish for CCMeval simply to report the problem and not attempt a fix. To disable automatic client remediation, change the following registry entry from FALSE to TRUE: HKEY_LOCAL_MACHINE\Software\Microsoft\CCM\CcmEval\NotifyOnly.
Our second client remediation method is server driven. It requires automatic site-wide client push installation to be enabled. You can see if this is enabled by navigating to Administration\Overview\Site Configuration\Sites. Select your site and then choose Client Installation Settings from the ribbon. Finally, select Client Push Installation from the drop down menu.
This site is enabled for automatic client push installations
In the same view, select Site Maintenance from the ribbon. Double click on the Clear Install Flag maintenance task. When this task runs on your site server, it will remove the install flag from stale client records. You can see an example in the screenshot below:
A more aggressive server initiated client repair task
This task relies on reliable heartbeat records from clients. It’s very important that clients send heartbeat discovery data at an interval less than the client rediscovery period that you see in the screenshot above. For example, the heartbeat discovery method should be set to a value less than 14 days.
Heartbeat discovery is set at 1 day in this environment
When a client goes 14 days without sending a heartbeat, the install flag is cleared. The site server is then able to push the client installation at the next available time.
Subscribe to 4sysops newsletter!
SCCM Current Branch does a really good job of managing clients and repairing itself in the event of a failure. However, all these methods still rely on the SCCM infrastructure in some way. If you want to add another layer of protection to your environment, you can still use alternative methods, such as those mentioned in the managing inactive clients in SCCM 2012 guide.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
Good day
I am busy designing for a client and I am wondering – is it possible to install the client as a first install?
In other words :
1 can I complete the CAS install on base 1511 and upgrade and
2 then do the database move to a SQL always on and
3 Primary Site install on 1602 then
4 deploy the clients?
Or do I have to this the long hard way?
1 First do I have to do the base 1511 completely (meaning must I first do a full install of CAS then Primary site then ) including clients,
2 then do the of the Application upgrade and
3 move SCCM databases to SQL Always on availability group.
4 and thee^n – only after that – do I then do the upgrades?
You can wait until everything is done and then deploy the new client version.
Set Heartbeat to “LESS” often than Client Rediscovery Period? I think that is poorly written if what they mean is MORE frequently. Please confirm that this is bad english or they really mean to set it to run less often than the Client Rediscovery Period. On the Clear Install Flag task it is written poorly also but suggests that The heartbeat should be sent more often than the period indicated in the Clear Install Flag task. Please advise. Thanks,
Sorry for the confusion, Paddy. The heartbeat setting value should be a smaller number than the Client Rediscovery Period. This ensures that a heartbeat is detected before the client could potentially be removed from SCCM. The description before and after the heartbeat discovery properties picture provide another example.
So, applying the server side changes should essentially do the following:
Server checks for client heartbeats every day
Server will push a client install to a workstation or server that does not heartbeat back
Every 14 days, Inactive flags will be cleared
Do I have that right?
Mostly correct.
Clients send a client heartbeats every day
After 14 days of no heartbeat, server marks client as inactive.
Server will push a client install to a workstation or server that does not heartbeat back
Every 14 days, Inactive flags will be cleared
I have to agree with Paddy, the guidance as written on the Clear Install Flag and Heartbeat Discovery Properties sheets is ambiguous at best. Potentially adding to confusion, the Client Rediscovery interval setting is in days, and Heartbeat Discovery schedule can be configured in hours, days or weeks. A valid configuration could have a larger Heartbeat Discovery schedule number (e.g. 23 hours) than Client Rediscovery period number (e.g. 14 days).
Clear Install Flag Properties
“If a client installation method is enabled, set this period to more than the client heartbeat discovery interval. This prevents needlessly reinstalling clients.”
Heartbeat Discovery Properties
“If automatic site-wide client push installation is enabled, configure the heartbeat schedule to run less frequently than the client rediscovery period for the Clear Install Flag site maintenance task. This prevents Configuration Manager from unnecessarily reinstalling clients.”
I think this guidance could be improved by re-writing something like, “If a client installation method is enabled, set _Client Rediscovery period (days)_, above, to an interval longer than client heartbeat discovery frequency. For example, you might set _Client Rediscovery period_ to 14 days and Heartbeat Discovery schedule to 23 hours. This prevents needlessly reinstalling clients.”
“If automatic site-wide client push installation is enabled, set the Heartbeat Discovery schedule to run more frequently than the Client Rediscovery period for the Clear Install Flag site maintenance task. For example, you might set Heartbeat Discovery schedule to 23 hours and Client Rediscovery period to 14 days. This prevents Configuration Manager from unnecessarily reinstalling clients.”
method was clear and this advice is still useful years late. thanks moody!