Server Fault is a question and answer site for system and network administrators. 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 trying to get to a comprehensive list of policy settings for developers using Visual Studio 2008 (2010 specific permissions are helpful too) to do .Net development on everything from a Command Line application to a Windows Service to ASP.Net applications to WCF, etc.

Is there any policy settings recommended by Microsoft that will enable .Net development on the machine?

There is always a clash between developers and IT admins on what permissions should be granted as developers always bank on elevated privileges to get their job done.

The domain server is Windows 2003 (Windows 2008 specific permissions can be helpful in the future as well).

The workstations are Windows 7 Professional.

Any help will be appreciated.

share|improve this question

We actually just recently deployed VS 2010 in a university lab environment where the users have nothing more than standard user privs on Win7 x64 workstations. I'm not sure how Microsoft managed it, but most of the basic tasks that used to require admin don't seem to anymore. For instance, normal users can:

  • Create new ASP.NET web projects and run the debugger against the developement web server (not full IIS)
  • Create new WinForms/etc projects and run the debugger against their compiled code

Ours is a pretty vanilla VS environment though. A real development shop will likely have various other add-ins or dependencies that will change the requirements. What permissions those things need will vary.

share|improve this answer

To develop (and test) ASP.NET (and other things hosted under IIS) you will need local administrator access. (The upcoming IIS Express will reduce this need, but you are still going to need at least some testing on full IIS).

Since a local administrator can always suppress group policy (e.g. by adding deny ACLs to registry keys updated by group policy), the quick answer is none. Of course you will likely need to accept some policy settings, and most settings have little or no impact (e.g. setting IE's window title or forcing lock and timer on screen saver).

If the culture between IT Administration and Development is lacking trust to allow this, then optimising group policy should be left until the trust issues can be resolved.

share|improve this answer

Your Answer


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