How do you do....it? Thread, Remove users from group after a set time automatically in Technical; Hi
We have a shared area called "Work Hand In" which is used by students and staff to hand in ...
5th July 2008, 10:48 AM #1
- Rep Power
Remove users from group after a set time automatically
We have a shared area called "Work Hand In" which is used by students and staff to hand in work for a lesson so a teacher can collect/mark it, or use it at a late date to allow students to demonstrate powerpoints to the class.
However to allow users to save work to the share, they obviously have to have write access to the share. It then becomes a dumping ground for students rubbish, games etc etc.
I would still like it to be used, but in a more controlled state. I had originally thought of having security settings put on the area for domain admins, staff, and then having a new group setup called WorkHandInGroup or something, which the students would need to be a member of to allow them to save work to the share.
What I would like to do is:
Easily pick out users from AD to add to the group with a few clicks, and then have a script automatically remove them from the group after the lesson has ended.
This way, if a teacher wants to use the area, they come to see me first and I add the class pupils to the group before the lesson. The student users are then automatically removed after the lesson, preventing them from messing with the area. I can then check the share for rubbish after the lesson, and find any offending users and ban them!
Hope someone can help.
IDG Tech News
5th July 2008, 11:10 AM #2
We have an area called Drop Box with an In and Out folder. The in folder is setup so students can write to it but not delete, this folder is emptied once a week (the content is temporarily moved not deleted so work can be retreived). Students add work during or at the end of a lesson then the teacher moves it to their shared area or work folder marks it and then put's it into the Out folder.
Each member of staff should create a folder of their own or one for that particular lesson then delete it once they have finished, this means that the area is reasonably self policing, any stray files are removed.
We've been using this for nearly a year now and have found it to work very well, students stopped putting games in there as they realised that they couldn't delete it again so we knew who added it. Remember to give creator owner read only permissions otherwise they can delete files that they add as this group has full control by default.
Last edited by cookie_monster; 5th July 2008 at 03:56 PM.
5th July 2008, 12:44 PM #3
Just add the creator owner group, then if they put crap in there you know who they are and can be dealt with appropriately. It obviously won't stop them putting crap in at first but a few detentions in front of the whole class and they will soon get the message.
Last edited by jsnetman; 5th July 2008 at 12:48 PM.
5th July 2008, 01:15 PM #4
Better: allow writes but not reads, then if they do put games etc there they can't actually use them. Also stops them pinching each other's work.
5th July 2008, 03:58 PM #5
Of course there is also the option to schedule a CACLS script to remove the permissions to a default at the end of the lesson, but i feel that the Drop Box system is better.
5th July 2008, 04:07 PM #6
- Rep Power
Thanks for the replies folks, I always wondered what the creater owner user was useful for??? LOL thanks for clearing that up.
I like the idea of write only, not read as that would stop them using it as a games drop area, and using it to chat lol (although why cant they talk to each other in person??)
Will try out some of the ideas.
5th July 2008, 04:24 PM #7
We did have a folder set to write only so they had to drag a file over the folder and place it in, we found that this created some issues as they couldn't always tell if they had added the file and couldn't open the folder to check there was also an issue with duplicate files in the folder.
Do you have server 2003 R2? If so you can ban exe files in that folder which will prevent then putting games in there, this way you can go with the more fexible drop box idea.
5th July 2008, 07:41 PM #8
- Rep Power
Yes we do have 2k3 R2, I never actually thought of putting a software restriction policy on it, although by preventing read, but not write would only allow games to be deposited there, but not played. We did have an issue where students work from office would not save properly unless they had modify permissions on the work hand in share, since office creates temporary files which are a requirement by office, although I don't see why they cant do the work in there area, then copy across afterwards...
5th July 2008, 08:40 PM #9
It's not a software restriction policy it's a feature of File Server Resource Manager FSRM called File Screening it's very handy (see link below)
You're correct about Office not being able to save files with write only permissions this is because it creates a temp file during the save process that it then cannot delete. We get around this by telling the students to save to their own work folder and then copying it into the shared folder. This has the added benefit that there is a backup copy of the work in case the teacher accidentally deletes it (it happens )
I know you just said some of that but i was just explaining the issues we found without loosing my train of thought .
Last edited by cookie_monster; 5th July 2008 at 08:44 PM.
Thanks to cookie_monster from:
5th July 2008, 09:27 PM #10
- Rep Power
I love this site mainly because you find out things that you might never come across if you tried to find them out yourself!
By Grommit in forum MIS Systems
Last Post: 18th January 2012, 02:30 PM
By baronne in forum Scripts
Last Post: 20th August 2007, 03:20 PM
By Halfmad in forum Windows
Last Post: 31st March 2007, 06:40 PM
By ninjabeaver in forum How do you do....it?
Last Post: 6th December 2006, 12:48 PM
By indiegirl in forum How do you do....it?
Last Post: 17th August 2006, 04:23 PM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)