Software Deployment

Hello,

I once had an interview and when I mentioned I used xcacls and similiar tools like that in custom actions to set permissions he said they only allowed use of the Lock Permissions Table and that is the only allowed method at his project.

I thought it was odd then that at all the places I worked it was a standard practice to use that in a custom action to set permissions over the Lock Permssions Table.

I sent an email direct to Acresso (Installshield Admin studio) asking if the Lock Permissions Table should always be used over my custom action methods.

This was the reply I got from them:

********************************
Regardless of the tool you're using, Windows Installer has a table called 'LockPermissions', which we expose in the Files and Folders and Registry views of the InstallShield Project file (*.ism).

However, there are some significant limitations associated with this such that Microsoft is rewriting this feature in a future release of Windows Installer. So, there may be some cases where you'll need to end up relying upon the custom action approach that you've used in the past.

Some scenarios that I'm aware of:

--Not natively localizing user groups based on well-known SIDs
--Appending to an existing ACL (it replaces the existing one)
--The following knowedgebase entry:

Q107639: PRB: Registry Permissions Propagate Upwards to Parent Keys
http://kb.acresso.com/selfservice/viewContent.do?externalID=Q107639

*****************************

Practice shmratcice. Who cares? LockPermissions is the Spawn of The Devil and they know it. They've been told what hymn sheet to sing from, simple as. If they REALLY thought that, why haven't they put in the work to

- add the normal/default Windows groups/users in to the table automatically;
- abandon the ludicrous number-to-permission level nonsense

Oh...wait...I know. It's because we're only up to v4.5. They haven't had time.

ORIGINAL: ditch_nz

lately I've been using secedit to create the security.inf file and calling that from a custom action/wisescript.



Ive had occasion to use secedit but usually only when I need to change both file/folder and registry permissions. Otherwise whatever gets the job done, lock permissions table, xcalcs, subinacl etc.

Owen ,this works.
http://itninja.com/blog/view/command-line-access-to-wmi-in-xp3

Where possible I use the lockpermissions table, its native and quicker than using a CA..

Only use subinacl when I need to set permissons on shared resources..

I agree, the numbering thing is really annoying, and administrators:f should be default if it's going to replace and not edit permissions (also a questionable decision). Also I notice that discussion is from a lock down perspective (make it more secure) whereas from a packaging perspective we usually loosen perms (users:c) to allow "dumb" apps to work.

Still, if the Windows installer team says it's a best practice it must be so. Argument from authority and all that....:-)

ORIGINAL: aogilmor
Still, if the Windows installer team says it's a best practice it must be so.  Argument from authority and all that....:-)



LOL. Im sure All developers follow those standards.
But anyway, back to the real world......

lately I've been using secedit to create the security.inf file and calling that from a custom action/wisescript.

MS's Best Practices also state that software should be installed to %ProgramFiles%\NameOfVendor\ProductName\VersionNbr. Thus we get 'C:\Program Files\Microsoft Office'... Oy! Shouldn't that be 'C:\Program Files\Microsoft\Office'? And what's with 'C:\Program Files\Internet Explorer' and 'C:\Program Files\NetMeeting'?

Give me a break...

Maybe "best practice" will work when the MsiLockPermissionsEx table is in place :D

Enhanced Permissions Setting with Windows Installer 5.0
http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx

thanks, I'll check that out!

I'd be curious as to the details of how yiou did that, I tried once and even though the inf file worked fine from the command line the msi always got errors. I gave up and used another method. (and yes I read the previous posts here, and used the search!)

thanks maybe I'll try that next time. the advantage to secedit as I see it is that you can do more than file/reg perms at one go - for example 'log on as a service etc.

ORIGINAL: AngelD

Maybe "best practice" will work when the MsiLockPermissionsEx table is in place :D

Enhanced Permissions Setting with Windows Installer 5.0
http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx



And you packages are only going to Windows 7

ORIGINAL: Tone

ORIGINAL: AngelD

Maybe "best practice" will work when the MsiLockPermissionsEx table is in place :D

Enhanced Permissions Setting with Windows Installer 5.0
http://blogs.msdn.com/windows_installer_team/archive/2009/03/05/enhanced-permissions-setting-with-windows-installer-5-0.aspx



And you packages are only going to Windows 7


I wouldn't say that, my comment was regarding when to treat Microsoft's "best recommendation" of using the LockPermissions table.

My point although not very clear and aimed at no post in particular- was its a good idea that overdue but cant really be implemented unless they pull their fingers out and release it a downlevel installer.

Was to lazy to just type MsiLockPermissionsEx [:)]

For anyone looking to know the joys and pains of using MsiLockPermissionsEx, here is a tutorial, some best practices and a helper script. The helper script extracts SDDL from existing system resources - so you just use Regedit and Windows Explorer to set permissions and the helper script extracts them for you.

You can check it out here: http://csi-windows.com/toolkit/csigetsddlfromobject

about time you found your way here Darwin :-)