Ok started at a SCCM shop... first time using the tool...

I am VERY particular how I structure my deployment objects, I like it clean and standard (MY standard).

When creating a package by definition (msi file directly), it seems to auto-create package names by default: %MANUFACT% %NAME% %VERSION% %LANG%

Can't stand this auto-creation, vendors change their meta data all the time, different versions of same software is all over the place because they changed "Adobe Incorporated" to "Adobe Inc." etc I also hate the 5 different programs SCCM auto-generates when using msi definition.

Well we have thousands of packages, and as "the new guy" I can't find anything easily since everything is sorted by manufacturer first, which I hardly ever know unless its adobe or MS. (Don't ask me why I don't like search...lol)

Well I noticed this auto-created name for packages are based on the general properties field of the package. I asked if we could leverage this for organization, but was told MIF files and reporting is based off this so things could get messed up.

I did some testing... running known bad cmdlines with and without the msiexec.exe /m switch... SCCM seemed to report status and error codes just fine.

Am I missing something, everywhere I read MIF are required. Even read you should use MIF matching based on package properties due to issues rerunning a failed deployment (2 msi running error etc). Even found a few posts where people said to avoid MIF???

So I am looking into manually creating packages/programs, not worrying about MIF file matching? Also looking into using Installshields SMS file generation with a modified template...

What would I miss if I do NOT use the /M switch or if I leave fields blank (or customize) the general package property fields for easier organization?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
0
Still more researching... the more I look the more it seems MIF is nothing but problems for msi

http://blogs.technet.com/b/configurationmgr/archive/2009/12/07/rerun-of-failed-advertisements-does-not-work-as-expected-when-you-use-status-mif-files-generated-by-windows-installer.aspx

Here they say using the default msiexec.exe /m command switch setup by SCCM if creating a packaged based on definition (using msi file directly), along with the Reporting Fields (which is set by default by SCCM) causes reinstall issues if there is a failure.

Not only that but it looks like the only benefit is possibly getting the description of the error code in sccm reports. Since that is the only additional information the mif generated by msiexec offers...

Anyone see a problem to this logic? The only thing I can see needed a MIF (At least for msi) is if for some odd reason the msi returns a code other then 0 for a success????

I guess the main question is: Is this specific MIF used for anything other then advert status?

EDIT: Looks like I have found my answer... Short answer: NO the MIF created by msiexec /m and MIF matching settings in an SCCM package ONLY refer to Advertisement Status Reports. The MS Blog above pretty much says MIF for msi installs is virtually useless (if you can google error codes).

http://social.technet.microsoft.com/Forums/en-US/configmgrinventory/thread/5bfd9163-d889-4ba6-8b90-f0654c875eb6/
Answered 08/16/2011 by: dandirk
Third Degree Green Belt

Please log in to comment
Answer this question or Comment on this question for clarity