Give coworkers access to win7 machine, but restrict access?

KingGheedora

Diamond Member
Jun 24, 2006
3,248
1
81
Hi,

I need to give a couple of developers access to a win 7 "server" that is running some scheduled jobs, so they can perform maintenance. They will need to be able to do this like kill tasks, kick off scheduled tasks, and maybe run a few of the jobs from the command line.

I don't want them to deploy any updates to these jobs though, nor to be able to install any new software or .exe's, or really to be able to do anything else on this machine other than what I listed above.

What's the best and easiest to manage way to do this? Keep in mind I'm not a sysadmin, just the lead developer at a small company. Normally I just deploy for them the code they write onto this machine but I always review it first. I don't want to be stuck monitoring and doing maintenance for this stuff though so I need to be able to hand this off to them.

Thanks!
KG
 

corkyg

Elite Member | Peripherals
Super Moderator
Mar 4, 2000
27,370
239
106
You can also create an account for your designated group and then apply controls on that account using permissions.

This is generally in Control Panel under User Accounts - Manage Accounts. To make such changes, you should be in elevated mode, i.e., run as Administrator. Each User Account can be assigned a password.

The simplest way is actually as Swampster has stated. You can provide a written policy to your designated users telling them what they can and cannot do.

Broad guidelines are better - avoid micro-managment.
 

mechBgon

Super Moderator<br>Elite Member
Oct 31, 1999
30,699
1
0
nor to be able to install any new software or .exe's

For that purpose, I'd put them on a Standard User account and enable Software Restriction Policy to make it impossible to for them to bring in and run any .EXEs from anywhere they can put them with the Standard account. See how it works out. You can turn off SRP if it's not working out for you.

One side effect of SRP is that it will prevent you as the Admin from launching certain filetypes, too. .MSI files are an example. To get around that, elevate a command prompt to "Run As Administrator" level, then use it to navigate to the .MSI file and launch it from the command line. Most other filetypes you'd want to run, you can just right-click them and choose "Run As Administrator" from the right-click menu.
 

Swampster

Senior member
Mar 17, 2000
349
0
0
Corky & MechBgon,

Thanks for your replies guys. I was in a pre-holiday Bah Humbug mood yesterday and was a little more curt that was probably necessary.

BUT . . . as Corky so aptly noted, my suggestion still stands as the best and most practical method. As we all know, if you give a qualified user unsupervised access to a computer, he can, is he so desires, do anything he wants.

Based on the assignment, I would suppose that those tasked with the maintenance would likely have the knowledge. Good supevision cannot be automated, it must be administrated.

Merry Christmas Ya'll
 

KingGheedora

Diamond Member
Jun 24, 2006
3,248
1
81
Corky & MechBgon,

Thanks for your replies guys. I was in a pre-holiday Bah Humbug mood yesterday and was a little more curt that was probably necessary.

BUT . . . as Corky so aptly noted, my suggestion still stands as the best and most practical method. As we all know, if you give a qualified user unsupervised access to a computer, he can, is he so desires, do anything he wants.

Based on the assignment, I would suppose that those tasked with the maintenance would likely have the knowledge. Good supevision cannot be automated, it must be administrated.

Merry Christmas Ya'll

Thanks everyone. I think the Software Restriction Policy might be what I'm looking for. I'll look into that.

Swampster, there is some truth to what you said, but I also don't want to have to do maintenance. My time is more valuable on other things (and not that it's more valuable than the other developers' time, we'll be sharing the maintenance duties instead of me doing all of it).

I don't distrust trust our developers, I just am a pessimist and believe that people will do whatever their access level allows them to do. Not necessarily with malicious intent – they may make changes or try out new things while trying to fix a bug (or enthusiastic employees might just want to mess with stuff "for fun", or to "optimize").

Sometimes the changes don't work but aren't fully reverted, sometimes they don't know the full impact their changes. Sometimes people just break things by accident and don't know how to fix it, and they keep quiet about it!

From my experience in different development shops, any open environment eventually turns to garbage because of the accumulation of such changes. This is the type of thing I'm trying to prevent, so while this is not a production environment I am simulating some of the change management / security used in production systems by locking down developer access & permissions.