locking down desktops

T

tghetti

I'm curious as to how other organizations handle desktops in a
development organization.

I work for a software company and we run into numerous issues with our
developers screwing with things. I would like to lock them down to
"regular user" status only, but they complain that they cannot get
their work done. How do other people handle situations like this?

thnx
 
R

Robert Moir

tghetti said:
I'm curious as to how other organizations handle desktops in a
development organization.

I work for a software company and we run into numerous issues with our
developers screwing with things. I would like to lock them down to
"regular user" status only, but they complain that they cannot get
their work done. How do other people handle situations like this?

Don't lock them down, but make them responsible for their own systems. To
some degree, you need to let developers have their heads on their own
machines. The exact level of rights a dev needs is open to debate, dependant
on the work being done and the tools being used. I can recall a few
developer tools that just won't run properly if you're not a local admin!

With that in mind, the aim should be to develop a mutually useful framework
for supporting their machines without draining the support department dry.

Meet with the devs and make it clear that when an issue is reported, you'll
work to clear it as normal up to a limit - the next step I'm going to
suggest is an extreme one and you wouldn't want to activate it for trivia
which *could* easily be fixed.

Once the issue goes beyond that limit, you have two choices. If this is a
large company that supports the concept of cross-department charging for
resources then any further work on dev machines past this "limit" is
chargable. This is simple in its way, but controversial.

The "other" next step is to produce, for example, a "standard issue for
developers" Ghost or RIS image or whatever it is you do. When a call passes
your "limit", simply re-image the machine back to it's default "supported"
state. Any further setup of the machine is up to the developer and is
unsupported.

Some might say these steps are a little harsh - and it certainly needs both
"sides" to be clear on how things will happen in advance - but at the end of
the day, its often unfair to expect devs to work on a machine that is
totally locked down to the same level that normal users have, and it is
equally unfair to expect support techs to unravel a gordian knot caused by
developers fiddling with things best left alone.

--
--
Rob Moir, MS MVP
Blog Site - http://www.robertmoir.com
Virtual PC 2004 FAQ - http://www.robertmoir.co.uk/win/VirtualPC2004FAQ.html
I'm always surprised at "professionals" who STILL have to be asked "Have you
checked (event viewer / syslog)".
 
P

Pheylan

1. Invest in a good imaging solution and make base images of each desktop
2. Assign the users local admin rights
3. Make sure that the departments know that if you have to use the
images, that they are liable for costs
4. And confirm that all critical data is stored serverside or is
consistently backed up, real-time if possible/need-be

HTH
Kelly
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top