Condividi tramite

ClientKeyData table gets corrupted on central site server

  • Articolo

 

Here’s an issue I’ve now seen on two different customers. They’re both running a 3-tier hierarchy with more than 30.000 clients. And both updated from SMS 2003 about half a year ago. The problem they’re experiencing is:

More than 20% of the clients do not report on hardware inventory properly and a lot of DDRs seem to get lost. The Matching errors for the data loader (the hardware inventory processor) and the statsys (the processor of the status messages) on the central site are:

 

PROBLEM:

sinvproc.log:
The data file "D:\ConfigMgr\inboxes\auth\sinv.box\l5s8o51h.SID" that was submitted by the client whose SMS unique ID is "GUID:34DA8F05-787B-4D3B-8539-AD4322A29E92", was rejected because the file was signed but the authentication key did not match the recorded key for this client.

dataldr.log:
Manager\inboxes\auth\dataldr.box\Process\X3vxse509.MIF" that was submitted by the client whose SMS unique ID is "GUID:1ACBD35E-8426-4CA3-AC84-D1212ACAD3CC", was rejected because the file was signed but the authentication key did not match the recorded key for this client.

It seems like the KeyData, which is stored for every client leads to the issue. The KeyData is the clients authentication key which is used to prove incoming data within inboxes\auth. If the KeyData on the central site somehow gets corrupted, the uploaded data from the clients is being rejected ad you experience backlogs in the folders:

inboxes\auth\dataldr.box\BADMIFS
inboxes\auth\sinv.box\bad
inboxes\auth\statesys.box\corrupt
inboxes\auth\ddm.box\BAD_DDRS

 

In order to prove the cause, you need to follow these steps:

Step 1: Get the SMS GUID of the suspicious client:

select Name0, smsid0 from system_data where Name0=‘ClientName’

 

Step 2: Get the KeyData field on both, the central site and the child primary site:

select SMSID, KeyData from ClientKeyData where SMSID=‘GUID:2A3D67C4-0F80-42B9-8659-1F4DE540B91B’

(insert the GUID received on Step 1)

 

Step 3: Compare the KeyData fields from Step 2:

image

 

RESOLUTION:

Currently I’m aware of two workarounds:

  1. Delete the entire row of the problem client on the central site server. It will be re-populated within 1-2 minutes.
  2. Select the KeyData field from the child primary site server and insert it in the matching field on the central site server. (Be careful, update table commands on the central site server can crash a lot of stuff and are not supported…)

 

ROOT CAUSE:

Well good question, next question. It looks like it happens when clients are getting re-staged and DDM in Central Site fails to update the table ClientKeyData via
spUpdateClientRegistration.

Comments

  • Anonymous
    August 19, 2013
    How supported is this method of resolving this error?  I've got a three-tier client with 18K workstations and currently am getting this on ~400 machines a day. Also, do you know of a better way of resolving the client name from the GUID in the Status Message from SCCM?

  • Anonymous
    August 19, 2013
    This is not officially supported. It is a best effort support topic... We implemented this at a 160k Seats customer and it works. I currently do not know any better solution.

  • Anonymous
    August 19, 2013
    The comment has been removed