Software Deployment

All you need to do to answer that question is watch what a selection of vendor's Setup programs do to your carefully-crafted standard workstation build. Sometimes, the activity undertaken has to be seen to be believed.

ALWAYS repackage - or apply transform(s) if supplied in MSI format - to vendor-supplied setups. There will of course be exceptions which you will allow ONLY if you know EXACTLY what they're going to do to your workstations. Those exceptions will be driven by time pressure or, commonly, the simple fact that repackaging would be counter-productive in terms of effort spent versus potential gains.


All you need to do to answer that question is watch what a selection of vendor's Setup programs do to your carefully-crafted standard workstation build. Sometimes, the activity undertaken has to be seen to be believed.

Its just 6:45 am here. Would you be more unclear? :)

Why always repackaging? Why not just using the commandline to use the manufacturer's setups? In fact, my understanding is never repackage unless, it is counter productive of finding a way to install ?!

What I'm saying is that vendors *generally* have no regard for the integrity of your corporate build. They will happily overwrite the system files which you have carefully selected to provide the most stable operating environment for your users. It isn't unknow for them to downgrade such files, for example. This is particularly true of older applications.

The 'never repackage' advice is for those setups which are provided already in MSI format (even though they might be encapsulated in a Setup.EXE).

The reason re-packaging came about initially is that many manufacturers didn't provide means for silently installing their products. Also, if there were special configurations to be set after the install it was easier to repackage and make them all one thing.

We support about 60,000 machines. When possible we don't repackage but we do wrap. What I mean by wrapping is that we use the manufacturers installation but put it in a Wise Package so that we can check for and do other things as well. Ultimately though the manufactures install is being used. This has been a big time saver and also makes troubleshooting easier. Several times we have gone back to the manufacturer of the software and let them know of a bug in their installation.

So, always repackage? No. However, don't abandon those skills as they come in handy.

Why always repackaging? Why not just using the commandline to use the manufacturer's setups? In fact, my understanding is never repackage unless, it is counter productive of finding a way to install ?!


For one thing, the manufacturer's setups would involve a lot of manual steps. Also, how would you ensure that everyone installed it the same if it's done manually?

One of the many cool things about MSI technology is its native ability to run silently. You don't have to do anything special with it, just feed it a /qn switch, or whatever amount of UI you want. Once you get it set up, set the UI level and push it out - voila, the same install on every machine.

However, many if not most vendors are going to MSI so repackaging isn't the issue that it once was.

Most manufacturers are provinding silent install switches as well. If you get a look to Microsoft Visio 2007 or Project 2007 , you will see /Q is not working.... They found another way.

But sometimes, their MSi are not silent compliant.... SAS ABM or are setup driven or the setup.exe is using a MSI and exe files to complete the setup.

ORIGINAL: Francoisracine

Most manufacturers are provinding silent install switches as well. If you get a look to Microsoft Visio 2007 or Project 2007 , you will see /Q is not working.... They found another way.



Well office is always special don'tcha know....[;)]
Actually it is MSI based but you do have to use seup. In this case you encode the UI in the setup.xml file....
this oughta get you started on that.

ORIGINAL: Francoisracine

But sometimes, their MSi are not silent compliant.... SAS ABM or are setup driven or the setup.exe is using a MSI and exe files to complete the setup.


....however that's not Windows Installer standard. That's the vendor crippling the MSI to force you to enter the license key or whatever.

Sometimes such vendors will provide you with resource kits for deployment to get around their limitations...adobe and msft do.

This one can have so many arguments one way or the other and the best that most of us can offer is how we do it and why.
Environment background: 22,000 workstations, SMS, 20 sites with different support staff, standard image, standards followed, 98% of the automated installls are done by me. I'm a busy person and I'm sure that most of you are too, so why reinvent the wheel? If the vendor provides the methods to do a silent install, I say use it. I don't repackage it unless it's something one of our developers have created or I have no other option.

I use MSI for installs created from scratch or for a repackage. I use an exe for any other wrapper and I have templates that all I have to do is typically fill in some variables and it'll take care of the rest.

Someone touched on a good point earlier about knowing exactly what their install does and that's part of why i don't repackage. Without having full knowledge of their setup script, it's almost impossible to tell what support they have and what I'll break by repackaging.

So use hte standard install methods and switches until Adobe and Microsoft get on a high horse and think that they'll just go change everything and screw the majority of us out there by coming up with new install types that don't work like we've all gotten used to.