Hi,

I've got a custom action running xcacls.vbs to set permissions on a folder that's getting installed by my msi package.
the problem is that when I install the msi file, the permissions are not added as they should.
What I've figured out is that when I run the xcacls.vbs command locally on the server as a user from a certain domain it works as planned.
(an important detail is that the domain user I need to add is from another domain than the domain the server is a member of. this is why it's more complicated.)
Is there a way I can run my custom action as a spesified user?
In the msi script session I've used the "execute program from destination" and placed it in the "Execute deferred" secion.

Thanks!
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
Have you already tried specifying the permissions through your packaging tool? In WPS, for example, you can specify what permissions you want on any directory through a couple of mouse clicks :).
Answered 06/10/2009 by: jcarri06
Senior Purple Belt

Please log in to comment
0
The problem with that, J, is that it populates the LockPermissions table, well known as The Spawn of The Devil, in that the permissions that it sets are not additive. Thus, you have to ensure that you add all the users which require permissions, including all the usual groups (Administrators, etc.) and you have to use their SIDs to do that. Of course, those usual groups's SIDs are equally well-known but it's just a bit of a palaver.

Having said that, what the OP actually wants is to run the CA as a different user, which is easy enough: just use RunAs. Whilst it is indeed easy, its use obviously exposes that user's password, unless you go through substantial hoops to encrypt/decrypt it.
Answered 06/10/2009 by: VBScab
Red Belt

Please log in to comment
0
Thank you both, I've been thinking about the same solutions already.
The reason why I haven't used the "builtin" option in WPS is that I don't want the new permissions to overwrite/prevent other permissions.
The RunAs command is a solution, but I'd prefer to avoid the RunAs command if possible to prevent revealing the user password...
Answered 06/10/2009 by: jgb
Orange Belt

Please log in to comment
0
I don't see how else you're going to run a CA as a different user (other than using a similar tool to RunAs). Alternatively, you may want to emulate the CA via a different route, e.g. from a script run against a machine or user group...
Answered 06/10/2009 by: VBScab
Red Belt

Please log in to comment
0
I've done some more testing, and this is what I've found out so far:
When I first started my test I copied the command which I'd put in Custom Actions and tried to run this in a command prompt locally at the server.
Still had problems, but running as a another user went fine in the command prompt.
So I tried to use icacls.exe instead, and when I tested this command in a command prompt locally at the server I didn't have to change user.
I thought I had solved the problem, but nope, when I put the same command in the Custom Action/msi script - deferred, I still had a problem.
So I'm confused now. How come I could run the command in the command prompt as local administrator without any problems, but still have problems running the msi file with the same user credentials? any clue?
Answered 06/10/2009 by: jgb
Orange Belt

Please log in to comment
0
I suspect you have the CA set to run in System context. If you will always be installing the package with local admin privileges, change it to run in User context.
Answered 06/10/2009 by: VBScab
Red Belt

Please log in to comment
0
I've been looking in the wrong direction! Turns out it was an IF condition -which leads me to another question: When making a condition, choosing "ignore case" in the condition builder - shouldn't that make the value case insensitive?
Turned out that one letter was uppercase instead of lowercase, and that was enough to stop the IF condition happen!
Any way I can make the values case insentive?
Answered 06/10/2009 by: jgb
Orange Belt

Please log in to comment
0
Any way I can make the values case insentive?
Property:
MY_PROPERTY="TEST"

Below condition will resolve to true:
MY_PROPERTY~="TeSt"
Answered 06/10/2009 by: AngelD
Red Belt

Please log in to comment
0
Thank you all!
Answered 06/10/2009 by: jgb
Orange Belt

Please log in to comment
0
assign the perms to a local domain group.

put the user into the group. Then the fix is scalable, individually adding a user account is a bad idea.
Answered 06/10/2009 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
Thank you for your feedback! I was a bit unclear, but I'm already using a domain group.
And after the IF problem got solved, both xcacls.vbs and icacls.exe works :-)
In my experience the pro about using icacls is that all W2K3, SP2 servers already got it installed, so I don't have to put the xcacls.vbs file in the package.
it also seems to go faster and doesn't seem to be dependent on a domain user running the command. (if the permissions is assigned to a user/group in a domain)
The cons about icacls is that there is a reported bug concerning editing inheritance permissions and ownership, but there is released a hotfix from Microsoft which should take care of this
Answered 06/11/2009 by: jgb
Orange Belt

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