Software Deployment

The single-most important advantage of re-packaging legacy installers is that you get to learn exactly what the installer is tryng to do with your carefully crafted workstation build. One of the earliest lessons you learn in this game is: never trust a vendor's installation package. More than several are more than happy to walk all over the files in your System32 folder!

Part of your question was answered, and I agree with others in this post... However, no one addressed the advantages to using the Vendor's setup method without Repackaging it. So I will attempt to give you the high level advantages to that method...

1) It normally speeds up your turn around time (depending on the vendor) alot of the logic has already been addressed for their install. For Instance AutoCad has a deployment tool that creates an INI file an MST to get their product installed. Their tool handles all of the prereq software that was needed when you ran the deployment. So, if you wanted to break it out, you would have to pre install all of the .net, vcredist 2008, 2010 xml, farosdk, and what every else you selected when you did the deployment, and then, install the main Autocad MSI with the newly created MST.

Or you could run the vendors setup.exe /l AdminImage.ini /language en-us /qb

2) in some cases the vendor has already considered what to do if a previous version of their product is installed on the pc, So make sure that you address that if you create something else that does not use their installers logic.

3) its been my experience that slightly more than half of the software created by vendors will have some method of an unattended install and uninstall. Most of them have it published somewhere, a few do not. Using their method of installation, might make the difference between them offering support or NOT.

The bottom line is, what ever method you choose, make sure that the route the packager chose to get a piece of software to work in your environment, it really needs to be documented. After all, there is a good chance that the vendor will be around long after the packager has finished his part. If the next packager can't pickup where he left off due to bad or no documentation, then you might be better off sticking with the vendors documented installation method.

There are lots of advantages with repackaging applications like, we can customize applications to a greater detail to suite the user needs, and simplify the installation and un-installation procedures. It also helps us to save space by doing modifications to the application installers. We also have a feature of scriptable APIs with repackaging software which helps us with MSI file manipulations and thus avoid unnecessary application deployments or failures.

We can also have a great flexibility of obtaining lost or corrupt files through a phenomenon called self heal i.e, application recovery can be improved. Also, upgradation of the application can be done with ease.

While I agree to the previous comments, I'd like to add that you may also be at the mercy of a vendor's ideology or idiocy. For example, since Microsoft released Office 2007 and went back to using EXE's along with MSI's, I have found that packaging standards (as if there was ever such a term) have gone horrendously awry. It doesn't help much that InstallShield is pretty much the de facto standard in packaging and everyone seems to feel the need to make their packages mangle the OS.

Basically, do what is best for your environment without sacrificing integrity while keeping licensing and future support always in mind.