Application prerequisites in SMS (MIF Files??)

There are a number of applications in our environment that require another application to be installed first or at least before they are run. As an example, Frontrange's HEAT requires Microsoft .Net Framework 1.1. There are a number of other applications as well, so I'm looking for a general solution.

I know that I can use SMS's ability to install another application first, but what I'm finding is that if the prrequisite program is already install manually, then the SMS install fails and hence the advertised program won't try to run.

I believe that I could use a MIF file to tell SMS that an error code of xxxx, which is returned when a program fails because it's already installed, is actually a success. Is this the best option? If so, are there any good resources out there on how to create and use these MIF files?

Comments

Answers

0

Some installers, like Install Shield, have the ability to check for and install the prerequisites before installing the main app. But usually that means bulking up your install package to include the prerequisite. Microsoft would recommend making a collection with machines that have a particular version file (for the app you want to upgrade) and another for the ones that don't have the .Net framework and then deploying to them seperately. But that is just a pain.

I don't know of any easy solutions. Not too familiar with MIFs either. I would also like to hear about what other people do.

Without question the easiest way I've found around that same problem is via a script wrapper for the package. I'm not overly talented in vbscript, so I typically use wisescripts. The wrappers include a series of checks for dependent applications, and if it doesn't find them it calls those installations.

Thanks for the response. I'm using InstallShield but have some small idea how to use VBScript, so would probably stick with that. Do you have any information you could point me to regarding the process you use. I'm thinking things like what you check for (ie Add / remove program, registry or files) and how you go about calling a dependancy if required (ie where the install files come from or do you have some way to call another SMS object from within an MSI).

I was also wondering if there is a whitepaper on those MIF files, and qwhat they do.. :P

What i usually do nowadays, i create VBS files, with simple commandlines that installs the prereq. applications.. For instance, a newer version of the dotnet framework, if required by the MSI..

First; the GOOD.
The good thing about this is, you can feed the vb script an exit code for every commandline, and make it wait during the install of the prereq. So, if the MSI/App. needs dotnet 2.0, and it isn't installed, SMS runs the script, installing the dotnet framework, and then running the MSI. If the dotnet is already installed however, the silent commandline will return a value which the installer considers a failure. HOWEVER, since you provided an exitcode in the vb commandline, SMS will not hang on that and resume towards the next step in your vb script, assuming the installation worked, probably being the commandline which tells SMS to install the MSI.
Now, for THE BAD..
I've seem in some cases that SMS fails to install an app.. But if you check the reports from sms 2003 later on, they will tell you the program succeeded. So, deploying setups this way using vb scripts sometimes seems to mess up the exitcodes returned to SMS i guess.
I've decided that it is, in my case, better to have the reporting tool messing up sometimes, than to have an (re)packaged app that doesn't install at all, ior, even worse, hang during installation so you have to wait for XX hours before you can re-advertise or something.. I do think making use of the status MIF files might change the situation, but this is going to take some time for me to figure out, time i don't have ATM.. :)

If anyone know of a good whitepaper describing the use of MIF files in relation to SMS.. I'm all ears. :P

Thanks for the reply neo. As it turns out, .net 1.1 seems to be the only culprit I've come against so far, so I haven't bothered to look into it too much further. We're putting SCCM in shortly and I'm hoping it might have better options with regard to what happens when a program install fails.