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 was wondering which policies, etc I could setup to stop any installations from occurring in a server 2003 domain environment? I have 2003 RC2 and XP Pro clients.

I guess the quick easy way is to make everyone guests, but this also blocks them from other things that they might need to do/access. I've seen a lot of ideas but they do not fully block everything. I know there probably isn't a fix all but would like to get as close as possible.

Thank you all,

share|improve this question

Remove local admin rights, remove local power user, spend hours debugging crappy and ill-architected software with access problems using sysinternals software to manually work around access issues.

Set up software shares for home directories, profiles, etc. and redirect select subdirs (like my docs) to a network share. Then use something like Faronics Deep Freeze to "reset" the computer back to a pristine state after each restart.

I think they also have software that can whitelist executables, but it will be a pain to set up and maintain if you have a large number of systems with diverse needs to attend to.

Get systems without CD drives and use a portable USB drive for installation of software.

Get HR to support policies that make it crystal clear what's allowed and what isn't on systems, that they're company property and that there's no expectation of privacy on them.

Use filtering software to monitor web use and you can block out downloads if need be.

How draconian do you want to get?

You could also use images of your systems and periodically re-image your computers to a clean state. Still takes maintenance though, as an image a month out of date needs a month of patch-tuesdays installed, plus users still need their own data accounted for on the server or if they're managing to "accidentally" save things locally you're going to hear grumbling.

You'll need to examine your policies and balance usability with how much of a PITA you're going to make it for employees to get their work done and how miserable you want to make your employees feel, if the employer expects a lot from the employees and at the same time won't give them any sense of empowerment or freedom at all...employees that feel a foot on the back and eyes over their shoulders have wonderfully creative ways of making your life more miserable and they won't feel bad in the least for it if they feel justified.

share|improve this answer
thanks for the reply btw, unfortunately we are lax in our company. But I hate when people install any apps. If they need something installed it needs to go through us. The re imaging is a good idea, but like you said if they save anything local there then they will be pissed. Someone mentioned that being just domain users that it will stop installation, am i missing something? I only have them as domain users, no local admin or domain admin privileges. – Chris Jun 7 '10 at 16:06
Local docs and such are an issue until user training takes over. Drill into them that documents can and will be lost if they don't save to the network; they'll lose them at some point anyway when the hard disk fails. THEN MAKE SURE YOUR NETWORK SHARES ARE SAFE with backups that are working. Otherwise, you tell them to save to XYZ so they'll be "safe" then you lose everything? They'll never trust you again. – Bart Silverstrim Jun 7 '10 at 16:14
And no, you're not missing something. It entirely depends on the program design and privileges needed to run. Otherwise you wouldn't have issues with malware sneaking into your systems; they're programs running quite easily with user privileges (or initially running with user privileges to get a foothold on the system). – Bart Silverstrim Jun 7 '10 at 16:15
The only way around it is to whitelist allowed exe files. A war of attrition can be waged using a Deep Freeze-like product, because users grow tired of reinstalling their pet programs each time they reboot. It's also a good training tool for users to save files where they're supposed to lest they lose them each reboot, but that's more of a BOFH perspective. – Bart Silverstrim Jun 7 '10 at 16:21
We have a script that backs up there desktop/mydocs etc, so that part isn't a problem. So I think I'm going to test out some re imaging software like you said, thanks for the idea. – Chris Jun 7 '10 at 16:30

The answer is to stop them from being administrators. If you are unwilling to do this, then there will always be a way for them to get around anything that you put in place.

share|improve this answer
They are only domain users, no local admin or domain admin rights, they are still able to install software. – Chris Jun 7 '10 at 15:53
Domain users are limited users unless they are made local admins or power users on their computers or are part of the Domain Admins group. There is something you are missing if they can install software. – MDMarra Jun 7 '10 at 15:56
I checked the groups and user profiles and they are only part of the domain users group, is there another spot where I am not looking? thanks for the reply – Chris Jun 7 '10 at 16:03
what groups\users are in the local administrators group on the workstations? – tony roth Jun 7 '10 at 16:10
Like Bart says if an app doesn't follow the rules stuff can happen! Applocker is the best solution at this point! – tony roth Jun 7 '10 at 16:26

Your first step will be to get buy-in from the business to actually allow you to do such a thing. Even in giant corporate secure environemnts I've seen execs unwilling to set up appication whitelists. After that you should look into software restriction policies.

This allows you to allow or block software based on:

Hash, Certificate, Path and Internet Zone.

Where Software restriction does not apply is:

Drivers or other kernel mode software.

  • Any program run by the SYSTEM account.

  • Macros inside of Microsoft Office 2000 or Office XP documents.

  • Programs written for the common language runtime.

For CLR lockdown you should use CASPOL.

The depoyment steps would be to set up a test machine and start locking down the policies. Admin rights have no effect on this type of restriction (unless you choose to see the link for details). Once you have locked down both regualr and CLR based software the only real source of worry is java.

share|improve this answer

They will always be able to "install" software that doesn't require admin access. A lot of software doesn't need to write to the Program Files folder or make any system wide changes. Especially simple apps that are just EXEs or "portable apps." Afterall, you allow them to run EXE files, right?

If they are truly non-admins and do not have write or modify rights to Program Files or Windows then I bet they're just running simple apps. There's a group policy setting that lets you whitelist which EXEs are allowed, but I would be very careful with playing with that as it can make all your machines inoperable.

share|improve this answer
I understand, I tried playing around with blocking exe's, but it gets a little crazy. Thanks for the reply. – Chris Jun 7 '10 at 16:22
No problem. I've noticed is that some installers will check for admin rights and if they don't have it, will then install themselves in the local profile. As as admin that's always bothered me. This is typical of ad-supported 'freeware.' I've always just ignored it or uninstalled it next time I worked on their computer. – DrZaiusApeLord Jun 7 '10 at 16:58

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.