SCCM Tips. Fixes and Guides

Dealing with Bad Mif files in a VDI environment

Whilst doing some housekeeping for a client recently I discovered that the SCCM inboxes were littered with bad mif files. Hmmm time to do some investigative work.

Bad MIF files occur in the following situations:

MIF file size is too large, as I know in SMS it is limited up to 5,000,000 bytes

If a NOIDMIF or an IDMIF can not be parsed successfully because syntax errors meaning simply that it is not formatted correctly.

Each mif file can be opened in Notepad and I noticed that mif files being created in the C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\MajorMismatch folder were all coming from VDI devices and that the physicals were not generating the files. Ok so I’ve narrowed the problem down a little.

If you open a mif file you can get the hostname of the affected device. So I then took at look at the dataldr.log on the site server. The dataldr log file processes Management Information Format (MIF) files and hardware inventory in the Configuration Manager database in case you were wondering.

Ok so I thought there must be something wrong with the original installation of the client on the VDI master image if only virtual machines were affected. I cast my mind back to the original installation where I’d followed advice from The Citrix Blog.

‘When you create cloned/streamed machines from that master image, the SCCM agent will automatically generate and store machine IDs that persist for the life of the VM. Your virtual desktops will register and behave exactly like their physical counterparts. One record per machine and that machine will continue to use the same ID across reboots. ‘

Great – set it and forget it – welcome news to the IT admin. Unfortunately this is not the case and the bad mifs are being generated because of this approach.

So how to fix.

It’s simple but adds some extra steps to prior your VDI master image and you’ll need to do this every time you update.

Stop the SMS Host Service – to do this run the command net stop ccmexec as an administrator

Delete the SMSCFG.ini file from the Windows folder – to do this run the command del %WINDIR%\smscfg.ini

Delete the SMS certificates – to do this run the following line in PowerShell – Remove-Item -Path HKLM:\Software\Microsoft\SystemCertificates\SMS\Certificates\* -Force or from DOS using powershell -command “Remove-Item -Path HKLM:\Software\Microsoft\SystemCertificates\SMS\Certificates\* -Force”

At this point shut down the master image and create your snapshot that will be deployed to end devices.

Note that I had to uninstall and reinstall the client the first time on my master image prior to running the steps above. I was then able to update my master image from then on with the steps outlined above.

Now when I deploy out the VDI devices in the estate they are no longer reporting bad mifs. One downside to this is that the WMI changes force the VDI’s to run a full inventory at start up but I’m happy to live with this until there is a permanent fix to Citrix’s ‘Set it and Forgot it’ option. You can see this in the clients InventoryAgent.log file.

I’ve been dealing with the bad .mif issue with provisioned devices for months. Even after following the recommended steps here. For these devices I curently have the hardware inventory schedule configured in client settings to run every seven days. Wondering if the frequency shoud be increased to daily. How often should hardware inventory be set to run on provisioned devices that reboot daily?

I noticed today our BADMIFS\MajorMismatch is almost 27GB big, and stumbled upon your blog.
Need to test it myself, but thank you a lot for this. Very helpful.

One thing I noticed when copying the last line, is that the quotes somehow are copy/pasted in their font type or something like that.
Even in Notepad, although if you look closely you can see it’s not alright.
Executing the batch file or even just the line in a CMD gives an error (I have it in Dutch, and not sure how it would translate in English).

Yes sorry about that I need to update it. What version of XenDesktop btw? I’m about to configure SCCM for the latest version and would be good to know if this issue still persists. Let me know how it goes Tom. Cheers Paul

Currently we run 7.6, but have recently build a brand new 7.9 setup next to it.
7.6 serves run on Windows Server 2008 R2, 7.9 servers run on 2012 R2.
Nothing has moved yet, as we need to export/import the polices first, and then I will build a image using a Task Sequence which will end up on the PVS 7.9 servers.

SCCM is 2012 SP1 and I want to update to 2012 SP1 CU5, sinec I need to build a Task Sequence for Server 2012 R2 (used for XenApp on XenServer with Grid cards) and support was added with CU3.

So sorry to say I don’t have any test results yet, and won’t have them till second or third week of October.
Hopefully. Depending on priority switches here…

One question: Do you know of a way to do the fourth line using PowerShell?
Remove-WMIObject or some CmdLet like that?