Uwe
2008-02-01 17:00:17 UTC
[I inadvertently posted this question in another thread, so I'm reposting in
a new thread and answering Rob Hamflet's question at the same time. Sorry.]
I have a question about the kind of privileges MSI grants custom actions:
As part of our product's installation on Vista, we place a file in our
product's ProgramData directory and then create a symbolic link to that file
from our product's Program Files directory. This worked when we were
performing an installation using an old pre-Vista Install Shield installer,
probably because the code that was creating the link was in a DLL that was
being called by the InstallShield setup program. However, we now are
converting our installations to MSI and we're encountering a problem
creating this symbolic link. The code that creates the link has been moved
to a Deferred Execution EXE and it is executed after all of the other files
have been installed. (It is after the RegisterFonts action.)
The error that we get when we try to create the symbolic link is 1314
(ERROR_PRIVILEGE_NOT_HELD). I made my Custom Action program Elevated by
setting requireAdministrator in the manifest, and that didn't help. I have
set the msidbCustomActionTypeNoImpersonate flag on the custom action, and it
didn't make any difference. I have tried to grant
SE_CREATE_SYMBOLIC_LINK_NAME privilege to my process, and all I got was
ERROR_NOT_ALL_ASSIGNED from AdjustTokenPrivilege for my trouble, which it
not what happens when I run the EXE from a command prompt. So, I've decided
that MSI must be running my custom action with reduced privileges.
Here are my questions:
1) Am I correct-- is MSI is doing this on purpose? (Am I doing
something wrong?)
2) Is there anyway to get MSI to give my in-script custom action the
privilege to create symbolic links?
3) What privileges does the in-script custom action actually have?
Where is this documented? (I've tried looking.)
In response to Rob's question,
believe that's when things are passed over to the server side.
--- Uwe
a new thread and answering Rob Hamflet's question at the same time. Sorry.]
I have a question about the kind of privileges MSI grants custom actions:
As part of our product's installation on Vista, we place a file in our
product's ProgramData directory and then create a symbolic link to that file
from our product's Program Files directory. This worked when we were
performing an installation using an old pre-Vista Install Shield installer,
probably because the code that was creating the link was in a DLL that was
being called by the InstallShield setup program. However, we now are
converting our installations to MSI and we're encountering a problem
creating this symbolic link. The code that creates the link has been moved
to a Deferred Execution EXE and it is executed after all of the other files
have been installed. (It is after the RegisterFonts action.)
The error that we get when we try to create the symbolic link is 1314
(ERROR_PRIVILEGE_NOT_HELD). I made my Custom Action program Elevated by
setting requireAdministrator in the manifest, and that didn't help. I have
set the msidbCustomActionTypeNoImpersonate flag on the custom action, and it
didn't make any difference. I have tried to grant
SE_CREATE_SYMBOLIC_LINK_NAME privilege to my process, and all I got was
ERROR_NOT_ALL_ASSIGNED from AdjustTokenPrivilege for my trouble, which it
not what happens when I run the EXE from a command prompt. So, I've decided
that MSI must be running my custom action with reduced privileges.
Here are my questions:
1) Am I correct-- is MSI is doing this on purpose? (Am I doing
something wrong?)
2) Is there anyway to get MSI to give my in-script custom action the
privilege to create symbolic links?
3) What privileges does the in-script custom action actually have?
Where is this documented? (I've tried looking.)
In response to Rob's question,
Do you get the UAC prompt at all? Either right at the start or when
things are passed over to theserver side?
We get the UAC prompt after pressing the [Finish] button in the GUI. Ibelieve that's when things are passed over to the server side.
--- Uwe