Software Deployment

This commonly occurs because a LaunchCondition has been set within the MSI. Native MSI vendors offten mistake the Priviliged property for the AdminUser property. This issue has been addressed within Windows Vista.

Check the LaunchCondition table.

Otherwise it could be a custom action. If this is the case, you could try to delete the custom action. Be carefull with this though. Always do a full functional test (or compare two snapshots) when removing an unknown action.

More information:
http://msdn2.microsoft.com/en-us/library/aa367545.aspx

Hope this helps you out.

The app is probably trying to write to a file/folder and/or registry key(s) to which the logged-in user has no rights.

Use ProcMon, or your chosen process/file/registry monitor of choice, to see what file and/or registry access the app is trying to make. Once you know that, you can permission the relevant file/registry key(s) wiuth suitable permissions. Avoid using the LockPermission table, unless you're into self-flagellation: use a command-line utility like SetACL.

thanks for the answers guys, i will have a look at those two possibilities.

thanks again!

ok so i have tried using regmon & filemon but i don't have any access denied, so that part is done!

then i saw a condition Admin in the LauchCondition table, i have erased it but the problem is still there.

what else can i do after these?

thansk!

- Any other conditions?

- Write a log file (either by using the policy: http://support.microsoft.com/kb/223300) or using the command-line: "/l*v %TMP%\InstallationLog.txt"
--> Check the log file for the last action before it quits (or rolls back).

- I was re-reading your first post.... Does the error message actually include the message that it cannot install for all-users (as in ALLUSERS=1) ?

Hope it will help

PS: You did remove the LaunchCondition from the MST, not the MSI correct?

i have removed the condition from the mst and it wasn't working so i tried ermoved it also from the msi. at this point, i'm willing to try anything.

for the log file, i already have tried it and this is what i got;

MSI (s) (F8:64) [14:51:09:772]: Doing action: LaunchConditions
Action start 14:51:09: LaunchConditions.
You do not have sufficient privileges to complete this installation for all users of the machine. Log on as an administrator and then retry this installation.
MSI (s) (F8:64) [14:51:09:772]: Product: eQRP -- You do not have sufficient privileges to complete this installation for all users of the machine. Log on as an administrator and then retry this installation.
Action ended 14:51:09: LaunchConditions. Return value 3.

i don't understand because now the LauchCondition table is empty.

thansk!

- Please verify that the table is really empty with orca.exe
- Is the account used a real SYSTEM account, or is it a self created service account
- I think its impossible, but maybe a custom action places a launchcondition on the fly.

the system accounts usually works, i don't have any doubts on that issue because all the softwares are deployed using this account and i have this problem only when i create a mst with a vendor msi.

i will try looking at the table with orca and i will also take a closer look at the CAs.

thanks!

could you have a look at the files if i put them online? am i asking too much? i don't wish to bother you but i really wish to learn how to fix this problem.

many thanks!

Also, are you ABSOLUTELY sure it's reading the MSI/MST you think it is?

yes i'm sure about that, the log file has the correct values.

...and does the log file show that the transform is being applied? The easiest place to check is near the top of the log file where it shows the command line used. What deployment tool are you using?

yes the mst is being applied. the distribution tool is BMC CM Tuner, which usually works great!

thanks!

Kardock,

I'm sorry I don't really have the time to look at your MSI/MST.

- Can you try to run it manually (first from an Admin account) (second from a System account --> use psexec.exe -s ) and post the results?

- Also, could you try to do a search through the tables for AdminUser ?

hi Frank, thanks for the answer!

i'm able to install the app with an admin account logged on the machine via the distribution software, but not with a test account.

i have already search all the tables for AdminUser and i can't find it from the time i have erased the AdminUser condition in the LaunchCondition table.

i was able to bypass the problem with a runas in a winbatch script, so the app can be installed now but i was hoping to fix the problem, not bypass it. when the admin password will change in the future, we will have to repackage this app with the correct password.

at least i could deliver the package on time. that was the main concern for now, but if i found a solution i will package a new release.

thanks all for your help, it's much appreciated!

Maaybe .. just maybe, the key to this problem might be the "DCOM identity issue". There's loads of discussion about this on the forum, I think one of the most informative threads are this one http://itninja.com/question/msi-corporate-standardiser6

For me, the next step would be to run ProcMon or your favourite file/registry monitor to see exactly what the package is trying to do that requires admin rights.

i tried procmon but no errors detected, but i have made some progress.

as a test, only to see how it would behave, i have deleted the merge modules from the mst file and now, although the package is obviously complaining that some files are missing, i don't have any error saying Admin Rights are required.

it's clear to me that the check for this condition comes from one of those MM, i now have to found which one.

thanks!

Very interesting,

I hope you will find the merge module that is responsible for this. Although I still think it is a bit strange, since merge modules actually merge with the MSI. Therefore if it adds an action or component it should end up in the MSI itself.

Hope to hear the solution

hi all,

i finally was able to make some progress with this thing.

the problem, in fact, is not related to the package. if i do a runas with an admin account, the installation works fine.

but if i runas as the system account, the i have rights problem.

so the system account has to be fixed!

thanks all for the time you put to try to help me, and sorry if i misdirected you on the real problem.