I work at a Fortune 500 company as a Windows software developer in R&D. Corporate IT is currently gearing up for a company-wide Win7 deployment and as a part of it they are looking to completely lock down admin rights on all boxes (including our dev workstations).

I've been tasked to work with them to make the transition as smooth as possible. Lucky me.

I'd like to know if there are any published or other highly respected resources out there that I can use to:

  1. figure out where to draw a line in the sand
  2. back up my position.

Personally, my take is that we're R&D and our job is to do things that are 'out of the box'. Thus we need admin rights. However, having started my career as a Windows Admin, I'm aware of their goals and what they need to achieve. What I need to figure out and back up is a way to build the environment in a way that both IT and R&D can live with it and continue to perform their jobs productively.

Development VMs with local admin rights will definitely help a lot, but not in all cases since we interface with lots of custom hardware.

The CIO pushing these changes is definitely a 'pure IT' kind of guy with limited knowledge of the development process so I need some references that would be appropriate to share with someone like that.

I'm not looking to gather a lot of personal opinions (a lot of which have already been shared here), I really need whitepapers, magazine articles, scholarly works, etc to use to make a strong case to upper management.


8 Answers 8


Because you are going specifically to Windows 7, you should push hard to be admins on your own boxes. There are two really good reasons to keep developers from being admins:

  • the same reason you keep everyone else from being admins, so that malware doesn't do really awful things if it happens to run
  • so they won't write apps that only work if you're an admin

With UAC, neither of these things will happen, since apps you launch won't run as admin unless you deliberately ask them to. Thus there is little risk to letting you have an admin account.

Some bosses have a third reason - I don't want you installing games or unauthorized tools. Without discussing the merits of this reason, I will observe that it usually remains unstated. You need admin access to install the stuff you're writing, to configure IIS, to reconfigure your machine for various kinds of testing (eg editing your host file) and the two "real" reasons for avoiding admin access no longer apply for Windows 7. Therefore, you should be admins.


Honestly I think it's going to be a tough case to make. Once upper management makes up their mind it's pretty difficult to get them to change. If they allowed more privileges on your machine, someone else might be able to access and perform the actions this whole plan was designed to prevent.

These may help:

PS: Best of luck!

  • Thanks for the reply. I'm aware of the goals they are trying to accomplish (I started my career in IT / Server Admin). What I'm looking for is a way to build the least restrictive environment that both IT and R&D can live in and continue to do their jobs.
    – Dan
    Mar 25, 2011 at 14:08
  • Upvoted because of the link to serverfault - my guess is that the OP should definitely be able to find some arguments for his case there. Aug 5, 2014 at 18:14

One option is to ask for test workstations that do allow administrative access.

Another option is to do exactly as they say. Then when the next project comes along, you won't be making any progress because you have to go to IT for every small change. Explain this to the project leader, and he'll arrange for admin rights quickly.

A third option is to check if your department is represented in the Win7 migration project. If it is, contact your representative, and ask if he can add administrative rights to your department's requirement list.

A fourth option is to trade. The migration project typically needs development to update their software for Win7. It might be possible to condition a supportive attitude on admin rights in the new environment.

  • 3
    Doesn't work - it just means you have to do your job without things like debuggers, and it's your fault for being slow Mar 26, 2011 at 15:24
  • 1
    @Martin Beckett: Well, colleagues one floor down had this problem. They went for the PM approach, and the PM arranged for local admin, faster laptops, and bigger screens.
    – Andomar
    Mar 26, 2011 at 15:35
  • Depends on who's enforcing the no-admin policy and how strict they're going to be. If (as in the case here) it's the CIO, and he's not from a development background, it would be better to make the case that there should be exceptions, rather than assume you can get one. Mar 28, 2011 at 14:09

I can't imagine trying to develop without being a local admin, however I think the needs will vary depending on development tasks and how standardized the development process and toolchain is at your workplace.

