I am looking to find an alternative update solution for a software I have packaged for deployment known as DBC Finance. Quick availability and maintance time are the major reasons I want to evaluate performing the updates for this software differently.

The software is a legacy Installshield script that does not have silent installation capabilities due to licensing prompts not being retained even during a setup.iss recording. I have been unable to manually add the key either with a silent installation...

The way I have been deploying this software is by creating a setup captured MSI. This works great, the only problem I have is the amount of maintenance that this software requires due to the frequent updates.

In order to update the software, my current process is to install my package, run a Wise setup capture when installing the Patch, infuse the modified (I do a binary comparison with Beyond Compare) files into my WSI (exe, dat, ect.), rename the version, change the GUID, compile and Uninstall\Reinstall the package. In order to keep the User settings from being removed, I have currently set the CurrentUser key component to Leave installed on uninstall.

The vendor install allows for the client users to download and install updates from within the program, or to install from a local file. Recently, the vendor has provided the ability to deploy the vendor patches via a silent switch in addition to downloading via the software. Syntax: iupdated -s <full path to dbc .upd file>

Now that silent updates with the vendor patch are possible, I want to investigate the ability to allow for my users to install the updates themselves if they are in a rush (which is 50% of them) or working outside of the office. Additionally for the majority of the users, I want a quick way to deploy the vendor patch file (all file updates only, no dll registrations or registry keys) to the users on my network.

If I were to deploy the actual vendor Patch on top of my installed MSI, what I am concerned about is the MSI performing a self repair and replacing the modified files, or just causing possible chaos. The patching does appear to work over the MSI, but I am uncertain if there is a better way to open up and configure the MSI to support this action to allow for modification of files, particuarily the main .exe program files.

Any suggestions, or links as to how to best support this type of hybrid setup would be appreciated.
0 Comments   [ + ] Show Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


Wouldn't it be better to do it the accepted way, i.e. by having an Administrative Installation Point (AIP), from which all installs are driven? You would then patch the AIP as appropriate and install/re-install from there. How do you currently deploy?
Answered 12/03/2009 by: VBScab
Red Belt

Please log in to comment
My current environment: package MSI, deploy it to distribution points on my branch servers overnight via SCCM. Then advertise my re-install to target machines to update them. This works ok unless the laptop is off the network at the time.

My reasoning is not to promote laziness on my part, but rather to help my users install the updates as soon as the vendor releases them... they are rather itchy for them, as they tend to offer needed functionality fixes.

Unfortunately with so many projects going on, it is hard for me to drop everything I am doing to repackage the application immediately. So I am looking to see if there is a way I can use the vendor patch over my MSI so that if the end user needs it immediately, they can drop the patch from the vendor and install it, or they can wait for when I have the time a week down the road to deploy it the same way to ensure consistancy.

At the end of the day, If I can't find an acceptable alternative to doing this, I will continue on with my current process.
Answered 12/03/2009 by: Digitalweezil
Orange Belt

Please log in to comment
Hmmm...allowing users to update from the 'net sounds to me dangerously like you intend users to have admin-level privileges. Best of luck with that... :) Pretty soon, they'll learn that they can install anything they want so, how badly do users really need these fixes? Enough for you to allow the potential for compromising the machine build?

To be frank, if they need fixes that badly, you need to be looking at different software.
Answered 12/04/2009 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity