Deployment-Ready Applications
A "Deployment-Ready" application is one that supports silent installation as well as command-line customization options without the need for additional work or tools. These are, by far, the best and simplest types of applications to deploy to the masses (aside from deploying shortcuts for web applications). These are usually .MSI packages, however some .EXE installers will do this as well.
Just as important however is that they also provide a silent UN-install capability. However, due to the nature of journalized or manifest-oriented installation technologies (like Windows Installer), items which are added or modified after the initial installation are typically left behind after an uninstall. This is where it helps to wrap uninstalls in script code to handle additional clean-up tasks.
The few situations that require additional work usually involve adjusting security permissions on files, folders and registry keys, but this can be handled easily. Options include script wrapping and Microsoft Application Compatibility Toolkit (ACT) shims.
Transform Applications
A "transform" application is a logical layer of customization added to an existing .MSI package. These are relatively easy to build and deploy, and only (very) slightly more work than a Deployment-Ready application. You can use tools like Wise Package Studio (soon to be defunct), Flexera InstallShield, or the ancient Microsoft utility: Orca. The net result is a .MST file which contains additional objects and properties that combine with the base .MSI during the installation process.
What a Transform won't do: Allow you to bundle security modifications to files, folders and registry keys. For that you either need to repackage again, or use a script wrapper.
Client-Sever Applications
The term "client-server" is pretty old, but in this context I'm referring client-side applications which require specific configuration or activation tasks to be performed on the server-side in order to make the two work together. This may involve one of the other mentioned application types (deployment-ready, transform, proxy) along with additional tasks to make it all work seamlessly for the end result: an unattended deployment.
Proxy Applications
A "proxy" application is one that (don't laugh) doesn't really exist. Many of you are probably familiar with this situation/scenario, but just in case, let me explain...
The word "proxy" means "to authority or power to act for another" (Merriam-Webster). In more contemporary terms (incorporating the long-standing use of such things as "proxy servers"), I would say it's more broadly defined as "an effective substitute". That's just me and I'm obviously not an English professor.
In many business environments, users tend to apply labels to things based on what the eventual use is, or will be. For example, you might have a Microsoft Access database with VBA code, forms and reports built in, and this "application" is used to order parts for a particular project or program called "TARFU". When you have a discussion with any of the users, they will almost certainly call it the "TARFU app", not the "Access database app for TARFU". So when you are asked to deploy it to users, they will expect to see a desktop (or start menu) shortcut named "TARFU" or something similar.
That's one example, but not really the one I have in mind.
Sometimes the application "TARFU" isn't really an application at all, but rather, a collection of files and components that are required in order to access and utilize a particular web site used for tasks related to "TARFU". Or, not to wear out the references to Access, maybe it's just the Microsoft Access Runtime with an accompanying database file. In either case, you would wrap all the necessary pieces up and give them a name. But what about the listing in "Add or Remove Programs" (ARP)? What about seeding the installation targets with the required things to support inventory collection and reporting? How will you identify the installation targets months later?
For example: If you deploy the Access Runtime and a database file, you won't likely see anything called "TARFU" in your inventory reports.
The solution is simple: wrap it with a new name. The best choice for this would be to repackage it into a new .MSI and force the labeling as "TARFU". This would not only create the necessary ARP entry, but solve the challenge of inventory reporting and, just as important, support an easy uninstall capability.
Complicating Factors
There are many potential complicating factors that can cloud the simplicity of a deployment. These are the buzz kills of software deployment. The party poopers. Among them are...
- Device driver installation and post-configuration
- Special activation tasks
- Per-user installation tasks that need to be applied to all users
- Removing previous versions of the same application before installing the new version
- Importing settings from a previous version into the new version
- Stopping services or processes at specific points during the installation
- Dealing with unusual COM and USB port interfaces
- Seeding files in order to pre-configure security permissions
It can be challenging, both in a good way and in ways that make you scream in anger and throw things. I've seen packagers call vendors on the phone and vent their anger directly at them. That's probably the most therapeutic and productive (the vendor gets a taste of what their customers don't like).
What Does This All Mean?
Keep in mind that I never promised to make a point here. I'm just making broad brush strokes over a very intricate and convoluted artful science. Ultimate however, what this could be summed up as, is to say that whichever of these types you're handed will generally dictate the level of effort, and hence the time, required to complete the deployment. And this is what drives most Project Managers completely insane.
0 comments:
Post a Comment