Trevor Sullivan's Tech Room

Minding the gap between administration and development

ConfigMgr: Hardware Inventory MIF Errors

Posted by Trevor Sullivan on 2011/06/13


Introduction

In this situation, I’m working with a System Center Configuration Manager 2007 Service Pack 2 R3 central + child primary site configuration. Both sites have local databases, and all SCCM components (eg. management point, provider, distribution point, etc.) are local. SCCM clients are a combination of Windows Server 2003, 2008, and 2008 R2.

Recently on the child primary site, I started getting a bunch of MIF processing errors in the INVENTORY_DATA_LOADER component on a primary site. I had recently made some very minor edits to sms_def.mof, by enabling a few additional properties for reporting – I didn’t add anything new or custom to my sms_def.mof or configuration.mof, so I was a bit surprised to be running into issues.

Let’s take a look at some specifics around the behavior I was seeing.

Symptoms

Status Messages

The first symptom I noticed were warning and error status messages being logged to the INVENTORY_DATA_LOADER component on the child primary site. This was easily discovered by seeing a red “X” on the icon for child site’s status in the SCCM console.

image

Digging into the actual status messages, I was seeing quite a few of the following messages, right next to each other (time-wise).

Message ID 2700

SMS Inventory Data Loader failed to read the delta MIF file "d:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\Process\XHUHKEG3S.MIF" and will move the file to the BADMIFs directory.

Possible cause: The file is invalid or corrupt.
Solution: Do nothing. The file will be moved to the BADMIFs directory where it will be checked for corruption. Any formatting errors will be logged in Dataldr.log. If there are no formatting errors, there might have been a memory error, in which case the MIF will be retried.

Message ID 2703

SMS Inventory Data Loader failed to process the delta MIF file "XHUHKEG3S.MIF" and has moved it to "d:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\z1trdc9t.MIF."

Possible cause: The file attempted to update inventory information in the SMS site database that does not already exist, or the file contains invalid syntax.
Solution: The client inventory needs to be resynchronized, which will be done automatically. Look for the status messages 2714 and 2715, which indicate the resynchronization has begun.

image

Dataldr.log

On the child primary site, I opened up the dataldr.log under the <ConfigMgrInstallationFolder>\Logs folder. I paged up through the log, and ended up noticing the following messages (I filtered for a specific thread ID, which I retrieved from the first line (5900), to make tracking the specific “conversation” easier):

01 Worker thread 5900 starting execution.
02 Thread: 0 is using GUID
03 Thread: 5900 will use GUID GUID:E8399740-22D7-440A-AAEC-E0951C509E58
04 Compilation failed~syntax error on line 6179, token ‘-‘
05 Could not convert MIF file d:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\Process\XHUHKEG3S.MIF for SQL processing
06 STATMSG: ID=2700 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=SITESERVERNAME SITE=123 PID=3428 TID=5900 GMTDATE=Mon Jun 13 05:29:21.182 2011 ISTR0="d:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\Process\XHUHKEG3S.MIF" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
07 Cannot process MIF XHUHKEG3S.MIF, moving it to d:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\z1trdc9t.MIF
08 STATMSG: ID=2703 SEV=W LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=SITESERVERNAME SITE=123 PID=3428 TID=5900 GMTDATE=Mon Jun 13 05:29:21.182 2011 ISTR0="XHUHKEG3S.MIF" ISTR1="d:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\z1trdc9t.MIF" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
09 Done: Machine=(GUID:E8399740-22D7-440A-AAEC-E0951C509E58) code=4 (0 stored procs in XHUHKEG3S.MIF)

Out of Date Hardware Inventory

During the course of developing some reports, and collection queries, I found that I was having inaccurate hardware inventory data. I had done some manual checks to verify this, such as checking items in Add/Remove Programs, and comparing that against what was inside the ConfigMgr database (in the v_GS_Add_Remove_Programs SQL view). Since I knew I had inaccurate hardware inventory data, I ran the following SQL query against the ConfigMgr database – this showed a number of systems (more, before this screenshot was taken) having “last hardware inventory” dates much older than the inventory cycle was configured for (several days):

select
    [sys].[AD_Site_Name0]
    , [sys].[Name0]
    , [ws].[LastHWScan]

from v_GS_WORKSTATION_STATUS [ws]

join v_R_System [sys] on [ws].[ResourceID] = [sys].[ResourceID]
left join v_GS_OPERATING_SYSTEM [os] on [ws].[ResourceID] = [os].[ResourceID]

order by LastHWScan desc

image

Finding the Problem

I’ll leave it to you to look over the rest of the evidence here, but the most important piece of information is actually in the dataldr.log file. If you look closely at the sample from the log above, you’ll notice this line:

Compilation failed~syntax error on line 6179, token ‘-‘

Now, which file did the syntax error occur on? Well, it happened on the MIF file in the auth\dataldr.box\process folder, but a couple lines later, you see that ConfigMgr actually moves the MIF file to the auth\dataldr.box\BADMIFS folder, and gives it a different name. Open the bad MIF file in Notepad, and navigate to line 6179 ([Ctrl] + G will initiate the “jump to line” in most text editors).

image

Now, if you look at it, line 6179 in itself actually looks just fine. Keep reading ahead though, and you’ll probably see a discrepancy. Re-read the last part of the error message from the log file above: token ‘-‘. To me, that instantly read that somewhere, a dash was interfering with the interpretation of the MIF file – those pesky special characters!!

Now, do you see a dash anywhere? Yep, on line 6180. Now what is the value being reported there? It’s “64-bit” right? Now, how is ConfigMgr interpreting the value? As an integer type. Does “64-bit” seem interpretable as an integer to you? It sure doesn’t to me … after all, what would you answer with if someone came up to you and asked “hey, what integer value does ‘64-bit’ equal?” You’d probably be a bit dumbfounded at the stupidity of the question, as I would be.

Fixing The Problem

I had recently enabled the Win32_OperatingSystem.OSArchitecture property to be inventoried, so that I could build ConfigMgr reports and collections based on the property. It appears I’ll have to go about this in another way though.

One option would be to use environment variables (ProcessorArchitecture, I think?). It’s either that, or I’d have to play around with changing the sms_def.mof file to interpret the OSArchitecture property as a string instead of an integer.

Note: Disabling the inventorying of the OSArchitecture property seems to have solved the issue of bad MIF files for now. I re-ran a full inventory synchronization on a group of servers, and I haven’t seen any errors reported.

Conclusion

I hope that this article has given you some insight into a hardware inventory issue that I recently encountered. Keep in mind that there are many other situations that could cause inventory problems to occur, and this is just one of them. Hopefully it still provided some insight into how to troubleshooting hardware inventory though. For more information, please check out the Technet documentation, and participate in the MyITforum SCCM mailing list community!

Advertisements

3 Responses to “ConfigMgr: Hardware Inventory MIF Errors”

  1. I love it 🙂 You really never know what you’ll receive within the inventory unless you try it out.

    Nice trace of your steps though. Some fresher SCCM admins will hopefully find this article and learn the most important lesson in SCCM ever: always check the logfiles

  2. Mark said

    Well documented, thank you!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: