Would someone be willing to take a quick look at this installer? It's a free download that has me baffled. http://www.clicktracks.com/hosted/ClickTracksViewer6.8.4.exe

The download is an exe that appears to extract multiple msi's with the same size and name plus an exe which appears to run the installer but I'm now sure which one. I also haven't been able to figure out what packaging software they used to create the msi's either. You can run the msi directly and it appears to install fine but generates an error when first launched.
0 Comments   [ + ] Show Comments

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.

Answers

0
I also haven't been able to figure out what packaging software they used to create the msi's either. So the text 'Welcome to the InstallAware Wizard for Clicktracks Viewer' wasn't a big enough clue, eh? :)

You can run the msi directly and it appears to install fine but generates an error when first launched. ProcMon will show you what's going on. It can only be a limited number of things, e.g. the app is trying to open and/or write to a non-existent file or registry key/value, or a file registry key/value to which teh account you're using has insufficient rights. As ever with either captured setups or ones which are installed via a stub, you should:

- run your MSI
- start a lightweight snapshotter (I use Ziff-Davis's In Control) and take a 'Before' snap
- if the original install uses an MSI, rename the relevant 'Uninstall' registry key (to avoid having the engine offer the 'Repair/Modify/Remove' dialog)
- run the vendor's EXE
- take an 'After' snap
- add any relevant changes to your package. If it was originally an MSI, then add those changes to a transform.
Answered 12/09/2008 by: VBScab
Red Belt

Please log in to comment
0
Out of curiousity, I took a look and have to say that I'm surprised that the MSI you picked installed anything.What a mess! It's possibly even worse than the one yesterday. It looks like it might even have been originally authored with InstallShield (e.g. the presence of the ISComponentExtended table as well as some component names looking very much like IS-generated ones) and then shoe-horned into InstallAware. [shudder] I'd venture that this is another candidate for re-working.
Answered 12/09/2008 by: VBScab
Red Belt

Please log in to comment
0
I had a quick look and it seems to be a "nasty" installation.
It extracts two directory structures in the %temp% folder, in my case mia1 and mia5.tmp containing all the required files.
In the latter it also include "Microsoft .NET Framework 2.0" and "Microsoft Windows Installer 3.1" as pre-reqs.
After the pre-reqs has been installed and a reboot has taken place due to the requirement of the 3.1 installation it "injects" a MSI hooker to interact with "ClickTracksViewer.msi" located in the mia1 temporary folder which in turn uses the sources files in this same folder and in the "mia5.tmp\data".

All File.Sequence values are set to 1, shouldn't be a problem here as the files are external uncompressed but why one would do that is out of my head.

The used Command Line: ADDLOCAL=ALL ALLUSERS=1 ARPSYSTEMCOMPONENT=1 ARPNOREMOVE=1 ARPNOMODIFY=1 ARPNOREPAIR=1 ARPINSTALLLOCATION=C:\Program Files\ClickTracks\ClickTracks Viewer
SRCDIR=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\mia1.tmp\data\ SOURCELIST=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\mia1.tmp\data\;C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\mia1\
MEDIAPACKAGEPATH=\DOCUME~1\ADMINI~1\LOCALS~1\Temp\mia1.tmp\ REBOOT=R

However due to the MSI hooking I guess it would be easier to just capture the installation.
Answered 12/09/2008 by: AngelD
Red Belt

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