I employed another method of doing this in a large school; after using a naming convention on all machines (which an 'S' at the end of the name indicated a student use machine) it made it easy to organise AD into a decent OU layout.

Using group policy applied to either the student machines OU (or using policy filtering for any machine without *S) denied logon locally to a security group that had all students... In large networks I often use group nesting for granulated policies so 'students' group contained no users but another set of groups which may have again contained no users but another set of groups until the groups actually had the users listed.

I also had the staff machines grouped into departments (teaching, admin, finance) and used group policy to add the ONLY that department staff admin rights to ONLY that departments machines (group nesting for the Win again). Although any staff could log on to any machine, admin rights were granted only to the staff whom belonged to that department.

Group nesting may seem like needless work; but when comes to future changes like adding a new user to the domain; you only need to add said user to a single group and every group policy is applied... no need to find 10 policies and add this new user to them etc. Its very late here I hope anyone reading this understands the concept without enumerating the whole benefit.... just ask I will go into complete detail - this is partly the fall down with using the Log on to option IMO.

...

Sadly the fall down in your case is that if the user is granted admin rights to any PC; you are restricting which machines they can log on to using their own account. If it was me and I wanted to install software; I'd login, create a local admin account and use that account to install software