Restrict software installation

[eejit]

...it says (or said) that it wasn't recommended for use with a large network...
beeswax

Can you remember if it said why?

[ajbritton]

I was going to suggest Ranger (which can spot and kill any dialog box enabling you to defeat different installers), but I'm sure I'll be shot down by the raw AD & GPO crowd (don't get me wrong, I'm raw AD & GPO myself!) but here's a thought.

You could do the same thing using AutoIt. It's possible to write an AutoIt script which sits on the system waiting for certain windows to appear and killing them automatically. I use the technique for automating nasty software installations which pop up dialogs mid-install. AutoIt is clever enough not to hog the CPU. The only tricky bit would be constructing the mechanism to distribute a central list of 'windows to kill'. If anyone is interested in this idea (or can see a reason why it wouldn't work), post here to let me know. Maybe I'll write the script...

[secman]

Thanks Dos_Box, it is as we thought. However, how easy is it to set up AD/GPO to replicate what Winsuite does....that is the thing. We don't want to miss a setting and let the little darlings loose.

On the subject of the MS Shared Computer Toolkit, we have looked at it briefly as well. The problem with locking down the C: drive is that you loose all MS Updates, AV updates etc everytime you restart the PC. One suggestion is to put your AV software on a further partition and not to restrict that, but that sort of defeats the object.

Anyone know if good ol' MS are planning a version for networks?

Thanks

[Dos_Box]

It is very easy. You just need to create a policy, call it DENY INSTALLATIONS to experiemnt on. I shall post later (when I have more time) and tell you the relevent sections of GPO's to look in, or if someone is not to busy they could start you off now with a suggestion or two.

[artram]

If you go to the user's software restrictions as described above set some path rules like these:

d:\ Path Disallowed
e:\ Path Disallowed
h:\ Path Disallowed
l:\ Path Disallowed
p:\ Path Disallowed
v:\ Path Disallowed

This allows users to access data etc from the blocked locations but EXEs can't be run. It works well for us. We do it at an OU level so we can be flexible for different levels of user.

[Cowman]

Hi

I've tried the solution mentioned above by adding some 'new path rules' but they do not seem to be working as the little blighters are still able to run doom and quake from their pen drives.

I looked at the other options available but unfortunately we use so much software it would take forever to populate the list of allowed software.

Any further assistance on this problem would be much appreciated.

[Ric_]

Disable access to pen drives, stating the reasons - anyone with work on a USB drive can give it to a teacher/technician who will copy the work to a share for collection by the pupil. Explain why this has had to be done - abuse of school resources!

[ChrisH]

^^ Thats what we do no removable drive access for students. Its more trouble than its worth to let them bring god knows what in. If they need to send something in they can email or bring it to me.

[Cowman]

Thanks for the suggestions, I have given a report to the schools leadership team regarding this matter and suggested the disabling of pen drives, not sure they will be too keen on that though :cry:

I've just been told by a colleague that there is a program available that will take care of this, I'll keep you all informed if I find out what it is.

[ChrisH]

Just disallow access to non network drives. You can still restrict c: and run your normal programs as well.

[eejit]

If you go to the user's software restrictions as described above set some path rules like these:

d:\ Path Disallowed
e:\ Path Disallowed
h:\ Path Disallowed
l:\ Path Disallowed
p:\ Path Disallowed
v:\ Path Disallowed

This allows users to access data etc from the blocked locations but EXEs can't be run. It works well for us. We do it at an OU level so we can be flexible for different levels of user.

This is the biggest mistakes in group policies as far as I'm concerned. You can't block exe's for subfolders. So for the examples above you would have to disallow
d:\*.exe
d:\*\*.exe
d:\*\*\*.exe
d:\*\*\*\*.exe
etc., for all the other drives too, and for any other extension that you'd like as well. Nightmare

[NetworkGeezer]

This is the biggest mistakes in group policies as far as I'm concerned. You can't block exe's for subfolders. So for the examples above you would have to disallow
d:\*.exe
d:\*\*.exe
d:\*\*\*.exe
d:\*\*\*\*.exe
etc., for all the other drives too, and for any other extension that you'd like as well. Nightmare

There are two methods of application blocking. Software restriction policies as mentioned above or Run/Don't Run specified Windows Applications in the Admin Templates section of the User part of the GPO.

This second method is reliant on filenames only and so changes in directory paths don't matter. It works well if your students are 'GUI centric'

It's also more forgiving when it comes to dependent exes for major programs such as in Microsoft Office.

The one flaw appears to have to be programs which have spaces in the filename.

[NetworkGeezer]

This is the biggest mistakes in group policies as far as I'm concerned. You can't block exe's for subfolders. So for the examples above you would have to disallow
d:\*.exe
d:\*\*.exe
d:\*\*\*.exe
d:\*\*\*\*.exe
etc., for all the other drives too, and for any other extension that you'd like as well. Nightmare

Actually looking at TechNet again if it's possible to specify a path as just *.vbs then you may be able to use d:*.exe which should cope with subfolders.