AOL Instant Messenger - Triton
Has anybody tried repackaging the latest AIM Triton? I am using Wise to capture this and it seems just fine, up until I deploy it onto XP and a user tries to login. They get into installer never-land, with a message saying it is "preparing to install", and it never gets any further. I can deploy the same package to a Windows 2k system, and it will not have any problems.
When I check the event log, MsiInstaller has an error about "The resource 'C:\Documents and Settings\Administrator\Application Data\AOL\AOLDiag\AOL\LaunchUSGM\Win32\1.5.3.1\manifest.bin' does not exist."
I've tried moving this file, but with no luck.
Again, the thing that stumps me the most is that i have absolutely no problems when doing this in 2k. (i've tried capturing in both 2k and xp, with similar results). This installer has about 8 different things it installs, so my next step is to emulate it's install routines to get a silent install, or literally capture each sub component and have 8 msi's for "AIM Triton"
argh.
Any advice on this would be greatly appreciated.
When I check the event log, MsiInstaller has an error about "The resource 'C:\Documents and Settings\Administrator\Application Data\AOL\AOLDiag\AOL\LaunchUSGM\Win32\1.5.3.1\manifest.bin' does not exist."
I've tried moving this file, but with no luck.
Again, the thing that stumps me the most is that i have absolutely no problems when doing this in 2k. (i've tried capturing in both 2k and xp, with similar results). This installer has about 8 different things it installs, so my next step is to emulate it's install routines to get a silent install, or literally capture each sub component and have 8 msi's for "AIM Triton"
argh.
Any advice on this would be greatly appreciated.
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
AngelD
17 years ago
By the missing :\Documents and Settings\Administrator\Application Data\AOL\AOLDiag\AOL\LaunchUSGM\Win32\1.5.3.1\manifest.bin
Do you have this problem for regular users?
I woul first log the installation to find out some more why the repair fails.
You could try to find the component holding this resource (manifest.bin) as a keypath and set a HKCU registry entry as the keypath instead.
There may be more then just failing on this resource so by logging that would help in your investigation.
Do you have this problem for regular users?
I woul first log the installation to find out some more why the repair fails.
You could try to find the component holding this resource (manifest.bin) as a keypath and set a HKCU registry entry as the keypath instead.
There may be more then just failing on this resource so by logging that would help in your investigation.
Posted by:
Drgnfyre
17 years ago
When you say log the installation, you're just referring to the whole /l*v logfile.txt method, right?
I did actually get the package to work, I just had to go in and tear out everything that was profile specific. I was hesitant to do that at first, as I was afraid the application would no longer work. So far, it seems to be working okay (had one little annoying file that messed me up in the Viewpoint folder, but cleaned that up).
I did actually get the package to work, I just had to go in and tear out everything that was profile specific. I was hesitant to do that at first, as I was afraid the application would no longer work. So far, it seems to be working okay (had one little annoying file that messed me up in the Viewpoint folder, but cleaned that up).
Posted by:
AngelD
17 years ago
I woul first log the installation to find out some more why the repair fails.
Let me rephrase this to I would first log the repair to find out some more why the repair fails.
If you havn't already; Add the Logging (SZ_REG) entry under "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" with a value of "voicewarmup" or whatever log options you like. When the repair startes you'll have the log in the %temp% folder.
hmm just read through your first post again ;)
You say it seems just fine, up until I deploy it onto XP and a user tries to login, but as the event log states the resource/file is located under the Administrator userprofile. Was the folder path for the file hardcoded to the admin's profile?
Let me rephrase this to I would first log the repair to find out some more why the repair fails.
If you havn't already; Add the Logging (SZ_REG) entry under "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" with a value of "voicewarmup" or whatever log options you like. When the repair startes you'll have the log in the %temp% folder.
hmm just read through your first post again ;)
You say it seems just fine, up until I deploy it onto XP and a user tries to login, but as the event log states the resource/file is located under the Administrator userprofile. Was the folder path for the file hardcoded to the admin's profile?
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.