There are plenty of posts with users getting a successful installation of the SCCM client on a system, but it showing Client = 0 in the console.  Generally this is due to not finding a management point (boundary issues), duplicate GUIDs, service not running, etc.  However I have a client where those things appear to be fine, so I'm unsure what I'm missing.  The client was pushed to the system (Server 2008 R2 Standard 64-bit) automatically via Client Push Installation and is currently at version 4.00.6487.2000 (the base install).  The properties for installation are set to the following:

SMSSITECODE=<SiteCode> FSP=<FQDNofFSP> RESETKEYINFORMATION=TRUE SMSSLP=<FQDNofSLP>

There are no errors that I can see in any of the following logs:

ClientIDManagerStartup.log: Reg Task: Client is registered, exiting.
LocationServices.log: Current AD site of machine is <CorrectSite>
ClientLocation.log: Current Management Point is <FQDN of correct MP> with version 6487...

Also, the SMS Agent Host service is installed and running.  The server has also been rebooted, and has been up for several days.  Heartbeat Discovery is set at 1 day and the Discovery Data Collection Cycle has been manually run just to be sure.  Relevant components in the ConfigMan Properties show Installed/Enabled and I even see configuration baselines shown on the Configurations tab.  The GUID is also unique in the environment and shows the correct NetBIOS name, OS, and client version when I query it in the database (Active=1, Obsolete=0, Client=0).

It's really strange and I'm not sure what I'm missing.  My assumption is that I can simply uninstall and then do a manual installation which may fix it, but I'd like to see if I can dig deeper and find the real cause of the issue.

Hi Jason,

Have you checked the InventoryAgent.Log for errors. If not trigger the Discovery data collection cycle and check the log for errors.

Regards,

Manohar Pusala

Hi Jason,

Have you checked the InventoryAgent.Log for errors. If not trigger the Discovery data collection cycle and check the log for errors.

Regards,

Manohar Pusala

InventoryAgent.Log doesn't have any errors.  I had already run a DDC cycle without any errors previously.  I re-ran it just for giggles and still no errors.  (Looked at {00000000-0000-0000-0000-000000000003} which is DDC).  It states in the log:

Inventory: Successfully sent report. Destination:mp:MP_DdrEndpoint, ID: {B15A6CC5-E2EA-4E15-B5D8-9F2A71F03F00}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted

It really sounds like a duplicate entry especially if there is no errors in the logs you can find, try updating and refreshing your all systems collection and searching for something else that's unique in the hardware like its network card mac address to see if you get two hits.

I guess you like a challenge :), if it was me I would be doing a clean uninstall of the client and reinstall to save time and then if that didn't solve it start digging deeper.

It really sounds like a duplicate entry especially if there is no errors in the logs you can find, try updating and refreshing your all systems collection and searching for something else that's unique in the hardware like its network card mac address to see if you get two hits.

I guess you like a challenge :), if it was me I would be doing a clean uninstall of the client and reinstall to save time and then if that didn't solve it start digging deeper.

Updated and refreshed the All Systems collection (verified no little hour glass on the icon).  Still showing no client.

Looking in the SCCM Database directly I did a query on the Hardware ID from v_R_System and only found one match.  Also queried on Name0, NetBIOS_Name0, and SMS_Unique_Identifier0 with no duplicates found.  The MAC address didn't return any results, so it's not in the DB it seems.  The SMS Unique ID also matched what is in the SMSCFG.ini file in the C:\Windows directory on the server.

Any other thoughts? (Besides the obvious of reinstalling the client :)).  Sure is an odd one.

What discovery methods are you using? Could it be a stale record from AD?

What discovery methods are you using? Could it be a stale record from AD?

I have the following active discovery methods:

AD System Group: Every 4 hours with 5 min Delta discovery

AD Security Group: Every 4 hours with 5 min Delta discovery

AD System Discovery: Every 4 hours with 5 min Delta discovery

AD User Discovery: Every 1 day with 5 min Delta discovery

Heartbeat Discovery: Every 1 Day

In looking at the resource properties for the system I can see that MP_ClientRegistration, SMS_AD_SYSTEM_DICOVERY, and SMS_AD_SYSTEM_GROUP_DISCOVERY have all ran within the past 3 days.  I am not seeing any details that the heartbeat discovery has reached the primary site, however, as shown above, I have not seen any errors in the logs when this was manually run from the clients control panel.  Perhaps it's getting stuck somewhere.  Any suggestions on troubleshooting heartbeat discoveries not making it all the way back to the DB (other than what has been shown above)?

Is there any firewall configured in this client machine?

You may check the following article to see if it helps:

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

Is there any firewall configured in this client machine?

You may check the following article to see if it helps:

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

That's a good article.  I have the server open now and I can see the Windows Firewall is set to off in server manager.  This is controlled in group policy.  Symantec Endpoint Protection 12.x is installed, but only has Virus/Spyware, and PTP running (no firewall).  I don't believe anything else could be blocking communications from the server.  Looking at the bullet points from the article here is what I can see (the one thing that stands out to me has been bolded):

Systems NOT on the network: It's on and domain joined (getting policy updates so I know that's good)

Stale Entries: not in this case

Agent Boundaries: Looking fine, no overlap

Unable to get the site code: Site code assignment has occurred and is the correct site

Client not installed in the Agent: No reference to the affected system in the ccm.log file on the primary site server.  This log goes back awhile, so I would of expected to see something here, could be an issue, but I see no errors.  CCR count in queue "Incoming" always seems to show 0, so maybe this isn't working?

Name Resolution issues: Ping to primary site server works fine and resolves to correct IP

Behind a firewall: Nope

Multiple GUIDs: Nope

MP not working: Seeing "Call to HttpSendRequestSync succeeded for port 80 with status code 200, text:OK" in MPControl.log.  So the MP seems good.  No Errors in LocationServices.log and it's getting the correct AD Site, but there is a warning for "Unknown task LSProxyMPModificationTask in non-quarantine - ignoring."

BITS Service: Started

MPCert/MPList URLs: Both work

Unable to download policy/WMI: WMI seems good, I can open the WMI Control Properties and see it's successfully connected, as well as query from PowerShell.  Also, it's a new server build.

Server Processing DDRs: No errors in ddr.log like KB886124.  KB891584 seems to only apply to SMS2003, and the system is in the same time zone as the primary and secondary site servers.  KB960634 doesn't seem to apply since it's for SP1 and i'm on SP2

In addition to the above, I followed the steps to troubleshoot discovery from this article:

http://blogs.technet.com/b/sudheesn/archive/2011/02/01/troubleshooting-part-v-heartbeat-discovery.aspx

Scheduler.log shows "Sending message for schedule 'Machine/{...00003}'..."

SMSCliUI.log shows "Site is in mixed mode..." and "Perform Action: Discovery Data Collection Cycle...{...103}..."

InventoryAgent.log shows "Inventory: Action completed" for ..003 action.

Nothing in MP_Ddr.log on the MP for this client, but it only goes back to yesterday so it likely cycled out of the log by now.  Any way to resend this and check?  Not seeing any errors though.

DDM.log shows that it's set to synchronize NCF files at startup