Software Deployment

Interesting thread.

Been working with Installer technologies for 7+ years now and I still come across somewhat troublesome applications (a rough estimate would be ~10% of the apps). Thankfully I haven’t seen it all if that was the case, my job would become boring as hell.

I’m in great favour of MSI packages over Legacy Installer, because Legacy Installers are much less reliant and usually requires a lot of “manual” maintenance (Install, Configuration, Uninstall, Upgrade), usually badly documented, if at all (what’s the freaking silent switch!?), lack of logging options (What the hell went wrong during install!?), What is this Legacy Installer actually doing? (Who/what downgraded xxx.dll!?) I think you get the picture ;).

Needless to say, I aim to repackage all Legacy Installers I stumble upon with a very few exceptions (usually because of vendors not supporting the application if repackaged or if vendor supplied patches are pushed frequently) in the end it’s a matter of cost vs. benefit.

In regards of knowledge I would say that for me personally ~95% comes from getting My hands dirty, and the rest is by studying whatever material is available on the vast information highway. And I’m sure people would agree that knowledge of programming and database structure is a plus when starting working with MSI, but not a requirement.

/Matias

Nothing much to add to that, bar saying that the lack of support from vendors owing to re-packaged applications has never bothered me, mostly because vendors either a) employ monkeys on their support desks, maing "lack of support" pretty meaningless; b) know next to nothing about their applications' use in our environments or c) know next to nothing about their applications!

To expand on Matias's notes about legacy installers, I *always* re-package these because I want to know EXACTLY what the installer is going to do to the client's workstations. It never ceases to amaze me that people let vendor's installers loose in their estate.

As a contractor in the field, I've worked at a couple companies now and am amazed that the difference in philosophy regarding vendor vs repackaged installs. One place I worked at insisted everything be an MSI, irrespective of what it took. one place said "do nothing to the vendor install and script out major non-transformable changes" .

I've tried talking to vendor packagers on occasion, and came away with the impression that these were just assigned to do packaging (one couldn't even assign a new non-duplicate product GUID). So I agree with above notes that vendor packagers are not always the best in the field.

I'd say that roughly 90% of what I do is routine, bang it out, move on, thanks very much and 10% is the puzzle that keeps me challenged. My background is in desktop support - it helped a little bit but as a person who has hired packagers, I find that intellectual curiosity and sometime sheer stubborness are more indicative of success than eduction/training.

hi Brettski,

i noticed nobody commented on the programming background. I can assure you this definately helps. Although I would hardly call myself a fully fledged developer I have a strong dev background and found that understanding coding practices certainly helps a lot. Particularly if you venture down the build / release path of packaging.

I personally am a massive msi advocate mainly because I can coax an MSI to do pretty much anything I want. I have seen some very weird packaging standards over the years. My favourite is my current site which insists on wrapping all MSI's in a self extracting exe. Installing then deleting the source media. (believe me I gave up trying to explain why this is stupid).

Needless to say the company I work for is currently getting slogged in the media for the worst IT department in the country.

I think the entire packaging landscape is changing rapidly so MSI is no longer the supreme packaging solution. At the end of the day each environment is different no one rule fits all sites.

I pretty much agree with Matias and vbscab not that i do much packaging these days. I found that got very boring many years ago.

I've been deploying software using a variety of of different methods for ~11years and all I can tell you is there are good software vendors and there are bad and to make it worse, they all have their bad days/months/years. I'd sight Adobe as a perfect example of a company that has gone through many transitions from good to bad to WTF were you thinking and then back again. And Microsoft doesn't help by changing the OS and Windows Installer. Win7 and Office 2007/2010 being examples of how older methods of software installs and best practices may no longer work the same using newer technologies.

I haven't had to repackage much lately (lucky I guess), but earlier on I used to if there was no other way to automate the installation. Actually, I prefer not to repackage when possible because if there is a problem afterwards, its hard to get vendor support. I'd have to say that I guess its just part of the software/packaging industry that you are going to have easy packages and some that will force you to think way outside the box.

I find that as time passes (I've been doing this for about 8 years now) more and more installers actually are, or contain, MSIs nowadays. So part of the skillset is being able to sniff these out and work with them.

When it comes to legacy installers, my initial preference is to repackage them into an msi. Not only does this allow much tighter control on the installation, and much more customisation... for me personally, I don't want to count the amount of times when an application that actually installed ok silently, then turned out to be an absolute HORROR to get uninstalled afterwards. Also the clients might want some very specific tweaking done to the installs, and having to build an entire scripting framework around an installer just to get a couple regkeys or a file modification in place (not to mention user settings) is just not worth it to me.

All that being said though, if strapped for time I will use silent install switches, IF there are no big customisations needed, and I know I can also get the application off the machine cleanly when the time comes.

Concerning problematic packages, with the years I have learned to balance the part of me that wants to dive in and get to the bone of every problem with an installation, and the part that knows that some things you just have to accept, and that packages tend to have a deadline. Without wanting to sound bigheaded, most problem packages nowadays are applications that you just cannot install silently, or automatically (machine specific licensing data / online activation comes to mind). Sometimes you just have to do the best you can and explain why you're limited and have to leave some stuff to be done by the users.

In finishing, the advent of new technologies like App-V and the like allow me to keep the interest in the field (which in itself has broadened alot for me, to include distribution, architecture, system design..) going since, let's be honest, as others said packaging can become largely routine. I still think that the limitations of these newcomers will allow MSI to remain a large player in the field for quite some time yet though, and it always helps to have it as a background when tackling the new stuff.

PJ

This is the question of "time - quality - money" on the one hand. And "experience - abilities" - on the other hand. No magic ;)

I'm quite surprised to hear so many people say they generally repackage vendor application installers rather than scripting around them (I like creating a second configuration MSI myself). Reading 'to package or not to package' articles on Microsoft and even AppDeploy I got the impression the general consensus is to avoid repackaging as the potential problems out weigh the benefits. I will have to re-evaluate that decision it would seem.

It's also useful (I'm not particularly surprised) to hear that having a background in programming is useful ... unfortunately I don't find my limit assembler language code experience is particularly relevant in this day of object oriented and Windows API based languages. But I might just need to finally sit down and learn some like I've been meaning to.

Thanks very much all of you for your informative responses, not just in this thread, but in all forum posts.

Brett

Hi VBScab,

You mentioned that you always repackage legacy applications as you want to know EXACTLY what the installer is going to do. Do you have a repackaging tool of choice? Do you know of some way to look inside vendor MSI CAs that are calling functions within DLLs also?

Brett

My packaging tool of choice is Wise package Studio but I can no longer recommend it as Symantec's development record in recent years has been, to be kind, woeful. They're clearly not interested in it as a product.

As for looking inside CAs in vendor's MSIs, there's no means to do that. The only recourse is to check the result with a lightweight snapshot tool like InstallWatch. I tend to regard those MSIs which consist entirely of InstallShield CAs (they always seems to be IS-authored...) as legacy installers. In those cases, I would retain them as MSIs but snapshot them, just to know what they're up to. Anything I thought suspect would be conditioned out and tidied up. On a similar note, any MSI which used the built-in Wise routines for creating web virtual directories and applications would be altered to run the Microsoft VBS scripts instead - MUCH more reliable!