Make Sure Your Infrastructure Supports Multiple Packages per Application, Even if Your Service Level Agreement Does Not Print E-mail
Written by Darwin Sanoy   
Thursday, February 10, 2011 5:50pm

"We are not supporting 64bit.", "We are going to do one .MSI package for XP and Windows 7."  Sound familiar?  It is always best to support as few variants as possible, but make sure you do not paint yourself into a corner.

IT groups are always fighting the relentless push to support multiple platform variants - and they should.  It is important, however, to realize that your technical designs should be more flexible than your policy.

Lets use an example.  Suppose your IT group decides that it is best to have one .MSI package for XP and Windows 7.  Makes sense right?  However, your IT group then builds a distribution directory structure that presumes this policy can be met 100% for as long as Windows XP is in your environment, then you are putting your design at risk that at some point in the future it will need to be redone to accomodate those software applications that simply cannot be made to fit into one package for both platforms.

So tell your users "We will not support 64bit.", but make sure your directory design or your master package kickoff script can support it if you are forced to.  You many not even need to have an entire directory level place holder to accomodate this, but rather just have a pre-designed plan to expand to support it.

It can also be helpful to utilize a script that probes the directory structure to discover what should be run on the client.  .NET uses this approach extensively (actually it's used all through the process of loading code in Windows - when searching COM DLL registration data in the registry and when using SideBySide DLLs.)

The main point is that purposely or inadvertantly leaving out the possibility of supporting multiple packages for the same software application usually does not prevent the need to support it when push comes to shove.

As we look at some examples here, I am not assuming any given packaging technology - it could be setup.exes, MSIs or virtualized apps.

For instance, maybe your directory structure is currently like this:

"<letter or unc>\software\adobe\reader\version 8\"

and your agree upon strategy is that the "Version 8" folder is for all the install packages that works across all variations.  Then if you need breakouts, you also support:

"<letter or unc>\software\adobe\reader\version 8\XP"
 "<letter or unc>\software\adobe\reader\version 8\Win7"
 "<letter or unc>\software\adobe\reader\version 8\Win7x64"

or maybe you explicitly identify the level that works across multiple variations like this:

"<letter or unc>\software\adobe\reader\version 8\ALL"
"<letter or unc>\software\adobe\reader\version 8\XP"
"<letter or unc>\software\adobe\reader\version 8\Win7"
"<letter or unc>\software\adobe\reader\version 8\Win7x64"

*ALL would be "ALL others that do not have a specific subfolder"

Any automation scripts that access these folders would need to probe for a sub-folder that fits the platform and situation they are running on when they attempt to start a package.  You can even support both the above methods with a probing script.  Check if the ALL folder exists, if it does not then expect the files to be in the "Version 8" folder.

You can even go farther and support multiple deployment technologies if necessary.  In the below scenrio you might find the files at the Win7 level if there is ONLY ONE way to deploy the application.  Or if it supports additional, you woud find subfolders related to those deployment technology options:

"<letter or unc>\software\adobe\reader\version 8\ALL"
"<letter or unc>\software\adobe\reader\version 8\Win7"
"<letter or unc>\software\adobe\reader\version 8\Win7\MSI"
"<letter or unc>\software\adobe\reader\version 8\Win7\App-V"

We do have a script in our toolkit that can help you accurately identify the bitness of your OS for doing a breakout along those lines.  It is CSI_GetBitness.vbs.

I like this method because even if you've already made the mistake of designing for only one package variation - the above helps you fix it up.

Drop a comment if you've found a clever way to accomodate multiple platforms!


Add comment

Security code