Sufficient privileges to install MSI on Win 7 or Win 2008 Server
Hello
I am trying to install my own Application MSI (Web Deployment) on a Win 2008 R2 Server or on a Win 7 Ultimate 64 Bit.
On both machines i am logged in as User which is member of the local Admin group.
But the installer fails right after starting the install progress with the Message (from log):
Error 1925. You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator and then retry this installation.
I our company we could not get the local admin account, so we have to work with our Domain Users which are in the local Admin group.
What do we have to change on the Server that it will be possible to install MSI's as Domain User in the local Admin group? Some Policy change?
For us, it is really important to get this run...
Thanks
Martin
msiLogServer.log
I am trying to install my own Application MSI (Web Deployment) on a Win 2008 R2 Server or on a Win 7 Ultimate 64 Bit.
On both machines i am logged in as User which is member of the local Admin group.
But the installer fails right after starting the install progress with the Message (from log):
Error 1925. You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator and then retry this installation.
I our company we could not get the local admin account, so we have to work with our Domain Users which are in the local Admin group.
What do we have to change on the Server that it will be possible to install MSI's as Domain User in the local Admin group? Some Policy change?
For us, it is really important to get this run...
Thanks
Martin
msiLogServer.log
kurian2z5
You MUST use a machine level admin account or a domain admin account.
ASKER
Sorry, domain admin or local admin is not possible to get such an account!
We could only work with users in the local admin group!
We could only work with users in the local admin group!
Since your domain user accounts are part of the local administrators group you can simply create a new local user.
ASKER
thanks, that i am knowing for sure...
But i do not believe that there is no way to work with a user in the local admin group...
But i do not believe that there is no way to work with a user in the local admin group...
did u try disable the UAC for the time of installation?
also, change the MSI project Properties to install for current account only and not all accounts.
ASKER
No, didn't try to disable UAC...
How can i change in a web setup project to install for current user only?
How can i change in a web setup project to install for current user only?
>>How can i change in a web setup project to install for current user only?
change InstallAllUsers property, see screenshot
Untitled.jpg
change InstallAllUsers property, see screenshot
Untitled.jpg
ASKER
That is ok for Win App Setups, but in webSetupProjects there is not such an option...
ASKER
Hmm, ok... if we run the installation over the setup.exe (not direct the MSI) then the setup.exe makes the uac call and it works.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> Enable "always install with elevated privileges"
Bad idea in security terms because it's a per machine settings and will enable weak users to install MSIs, probably some they built by themselves with the purpose to gain permanent admin access.
Bad idea in security terms because it's a per machine settings and will enable weak users to install MSIs, probably some they built by themselves with the purpose to gain permanent admin access.
1. weak users supposedly can't touch the server at all.
2. they are already in local admin group, so fight for security should probably start there.
2. they are already in local admin group, so fight for security should probably start there.
3. in real life, most installations are not MSI-based, so preventing installations of MSI wouldn't make much sense.
In any case, if the admin has already made conscious choice to make local users admins, there's no reason for the o/s to override it with its own opinions.
In any case, if the admin has already made conscious choice to make local users admins, there's no reason for the o/s to override it with its own opinions.
vadim, you don't get the problem.
He has an msi that does not trigger UAC to ask for elevation, that's all. I gave him a way to elevate any msi, there is no need to alter security settings in any way.
1. You don't know if there are other users at the server (TS maybe) or at the win7 client he mentions.
2. your policy enables anyone to install any MSIs, no need for admin group membership
3. who does prevent MSI installations? I don't follow.
He has an msi that does not trigger UAC to ask for elevation, that's all. I gave him a way to elevate any msi, there is no need to alter security settings in any way.
1. You don't know if there are other users at the server (TS maybe) or at the win7 client he mentions.
2. your policy enables anyone to install any MSIs, no need for admin group membership
3. who does prevent MSI installations? I don't follow.
If I understand correctly, his users are already all local admins, and so if they are able to install from elevated prompt, the g.p. setting I suggested achieves the same, with less keystrokes. It's just another option for admin's consideration. Note that the question was about resolving specific problem with Installer, rather than what would be the best security practices in his domain. If Microsoft has created this group policy setting, it probably does have some scenarios when it's ok to do.
Note that in the same place of the policy there are other security-related settings, for instance "prevent removable media source from any install", "allow admin to install from TS session", "enable user to use media source while elevated", and more.
> 3. who does prevent MSI installations? I don't follow.
Installer. If users are already local admins, and they are able to bring and install some unapproved setup.exe, then there's no much point in Installer introducing some extra checking of MSI's only.
Note that in the same place of the policy there are other security-related settings, for instance "prevent removable media source from any install", "allow admin to install from TS session", "enable user to use media source while elevated", and more.
> 3. who does prevent MSI installations? I don't follow.
Installer. If users are already local admins, and they are able to bring and install some unapproved setup.exe, then there's no much point in Installer introducing some extra checking of MSI's only.
"Your" Policy mentions it:
> Caution: Skilled users can take advantage of the permissions this setting grants to change their privileges and gain permanent access to restricted files and folders. Note that the User Configuration version of this setting is not guaranteed to be secure.
I think you are still missing that he has not told us if there are other users on those two systems. If there are, this policy compromises security. Always install elevated is meant for systems where admins would like users to be non-admins but on the other hand enable them to install applications. That's the only purpose. In the policy description you can see that this policy exists since win2k - it had nothing to do with UAC elevation.
My argument is that we don't need this change. Sure, he can try if this triggers UAC (which I personally doubt), but there is no need to. He should learn how to write MSIs that ask for elevation. As a workaround I gave him that elevation tool that expands the context menu (or the "trick" to start that MSI from an elevated command prompt). This is easy and does not alter security settings.
I think security settings should be left alone unless you can't get around those. Do you agree?
> Caution: Skilled users can take advantage of the permissions this setting grants to change their privileges and gain permanent access to restricted files and folders. Note that the User Configuration version of this setting is not guaranteed to be secure.
I think you are still missing that he has not told us if there are other users on those two systems. If there are, this policy compromises security. Always install elevated is meant for systems where admins would like users to be non-admins but on the other hand enable them to install applications. That's the only purpose. In the policy description you can see that this policy exists since win2k - it had nothing to do with UAC elevation.
My argument is that we don't need this change. Sure, he can try if this triggers UAC (which I personally doubt), but there is no need to. He should learn how to write MSIs that ask for elevation. As a workaround I gave him that elevation tool that expands the context menu (or the "trick" to start that MSI from an elevated command prompt). This is easy and does not alter security settings.
I think security settings should be left alone unless you can't get around those. Do you agree?
> I think security settings should be left alone unless you can't get around those. Do you agree?
sure
> My argument is that we don't need this change.
but it's simply an equivalent to user opening elevated box. Compare: "whenever you need to install something, open elevated box and install" vs. "whenever you need to install something, the system will assume it's elevated". No big difference. In fact, in some degree it's even more secure, since with elevated box the user can do other things, while this one is specifically for installations.
> He should learn how to write MSIs that ask for elevation.
according to http://msdn.microsoft.com/en-us/library/aa372468%28VS.85%29.aspx , this should be done automatically: "Before an installation identified as requiring administrator privileges can be run, UAC prompts the user for consent to elevate the installation. The consent prompt is displayed by default, even if the user is a member of the local Administrators group, because administrators run as standard users until an application or system component that requires administrative credential requests permission to run."
sure
> My argument is that we don't need this change.
but it's simply an equivalent to user opening elevated box. Compare: "whenever you need to install something, open elevated box and install" vs. "whenever you need to install something, the system will assume it's elevated". No big difference. In fact, in some degree it's even more secure, since with elevated box the user can do other things, while this one is specifically for installations.
> He should learn how to write MSIs that ask for elevation.
according to http://msdn.microsoft.com/en-us/library/aa372468%28VS.85%29.aspx , this should be done automatically: "Before an installation identified as requiring administrator privileges can be run, UAC prompts the user for consent to elevate the installation. The consent prompt is displayed by default, even if the user is a member of the local Administrators group, because administrators run as standard users until an application or system component that requires administrative credential requests permission to run."