Another alternative is to let them have access. We ended up curbing their behavior (well, destructive behavior) using Deep Freeze from Faronics; it lets you "freeze" the hard disk and then on reboot it goes back to the default state. It was cathartic when we tested it by wiping the Windows subdirectory until Windows kind of lurched and fell over...then rebooted and it came back up.
That allows the students to do whatever they want without destroying your configuration; we also found that it eliminated a lot of corruption issues with profiles and caches.
I think there are a couple other alternatives out there but I only have used DeepFreeze. There's a central console used to monitor workstations and can remotely thaw and freeze them, we also use it to get IP addresses for particular workstations.
I've worked in labs that were locked down to the point of being nearly unusable for anything. Even in class we couldn't get, for example, certain documents to open or use notepad to read source code because it wasn't allowed by the sysadmin who happened to be two hours away in a central site, and the local admin guy lamented not being able to fix certain issues without prearranging things with the central admins. And this was a college. Deep Freeze gave more freedom for getting work done without interference (it also allows at our site for certain people to get higher privileges on the local machine since any malware or alterations are erased at reboot; if they're going out of their way to install "personal" software they grow weary of having to constantly reinstall at each reboot; at least that's what we've seen).
We tried locking out things through policy when we ran 2000 terminal services; we found that the policy only locked out access from certain things like explorer. It looked like some programs (like an old copy of file manager from the 3.x days) was able to still browse the C: drive, along with some freeware file managers! Unless that was fixed, it looks like certain APIs still allowed users to get access to local drives that were supposed to be blocked out by policy. Plus we have systems that for reasons we never understood will sometimes not get the policy right away or act as if they wouldn't get any policy updates until after a reboot or two, so sometimes we had people that could bypass configuration lockouts and do things they weren't supposed to.