how to best deploy apps without repackaging?
After spending much time on repackaging applications (to MSI packages), I came to one conclusion: it's time consuming and mostly completly unreliable.
Most of the software come with a silent installer anyway, so why to produce something unreliable ("repackaged" MSI), when it's often enough to run a silent installer?
So I searched for a tool with which I could deploy packages which have a silent EXE installer.
Among many that cost lots of money I found one free solution - WPKG - http://wpkg.org
It claims to be able to deploy any software that come with a silent installer (MSI, EXE, script, etc.), upgrade software, and remove software, and can be used with Active Directory or Samba.
Is anyone using it?
If so, what are your opinions about it?
Most of the software come with a silent installer anyway, so why to produce something unreliable ("repackaged" MSI), when it's often enough to run a silent installer?
So I searched for a tool with which I could deploy packages which have a silent EXE installer.
Among many that cost lots of money I found one free solution - WPKG - http://wpkg.org
It claims to be able to deploy any software that come with a silent installer (MSI, EXE, script, etc.), upgrade software, and remove software, and can be used with Active Directory or Samba.
Is anyone using it?
If so, what are your opinions about it?
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
craig16229
18 years ago
Micro,
Welcome to AppDeploy.
I am not familiar with WPKG. I will have to check it out and see what it offers. Another option you might want to investigate is pushing your apps with SysInternals PsExec tool. There is a short article here:
http://itninja.com/blog/view/command-line-printer-control-in-2000/xp9
Although the tip talks about pushing .msi's, the principle could be applied to pushing other types of silent installs. Of course, it cannot do anything more with an application that what that app supports via command line.
As for repackaging into .msi - what tool have you been using, and for how long? One of the top ten myths on InstallShield's site about repackaging into .msi is (paraphrased) that all you have to do is buy a tool, take a before and after snapshot of an installation, and compile.
The truth is that that repackaging into .msi (or into any other format) is extremely involved, and requires specialized knowledge/training. That is one of the reasons AppDeploy exists. I know that I continue to find it an invaluable resource.
I will wholey agree, though, that an .msi that does not fully work or is not reliable is not worth having.
The advantages, though, of having a quality .msi are great. Among them, are:
1. being able to install with elevated privileges to non-admin users
2. self-repair capability
3. the ability to create patches and upgrades
4. the ability to push a package via various methods: VB scripts, AD, login script
5. a tremendous ability to customize
This last one is very important in our environment. One of our initiatives is for workstations to be locked down. We build custom actions into our packages to modify security selectively for applications that natively will not run for a non-admin user.
It really comes down to return on investment when it comes to repackaging. We are a network of only 400 client nodes. If we had to go outside for our packaging, we would probably not be doing it at all. I started pitching the idea when I came aboard, and there was skepticism. Eighteen months later, the skepticism is gone. Techs like being able to go to one place, not worry about finding media or license keys, step through dialogue boxes, manually adjust security, etc.
Craig --<>.
Welcome to AppDeploy.
I am not familiar with WPKG. I will have to check it out and see what it offers. Another option you might want to investigate is pushing your apps with SysInternals PsExec tool. There is a short article here:
http://itninja.com/blog/view/command-line-printer-control-in-2000/xp9
Although the tip talks about pushing .msi's, the principle could be applied to pushing other types of silent installs. Of course, it cannot do anything more with an application that what that app supports via command line.
As for repackaging into .msi - what tool have you been using, and for how long? One of the top ten myths on InstallShield's site about repackaging into .msi is (paraphrased) that all you have to do is buy a tool, take a before and after snapshot of an installation, and compile.
The truth is that that repackaging into .msi (or into any other format) is extremely involved, and requires specialized knowledge/training. That is one of the reasons AppDeploy exists. I know that I continue to find it an invaluable resource.
I will wholey agree, though, that an .msi that does not fully work or is not reliable is not worth having.
The advantages, though, of having a quality .msi are great. Among them, are:
1. being able to install with elevated privileges to non-admin users
2. self-repair capability
3. the ability to create patches and upgrades
4. the ability to push a package via various methods: VB scripts, AD, login script
5. a tremendous ability to customize
This last one is very important in our environment. One of our initiatives is for workstations to be locked down. We build custom actions into our packages to modify security selectively for applications that natively will not run for a non-admin user.
It really comes down to return on investment when it comes to repackaging. We are a network of only 400 client nodes. If we had to go outside for our packaging, we would probably not be doing it at all. I started pitching the idea when I came aboard, and there was skepticism. Eighteen months later, the skepticism is gone. Techs like being able to go to one place, not worry about finding media or license keys, step through dialogue boxes, manually adjust security, etc.
Craig --<>.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
