Software Deployment

Hi Eric:

I just checked out this package, you could record an answer/response file for the setup and then call the setup in silent mode. Run thru these steps:

1. Run c:\hotdocs\setup.exe -r -f1c:\hotdocs\setup.iss

2. once the setup answer file is created you can run this command

c:\hotdocs\setup.exe /s/v/qn

This would run the installation in a silent mode.

Do get back in case you require more help. Since this installation is ISSCRIPTDRIVEN and can be executed as per the steps given here http://itninja.com/blog/view/7.8-gigabyte-size-limit-in-nt''s-ntfs4 however the setup.exe is made in such a way that it has all the necessary dialogs that you need to go thru otherwise the installation would fail. so if you follow the steps that I mentioned you could probably install this package without any errors.

Hi Eric,

Here's a thing you can try:

Turn on installer logging (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer Logging=voicewarmup) and run the setup. (the logfile will be located in %temp%)

Now if you check the propertie values in the logfile (and compare them to the values in the msi) you have a good chance of finding the ones you need to add to your transform.

Ilikebananas

Hi Kire:

In case you are not allowed to use/deploy exe's then in that case what I'll say is this installation is pretty complex and does many things at the runtime with its setup.exe. Hopefully there is still some hope left :

1. You can repackage this whole @#@%@# installation using snapshot method of wise or installshield(whichever you are using)

2. You could also try creating an MSI wrapper that shall call this exe in a silent mode and will install everything with all the required parameters.

In both cases you are not going to loose and the application will also work. Do let me know in case you require any further clarifications.

Hi Kire:

Good to hear that my solutions worked[:)] anyways you should also include this line in your MSI :

If Installed and REMOVE~="ALL"
Execute program from destination(Call Uninstall program here, this is your uninstall string for hotdocs C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\7\INTEL3~1\IDriver.exe /M{96669261-D4A9-4EFC-8177-C610C9112550})
End

If Not Installed and REMOVE~<>"ALL"
Execute Program from Destination(call the setup in silent mode)
End

Now once you remove the MSI then it would also uninstall hotdocs.

Hope this would help you more and yes thanks once again for the points(I hope that was given by you)

Thanks guys, I'll give both of these a try.

Eric

OK I'm a little bit further down the track but a lot more angry at the developers who built this product. It now doesn't come up with the error regarding the configuration of the Word Processors thanks to Ilikebananas suggestion. I checked the logs and found the settings that were being passed to the msi and configured it.

Problem now is it's still coming up with the application has not been installed properly message. Checking the differences between a setup.exe installed and my custom msi/mst installed there's a bunch of files missing.

I work out that the setup.exe is calling another executable that is being extracted and this is installing a bunch more files and changing some registry settings. Thank god for regmon and filemon. Attempting to run this exe separately it comes up with an error regarding parameters that it's expecting to be passed. So unless I can work out what parameters are being passed I'm going to have to try and work up an msi to install the files/registry via snapshot. Or add the files/registry settings into my mst.

How difficult is it to add another directory and files/registry into the mst? I've looked around for some instructions but can't seem to find any. A few places point to this URL [link]http://msdn.microsoft.com/library/en-us/msi/setup/using_transforms_to_add_resources.asp[/link] but there doesn't seem to be any instructions there. I'm using ORCA, still trying to persuade management to get a more expensive tool.

Thanks in advance

Eric

PS. can't use the run a setup.exe and an answer script to install the product as all packages must be msi distributed.

The question is why isn't the setup routine being executed when you run the MSI? There must be another property that you've missed?

I sometimes use ProcXPNT (Sysinternals) to check the command line that's used to launch processes.

The exe isn't getting called from msiexec. It's being called by idriver.exe. Looks like they've tacked this onto the installshield script after they've created the MSI. Instead of calling it from within the MSI. I've got process explorer on the virtual machine I'm testing on now. How can I use this tool to check the command line that's calling the exe?

Eric

Hi Kire:

Are you using GPO/AD to deploy these packages ? As earlier said in the post most of the job in this package is done by the Setup.exe , so you cannot actually afford to miss it. However if you are using some other deployment tool rather than AD then try my option I have tried it and actually gives you no errors. Rest is your choice do let me know.

Hi Eric,

Adding resources isn't hard in Orca. But when you compare it to the big msi editing tools it's a lot more work (especially when you have a lot to add), and takes more understanding of the msi database.

There is an example in the SDK: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/an_installation_example.asp

The example is actualy about creating an msi, but you can also use parts of it for transforms.

Hope this helps...

Ilikebananas

Wiseapp they're using Landesk to install applications and corporate policy is that all applications are packaged as an MSI prior to the install. This is why I'm fighting with this frustrating package. I'd love to run setup.exe, I'm just not allowed to.

