Issues deploying Installshield package
I was wondering if anyone has come across this or can suggest anything?
I have an Installshield Package that installs correctly manually.
e.g. <UNC Path>\Setup.exe -s -f1"<UNC Path>\Setup.iss" -f2"%Temp%\Log.log"
or <Local Path>\Setup.exe -s -f1"<UNC Path>\Setup.iss" -f2"%Temp%\Log.log"
the command prompt is launched using the PDQDeploy Username and Password.
However, pushing through PDQDeploy, the installation finishes (successfully), but the application hasn't been installed properly and crashes after a runtime error occurs. This does not happen if I install it manually with the same command lines.
The same result if I use the UNC path as the command line or use PDQ to copy the folder locally and execute it locally.
0
Comments
Can you post a screen shot of your package step(s) please?
Here's a screenshot of my package. I have narrowed it down to this step being the issue. (If I allow PDQ to perform the previous steps, then manually deploy this step, and then let PDQ to deploy the remaining steps, the application works okay.
I am on a trial license so this is time sensitive. This is one of our vital applications, and is the make or break of whether I purchase the full license.
the f1"blah blah blah." and -f2 bits again don't have spaces between them. That actually works when ran manually via command line? That's not a typo in that particular step? Just for kicks and giggles change that line to -f1 "blah" and -f2 %WINDIR% etc etc. and let me know what happens.
No, it's not a typo, I can try it with spaces, but I can guarantee that it won't even install (remember it is currently doing the install with the correct response file and reporting a success - the application is installed but causes a runtime error).
From : http://publib.boulder.ibm.com/tividd/td/framework/GC32-0804-00/en_US/HTML/instgu25.htm
-f1response_fileSpecifies the file name and location of the customized response (.ISS) file. Do not include a space between -f1 and response_file. If you do not use this option, the default setup.iss file is used.
-f2IS_log_fileSpecifies the file name and location where the InstallShield log files will be written. Do not include a space between -f2 and IS_log_file. If you do not use this option, the default setup.log file is created.
Can I see the runtime error that you get after you deploy this package as is to a client?
This is the error I'm getting. The application is a client/server application. It opens fine to a logon screen, and after entering the credentials (yes they are correct), it attempts to connect to the database and then fails with this error.
For kicks, try the workaround found here: http://support.accountingfilerepair.com/error-this-application-has-requested-the-runtime-to-terminate-it-in-an-unusual-way-error-occurs-after-login-to-300-erp-database-2/
If that works we can script our way around the error (thanks powershell!)
This might be due to PDQ copying the files to the computer and running them from there instead of running them from the UNC share. Try using a Command step instead.
HI Stephen, the link you provided is not a workable solution as it suggests installing System Manager on the local workstation and then changing the paths. I believe this solution is designed for an environment where the executables are installed on a Network Share as installing the System Manager on the local workstation is precisely what I am trying to accomplish here.
Colby, thanks for the suggestion, but unfortunately I have also tried this with the same result.
Ohhhhh. Ok. I'm sorry, I misinterpreted the link then. Sorry about that. Could it possibly be something related to the C++ Runtime? What does the Event Log say? Open the application, let it error, and then check the logs for more information. Maybe a class isn't being registered correctly because it isn't running in the userspace?
Perhaps adding a step that silently installs the C++ Runtime after you install the software will work? I dunno, I'm very much pulling at straws with that suggestion.
Looks like I've made some progress ....
It appears that a command that is supposed to run during the application install which registers the application's dll and ocx files (we'll call it "REGACC") is crashing when it is being run by the install.
This isn't the end of the world as once the application is installed I need to install some other plug-ins and re-run this command anyway.
However, I am unable to run the command successfully via PDQ at all. If I run it manually as an administrator, it is successful.
Obviously the command needs to be run as Administrator.
When I run it using the "Command" step in PDQ. It returns the error 255.
However, if I am logged in as an administrator and configure PDQ to run it as the logged in user, it successfully completes and my application works.
Any ideas on how I can force this to run successfully? (Configuring it to run as the Deploy User interactively also fails).
Command steps are already run in an elevated mode. Does the account you are using in PDQ Deploy have administrative rights to the machine?
All my deployments use the local administrator account of the machine.
Hi,
Yes it does, my point was that I can't use the option to use the logged in user (which is the only way I have got it to work when the logged in user is an Administrator) so need to find another solution.
The issue might be that you are deploying to a 64 bit OS. Do you have the C++ runtimes in both (x86 and x64) versions installed? If you have thepossibility to deploy to a 32 bit OS, please test it.
There is a difference when you run the setup from a command line (CMD) as its 32 bit. The deployment runnner is a 64 bit application.
You can try one more thing. get a 32 bit WinRAR application. Create a batch file like setup.cmd. Put the installation command line in there. Then create a selfextracting package where you specify the setup.cmd to be executed after extraction.
If you need more help, jsut say so.
BTW I found this accpac related site where you might find some usefull diagnostic info.
Thanks for the response and the advise, unfortunately this hasn't got me any further, but I have concluded that this is an issue with the application rather than PDQ. It appears that this executable cannot be run in the background as no matter what I do, the executable crashes and therefore doesn't run.
It appears that I will need to complete this final step manually. It's a little unfortunate, but luckily I only have a handful of computers that it needs to be installed on, so it's not too much of a hardship.
Did you the test on a 32bit system? Just curious.
P.S.> you are not alone with the final step - running arround all the machines - I feel your pain
Please sign in to leave a comment.