The key for machine did not match the one in the database
I have a SCCM SP2 site in mixed mode. Site server OS is 2003 SP2 x64. I see occasional error messages on central site from SMS_STATE_SYSTEM component: Message ID: 6104 The SMS State System message file processing could not process file 'pg3imu6d.SMW' and moved it to the corrupt directory. Review the statesys.log file for further details. Message ID: 6105 The SMS State System message file processing processed one or more files that contained errors or invalid data. Review the statesys.log file for further details. The statesys.log shows these lines for that: SQL MESSAGE: spProcessStateReport - Error: The key for machine TRD01EV015 (GUID:A59C8E3F-56C4-470A-84F1-808041F0637A) did not match the one in the database. SMS_STATE_SYSTEM 6/29/2010 9:09:55 AM 12848 (0x3230) CMessageProcessor - Non-fatal error while processing pg3imu6d.SMW SMS_STATE_SYSTEM 6/29/2010 9:09:55 AM 12848 (0x3230) STATMSG: ID=6104 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_STATE_SYSTEM" SYS=FISHEL03001 SITE=CEN PID=23660 TID=12848 GMTDATE=Tue Jun 29 06:09:55.031 2010 ISTR0="pg3imu6d.SMW" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_STATE_SYSTEM 6/29/2010 9:09:55 AM 12848 (0x3230) Thread "State Message Processing Thread #0" id:12848 was unable to process file "D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\process\pg3imu6d.SMW", moving to corrupt directory. SMS_STATE_SYSTEM 6/29/2010 9:09:55 AM 12848 (0x3230) I can see those SMW files in "auth\statesys.box\corrupt" folder from 1 year back ever since that site was set up. I don't see this issue on any of the child primary sites - it only appears on central primary. Any thoughts on what might cause that and what should I check?
June 29th, 2010 10:03am

The key for machine TRD01EV015 (GUID:A59C8E3F-56C4-470A-84F1-808041F0637A) did not match the one in the database. It seems as if a .smw file arrived at the central site, but the GUID for client trd01ev015 does not match. Double check the GUIDs on the child and primary site and if there are duplicate client records.
Free Windows Admin Tool Kit Click here and download it now
June 29th, 2010 10:41am

Thank you for reply! I actually did check the GUIDs as one of the first things. I discovered that GUID is same in database (queried SYSTEM_DISC table and v_GS_SYSTEM view), in smscfg.ini on the client and in a .SMW file. I also queried database for a client GUID on both central primary and child primary, and they were same. That's when I ran out of ideas.
June 29th, 2010 11:05am

Delete the client on the central site. That will automatically remove it from the child site too. Heartbeat should bring it back on the child site and that will be replicated up to the central. It's worth a try.
Free Windows Admin Tool Kit Click here and download it now
June 30th, 2010 3:51pm

Thank you! Deleting the client on central fixed the issue for that specific client. When it was gone from child primary as well I initiated Discovery Data Collection Cycle again and soon I noticed that client appeared again. This time the heartbeat agent time was correct on both primaries. So this way I can fix those specific clients. However the cause is still unclear. All clients are assigned to child primaries only and there are no clients in central primary. So could it be related that barebone computers are imported manually (unknown computer support is not used) on primary site and not on central primary?
June 30th, 2010 10:13pm

I didn't pay enough attention and I was cheering too early. After I deleted a client from central and it was gone from child primary it was brought up correctly on child primary after the next heartbeat, but not on central. It appeared on central after it was discovered from AD, but the record on central didn't show heartbeat. When I checked SYSTEM_DISC table the resource record on central didn't have GUID at all (it was NULL). The resource record on child primary was fine - hardware discovery, etc worked, but none of this was replicated to central. When I monitored ddm.log on central during the time I initiated Discovery Data Collection Cycle on client, I noticed that it complained about the public keys again: CDiscoverySource::VerifyClientPublicKeys - Public keys do not match for client GUID:BD78D45A-7BCB-4A9F-A0D6-E31F0EB52731. SMS_DISCOVERY_DATA_MANAGER 7/2/2010 1:04:51 PM 26980 (0x6964) Is there anything else to try? Generate new GUID for client or reinstall it?
Free Windows Admin Tool Kit Click here and download it now
July 2nd, 2010 1:14pm

Well, generating new GUID solved the issue. Now I just need to find a way how to generate new GUID to all clients having this issue automatically.
July 6th, 2010 12:37am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics