Forum Discussion
Solved
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 t...
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
MicrosoftPaulKlerkx 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 - thanks again.
- Hi 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?