From my experience, there are usually senior development staff that will need to install various dev tools (sometimes at odd hours) to rapidly prototype or troubleshoot some critical issue. They almost certainly need local admin access to install, debug, work with services, etc.

The remaining staff may be able to get by without it, if your toolset is fairly constant, and depending on what they develop/debug/deploy. My suggestion would be to get a small set of your most level-headed senior dev staff together, explain the issue and their options, and have them take a couple days to consider it, and then have a planning meeting to determine what kind of access the staff should have.


From a pure IT perspective and a development perspective, many companies solve the problem in this manner:

Put all development boxes on a separate network. The development network might be completely isolated (no internet and no intranet). In this case, the developers have a separate corporate box that is used for email and official communications--i.e. access to both the internet and intranet. This solution has its own challenges as certain IDEs (like Eclipse) and other development tools assume you have a live connection to the internet to get updates and plugins. Still the large majority of development tools know that isolated networks exist.

Another variation of this approach is to have the dev network on a sub-net. You have indirect access to internet and intranet through a strict DMZ firewall, but still the developers have local admin access.

  • 1
    +1 for separation, treat dev like remote users and it tends to assuage corporate IT pretty well. Mar 28, 2011 at 15:15
  • "no internet" you mean they schouldn't be allowed to use Stackoverflow on their dev machines?!
    – mbx
    Jul 1, 2013 at 9:28
  • Correct. Separate machines for internet and devopment Jul 1, 2013 at 10:58

Consider giving the developers two accounts.

The first is a normal non-privileged user account, which is the one to use for all everyday work (including software development). The other is a local admin account, which only has admin privileges on specific machines. It should only be needed when actually installing stuff or tweaking machine settings.

Ensure that everyday services such as the internet proxy server, email and so on only recognise the normal account, so developers can't just use the local admin one all the time. Whenever admin privileges are required, UAC will pop up and offer the developer a chance to enter their local admin log-in details to proceed.

  • this is what I got at my job and it work pretty well + 1
    – Rémi
    Aug 5, 2014 at 19:11

Software development is a fundamentally different beast from literally every other use of a computer, and it has to be treated as such.

The ability to write your own code, and more importantly trace your code execution in debugging, requires you to have permissions on your computer that, under any other context, would pose a huge risk to local security. Rephrased in sound-bite form:

Permissions required for software development are not appropriate for typical users.

In order to get your job done, you need to be local admin. But by being local admin and circumventing security policy, you're theoretically posing a risk to the rest of the network. So that concern needs to be addressed as well. The way security-critical companies solve this issue is by imposing two simple rules:

  1. Programmers are local admin access on their development machine.
  2. Development machines are not connected to the company network.

How the second rule plays out is up to the IT department. Sometimes the development machine is isolated on its own with no network in or out (seen in several Defense contractors), and sometimes the machine is connected to a "Guest" or "DMZ" network to allow for Internet access (downloading patches, accessing documentation, etc.) without putting the company network at undue risk.

Now, will you find some offical source on this? I guess that depends on whom you see as official. The opinion on this matter is basically unanimous. But it's so well-understood that it's rarely stated. It's a bit like asking: "Should my car have a parking brake?" You're not going to find authoritative sources speaking out of the subject because they have better things to do and everyone already knows that answer.


Can you use a virtual environment?

If you aren't doing graphics heavy stuff then running MSVC in vmware or virtualbox is fine (if you have lots of ram) then you can have admin in the virtual environment and 'their' install is locked down

  • 2
    The opposite might work better: use a corporate workplace in a virtual environment. Corporate IT usually provides this for managers anyway, and you only use it to read and send email.
    – Andomar
    Mar 26, 2011 at 15:36
  • yes but if the problem is not letting you have admin rights to run a debugger or test installs that doesn't help Mar 26, 2011 at 15:42
  • Well the idea is that the virtual server is on corpnet, but you are not. So you can be local admin
    – Andomar
    Mar 26, 2011 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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