This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Conditional Permissions
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Jan 07, 2010
04:43 PM
Conditional Permissions
I am trying to write an MSI InstallShield 2010 project which will set the proper permissions on a few folders. The problem is that Vista users are covered in the group "Everyone". As far as I know, no "Authenticated Users" group normally exists on Windows Vista. Our own corporate users, who use Windows XP are all covered in the group "Authenticated Users", but none of our corporate users are included in the "Everyone" group.
If I try to set permissions for both "Everyone" and "Authenticated Users" in the install, it will fail on both operating systems since one group, or the other, will not be present on the target operating system. This will cause the install to fail and abort.
Is there a way to set permissions for both groups conditionally based on whether or not the user groupo exists on the target operating system?
Cheers,
Don
If I try to set permissions for both "Everyone" and "Authenticated Users" in the install, it will fail on both operating systems since one group, or the other, will not be present on the target operating system. This will cause the install to fail and abort.
Is there a way to set permissions for both groups conditionally based on whether or not the user groupo exists on the target operating system?
Cheers,
Don
(2) Replies
‎Jan 08, 2010
12:06 PM
Authenticated users should exist on Vista or newer versions of Windows (it's listed as an account on Windows 2008 and Windows 7 machines that I checked). Unless you are using the MSI LockPermissions support, it should be possible to set permissions for Everyone and Authenticated Users on Windows XP or newer version of Windows.
If you are using the MSI LockPermissions support or InstallShield ISLockPermissions support, unfortunately, there is no way to conditionally apply permissions (this is possible with the new MsiLockPermissionsEx table in Windows 7/MSI 5.0). A custom action would be required in this case to apply permissions as needed based on the target operating system (note that InstallScript custom actions can call the InstallScript SetObjectPermissions function, which is functionally equivalent to the ISLockPermissions table support).
If you are using the MSI LockPermissions support or InstallShield ISLockPermissions support, unfortunately, there is no way to conditionally apply permissions (this is possible with the new MsiLockPermissionsEx table in Windows 7/MSI 5.0). A custom action would be required in this case to apply permissions as needed based on the target operating system (note that InstallScript custom actions can call the InstallScript SetObjectPermissions function, which is functionally equivalent to the ISLockPermissions table support).
‎Jun 08, 2010
08:50 AM
There is a difference between LockPermissions and ISLockPermissions though.
In our install we have for each OS version a separate component that creates the same folder. For Windows 2003 IIS_WPG will be added and for XP the ASPNET is added.
When using the LockPermissions table only the entries are processed for the LockObjects that are actually being installed.
When using the ISLockPermissions table all permissions in the table are executed unconditionally, regardless of the component install state.
After several hours of investigation we went back to the LockPermission table. It's a pity cause the support for automatic conversion of localized names was a very nice feature.
In our install we have for each OS version a separate component that creates the same folder. For Windows 2003 IIS_WPG will be added and for XP the ASPNET is added.
When using the LockPermissions table only the entries are processed for the LockObjects that are actually being installed.
When using the ISLockPermissions table all permissions in the table are executed unconditionally, regardless of the component install state.
After several hours of investigation we went back to the LockPermission table. It's a pity cause the support for automatic conversion of localized names was a very nice feature.