Can Developers Work in a 'Locked-Down' Environment? 648
brad-d queries: "My company is seriously considering enforcing a SOE on all employee computers, including developers. The level of lock-down would likely include baring the Windows registry from changes (and in effect stopping the installation of new software). The goals of this SOE are to prevent users from installing unlicensed software, plus some support issues. What are others experiences with situations like this? Can a developer really work in a lock-down environment? What compromises could be made between developers and IT services? And no, Linux would be likely banned." It depends on how "locked-down" said environment is, and what the developer would be will be working on, however if the Registry is locked with no mechanism provided for the Developer to add in whatever keys are necessary, how much real developing can one do?
Re:Registry lockdown? (Score:5, Informative)
Yes, I've seen this before. In a university environment I used to work in, we tried to lock down the registry...we had to make so many exceptions for various application that required full registry access to run (scary), that by the end of the semester we gave up on locking down and went back to rebuilding the systems nightly (which introduced a whole group of other messes...)
Re: What is SOE?? (Score:5, Informative)
Just so ya know... I had to look it up
antidigerati
What a loss in productivity. (Score:2, Informative)
Where I currently work, no software can be installed, and much existing software breaks. Windows media player causes a GPF, and many enhanced websites cause the machine to hang. The registry is locked down, and I don't have rights to "program files".
Every time in the past I've needed a piece of software, it generally takes days to be installed, and the entire chain of command has to OK it. If we directly submit a request be it for software or support, it gets deleted.
This completely and utterly lowers productivity. If I need something and I need it now, it takes days or weeks to make it happen. Problems or requirements that could easily be taken care of by the user are not possible, resulting in delays and wasted time.
Plus, IT stops by once a week to add software, odbc connectors, or make other changes. Those are things I could very easily do myself. Doesn't IT have better things to do?
I'm surprised they let me add bookmarks. Don't even get me started on firewall rules.
Hell no, BUT!!! (Score:2, Informative)
Re:They can't (Score:2, Informative)
Our source control system, critical apps, intellectual property, bug-tracking system and stuff like that are kept on servers to which the average developer has no admin rights. And only IT can add new machines to the domain/change domain properties for machines.
It works quite well. There's a good mix of tools (shareware, freeware, commercial) and we can usually try things which might make our lives more useful.
The only things IT mandate are that we keep the Virus Protection up to date, and lock the screen/log off when we go home at night.
Propose this model to your IT folk -- it works, it's less trouble for most people, and you can weed out the troublesome alleged l33t developers who can't keep a system running without help!
Re:They can't (Score:1, Informative)
Re:Registry lockdown? (Score:3, Informative)
OTOH, locking down HKEY_LOCAL_MACHINE makes perfect sense and programmers who use it for user-settings should be shot. Twice.
Developers need to write the administrative portions, so they really can't be locked down. Giving a programmer a C compiler and no registry access is like giving a soldier an Uzi, but no ammo except rubber bands. Well almost.
My troll sensor is going off (Score:2, Informative)
Re:Registry lockdown? (Score:5, Informative)
I'm also assuming by "Lock-Down" you are saying they have no rights to use Registry editing tools (regedit, regedt32, reg, regdmp, etc.) Also, no file permissions have been changed from their default.
By default, only "Administrators" have the ability to add or change keys in "Classes_Root". All users have full control to their own user hive (ntuser.dat).
For "Local_Machine, only "Administrators" have change ability to "Hardware";and "Administrators" and Power Users" have the ability to change keys within "Software".
As a developer, all developed programs should be able to be used by a person with only local "User privileges", but the person installing the application will need to have administrative privileges, because they will need access to CLASSES_ROOT or LOCAL_MACHINE.
So, if I was a developer writing an installation program, I would need to be able to test my installation code on a machine where I had local "Administrator" rights, but I would not need to have those rights on a machine I was compiling my source code on, since that only needs file permissions.
Where I work, the developers are normal users on their development machines (Visual Studio, Team Fusion, etc.), but they test their applications on machines set aside specifically for their testing purposes (their development and test machine sit side-by-side, sharing a monitor, keyboard, and mouse through a KVM switch). The test machines get wiped out and re-imaged as much as a dozen times a day (with a bootable CD image), but their development machine is rarely touched by IT.
In the rare instances where an app or development tool must run as local admin, we use the SU tool of the Windows NT/2000 resource kit. SU (we call it the Super User tool) will allow a specific application to run with elevated privileges.
We also use a freeware tool called RegDACLS to change registry key security to allow evelated access to specific keys in the registry.