Ilikebananas, thanks for that, that's exactly what I was looking for. Gonna have to send you some bananas.



Eric

Thanks Eric,

They're great! [:D]

Thanks Wiseapp. I've already tried repackaging this @#^@# installation with not much luck. You know how you're not supposed to repackage msi installs. Well this one seemed to really screw up when I snapshotted it.

So looks like the creation of an MSI wrapper could be the go. I've been looking through the instructions that the banana lover linked earlier, and I think I've got it all set. Only question is in the custom action that I create to run the exe. How do I specify a command line switch?

Eric

Don't worry, got it sorted, so I've got my MSI wrapper which calls their setup.exe in silent mode which then calls their MSI.

So complicated for what should be a simple application.

Thanks everyone.

Eric

ORIGINAL: kire

The exe isn't getting called from msiexec. It's being called by idriver.exe. Looks like they've tacked this onto the installshield script after they've created the MSI. Instead of calling it from within the MSI. I've got process explorer on the virtual machine I'm testing on now. How can I use this tool to check the command line that's calling the exe?

Eric


Now you see why I dislike ISS?

Hi Jim:

Exactly this specific installation was a pain in my *&@ I had to look for each every file that it was installing and creating, but you saw the big fight for ISS in my poll. I think the developers of this installation did not wanted to make this installation flexible enough.

I am going to post this twice.....once in here and once in the poll section.

Most vendor apps are designed to install for the "common" user. This is the user who is a local admin, who will run the Setup.exe from a local drive or the internet and install the app, and if the "Finish" button comes up will think nothing more about the app unless the shortcut isn't there to click on.

In the corpporate world we deal with users who have NO rights. Can't install the app because we deploy it to them. Can't write to the hard disk/registry with any certainty etc. This is why we "repackage" vendor apps.

Vendor apps can be as slipshod and as nasty and reckless as they want to be because they only aim to hit the "Home User" type of people. Local admins.....omg!! lets all be local admins then you too can get hacked to the bejesus by any script kiddie with 2 spare weeks of school holidays up their sleeve.

Because of this the vendor is "allowed" to create dodgy custom actions and run scripts that don't work in the corporate world. ISS is one of these and is the main offender when it comes to creating "Unreal" apps. These are athe apps that WILL NOT install without local admin. This is just outrageous!

Adobe is a Prime offender......Not a local admin. Well forget it. You cant install Adobe Reader!!!!!

This is why we ALL repackage Adobe Reader!

We spend hours of our time to work out the registry keys to unblock or lock to stop users fromj doing harm to themselves...this is the Corporate environment....but vendors don't get it.

I spend 80% of my time PROTECTING the platform within the bank I work in.....not from hackers but from vendor apps that will stick just any old dll in the System32 folder. Why does a vendor dll "HAVE" to go into System32? Why does a vendor HAVE top ship an Operating System DLL with their app?

This is the sort of thing that is OK for home users......but in the Corporate world when you have 30,000 users to protect.....the vendor app just doesn't cut it in most cases

I agree with you Jim, these vendor provided MSI's that too on ISS are big nightmare for corporate packagers/application packagers working in corporate world. Sometime you do come out of these sick MSI's but most of the times I have seen you might end up creating a VB app/Script that should modify the system as per the client/corporate requirement and that's where the problem comes and meets with "Worst". I think most of the packagers who are working in corporate world try to create an MSI that is flexible enough to fit in any system be it corporate systems with GPO's or end-user desktops. In any case if any of these vendors are looking at this post, they should better try creating packages that are flexible enough to fit into corporate requirements. I think this would bring more confidence to the newbies of packaging.

What do you think Jim?

God Bless!

Bob has created a new forum for EXACTLY this topic

Package Security

I'm hoping to develop discussion about this in there and help all "AppDeployers" with this issue.

See you there :)

Thanks Wiseapp, yeah the points were from me, I have no problem with rating helpful posts. I'll add that line to the MSI, still playing around with it. Currently it's copying the setup files to the machine and running setup.exe, going to try and get it to run the setup.exe from the source.

Kire

Hi Kire:

Trying using Execute Program from Path command in your MSi to run the exe from source rather than copying it to the target machine:

Use this in User Interface Tab;

Create a property SETUPPATH Value should be [SourceDir]Setup.exe

Call Set Property action and type the name of the property that is SETUPPATH and Value [SourceDir]Setup.exe

Call Set Property action in Execute Immediate and type the name of the property that is SETUPPATH and Value [SourceDir]Setup.exe

In Execute Deferred Type in these lines

If Not Installed
Execute Program From Path (Type in the name of the property here SETUPPATH)
End

I hope this would help you in executing the setup from source.