Hi,

In our Device list, we've got a group of computers showing as "Inactive" where the Last Logon Timestamp field shows as newer than the Last Activity (with the Last Activity being the same date and approximately the same time, for this particular batch of computers).  Has anyone seen this previously ?

Specifiying a client push (with "Uninstall existing Configuration Manager client before the client is installed") doesn't help.  Most of the existing and new deloyments are showing computers with the normal "Active" Client Activity status.

Any logs that we should check ?

Thanks

By default, the client requests a new policy every 60 min, sends a heartbeat DDR every 7 days, and reports hw/sw inventory every 7 days. On the client computer check the following log files (%windir%\ccm\logs):

- Inventory log: should have information about heartbeat DDR, hw/sw inventory)

- PolicyEvaluator.log should give you information when a new policy has been applied or you see that no changes are necessary

check this link for more troubleshooting - http://blogs.technet.com/b/configurationmgr/archive/2009/08/10/troubleshooting-issues-where-clients-are-not-reporting.aspx

HI ,

If the SCCM Host server/ Site have port 443 open for all clients than you need to check the Client system. 

Go to control Panel > Navigate to "Configuration Manager" > Open > Go to "Actions" > Select the action from List > Click on "Run Now".

Check your luck now. 

If the SCCM Host server/ Site have port 443 open for all clients than you need to check the Client system. 

This is only true if running https; otherwise (http) it would be port 80 (given that the defaults are used).

Yes, we would be using the default, which would be Port 80.  We've been testing a web filtering appliance, which could account for HTTP traffic being blocked on some subnets, but not consistently.  Because if you have Internet Explorer open, HTTP traffic will be allowed through on the web appliance via AD single sign-on.

Does the SCCM agents communicate via FQDN or IP or both ? 

To test, we'll make exceptions on our web appliance for traffic going to the FQDN of our SCCM server.

Thanks

Does the SCCM agents communicate via FQDN or IP or both ? 

SCCM basically collect the client details using LDAP Configured on the ACCM Primary Management Server. And also lookup the FQDN while check the Client heartbeat. 

Make sure you have any Antivirus / Firewall / IPS enable on the SCCM host or Client. Disable all these following and try .

Before you start working check the "Default Client Settings" under "Administration" . 

After exempting port 80 on our web filtering appliance, we had to push an agent re-install for the affected systems to get them to show as "Active".  We had > 150 "Inactive", but we're only down to 117 "Inactive" clients.  Looks like they're stuck as "Inactive", it's been > 2 months, only noticed the problem recently, perhaps we've gone over a threshold setting ?  The affected clients can find the correct AD site, Site Code, MP (just one), and the BITS service is started.

Looking at the troublehshooting tip above, the LocationServices.log has the Failed statement below:

<![LOG[Failed to send management point list Location Request Message to SC2012.corp.mcelhanney.com]LOG]!><time="03:18:55.496+420" date="08-11-2015" component="LocationServices" context="" type="2" thread="1260" file="lssecurity.cpp:5558">
<![LOG[Current AD site of machine is SRY]LOG]!><time="03:18:55.653+420" date="08-11-2015" component="LocationServices" context="" type="1" thread="1260" file="lsad.cpp:770">

and the ClientIDManagerStartup.log has the following Failed statement:

<![LOG[RegTask: Failed to send registration request. Error: 0x87d00231]LOG]!><time="16:06:58.809+420" date="08-11-2015" component="ClientIDManagerStartup" context="" type="3" thread="1260" file="regtask.cpp:1483">
<![LOG[[RegTask] - Sleeping for 15360 seconds ...]LOG]!><time="16:06:58.809+420" date="08-11-2015" component="ClientIDManagerStartup" context="" type="1" thread="1260" file="regtask.cpp:1420">

• Edited by APang.F1 7 hours 10 minutes ago

After exempting port 80 on our web filtering appliance, we had to push an agent re-install for the affected systems to get them to show as "Active".  We had > 150 "Inactive", but we're only down to 117 "Inactive" clients.  Looks like they're stuck as "Inactive", it's been > 2 months, only noticed the problem recently, perhaps we've gone over a threshold setting ?  The affected clients can find the correct AD site, Site Code, MP (just one), and the BITS service is started.

Looking at the troublehshooting tip above, the LocationServices.log has the Failed statement below:

<![LOG[Failed to send management point list Location Request Message to SC2012.corp.mcelhanney.com]LOG]!><time="03:18:55.496+420" date="08-11-2015" component="LocationServices" context="" type="2" thread="1260" file="lssecurity.cpp:5558">
<![LOG[Current AD site of machine is SRY]LOG]!><time="03:18:55.653+420" date="08-11-2015" component="LocationServices" context="" type="1" thread="1260" file="lsad.cpp:770">

and the ClientIDManagerStartup.log has the following Failed statement:

<![LOG[RegTask: Failed to send registration request. Error: 0x87d00231]LOG]!><time="16:06:58.809+420" date="08-11-2015" component="ClientIDManagerStartup" context="" type="3" thread="1260" file="regtask.cpp:1483">
<![LOG[[RegTask] - Sleeping for 15360 seconds ...]LOG]!><time="16:06:58.809+420" date="08-11-2015" component="ClientIDManagerStartup" context="" type="1" thread="1260" file="regtask.cpp:1420">

• Edited by APang.F1 Wednesday, August 12, 2015 12:35 AM

After exempting port 80 on our web filtering appliance, we had to push an agent re-install for the affected systems to get them to show as "Active".  We had > 150 "Inactive", but we're only down to 117 "Inactive" clients.  Looks like they're stuck as "Inactive", it's been > 2 months, only noticed the problem recently, perhaps we've gone over a threshold setting ?  The affected clients can find the correct AD site, Site Code, MP (just one), and the BITS service is started.

Looking at the troublehshooting tip above, the LocationServices.log has the Failed statement below:

<![LOG[Failed to send management point list Location Request Message to SC2012.corp.mcelhanney.com]LOG]!><time="03:18:55.496+420" date="08-11-2015" component="LocationServices" context="" type="2" thread="1260" file="lssecurity.cpp:5558">
<![LOG[Current AD site of machine is SRY]LOG]!><time="03:18:55.653+420" date="08-11-2015" component="LocationServices" context="" type="1" thread="1260" file="lsad.cpp:770">

and the ClientIDManagerStartup.log has the following Failed statement:

<![LOG[RegTask: Failed to send registration request. Error: 0x87d00231]LOG]!><time="16:06:58.809+420" date="08-11-2015" component="ClientIDManagerStartup" context="" type="3" thread="1260" file="regtask.cpp:1483">
<![LOG[[RegTask] - Sleeping for 15360 seconds ...]LOG]!><time="16:06:58.809+420" date="08-11-2015" component="ClientIDManagerStartup" context="" type="1" thread="1260" file="regtask.cpp:1420">

• Edited by APang.F1 Wednesday, August 12, 2015 12:35 AM

Routed traffic going to the SCSM 2012 R2 server around our web appliance