Software Deployment

ORIGINAL: Tsocks
Using Orca I was able to create a custom action to run a vbs from the binary stream using the following info-

Binary Table
Name - testvbs
Data - path to vbs file.

Custom Action Table
Action - Runtestvbs
Type- 6
Source - testvbs
target - blank

InstallExecuteSequence Table
Action - Runtestvbs
Condition - NOT Installed
Sequence - 6500

Testvbs was a simple script to add a registry key and this worked. But I really want to run XCACLS.vbs to change permissions on a directory. How can I pass the command line switches needed with xcacls so that when xcacls.vbs runs it will set the permissions on the directory I wish?

This command line works when running xcacls by itself - xcacls.vbs c:\progra~1\testfolder /G "builtin\users"":F /G "nt authority\authenticated users":F /G "builtin\power users":F /T /E


you've got an extra quote on the end "of builtin\Users""
Other potential problems:
don't use builtin, there's no need. Unless a domain is specified it's assumed local users is the group
Use the "[INSTALLDIR]" property in quotes instead of the short path
Don't use authenticated users or power users (no need, redundant)
depending on whether xcacls replaces or edits the permissions, add Administrators (again, no need for builtin)
I take it this is so locked down users can use a legacy app?
Let us know how it goes!

aogilmor,

Right now this is just a test exercise so I will know what to do when I have the real package to play with. I will need to elevate the permissions in the install directory for locked down users to run the app.

Your suggestions about tweaking the xcacls vbs command line switches are appreciated. I just put these different groups in for testing. When I ran the initial testvbs file to create a registry key, simply running the vbs file with the CA made the change and that worked. The problem I'm running into is that xcacls.vbs is a vbs by itself. If you run it from a command line you have to include the various parameters and switches for it to complete the changes. I'm not sure where to specify the parameters and switches when I create the custom action. Can I add the switch parameters in the binary table path for the xcacls.vbs file? Or can I specify them in the CA table? Or, if its not possible to do that, is it better to create a separate vbs that calls xcacls.vbs with the switches needed?

I am new to packaging so I appreciate your help!

call cscript.exe/wscript.exe from a CA then pass it your command line (.vbs & switches)...

Hi Kenneth,
your approach seems a good idea.
However, this can't work like this.
Maybe the call to cscript helps (like kiptek suggested), but this produces another issue. If vbscript is disabled or restricted on a system, it won't run.
A better approach would be, to modify "xcacls.vbs" for MSI.
Most important: All the "Wscript" statements have to be removed, Windows Installers own script engine doesn't understand it.
This CA is best run in deferred mode, therefore the command line doesn't work. You have to set a property to do it.
Search Appdeploy for scripts, there are a lot of examples in here.
Hope this puts you on the right track.
Regards, Nick

OK Guys,

I have a CA calling a vbs that runs xcacsl.vbs with the command line switches (works with SetACL.exe as well). It works fine as long as xcacls.vbs or setacl.exe resides on the target machine, but obviously won't run if the file is not available. Now my question is how to include xcacls.vbs or setacl.exe with the msi package?

I appreciate any help you can give!

Copy setacl.exe to a temp folder on machine, execute vbscript to set permissions, delete setacl.exe at end of installation.

Alternativly deploy setacl.exe as part of your build in the system32 folder and problem solved.

P

Tsocks, did you ever resolve this? sometimes you have to experiment a bit to see if a binary in the msi, or a file on the machine works best.

Also (something I failed to bring up in my original post) you can use the LockPermissions table to set permissions within the MSI. No need for any outside tools, scripts, etc. Some people don't like using it for various reasons, but it does work.

I never quite got it to work the way I wanted with Orca. My company did cough up the $ for WPS and I have been working with that; much easier! Still, I figured if I could learn how to do it with Orca, then I would understand the process more thoroughly. I appreciate all the suggestions and help with that. I was able to make the changes I needed with Wise and the package looks pretty good at this point. I think Wise is actually using the Lockpermissions table to make the permission changes, but setting that up is a lot easier. Thanks to all!

you're right, Wise does use the lockpermissions table. One caveat you should be aware of is that you can actually replace permissions so be careful.

you can actually replace permissions Naughty boy, Owen! Not 'can' but 'will'! That's why anyone with any sense uses Custom Actions to perform permissioning: life's too short to have to faff about populating the LockPermissions table correctly.

ORIGINAL: VBScab

you can actually replace permissions Naughty boy, Owen! Not 'can' but 'will'! That's why anyone with any sense uses Custom Actions to perform permissioning: life's too short to have to faff about populating the LockPermissions table correctly.


I knew I'd draw you out with that one, Ian! Yes, it will replace perms. Yes, it's odd and kind of a pain to work with. But, it has the advantage of being native to MSI/windows installer. I used to use a macro which would add administrators:f users:w on select directories, so it can be automated somewhat with Wise (or even VBscript if you're stuck with Orca). Must admit I'm a bit rusty at permissioning issues now. Hopefully between Vista/shimming/better written apps this issue will gradually go away....Always good to debate with you, Ian!

You remind me that messing around with default permissions can really screw you up. I remember some joker removed users:r from the Oracle directory and everyone was up in arms: "Users need to be administrators!"....BS. Read access was fine, and I proved it by doing a tnsping as a user after granting them read access to the local Oracle binary directory.

Ha, ha! And THAT reminds me of something which foxed me many, many moons ago when I used to have a permanent job, working for a Kuwaiti government agency, dabbling with Microsoft Lan Manager (which gives away my age somewhat). Anyway, once we'd persuaded MS to allow us to test Word for Windows 1.1 across the network, I was stumped as to why Word insisted at print-time that no printer was installed. Odd, given that each department had at least two set up. Long story short, Word was unable to write a temp file to the user's private folder (I can't recall what permission exactly was missing...) hence my oft-heard cry about MS's error messages: "Something happened, I don't know exactly what it was, but I have to tell you something so I'll say this..."