Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having an installation issue with a custom written add-in for Outlook. If I am logged in as the domain admin on the PC I can install the program without seeing a UAC prompt and the installation functions normally (end result: all users of the system are given access to the Outlook add-in). If I login with a domain user that is a local admin of the machine and install the program I get a Yes/No UAC prompt and no users have access to the program (including the user that did the install).

Allow me to summarize in a different way.

  • Domain Admin:
    • UAC prompt during installation?: No
    • Program installs without error and functions properly?: Yes
  • Domain user in local Administrators group:
    • UAC prompt during installation?: Yes
    • Program installs without error and functions properly?: No because other users (including domain admin) do not have the add-in available to them in Outlook.

In a vanilla domain environment, what are the differences in permissions between a domain administrator and a domain user with local admin privileges when operating on the same domain joined computer?

share|improve this question
Care to elaborate? – idon'twearsuits May 3 '13 at 15:31
That's not what is at question. I believer you've misunderstood my original question. – idon'twearsuits May 6 '13 at 5:54
I fully understood your question. I will again point out the domain has the ability to prevent even a local administrator account from installing an application. You asked if they are given their rights from the same Administrator groups and the answer to that question is NO – Ramhound May 6 '13 at 10:38
Then I apologize. I have rephrased my questions. – idon'twearsuits May 6 '13 at 15:16
The group policy that defines the permission of a domain User will override the local Administrator permissions. Likewise if you logged as the domain Administator you take on any permissions defined by that role even if its an local user account. I suggest doing some research on how domain roles are defined. There are too many differences to list to compare a domain administrator and a local administrator since that would be based on your domain itself. – Ramhound May 6 '13 at 15:27
up vote 1 down vote accepted

In the normal course of things, there is no difference for workstation permissions between an account in the Domain Admins group and a Domain User account that has been added to the local Administrators group. Windows implements Domain Admin permissions primarily by placing the Domain Admins group in the local Administrators group at the time a machine is joined to the domain, so it amounts to the exact same thing from the point of view of a single workstation. You can see this by viewing the local Administrators group on a domain-joined workstation, and noting that the Domain Admins group is present as a member. The Domain Admins group has additional privileges when working on the domain itself, plus the benefit of being a member of the local Administrators group by default on all workstation in the domain, but from the point of view of a single workstation, and things that can be done on/to that workstation, there is no difference at all. Also remember that this is just the "normal course of things"; you can configure your domain or a workstation so that things are different.

This means that by default the Domain Admins user should still need to pass a UAC prompt to install your app. That you did not see one indicates that you no longer have a "vanilla domain environment", and someone deliberately disabled this on your domain... probably through group policy. This is a bad idea. You should see about getting that turned back on. The difference here between that and your normal user with admin rights is that someone took the time to turn off UAC. IIRC, disabling UAC is also a per-account (really: per profile) feature, and so this may even be something that you had to do for your own account.

The question now is how to work around this, to allow your local-Administrator Domain Users to install your software. To that end, it's important to remember how administrative accounts work by default in Windows now. Things have changed since Windows XP. Starting with Vista, and including Windows 7 and 8, you never have administrator rights by default, even if you're in the Administrators group, and sometimes even if you pass a UAC prompt. If you really want to use your administrator privileges in Windows Vista and later, you need to right-click the application or installer and select the Run as Administrator option. Doing this will likely allow your Domain User accounts to install the program successfully, such that any user on the workstation can use the Add-In.

In this particular case, you may also be able to get around the issue by changing some file system permissions on the location where the app installed. By default, standard users do not have any write access inside the Programs Files folder where your add-in is likely installed. You may be able to fix your issue by finding the app's folder and setting permissions on that folder so that standard users will have write access. However, because we are dealing with an Office Add-In I suspect the problem is more likely to be write access to a registry key, or missing write access at install time such that an expected registry key is now missing. If that is the case, a work-around fix such as this may still be possible, but will be a lot more difficult to figure out and implement.

share|improve this answer
What you've said is what my understanding has been also. I'll look and see if any of my policies are in fact disabling UAC. – idon'twearsuits May 6 '13 at 16:55
Hey, I just added a paragraph at the end that might help you. – Joel Coehoorn May 6 '13 at 19:49
You're right in that the problem is not the filesystem but the registry. Thanks, though! – idon'twearsuits May 6 '13 at 20:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.