Forum Discussion
PaulKlerkx
Aug 27, 2020Iron Contributor
Inboxes - Automatic or do I need to deal with the files in them?
HI,
We have recently escaped a hardware failure by migrating and restoring onto new hardware.
My question is regarding all the inboxes, particularly things like "Corrupt" and "Badmifs."
I've tried google and don't seem to be able to find anything describing exactly what I need to do with the files in here or what issue they might indicate. If they automatically sort themselves out and I don't need to do anything, I'm fine with having the failures in the console for a few more days, but if these aren't things that MECM deals with automatically, I need to figure out what the process is for dealing with them.
examples.
C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFs\Delta Mismatch (we have 40 so far),
C:\Program Files\Microsoft Configuration Manager\inboxes\auth\statesys.box\corrupt (we have 93 so far)
Under Monitoring, our SMS_STATE_SYSTEM is full of errors similiar to this
The State System message file processing could not process file 'L_FPE4MWBG.SMX' and moved it to the corrupt directory. Review the statesys.log file for further details.
Statesys.log then has these matching messages (which I have sent to our SQL guy and he thinks maybe it is just a wait and see situation. )
SQL MESSAGE: dbo.spProcessStateReport - Error: Message processing encountered a SQL error 2627 at record 288 for TopicType 7201, StateID 2: "Violation of PRIMARY KEY constraint 'SuperPeerContentMap_PK'. Cannot insert duplicate key in object 'dbo.SuperPeerContentMap'. The duplicate key value is (820b581a-66e5-4377-ad71-5c79c941b0bd, 16781475, 1).", Line 0 in procedure ""
SQL MESSAGE: dbo.spProcessStateReport - Error: Message processing encountered a SQL error 3621 at record 288 for TopicType 7201, StateID 2: "The statement has been terminated.", Line 0 in procedure ""
CMessageProcessor - Non-fatal error while processing L_FPE4MWBG.SMX
Thread "State Message Processing Thread #0" id:17896 was unable to process file "C:\Program Files\Microsoft Configuration Manager\inboxes\auth\statesys.box\process\L_PZ4616HY.SMX", moving to corrupt directory.
I did a quick check on the oldest file in "Corrupt" and a search found two other files with the same PC hostname in them so I'm thinking something is broken and MECM is not going to deal with it. it's my problem.
If there is any up to date doco, happy to read it if you can point me to it, everything I've found has been 10+ years old so not stuff I would trust to still be true for MECM CB 2002.
PaulKlerkx Quick answer: some of the inboxes may need manual cleanup every now and then, some don't. It's all very much undocumented, so we don't encourage people to do this on their own.
Having said that, you can leave the auth\dataldr.box\BADMIFS folder (and its subfolders) as well as the sinv.box\BADSinv folder alone. The associated components (the SMS_INVENTORY_DATA_LOADER and the SMS_SOFTWARE_INVENTORY_PROCESSOR respectively) delete files that are older than 14 days from these folders automatically. This can be observed in their log files (dataldr.log and sinvproc.log, respectively).
As for the corrupt state message files in the auth\statesys.box\corrupt folder: you can always try processing them again by moving (NOT copying!) them to the auth\statesys.box\incoming folder. Worst case is they end up in the corrupt folder again. If that's the case, you might as well delete them, because then they will most likely never get processed successfully.
- Michiel Overweel
Microsoft
PaulKlerkx Quick answer: some of the inboxes may need manual cleanup every now and then, some don't. It's all very much undocumented, so we don't encourage people to do this on their own.
Having said that, you can leave the auth\dataldr.box\BADMIFS folder (and its subfolders) as well as the sinv.box\BADSinv folder alone. The associated components (the SMS_INVENTORY_DATA_LOADER and the SMS_SOFTWARE_INVENTORY_PROCESSOR respectively) delete files that are older than 14 days from these folders automatically. This can be observed in their log files (dataldr.log and sinvproc.log, respectively).
As for the corrupt state message files in the auth\statesys.box\corrupt folder: you can always try processing them again by moving (NOT copying!) them to the auth\statesys.box\incoming folder. Worst case is they end up in the corrupt folder again. If that's the case, you might as well delete them, because then they will most likely never get processed successfully.
- PaulKlerkxIron Contributor
Michiel Overweel - thanks again.
- Stephan2kCopper ContributorHi there,
we are also getting every day various messages like that:
SQL MESSAGE: dbo.spProcessStateReport - Error: Record 507 returned an 'invalid record' return code and failed processing with error 2627: ERROR 2627, Level 14, State 1, Procedure dbo.spUpdateSuperPeerStatus, Line 1, Message: Violation of PRIMARY KEY constraint 'SuperPeerContentMap_PK'. Cannot insert duplicate key in object 'dbo.SuperPeerContentMap'. The duplicate key value is (9ed68171-d84c-43ea-8acb-5e3ca590d3ad, 16783062, 1).
So I was wondering why is it trying to do an insert when the record already exists: Cannot insert duplicate key. However, when I queried the table I got 0 records back with these IDs. After that I figured out that the client itself does not exist in the SuperPeers table even when the setting is turned on by client policy.
So far I did not get to any further conclusion, event the client version seems not to make any difference:
Select DISTINCT
v_R_System.Netbios_Name0, v_R_System.ResourceID, v_R_System.Client_Version0, SuperPeers.Port
From CollectionMembers Members
INNER Join Collections Coll on Members.SiteID = Coll.SiteID
INNER JOIN v_R_System ON v_R_System.ResourceID = Members.MachineID
LEFT JOIN SuperPeers ON SuperPeers.ResourceID = v_R_System.ResourceID
WHERE Port is Null
So currently I am checking why are some clients not in the SuperPeers table, or maybe it works as designed?
- PaulKlerkxIron Contributor
@update to C:\Program Files\Microsoft Configuration Manager\inboxes\auth\statesys.box\corrupt (we have 93 so far)
we are now at 148 corrupt smx files. the numbers per day are significantly lower, but the files don't seem to be getting removed. still haven't identified what we are supposed to do here.