We have an offshore development crew who has a bad habit of installing nonsense software on corporate desktops (which has nothing to do with their job function) and so are considering removing their local administrator rights.
Is Local Administrator, or local Power User a requirement with VS2010? How do you run without elevated rights? What issues will you run into?
A programmer should work as a limited user with admin access. That is, the programmer should be the admin of the machine, but while working, he should always use a limited user account.
If you need elevated rights to work, for anything but installing software, you're doing something very wrong. Worse, if you work as a power user or disable UAC prompts or the like, you're ignoring issues that will affect end-users of your software, forcing them to run with the same privileges you did. This is wrong.
This is true, irrespective of the operating system you're on. Though Windows seems to be the only one where where it comes up.
To clarify:
When I say the developer should be a limited user, I mean that they should have full admin rights to the machine, but when they test their code, it should be done in a limited-user environment. For example, the developer could be operating the machine as an Admin-capable user, but runs all tests in a virtual machine or in a limited user account. On Linux, this means simply that the dev has sudo access; on Windows, this may mean an Administrator-level account with UAC and other security features fully enabled.
This is a political or management issue, not a technical.
Consider creating and communicating a "we do not want you to install software that is not relevant to your job function" rule, so the boss can follow up accordingly.
To aid in this, the system administrator can ask each machine for a list of installed programs. If you do this on a regular basis, you can write a small program to show what has been installed, so you can get a quick overview.
That said, unless said programs are illegal or morally unacceptable, then why is this an issue in the first place?
It depends on what you expect them to develop independently.
Some things like IIS configuration, remote debugging, modify access to the GAC, the ability to run your own MSI would definitely be affected. If these are things you expect the outsourced resources to do independently I would not attempt it without a lot of testing.
If your outsource people are working on a desktop app they can debug locally you would likely get away with it with few issues.
Assuming they are using source control you could always schedule periodic re-image of the machines.
Most places I have worked do a whole lot of the first case, and expect high independence, so all devs are local admins and the corporate policy allows for disciplinary measures if you install unapproved software to any machine and cause problems.
I need admin rights to fire up Apache on port 80 on my development MacBook. Apart from that, there's no reason I couldn't be on a locked down machine with no admin rights. And I could use a nonstandard port, if I really needed to. From an enterprise resources standpoint, it makes sense to have developers not be privileged users of their machines.
However, locking a developer down on their machine needs to come along with a responsive and willing admin team. If I can't install stuff myself, I need somebody who can do it for me chop chop, and without putting me through three rounds of approval paperwork about it. If the enterprise is unwilling to commit to that, then they should give developers full run of their boxen.
I prefer the latter, obviously, but I can see the wisdom of the former.
I run VS 2010 not as administrator the vast majority of the time. But if you want to add or remove a service, configure IIS, or tinker in the registry, you're going to need admin rights. Also some of the profiling tools urge you to relaunch VS as admin. So I think giving your offshore people accounts that do not have admin powers is going to keep them from doing some (perhaps small) parts of their jobs.
What's more, with the rise of UAC, more and more apps can now install without admin powers. They don't put things in HKLM, they don't touch anything under System32, they put the exe somewhere under the users\whoever folder, and this makes them much easier to remove but may not address your original point that they are installing "nonsense software" by which I assume you mean games, music players etc.
If you really want to prevent local installs, perhaps the best bet is to the old vision of "the network is the computer" from early Java days. Everyone works from a version control system and must check in or shelve each night before going home. Email lives in the cloud not on the dev machine. Etc. Then whenever you want you can re-image their dev machines (even easier if they are virtual) and those who had nothing extra installed won't even notice. Kind of like cleaning out the office fridge over the weekend.
But be warned - I would not work in that environment. I install utilities and helpers, and I play games occasionally, and would not take kindly to someone who tried to prevent either. I am productive as hell. If some of your devs are not productive, taking away their local installs won't make them more productive or dedicated. Address that problem at the root and you won't mind that they are admins.
I suppose that removing admin rights from developers should come together with assigning one of the system administrators to install software for the team. If you both don't have admin rights, and can't ask administrator to install stuff for you, you're just handless in front of challenges you're facing. It's like you lock your offsore team in prison.
It depends what you are writing software for.
If your software doesn't need to intrude in your system, there is no need for administrator powers.
A better solution: For installation/testing purposes one might want to use VMs or test lab computers.
I've seen two approaches to this. One was to have everyone work from laptops, which they had to turn in to the admins when they went home. Once the admin had it, they would stick in a CD that would re-image the machine. Once it was re-imaged, it went on a shelf, where it would be available to the next person who needed one. Just make sure all machines are identical, so you don't wind up with people pawing through them all looking for a "good" one.
The other thing I've seen is to have everyone boot from a Citrix server. The machines have no local storage at all, they just load a standard image from the network and run from that. This works better if you have different "types" of users who require different configurations (e.g., UI developers have an image with Silverlight, WCF developers have IIS and SQL Server, etc.)
BUT, with all that said, I think Thorbjorn [sic] hit the nail on the head: this is a management issue, and probably won't be adequately addressed with a technical solution.
