You take all your computer accounts in Active Directory, filter out the old records (I use a cut-off of 30 days), and then compare it to your SMS or SCCM database.
(I showed you how to export the LastLogin date from Active Directory here).
I love Active Directory, as you can use it as an “Authoritative Source”. If the computer is not in Active Directory then it won’t be able to use AD resources, such as the corporate intranet or email or network printing; if your sysadmin is particularly clever.
You’re going to have 3 cases where computers aren’t reporting into SMS/SCCM, but are in Active Directory.
1. SMS/SCCM client is not installed
This is the easy to detect. You can see it in the Active Directory but it’s not in your SMS/SCCM database. Simple fix, install the SMS/SCCM client.
2. SMS/SCCM client is installed but has never reported.
Investigate and resolve the issue. If there are lots of clients not reporting, it might be a site boundary issue.
3. SMS/SCCM client is installed but has stopped reporting.
The client has become broken. When I last had this problem, it was WMI based and I wrote a custom script to repair it. With mixed results.
The way I tell if a client has stopped reporting?
I subtract the SMS last contact date from the Active Directory LastLogin date. If the difference is greater than 14 days, it’s likely the SMS client has a problem.
You could fix these broken clients manually, but a better way would be to have something in your users logon script. Which runs at user logon and just detects and fixes common SMS/SCCM problems. Which someone has already done. You can find it here:
SMS 2003 Client Health Startup Script v4.19
- 30 days? Well people go on holidays for 4 weeks, and their computer may be turned off…
- Corey Hynes suggested at TechEd 2005 that you should automate repeative tasks with scripts. He was right you know.
Microsoft Systems Management Server 2003
Microsoft System Center Configuration Manager 2007