Folder Permissions - unwanted repairs?
Hello,
Just as VikingLoki recommends in the topic http://itninja.com/question/adobe-reader-6.06, I use setacl for setting permissions on application directories.
Only users in a Global application group may use a specific application.
But now I have some problems with my repackaged msi's.
The situation is as follows (sorry for the long description):
The msi's basically have only two features (One with the HKCU-keys, subfeature with all the files and HKLM-keys).
First time user setting repair must take place using the cached msi only (strict policy here, therefore this feature structure).
We do only machine-based installations, never userbased installs.
Sometimes, when I am logged on with a user account without permissions on some applications, I get a repair of an application I am not entitled to use. The repair comes up when I try to use a function in another application, like Outlook or the Search-function in Windows Explorer. I had a look at it with regmon and discovered that the repair starts just after COM-registration of a dll has been used. (Examples: oleaut32, msinet). All those dll's are in standard Merge Modules, that are added to the msi that gets repaired.
So the problem is that a dll, which is shared by more applications, has information in the inprocserver32 value in the HKCR\CLSID\{GUID}\Inprocserver32 subkey, pointing to a feature of a product that is not accessible for all users. Keypaths of other components in this feature cannot be found because they are in locked-down directoires, and that's why I get the repair.
I solved this problem for some applications by moving the Merge Modules to a separate feature, that does not contain locked-down directories. This works excellent, no unwanted repairs anymore. But this solution has a major drawback: I cannot use advertisements now, because the feature with Merge Modules will not be installed when I use a shortcut that targets to another feature.
It could advertise it if I made the Merge Module feature a parent feature of the application feature, but then what do I have to do with my UserSettings feature?
I just wonder if someone else has encountered the same behaviour on locked-down machines, and of course how you solved it.
Also other experiences with unwanted repairs in locked-down environments will be of interest.
CS
Just as VikingLoki recommends in the topic http://itninja.com/question/adobe-reader-6.06, I use setacl for setting permissions on application directories.
Only users in a Global application group may use a specific application.
But now I have some problems with my repackaged msi's.
The situation is as follows (sorry for the long description):
The msi's basically have only two features (One with the HKCU-keys, subfeature with all the files and HKLM-keys).
First time user setting repair must take place using the cached msi only (strict policy here, therefore this feature structure).
We do only machine-based installations, never userbased installs.
Sometimes, when I am logged on with a user account without permissions on some applications, I get a repair of an application I am not entitled to use. The repair comes up when I try to use a function in another application, like Outlook or the Search-function in Windows Explorer. I had a look at it with regmon and discovered that the repair starts just after COM-registration of a dll has been used. (Examples: oleaut32, msinet). All those dll's are in standard Merge Modules, that are added to the msi that gets repaired.
So the problem is that a dll, which is shared by more applications, has information in the inprocserver32 value in the HKCR\CLSID\{GUID}\Inprocserver32 subkey, pointing to a feature of a product that is not accessible for all users. Keypaths of other components in this feature cannot be found because they are in locked-down directoires, and that's why I get the repair.
I solved this problem for some applications by moving the Merge Modules to a separate feature, that does not contain locked-down directories. This works excellent, no unwanted repairs anymore. But this solution has a major drawback: I cannot use advertisements now, because the feature with Merge Modules will not be installed when I use a shortcut that targets to another feature.
It could advertise it if I made the Merge Module feature a parent feature of the application feature, but then what do I have to do with my UserSettings feature?
I just wonder if someone else has encountered the same behaviour on locked-down machines, and of course how you solved it.
Also other experiences with unwanted repairs in locked-down environments will be of interest.
CS
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
francist
18 years ago
Yes, we've experienced similar problems on machines where shared COM components are 'advertised' and the logged on User does not have rights to all installed applications (on a Citrix server for example). There are 2 solutions:-
1) Don't advertise COM components (might be difficult to achieve as some merge modules have this built in)
2) Give the built in Group 'Everyone' List Folder/Read Data permissions (but not execute) in all your packages
We've gone for option 2, but are considering also removing COM advertising as it causes more trouble than it's worth
1) Don't advertise COM components (might be difficult to achieve as some merge modules have this built in)
2) Give the built in Group 'Everyone' List Folder/Read Data permissions (but not execute) in all your packages
We've gone for option 2, but are considering also removing COM advertising as it causes more trouble than it's worth
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.