LockPermission Table
Created: 23 Aug 2012 | 6 comments
why dont we use Lock Permission table in MSI.....while it is very easy to set the permission from it.
Discussion Filed Under:
why dont we use Lock Permission table in MSI.....while it is very easy to set the permission from it.
Comments 6 Comments • Jump to latest comment
Because it has a lot of restrictions you might not notice on first sight:
- Only a few well known Users/Groups
- Not localizable
- Affects existing permissions
- ... more i cannot remember right now
This is why you should use:
- a custom action with a tool of your choice
- MsiPermissionEx (Installer 5.0 ... not supported in WISE)
First of all, permissions set via the Lockpermissions table totally REPLACE any existing permissions, rather than adding to them.
Secondly, if you are deploying using a service account based deployment system, the installer will not be able to access the security SIDS of any domain resources, so Lockpermissions in these circumstances can only be set for local accounts such as "Administrators" and "Users". Note that the "Everyone" group cannot be used here.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
You can also have a look at my blog where I have mentioned some more details about LockPermission Table:
http://msiworld.blogspot.com.au/2008/11/different-ways-of-giving-permissions-in.html
Piyush Nasa Altiris Certified Professional (ACP)
http://msiworld.blogspot.com/
Hmmm...I wonder if somebody was interviewed for a packaging role recently....
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
Might well have failed the test if mentioned using "Everyone" in lockpermissions table, as this option was removed at XP SP2 if I recall correctly.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Note that common known user and group names in Windows are differently named in different languages. That's why you can't use e.g. 'Authenticated Users' in the LockPermissions table if you are going to install the package in a non-english environment. Instead, I use a property in the LockPermissions table that is populated by a custom action that looks up the real (localized) name for "Authenticated Users" (using the SID) from the operating system. I use this only on certain folders that the installation package is creating.
Would you like to reply?
Login or Register to post your comment.