Microsoft Systems Management Server (SCCM) is an enterprise management infrastructure that is used for Asset Inventory, Software Distribution, Patch Management, System Configuration, and more. The SCCM product works in such a manner that the clients process policies that the server offers via a web service. These policies include instructions for actions that the client must perform. These actions include, but are not limited to, inventory based on hardware and software installed on the client system. This document will discuss clients who are submitting hardware inventory, but the inventory is not being processed by the site server.
When an SCCM client agent is installed for the first time on a client system, the client system has no policies. The very first thing that the system does is contact the management point to download any policies that are targeted to the system. The first batch of policies that are received are instructions to enable different components of the client agent that include, but are not limited to, the different inventory components.
Some of these components include:
- Software Updates
- Hardware Inventory
- Software Inventory
- etc…
For the first time, the client will now submit inventory for each of those components. This first inventory is called a “FULL” inventory, and unless instructed to do so by the site server or a script, the client will never submit a full inventory again. The following inventories will be “DELTA” inventories. “DELTA” inventories only submit information that has changed since the last inventory was sent (this reduces the size of the inventory file that is sent, thus reducing bandwidth and database processing).
Inventory Process:
The below flow chart walks through the process from when the client begins inventory until the inventory file is dropped onto the site server for processing.
Scenarios that may cause a BADMIF to be generated:
Delta report without a full inventory report
If a client inventory report is received and there is not a full inventory report for the particular client, the inventory will be dropped into the BADMIF directory.
Don’t worry, A client resynchronization request will be submitted.
Reasons:
The system may have been offline for a period greater than the aged inventory rules, thus the inventory was purged and the client needs a full inventory report.
OR
The full inventory file is over the maximum size limit and was not originally processed.
Remediation:
Try to match your Delete Inactive Client Discovery Data Task with the business use of the systems. If the systems are mobile and the customer tends to leave them offline for a long period of time (travel, throws it in the closet, loans it out to an aunt) then maybe you need to bump up the amount of days before inactive data is deleted. But if you choose not to, the system will be sent a resynchronization request and will submit a full hardware inventory.
But if the inventory file is larger than the maximum size, you could fall into a loop.
Inventory File Too Large
The default maximum file size that the site server will allow is 5MB. Any file that is larger than the maximum will be moved into the BADMIF directory.
NO client resynchronization request will be submitted.
The client will perform it’s normally scheduled delta inventory, the site system will see that it does not have a full inventory and will send a resynch request.
This process will loop indefinitely unless action is taken to reduce the inventory size of the client.
Possible Reasons:
The CCM_RecentlyUsedApps section of the inventory process can gather large amounts of data on systems that are used by many different users, such as Citrix servers, Terminal servers, and public/kiosk type systems. Since many apps are “recently used” by many different persons, the inventory size can balloon to exceed the maximum size.
You also may have added custom inventory items to the sms_def.mof recently and caused some systems to increase their MIF size past the dataloader's size limit.
Remediation:
Increase the maximum inventory size. The maximum file size for inventory is stored on the primary site server’s registry. The setting is in the key:
HKLM\Software\Microsoft\SMS\Components\SMS_Inventory_Dataloader\Max MIF Size
Increasing the maximum size is not recommended unless you have enough storage to accommodate the additional inventory size.
OR
Disable the CCM_RecentlyUsedApps section of the SMS_DEF.mof. By default, this setting is enabled for all systems. This setting can be turned off by modifying the SMS_DEF.mof file to turn reporting to OFF for this section. Custom MOF additions would be turned off in the same manner.
(Note: Custom metering rules for defined applications can replace the recently used apps inventory process to target specific apps.)
OR
If there are a defined set of systems and it has been identified why these systems are submitting large inventory mifs (public use computers, multiple and kiosk type users, etc...), you may want to disable the CCM_RecentlyUsedApps only on the affected clients.
There is a method of modifying the WMI repository on individual clients to turn this inventory process off by compiling a local policy on the remote clients. I would not recommend this unless you really have to because, when creating reports based on the recently used application information, you have to take into account that these systems may be using an application and it's not being reported. If you are going to take action with the data, make sure you don't accidentally uninstall an application on these systems because you don't *think* they're using it.
Bad Syntax
The syntax of the file is incorrect.
Don't worry, A client resynchronization request will be submitted.
Possible Reasons:
Corrupt client data, interrupted inventory process, etc…
Remediation:
Not so sure. I've seen this a few times on clients and it seems that they always tend to come back in with an inventory file that works eventually. Sometimes, rebuilding the client and/or performing a WMIDiag on the system with the -sms switch helps. A reboot may be in order if the repository is found to be inconsistent. It will rebuild when the system restarts. If that doesn't help, a manual rebuild of the repository may be required.
When I get some more time, I'll be posting a script to parse through the badmif directory and give a little bit of information about what's going on. It will give you file sizes and names of clients submitting the files. You will be able to see the systems that repeatedly are submitting bad inventory files instead of staring at a collection of systems that do not have a recent hardware inventory time stamp.
0 Comments