Skip to content

January 26, 2011


FEP Installation – SCCM Inventory No Longer Works

As you may already know, Microsoft’s latest antivirus product, FEP (Forefront Endpoint Protection) integrates very tightly with the Configuration Manager 2007 product.  When we rolled the product out, everything went smoothly throughout the installation process, but once we got the product installed and deployed we started seeing a few issues.

We quickly found that the FEP installation broke SCCM’s Inventory features (Software and Hardware Inventory) in our central site.  The FEP infrastructure is also very dependent on these roles.  We found that none of the FEP collections were being correctly populated, notifications did not work, and report data was not available (FEP dashboard did not have valid data).  However, the FEP client installs via SCCM worked just fine and policy distribution was working as expected; just the features mentioned previously did not work properly.  We found most of our clients were getting tagged as “Locally Removed”, which was not correct.  However, everything continued to function at my child sites, but FEP Server services were not installed in those sites specifically (they are leveraging from the central site).  Clients in our child site, were properly getting marked as deployed, collections were accurate, and reports worked as expected.  After some digging I found the following errors in our Central Site:

On the SMS_INVENTORY_DATA_LOADER (Message 2703):

SMS Inventory Data Loader failed to process the delta MIF file “XHIS9QJA2.MIF” and has moved it to “C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\\BADMIFS\sbklk1e3.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.


SMS Software Inventory Processor failed to process software inventory file “C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\\2DOF71GM.SID,” and has moved it to “C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\\BADSinv\d3vjuy2u.SID.”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 subsequent message 3703, which indicates the resynchronization has begun.


MP has rejected a policy request from GUID:67721D88-256E-4282-AF9A-71D0AF14E4FD because it was not approved.

These errors would be in the logs hundreds of times in matter of seconds.  Unfortuantely, the fix we found was not a simple one and is somewhat disruptive to the SCCM environment and time consuming.  We preformed the following steps on our central site:

  • Uninstall all Site Systems that use IIS
    • Distribution point (turn off BITS)
    • Fallback status point
    • PXE service point (also remove WDS)
    • Reporting point
    • Software Update point (also remove WSUS)
    • Management point
  • Remove SCCM Client from Site Server
  • Uninstall IIS/BITS/RDC
  • Reboot Server
  • Reinstall IIS/BITS/RDC
  • Reinstall Management Point
  • Reinstall Site Systems and their associated services (re-enable BITS for Distribution Point)
  • Reinstall SCCM Client on Site Server

In general, SCCM will remember how many of the items were configured before the reinstall, saving a lot of reconfigure time.  Most importantly, the database and site code hierarchy is not disrupted.  However, this process will keep SCCM very busy for a while as it re-catalogs a lot of data.  In our case it took overnight for our SCCM server to fully catch up and be 100% functional.  An example of this is, immediately after reinstall every Software Update gets marked as expired.  Until SCCM reprocesses every single update, they do not get marked as unexpired and are not available to clients.  Once everything in SCCM caught up, everything was functional in both SCCM and FEP.  We have had no further issues.

Read more from FEP, Microsoft
4 Comments Post a comment
  1. Brandon
    Nov 1 2011

    We are having this issue as well and we also need to re-install our site on a new server. If we re-build SCCM using R3 how do we avoid this issue from happening again?

    • Brent
      Nov 2 2011

      Brandon, I have never been able to reproduce this issue on a new installation, it has always “just worked” as it should. Unfortunately, I don’t know any way to “prevent” it from happening as I can’t make it happen on demand. I’ve only seen it happen in production environment (that is a year or two old), but never in a new lab setup. My guess would be that if you have a clean new site and new installation, it will probably just work (hopefully). Having a clean rebuild should be similiar to steps above, just more details of doing everything not just the components above. Sorry I’m not more helpful…

      • Brandon
        Nov 2 2011

        In that case in your mind what would be best practice
        1) Keep FEP running and install SCCP
        2) De-commission FEP install SCCM and instal FEP
        3) ..?

        Thank you for your help.

        • Brent
          Nov 3 2011

          If you are essentially “starting over”, then yes, I would decommision FEP, and then SCCM. Then on the new server install SCCM (confirm all systems are working), then install FEP. Also, if you are fully decomissioning and starting over, it is recommended to not use the same site code, it has been seen in the past that reusing a site code can cause issues. Your other option is to do a side by side migration (so you don’t loose packages, etc.), but that might not be as clean as you are wanting.


Share your thoughts, post a comment.


Note: HTML is allowed. Your email address will never be published.

Subscribe to comments