locked
Hardware Inventory Issues on some Windows 2000 Terminal Servers RRS feed

  • Question

  • I have 21 production Windows 2000 terminal Servers (SP 4 and current on monthly updates).  Of these 21 servers, 16 do not report their hardware inventories.  There are no differences between the ones that work and the ones that do not work, other than daily use (the ones that work have lighter user loads, not sure if that is significant or not).

     

    All of the Terminal Servers had the SCCM client installed the same way.  None were previous SMS clients.  The initial hardware inventory works fine, but it fails on the weekly schedule the next week.  I manually uninstalled and reinstalled each server to test install issues.  Install went fine, and both hardware and software inventories are successful.  I even ran several client initiated Hardware Inventory actions over the next day or so and all were successful.  But the next week, the reports do not make it to the database and I have a bunch of bad MIFs in the auth\dataldr.box\BADMIFS folder.

     

    I am confused, because there is abosolutely no difference (other than use) on the few that work and the ones that don't.  The traffic through the logs look fine (as near as I can tell) - it goes through the local InventoryAgent.log, and then to the

    MP_Hinv.log, but it logs in the dataldr.log that it moved the MIF to the BADMIFS folder.  The MIF file it creates is generally large (5-8 MB, varies with server).  I cannot tell from the MIF file what it doesn't like, but from the logs it may seem like the client is doing a delta, but the server wants a full, but not 100% about that.

     

    I have seen other posts that recommend uninstall and reinstalling the client, but that did not work for us (at least it stopped working after the first few days).  I would appreciate any ideas.  Out of the 1100 computers that are actively in SCCM, these are the only ones that are failing this way.

     

    I will be including in future posts the applicable entries in each log file and the MIF file.  Thanks for your help!

    Tuesday, April 8, 2008 4:23 PM

Answers

  • One thing I just ran into onsite today. We ran into a problem with some Terminal Server systems where the inventory was not processed as the inventory file was too large. Our default inventory file size maxes out at 5MB.

     

    How we found this was that the files were in the Inboxes\Auth\Dataldr.box\Badmifs folder. We then looked in the dataldr.log, searched for a client name (as viewed by opening a .mif file) and saw a line that stated the mif was too large ("exceded the max file size" or something like that).

     

    We bumped up the file size in the Registry (HKLM\Software\Microsoft\SMS\Components\SMS_Inventory_Data_Loader\Max MIF Size), moved the badmif to the Inboxes\Auth\Dataldr.box folder, and it was immediately processed.

     

    So, give that a shot to see if that helps out.

     

    Saturday, April 26, 2008 12:50 AM

