Software Deployment

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 :).

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.

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...

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...

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?

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.

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?

Any way I can make the values case insentive?
Property:
MY_PROPERTY="TEST"

Below condition will resolve to true:
MY_PROPERTY~="TeSt"

Thank you all!

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.

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