Issues around Policies, elevated privs, Local user vs Domain user
I'd like to get a conversation going about the different aspects of installing as various users
Some things I have found in testing but no documentation on these types of things.
1. A Domain user Installes a Per-Machine package. (Admin has allowed for AllwaysInstallElevated in both HKLM & HKCU, and EnableUserControl)
2. The package gets installed, the system gets a re-boot, policies remain the same.
3. The Domain user Looks in add remove programs highlight the just installed package and Change/Remove are disabled.
4. The install author has the ability to allow the Domain user to "Repair" the installation.
5. The domain user navigates to the Install Source location and trys to Lanch the installer a second time to say, lets add an additional feature only to have the installer report back "The system administrator has set a policies to prevent this instalaltion"
6. So the savy Domain user knows that the install package is cached locally on the system so they navigate to \\winnt\installer and launches the install ab3ea.msi and bam the installer launches and the Domain user gets to add the additional feature remove features or even remove the entire product.
7. SO I say why then can't I allow this behavior from the Add/Remove programs group.
Like I said in the begining I'd like to see this as the start of a conversation around these type of deployment issues.
-Michael Clark
Some things I have found in testing but no documentation on these types of things.
1. A Domain user Installes a Per-Machine package. (Admin has allowed for AllwaysInstallElevated in both HKLM & HKCU, and EnableUserControl)
2. The package gets installed, the system gets a re-boot, policies remain the same.
3. The Domain user Looks in add remove programs highlight the just installed package and Change/Remove are disabled.
4. The install author has the ability to allow the Domain user to "Repair" the installation.
5. The domain user navigates to the Install Source location and trys to Lanch the installer a second time to say, lets add an additional feature only to have the installer report back "The system administrator has set a policies to prevent this instalaltion"
6. So the savy Domain user knows that the install package is cached locally on the system so they navigate to \\winnt\installer and launches the install ab3ea.msi and bam the installer launches and the Domain user gets to add the additional feature remove features or even remove the entire product.
7. SO I say why then can't I allow this behavior from the Add/Remove programs group.
Like I said in the begining I'd like to see this as the start of a conversation around these type of deployment issues.
-Michael Clark
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
Bladerun
18 years ago
EDIT: *Removed*
As far as the remove and change functionality showing up in Add\Remove programs, I've seen that several times and in each case it was a setting in the MSI.
As far as the remove and change functionality showing up in Add\Remove programs, I've seen that several times and in each case it was a setting in the MSI.
Posted by:
viv_bhatt1
18 years ago
Also you can write custom actions while packaging MSI to control repair and modify functionalities .
Common examples are : - disabling cancel button during repair etc .
Common examples are : - disabling cancel button during repair etc .
Posted by:
mclark114
18 years ago
Bladerun, your comment about AllwasyInsatllElevated "AlwaysInstallElevated property only applies to Advertised/Assigned packages, not those that are manually run by the user" is not true.
If I'm a local or domain user with Non-Administrative privilege and I have a CD with software that requires Administrative access to the system then AlwaysInstallelevated Must be set, regardless of Advertise/Assigned. Installed in this way as a Per-Machine Install is referred to as a Managed Installation/Managed App.
And yes in the MSI there are 3 keywords
ARPNOMODIFY
ARPNOREPAIR
ARPNOREMOVE
But the only one that seems to have any effect for and Non-Admin users is ARPNOREPAIR setting this value you can enable/dis-able the repair functionality for All users.
Michael Clark
If I'm a local or domain user with Non-Administrative privilege and I have a CD with software that requires Administrative access to the system then AlwaysInstallelevated Must be set, regardless of Advertise/Assigned. Installed in this way as a Per-Machine Install is referred to as a Managed Installation/Managed App.
And yes in the MSI there are 3 keywords
ARPNOMODIFY
ARPNOREPAIR
ARPNOREMOVE
But the only one that seems to have any effect for and Non-Admin users is ARPNOREPAIR setting this value you can enable/dis-able the repair functionality for All users.
Michael Clark
Posted by:
Bladerun
18 years ago
Interesting. I remember reading otherwise, but it likely was on a forum and not a reputed source.
Learn somthing new everyday I suppose [8D]
Learn somthing new everyday I suppose [8D]
Posted by:
mclark114
18 years ago
This is exactly why I wanted to get this conversation going. MSI seems to carry with it a lot of black magic (i.e. things people don't fully understand). Microsoft has made very little attempt to update there documentation and has left it to Developers and third party programs to fill in the blanks. I have requested from MS several times that the should offer a certification program on MSI, and again they are leaveing it up to Product vendors to do this or boards like this. The problem there in lies is the product vendors gear there training towards there product and not the details of MSI. So I invite anyone with any questions on the black art of MSI to participate in this conversation.
-Michael Clark
-Michael Clark
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.