• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5488
  • Last Modified:

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
0
Martin Kreis
Asked:
Martin Kreis
  • 5
  • 5
  • 4
  • +2
2 Solutions
 
kurian2z5Commented:
You MUST use a machine level admin account or a domain admin account.
0
 
Martin KreisAuthor Commented:
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!
0
 
kurian2z5Commented:
Since your domain user accounts are part of the local administrators group you can simply create a new local user.
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
Martin KreisAuthor Commented:
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...
0
 
Meir RivkinFull stack Software EngineerCommented:
did u try disable the UAC for the time of installation?
0
 
Meir RivkinFull stack Software EngineerCommented:
also, change the MSI project Properties to install for current account only and not all accounts.
0
 
Martin KreisAuthor Commented:
No, didn't try to disable UAC...

How can i change in a web setup project to install for current user only?
0
 
Meir RivkinFull stack Software EngineerCommented:
>>How can i change in a web setup project to install for current user only?

change InstallAllUsers property, see screenshot
Untitled.jpg
0
 
Martin KreisAuthor Commented:
That is ok for Win App Setups, but in webSetupProjects there is not such an option...
0
 
Martin KreisAuthor Commented:
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.
0
 
McKnifeCommented:
Your problem is that the msi does not invoke the UAC. As I am not familiar with self-built MSIs, I can only advise you to read MS' guidance on how to build UAC compatible/UAC-aware MSIs.

For now you can workaround this problem by either starting the msi from an elevated command line or by installing this MS powertoy: elevate. Elevate adds a context menu entry for the .msi-filetype: "install as administrator". http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx
0
 
Vadim RappCommented:
Enable "always install with elevated privileges" in the group policy. Or you can publish or assign the MSI package in the group policy and launch the installation from "add programs from network", then it becomes elevated automatically.

If that does not help, please post detailed installation log, see kb 223300.
0
 
McKnifeCommented:
> 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.
0
 
Vadim RappCommented:
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.
0
 
Vadim RappCommented:
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.
0
 
McKnifeCommented:
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.
0
 
Vadim RappCommented:
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.


0
 
McKnifeCommented:
"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?
0
 
Vadim RappCommented:
> 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."
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 5
  • 5
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now