All replies

  • Here is the InventoryAgent.log entries from a computer initiated Hardware Inventory action:

     

     

    Inventory: *********************** Start of message processing. ***********************   InventoryAgent                4/8/2008 11:02:16 AM    11048 (0x2B28)

    Inventory: Message type is InventoryAction       InventoryAgent                4/8/2008 11:02:16 AM    11048 (0x2B28)

    Inventory: Temp directory = C:\WINNT\system32\CCM\Inventory\Temp\           InventoryAgent                4/8/2008 11:02:16 AM         11048 (0x2B28)

    Inventory: Clearing old collected files.    InventoryAgent                4/8/2008 11:02:16 AM    11048 (0x2B28)

    Inventory: Opening store for action {00000000-0000-0000-0000-000000000001} ...              InventoryAgent                4/8/2008 11:02:16 AM       11048 (0x2B28)

    Inventory: Action=Hardware ReportType=Delta                InventoryAgent                4/8/2008 11:03:05 AM    11048 (0x2B28)

    Inventory: Initialization completed in 49.375 seconds      InventoryAgent                4/8/2008 11:03:05 AM    11048 (0x2B28)

     

    ....There is a whole bunch of collection namespace tasks that run.....

     

    Collection: 41/59 inventory data items successfully inventoried.                InventoryAgent                4/8/2008 11:05:50 AM                12880 (0x3250)

    Inventory: Collection Task completed in 164.875 seconds              InventoryAgent                4/8/2008 11:05:50 AM    12880 (0x3250)

    Inventory: 18 Collection Task(s) failed.   InventoryAgent                4/8/2008 11:05:50 AM    12880 (0x3250)

    Inventory: Temp report = C:\WINNT\system32\CCM\Inventory\Temp\1d32680a-f061-4894-ac77-5a53c0dd06d6.xml                InventoryAgent                4/8/2008 11:05:50 AM    12880 (0x3250)

    Inventory: Starting reporting task.           InventoryAgent                4/8/2008 11:05:50 AM    11048 (0x2B28)

    Reporting: 1395 report entries created. InventoryAgent                4/8/2008 11:06:09 AM    11048 (0x2B28)

    Inventory: Reporting Task completed in 18.235 seconds                InventoryAgent                4/8/2008 11:06:09 AM    11048 (0x2B28)

    Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {BE47B652-7C98-432B-88E3-502AC7483C04}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted          InventoryAgent                4/8/2008 11:06:15 AM    11048 (0x2B28)

     

    Tuesday, April 8, 2008 4:27 PM
  • Here is the MP_HINV.log entries:

     

    Mp Message Handler: copying attachment to E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\HinvAttachment2WFOQ1TF.xml    MP_HinvEndpoint           4/8/2008 11:06:51 AM    8368 (0x20B0)

    Inv-Hinv Task: processing xml file "E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\HinvAttachment2WFOQ1TF.xml"  MP_HinvEndpoint           4/8/2008 11:06:51 AM    9156 (0x23C4)

    Hinv Retry: ******************* Start of Task *********************   MP_HinvEndpoint           4/8/2008 11:06:51 AM         9156 (0x23C4)

    Hinv Sax: loading E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\HinvAttachment2WFOQ1TF.xml    MP_HinvEndpoint           4/8/2008 11:06:51 AM    9156 (0x23C4)

    Delta report from client TS05, action description = Hardware       MP_HinvEndpoint           4/8/2008 11:06:51 AM    9156 (0x23C4)

    Hinv Task: Translate report attachment to file "E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\HYF4X2NC.MIF" returned 0              MP_HinvEndpoint           4/8/2008 11:06:51 AM    9156 (0x23C4)

    Hinv Retry: ******************* End of Task *********************     MP_HinvEndpoint           4/8/2008 11:06:51 AM         9156 (0x23C4)

     

    Tuesday, April 8, 2008 4:29 PM
  • And finally, the entries in the dataldr.log file:

     

    >> Add 1 files to process directory ...      SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:56 AM    4796 (0x12BC)

    Moving MIF file E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\HYF4X2NC.MIF to E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\process\HYF4X2NC.MIF                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:56 AM    4796 (0x12BC)

    Started the machine MIF processing thread, thread ID = 259C     SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:56 AM         4796 (0x12BC)

    Worker thread 10100 starting execution.              SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:56 AM    10100 (0x2774)

    Done with job queueing.              SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:57 AM    9628 (0x259C)

    Blocking until completion.            SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:57 AM    9628 (0x259C)

    Thread: 0 is using GUID SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:58 AM    10100 (0x2774)

    Thread: 10100 will use GUID GUID:12C3F2A3-4EAD-4ECB-AC38-4F969A8BCD1F   SMS_INVENTORY_DATA_LOADER                4/8/2008 11:06:58 AM    10100 (0x2774)

    Processing Inventory for Machine: TS05   Version 1.2  Generated: 04/08/2008 11:05:50   SMS_INVENTORY_DATA_LOADER                4/8/2008 11:06:58 AM    10100 (0x2774)

    Pragma delete found in inventory group MICROSOFT|SYSTEM_CONSOLE_USAGE|1.0.  Deleting group...                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:58 AM    10100 (0x2774)

     

    ... These two lines are repeated several times (around a hundred).....

     

    SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:58 AM    10100 (0x2774)

    Pragma delete found in inventory group MICROSOFT|SOFTWARE_SHORTCUT|1.0.  Deleting group...                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:58 AM    10100 (0x2774)

    Pragma delete found in inventory group MICROSOFT|SYSTEM_CONSOLE_USER|1.0.  Deleting group...                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:58 AM    10100 (0x2774)

    Begin transaction: Machine=TS05(GUID:12C3F2A3-4EAD-4ECB-AC38-4F969A8BCD1F)      SMS_INVENTORY_DATA_LOADER                4/8/2008 11:06:59 AM    10100 (0x2774)

    WARNING - Attempting to resync due to missed delta reports (sp return code = 7)          SMS_INVENTORY_DATA_LOADER                4/8/2008 11:06:59 AM    10100 (0x2774)

    Rollback transaction: Machine=TS05(GUID:12C3F2A3-4EAD-4ECB-AC38-4F969A8BCD1F) SMS_INVENTORY_DATA_LOADER                4/8/2008 11:06:59 AM    10100 (0x2774)

    Remote client hardware inventory resync generated for client GUID:12C3F2A3-4EAD-4ECB-AC38-4F969A8BCD1F; update/insert result = 2                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM    10100 (0x2774)

    Send resync command to local site for machine GUID:12C3F2A3-4EAD-4ECB-AC38-4F969A8BCD1F.                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM    10100 (0x2774)

    STATMSG: ID=2722 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=SYSADMIN06 SITE=DM1 PID=2336 TID=10100 GMTDATE=Tue Apr 08 16:06:59.822 2008 ISTR0="TS05" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0      SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM         10100 (0x2774)

    Cannot process MIF XHYF4X2NC.MIF, moving it to E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\91a0l0hr.MIF      SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM         10100 (0x2774)

    STATMSG: ID=2703 SEV=W LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=SYSADMIN06 SITE=DM1 PID=2336 TID=10100 GMTDATE=Tue Apr 08 16:06:59.869 2008 ISTR0="XHYF4X2NC.MIF" ISTR1="E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\91a0l0hr.MIF" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0      SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM         10100 (0x2774)

    Done: Machine=TS05(GUID:12C3F2A3-4EAD-4ECB-AC38-4F969A8BCD1F) code=2 (1397 stored procs in XHYF4X2NC.MIF)                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM    10100 (0x2774)

    Done blocking until completion.                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM    9628 (0x259C)

    No more machine MIFs to be processed, terminating thread      SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM         9628 (0x259C)

    Shutting down Machine Writer.                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:06:59 AM    9628 (0x259C)

    Worker thread 10100 halting execution.                SMS_INVENTORY_DATA_LOADER           4/8/2008 11:07:00 AM    10100 (0x2774)

    Finished processing 1 MIFs          SMS_INVENTORY_DATA_LOADER           4/8/2008 11:07:04 AM    9628 (0x259C)

     

    Tuesday, April 8, 2008 4:33 PM
  • With all those lines indicating pragma deletes, my *guess* would be that you have issues with duplicate GUIDs. I know there are KBs regarding duplicate GUID issues, so I'd search for them, then follow themn to see if it returns the results I'd guess it will.

     

     

    Wednesday, April 9, 2008 1:57 AM
  • Thanks for the direction.  None of these servers were built from images that contained either a current or old SMS client, so the issue shouldn't be stemming from that.  I checked the SMS ID located in the smscfg.ini and none of the terminal servers have a duplicated entry there.  I also checked the dbo.tbComputerTarget table, and there are no duplicate entries there.

     

    Most of the information I found via searches refer to GUID duplication due to imaging (not our issue).  The "pragma delete"  lines turned up some information about SMS 2003, but that was never in our environment, and certainly isn't what we are running today.  Is there something else I should be looking at?

    Wednesday, April 9, 2008 4:48 PM
  • Is the problem only exhibited on these terminal servers? Other clients work fine?

     

    I'm not familiar with any specific issues with terminal servers, but honestly have never used one before, so never had one in my sites to do any testing with.

     

    Unless others have experience, it may be time for a call to product support.

    Wednesday, April 9, 2008 5:26 PM
  • I was hoping for some "grassroots" solutions - it would be unfortunate if I were the only one who has seen this issue with SCCM!

     

    I am only seeing this on the 16 or so terminal servers out of almost 1100 clients.  It is very weird, since I am not seeing it on all of my Terminal Servers either.

     

    I found some instructions on resetting the SMS GUID by deleting the smscfg.ini file on the client and restarting the Agent Service.  This did not fix my Hardware Inventory problem.  Here is the final entries in the dataldr.log:

     

    Begin transaction: Machine=TS01(GUID:AA7D0E38-8F0F-43A3-9B0E-3131F561716C) SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:20 PM 9432 (0x24D8)
    WARNING - Attempting to resync due to missed delta reports (sp return code = 7) SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:21 PM 9432 (0x24D8)
    Rollback transaction: Machine=TS01(GUID:AA7D0E38-8F0F-43A3-9B0E-3131F561716C) SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:21 PM 9432 (0x24D8)
    Remote client hardware inventory resync generated for client GUID:AA7D0E38-8F0F-43A3-9B0E-3131F561716C; update/insert result = 2 SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:21 PM 9432 (0x24D8)
    Send resync command to local site for machine GUID:AA7D0E38-8F0F-43A3-9B0E-3131F561716C. SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:21 PM 9432 (0x24D8)
    STATMSG: ID=2722 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=SYSADMIN06 SITE=DM1 PID=2336 TID=9432 GMTDATE=Wed Apr 09 21:29:21.654 2008 ISTR0="TS01" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:21 PM 9432 (0x24D8)
    Cannot process MIF XHFDVU704.MIF, moving it to E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\zakarny6.MIF SMS_INVENTORY_DATA_LOADER 4/9/2008 4:29:21 PM 9432 (0x24D8)

    Any other ideas?  Thanks!

    Wednesday, April 9, 2008 9:49 PM
  • What I would do is:

     

    * Delete the system from the All Systems collection - verify it is removed

    * Go to the client, and force a Discovery Data Collection Cycle

    * Update the All Systems collection to ensure that the system is added back in

    * Go to the client, and force a Hardware Inventory Cycle

    * Update the collection

    * Select a client and start the Resource Explorer

     

    Wednesday, April 9, 2008 11:42 PM
  • That did not work either.  In fact, when I run the "Discovery dates for a specific computer report", the terminal server shows up twice, and neither with a Hardware Inventory date.

     

    We are finalizing our EA with MSFT in the near future, and will call this in for support when we can.  Thanks for the ideas!

     

    Thursday, April 17, 2008 2:52 PM
  • Hardware inventory is based on WMI information. WMI might be corrupted on terminal services.

     

    Check the following link for more details about debugging WMI:

    http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx

     

    Thursday, April 17, 2008 3:51 PM
  • One thing I just ran into onsite today. We ran into a problem with some Terminal Server systems where the inventory was not processed as the inventory file was too large. Our default inventory file size maxes out at 5MB.

     

    How we found this was that the files were in the Inboxes\Auth\Dataldr.box\Badmifs folder. We then looked in the dataldr.log, searched for a client name (as viewed by opening a .mif file) and saw a line that stated the mif was too large ("exceded the max file size" or something like that).

     

    We bumped up the file size in the Registry (HKLM\Software\Microsoft\SMS\Components\SMS_Inventory_Data_Loader\Max MIF Size), moved the badmif to the Inboxes\Auth\Dataldr.box folder, and it was immediately processed.

     

    So, give that a shot to see if that helps out.

     

    Saturday, April 26, 2008 12:50 AM
  • The past two posts both offer some good ideas.  The automatic inventory runs tomorrow morning, so I will know at that time where I stand.

     

    I rebuilt the WMI on one of the servers, and re-installed the client.  Initial inventories (and subsequent manually requested deltas) have worked so far, but I saw this before when I first started troubleshooting the issue.  It wasn't until the next regurlarly scheduled inventory (we use 7 days) that the problem reappeared.  That is scheduled for tomorrow morning.

     

    As for the MIF size, the console only lets you set it to 5 MB - I didn't realize you could overwrite that value on the client registry.  Some of my MIF files are definitely larger than the default (I think it was 256 KB or something), and are also larger thatn the 5 MB (some of these are 7-8 MB).  If the WMI didn't resolve anything, I will manually update the registry and try to re-run the MIF.

     

    I will post my results tomorrow.  Thanks again for the help!

     

    Brandon

     

    Monday, April 28, 2008 2:30 PM
  • The console setting in the Hardware Inventory Client Agent is NOT related to the .mif that clients generate (though it does sound like does :-)

     

    It is only for Noidmif and IDmif files that are separate files added to the client to be included with the normal inventory generation process (the MIF collection tab).

     

    For the normal hardware inventory collection cycle, the default is 5MB for a max (versus the 250KB) for .mif files. To increase it, it is the Registry setting.

     

    So, if you are looking at the Badmifs folder, and see files larger than 5MB, they will NOT be processed unless you do increase the Registry limit (which has nothing to do with the console setting :-)

    Friday, May 2, 2008 11:23 PM
  • Rebulding the WMI repository did not accomplish anything.  The MIF file looked like it always did.

     

    Increasing the file size in the registry did work for my guinea pig terminal server.  Moving the MIF file back to the first folder allowed it to process successfully.

     

    This did not work for the others, and I get an error about it synching between full and delta reports.  I am assuming that I will need to uninstall/re-install the client one more time to make sure it gets a good full inventory and a successful delta as well, to keep everything in line (this is what I did for the guinea pig prior to bumping the registry key).  I will try this on a couple more boxes this week to see if the results stay consistent.

     

    Thanks!

     

    Brandon Jackson

     

    Monday, May 5, 2008 2:57 PM
  • Good, sounds like the Registry is the issue.

     

    You don't need to reinstall the clients however. All you need to do is to force the clients to send in a full hardware inventory. There is a script I've seen (probably from myitforum) to force the clients to do a resync inventory.

     

    Of course you could also reinstall the client to force it as well.

     

    Monday, May 5, 2008 11:47 PM
  • Changing the registry setting on the site server seems to be the fix.  I have now uninstalled/installed half of the farm and they are continuing to report good inventory data.  I will have the rest done this week and will post if I run into any more gotchas.  Thanks!

     

    Brandon

     

    Tuesday, May 13, 2008 2:43 PM
  • Great, glad you have it working now.

     

    For reference, when a question gets answered, please mark the response that resolved it as the answer so we all know you are set. You can even mark posts as helpful if they have been :-)

    Tuesday, May 13, 2008 10:38 PM
  • Of course you note the words "seem to be fixed".......  As soon as I ensure all of my servers are fixed using the directions given I will gladly give credit to the answering post.   I am very confident that everything will work, but you know what they say about assuming......  I guess you will just have to wait one more day for you kudos.......    

    Wednesday, May 14, 2008 1:43 AM
  • See... I spoke too soon.

     

    Although your answer does allow for the MIFs to run, the larger question of why the MIFs are so large remains unanswered.  I now have MIFs on my TS that are over 20 MB and are "broke" again.

     

    I have found that the section for the class "Microsoft|CCM_Recently_Used_Apps|1.0" accounts for over 20-30 MB of the MIF file.  These servers are used by between 40-50 users concurrently at any given point in time.  I currently do a hardware inventory every 7 days.  Would increasing the interval to every 1-2 days decrease this class in the MIF (the recently used variable going from the last MIF generation), or is this class being keyed off of something else entirely and the frequency of the inventory would not help?

     

    Thanks!

     

    Brandon Jackson

    Wednesday, May 21, 2008 5:36 PM
  • That class is used to track applications used and then create software metering rules automatically. We do recommend that you enable this, especially in the case of Terminal Servers. It will affect nothing, other than the automatic creation of software metering rules.

     

    Thursday, May 22, 2008 2:44 AM
  • That is good to know.  We aren't currently using the Software Metering piece but may in the future. 

     

    On second glance, it appears that the ones with the really large MIF files appear to be the ones that still aren't working (haven't done the uninstall/reinstall), so this may be a non issue.  We have a single maintenance window a week so we have a couple left to so this for - once they are all installed we may be okay.  I will keep you posted.  Thanks!

     

    Brandon Jackson

    Thursday, May 22, 2008 7:16 PM
  • You don't need to deinstall and reinstall clients for this. You just modify the sms_def.mof to designate what you want to collect, and clients will pick that up automatically. A reinstall is not needed herefrom what I see. But if you want to do so, feel free :-)

     

    Friday, May 23, 2008 1:20 AM
  • We are now fixed.  It was defiinitely the registry size issue.  I wasn't able to "trick" the client into doing a ful inventory using any of the methods I found online, so I did have to do the uninstall/reinstall.  Other than that, your solution delivered, and I would have never figured this out without your help.  Thanks!

     

    Monday, June 2, 2008 3:37 PM
  • Glad it worked. And I would have only found it because while onsite at a customer, we ran into it :-)

    Monday, June 2, 2008 5:55 PM
  • Hi Wally,
    This post was very helpful. Thanks for this post.

    We were also having the similar issue of "cannot process mif .... moving it to C:\SMS\inboxes\auth\dataldr.box\BADMIFS\ ..." and the BADMIF folder was filling up like anything.

    dataldr.log file revealed that there were two related errors
    1. WARNING - Attempting to resync due to missed delta reports (sp return code = 7)
    2. ERROR: File size exceeds defined maximum

    Root cause:
    Apparently, there was several 'missed delta report (inventory)' for many clients for which it was triggering a resync(full inventory) for each of them.
    In one of our SCCM site servers, the said regkey value (HKLM\Software\Microsoft\SMS\Components\SMS_Inventory_Data_Loader\Max MIF Size) was set to its default (5MB), and that was preventing those full hw inventory MIF files (being larger than 5MB) from processing, instead it was moving them to BADMIFS folder. And this kept cycling as it could never get the resync done, resulting piling up the MIF files into BADMIFS folder.

    Increasing the reg value to 30000000 (30MB), sorted this out.


    Cheers.
    Tuesday, July 7, 2009 6:14 AM
  • Just adding this to this thread:  http://myitforum.com/cs2/blogs/skissinger/archive/2009/07/03/selectively-disable-ccm-recentlyusedapps-per-client.aspx

    IMO, often the cause for a large inventory mif file is having on a particular verbose class in sms_def.mof on -- like ccm_recentlyusedapps.  That one in particular has been known to make the delta mif file huge from citrix servers or servers where multiple users launch applications from them -- because it's hundreds of entries.  If you get large mif files, you can check if this workaround, applied specifically to those particular servers, addresses the issue.
    Standardize. Simplify. Automate.
    Tuesday, July 7, 2009 12:29 PM
  • I am also facing this trouble on my SCCM 2007 R2 server. The folder BADsinv contains hundreds of .SID files with file size as large as over 35 MB and they keep on accumulating. This also results in large size of backup files.

    i checked into the sinvproc.log file too and noticed following log entries therein.
    -----------------------------------------------------------------------------------------------------------------
    WARNING - File size of 33 MB has exceeded the limit of 4 MB. SMS_SOFTWARE_INVENTORY_PROCESSOR 2009/08/14 20:52:25 15552 (0x3CC0)

    WARNING: Report size for machine XXXYYYZZZ has exceeded the limit. SMS_SOFTWARE_INVENTORY_PROCESSOR 2009/08/14 20:52:25 15552 (0x3CC0)
    STATMSG: ID=3708 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_SOFTWARE_INVENTORY_PROCESSOR" SYS=SCCMSERVER SITE=CPS PID=9376 TID=15552 GMTDATE=‹à 8 14 11:52:25.822 2009 ISTR0="E:\Program Files\Microsoft Configuration Manager\inboxes\auth\sinv.box\YWYLWM20.SID" ISTR1="5000000" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_SOFTWARE_INVENTORY_PROCESSOR 2009/08/14 20:52:25 15552 (0x3CC0)

    Moved file E:\Program Files\Microsoft Configuration Manager\inboxes\auth\sinv.box\YWYLWM20.SID to E:\Program Files\Microsoft Configuration Manager\inboxes\sinv.box\BADSinv\nte913k2.SID in BADSINV Directory !!! SMS_SOFTWARE_INVENTORY_PROCESSOR 2009/08/14 20:52:25 15552 (0x3CC0)
    STATMSG: ID=3701 SEV=W LEV=M SOURCE="SMS Server" COMP="SMS_SOFTWARE_INVENTORY_PROCESSOR" SYS=SCCMSERVER SITE=CPS PID=9376 TID=15552 GMTDATE=‹à 8 14 11:52:25.825 2009 ISTR0="E:\Program Files\Microsoft Configuration Manager\inboxes\auth\sinv.box\YWYLWM20.SID" ISTR1="E:\Program Files\Microsoft Configuration Manager\inboxes\sinv.box\BADSinv\nte913k2.SID" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_SOFTWARE_INVENTORY_PROCESSOR 2009/08/14 20:52:25 15552 (0x3CC0)
    -------------------------------------------------------------------------------------------------

    This inventory file belongs to a Windows XP SP2 workstation. i wonder how the file size is so huge and how can i limit the size or alternatively how to allow SCCM to process larger size inventory files?
    Friday, August 14, 2009 12:49 PM
  • ANIL,
    You can use the skpswi.dat (found in your client's cache folder) to skip software inventory (skpswi) on a folder and all subfolders.

    Just note that it will skip all subfolders.  If you don't want it to do that, you need to put the file in all the subfolders you wish to skip.

    I'm assuming this client has a lot of files you are trying to inventory... I would look at what files you are inventorying and take a manual look at that client to see if they have a lot of those files...  Maybe the user is a programmer and has lots of compiled EXE files?  Maybe you guys are inventorying on MP3 files and he/she's a music lover?

    ---------------------------------------------------------------

    However, I am working on some BADMIF troubleshooting as well.  What I've found so far is that the default size is set to 5MB and is stored in the registry.  We have a decent number of clients in our environment and have sized our DB based on 5MB per client for inventory size.  Having said that, I do not want to modify the default HINV MIF size because I do not want to balloon our database.

    So now I am troubleshooting on why some clients have a large size and have determined that it is due to public computers that are like kiosk machines.  Many many users walk-up and use these systems, therefore increasing the recently used apps section.  So I understand that one, but what about some of the other reasons?

    For example... everyone online says "bad character".  I'm a human... a lot of those characters look out of the ordinary inside the MIF file, but I have compared a good MIF to a bad one and still cannot find anything that I can humanly interpret as "bad".  So how do we identify bad characters?

    So here are the errors and warnings I'm seeing in the dataldr.log file:

    1.) WARNING - Outdated report will be discarded. (sp return code = 8)
    2.) WARNING - Attempting to resync due to missed delta reports (sp return code = 7)
    3.) ERROR: File size exceeds defined maximum

    So I understand these as
    1.) A report with a more recent version has been received and this one will be thrown away... no resync request.
    2.) A full may or may not have been generated, but whatever the case, the site server exptected to see a previous inventory (delta or full) prior to this inventory.  A resync is requested.
    3.) The file is larger than the 5MB default.

    So for 3, I understand.  And it seems that if 3 happened on the initial FULL, then 2 would happen with the delta that the client submits after it's full, then a full would be requested by the site server and the process would loop.

    But what about 1?  Does anyone know how that one happens?

    Help?  I have over 14,000 badmif files coming from over 500 unique clients.  Sometimes the resync works for some, but others are repeat offenders with over 50 files in the directory belonging to one client alone.


    nick
    Wednesday, September 9, 2009 8:55 PM
  • By the way... these are XP SP2 clients, not Terminal Servers.  It's just that this is the only topic I've found with any clue to the reasons badmifs are generated.
    nick
    Wednesday, September 9, 2009 8:55 PM