One of the fundamental problems with Windows Installer (MSI) versions before 5.0 was an inability to change permissions reliably on an object in an installer (such as a registry key, file, or folder). When the MSI installs that object, the default behaviour is that the object will inherit the permissions from its parent folder or key.
If we set permissions on an object in the UI in InstallShield 2009 and earlier, an entry was added to the LockPermissions table; during installation the object’s access control list (ACL) would be changed to whatever was set in the table entry, completely disregarding any inheritance.
The only way to reflect the inheritance was to install the desired resource with the standard inherited ACL and then call a custom action to carry out the modification to the access control list.
In MSI 5.0, Microsoft has finally addressed this lacuna, plugging the gap with the MSILockPermissionsEX table, which has extra functionality in it. However, this table is ignored when the MSI is installed on a system with a Windows Installer version prior to 5.0, so it cannot be used when the installer needs to be installed on systems earlier than Windows 7. To add insult to injury, version 5.0 of Windows Installer will fail an installation if both the MSILockPermissionsEX table and the LockPermissions table are present in an MSI.
However, one of the new functionalities in InstallShield 2010 and later versions is a “standard” custom action and associated table ISLockPermissions. Now, as long as the option “Locked-Down Permissions” is set to “Use Custom InstallShield Handling”, if we set permissions on files, folders, or registry entries in the InstallShield UI, the default behaviour is that inheritance will be reflected, as well as some extra bonuses (such as the ability to use a security identifier (SID) in the permissions definition). The major benefit over MSILockPermissionsEX however, is that it works on all versions of Windows Installer, and thus Windows 7 and other versions.