Software Deployment

Hi,

We also often use the command "setacl.exe" to change foder, file permissions etc., but insteand your line code, we use the SID Value

Your line: setacl.exe -on "HKLM\SOFTWARE\Classes" -ot reg -actn ace -ace "n:Authenticated Users;p:full"


Our line: setacl.exe -on "HKLM\SOFTWARE\Classes" -ot reg -actn ace -ace "n:S-1-5-11;p:full"

Try it

Check this website for the other well-knowned SID's
http://support.microsoft.com/kb/243330

by

Pascal

Forget about using SIDs, it's irrelevant for your issue. I have used SetACLfor years and have never used them.

1631 is a bizarre error to get, as it means "Windows Installer service failed to start." Are you *sure* it's 1631?

- Does the 'Perms' folder exist at the point where SetACL is run?
- In what sequence are you running SetACL? It ought to be in ExecuteDeferred, as it's making a change to the system.

As per your requirement you are using the correct CA and you have copied the file also. But "Execute Program Form Destination" CA can look only to those folders listed under your MSI Directory Table.
Create Tools and Perms dir in your MSI as empty DIR and browse Perms as working directory in your CA.

Jeeoo!
Santro

Thanks for the replies.

I have tried again today, after the weekend, and I still have the problem with the custom action, but the error code is different. (I guess I must have done something wrong, as I am now getting error 1721, which is what I would expect)

I agree with VBScab about the use of SIDS, this would work, but the command I am running on SetACL also does work, as I can run it from a dos box fine with no errors.

Just to make things clearer:

I have manually copied setal.exe to c:\windows.

I have a brand new empty .msi that I have created, and added 1 picture into it to create a component for testing.
I then create a custom action, 'Execute Program from destination'
Command = setacl.exe -on HKLM\SOFTWARE\Classes -ot reg -actn ace -ace "n:Authenticated Users;p:full" (this works from dos)
Working Directory = C:\Windows, (WindowsFolder in my directory table)
Location = Execute Deferred, Just before InstallFinalize
Processing = Synchronous

I have reverted to a previous snapshot (I use VMWare, and reverted to a previous snapshot so that I had no issues with cached msi's etc)

Install app with command line: setacl.msi /qb /l*vx c:\log.log

Log file snippet:
MSI (s) (D8:98) [09:56:11:687]: Doing action: SetPermissions
Action ended 09:56:11: PublishProduct. Return value 1.
Action start 09:56:11: SetPermissions.
MSI (s) (D8:98) [09:56:11:687]: Doing action: InstallFinalize
Action ended 09:56:11: SetPermissions. Return value 1.



Using the same .msi, is I change the working directory in this custom action to C:\Windows\RDM\Store\Tools (Tools in my Directory Table)

I then copy setacl.exe to C:\Windows\RDM\Store\Tools, and run the .msi with the same command line:

I get the error, again atached is the log file snippet:

MSI (s) (0C:9C) [10:04:39:750]: Note: 1: 1721 2: SetPermissions 3: C:\WINDOWS\RDM\Store\Tools\ 4: setacl.exe -on HKLM\SOFTWARE\Classes -ot reg -actn ace -ace "n:Authenticated Users;p:full"
MSI (s) (0C:9C) [10:04:45:328]: Product: SetACL -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: SetPermissions, location: C:\WINDOWS\RDM\Store\Tools\, command: setacl.exe -on HKLM\SOFTWARE\Classes -ot reg -actn ace -ace "n:Authenticated Users;p:full"

I still cant make this work, and would appreciate comments?

Why are you worried about changing the working directory? It doesn't affect the target for SetACL itself so why beat yourself up? Leave it as 'Windows' or whatever.

Having said that, I get the feeling you're determined to make this work (good on you!) so, how you specifying the path in the 'Working Directory'? Are you using a packaging suite or are you using an MSI table-editing like Orca/InstEdit to edit the CA table directly? You do know that you have to use a directory property name, rather than a full path? So, if 'C:\Windows\RDM\Store\Tools appears (as it should) in the Directory table as 'Tools', you need to use THAT name i.e. 'Tools' as the Working Directory.

Hi,

I am determined, (one of my many downfalls!)

I am use Wise Packaging Studio 7 to create the .msi within the msi i have created the directory structure, and the entries are in the directory table.

When I browse to the working directory for the CA, wise automatically puts the directory property there for me. I am not putting C:\WINDOWS\RDM\Store\Tools\ as the value, Wise is putting TOOLS in for me.

My custom action table entry looks like this: (I have manually added the pipes to seperate each column of the table)

SetPermissions | 3106 | TOOLS | setacl.exe -on HKLM\SOFTWARE\Classes -ot reg -actn ace -ace "n:Authenticated Users;p:full"

Hi have executed with the same entry and it is working fine.
Could you please make sure that your CA sequenced under Defered and before InstallFinalize?

Cheers!
Santro

ORIGINAL: zipsantro
Could you please make sure that your CA sequenced under Defered and before InstallFinalize? Santosh, The fact that the CA type is above 3000 indicates that it's in ExecuteDeferred and WPS prompts you if you try to add a CA after InstallFinalize in that sequence.

Gary, the table looks fine. Weird... :(

BTW, if you're opening up HKLM\Software\Classes with Full Control for AUs, I'm going to guess that you're trying (elsewhere in the MSI) to get the RegisterComPlus action to work for non-admin users. Am I right?

Finally got this going, in the end I was being REALLY stupid.

I didn't add the path to start of my exe. CA table entry now looks like this:

SetPermissions | 3106 | TOOLS | [TOOLS]setacl.exe -on HKLM\SOFTWARE\Classes -ot reg -actn ace -ace "n:Authenticated Users;p:full"

all works fine.

Thanks for all your help VBScab, I'm sure I'll be calling again....

Huh? What about:
I have manually copied setal.exe to c:\windows.

In which case, Windows should pick it up in its default path. BTW, I generally copy things like this to %SystemRoot%\SYSTEM32 as that's guaranteed to be on the path since, if it isn't, almost nothing works! Windows is so 80s like that...

the mistake I was making was even simpler.

I was treating the working directory as the .exe location. When I was changing the Working directory, I was thinking I was changing the location the .exe was running from.

When i changed the working directory to windows, i copied the setacl.exe to that location. When I was testing the c:\windows\RDM\Store\Tools folder, i was moving the exe out of windows directory into c:\windows\RDM\Store\Tools.

It was just a really bad friday i guess!

PS. I was using HKLM\Software\Classes as an example, nothing more.