I would never give anyone other than IT staff the ability to install anything other than maybe printers. Bear in mind that if they are local admins, they could download and install anything when away from the domain and bring back all kinds of nasties.
Roaming profiles, folder redirection and make redir. folders available offline.
There is a GP setting in User->Administrative Templates->System/Driver Installation for "Allow non-administrators to install drivers for these device setup classes". You can put the GUID for printers in there to allow them to install just printers, then set the scope to just their laptops.
Following advice further up the thread, I've removed them from the local admin group, added them to the local Network Configuration Operators group, which will allow them to add their home wireless, used loopback processing to allow them to see and save to the local drive for working at home. I don't want to make redirected folders available off-line - some redirected My Documents contain over 10Gb of files, but I have allowed redirected appdata and favorites to be available. To a certain extent it needs to be a "work in progress" and I'm sure various thinks will have to be "tweaked" one the system is used in anger, but I've been given plenty of time to develop a new domain, so I'm trying to pre-empt as many problems as I can.
I wouldn't worry too much about the making documents available offline. You'll get more of a headache from staff not knowing if they saved to the C: drive or not. The sync only syncs differences, so you'll only get high load when they all first sync up. I would be insistent that standard users (staff/students etc) not be allowed to have any write or modify permissions to any part of C: as malicious scripts could still run with their credentials. Not to mention the fact that anything just saved locally won't be caught in your backups. If they absolutely MUST have local write, then set your image to partition the disk to C: and D: and just give them permissions on D:. I just can't stress enough how much of a bad idea letting staff have any write permissions on their system disk is :p
Originally Posted by clareq
We've been running our domain this way for this academic year and it's been working like a charm.
One thing I'm working on at the moment is making sure that profile size is kept to a minimum (appdata and the like) in case of using a new machine as you'll find logon and logoff times going through the roof. (Found some profiles here that were >40GB)
Similar to @JonDaviesBourne, we don't allow our faculty/staff to be local admins with their domain accounts. However, for those individuals or situations where someone absolutely must have an admin account, we create a separate local admin account, specify a complex password and then show them how to use that set of credentials from within their (non-admin domain account) logged-in session. This protects the system from executing "drive-by" malicious code with admin credentials because the user logs in everyday with their non-admin account, and thus, most software that is targeted for malicious code/exploits (browsers, browser plug-ins etc) is running with the non-privileged credentials. Armed with an admin account, they can do little updates/installs when prompted by using ".\LocalAdmAcct" and the password. Yes, they can also run "CouponPrinter.exe" with admin credentials and hose their system, but surprisingly, that doesn't happen as much as you'd think. Obviously, there are systems and situations where you absolutely should not give local admin access (systems with sensitive data) but that's up to your judgement.
You can define what accounts should be in the local administrators group in a GPO here: Computer Configuration-->Policies-->Windows Settings-->Security Settings-->Restricted Groups-->Group (BUILTIN\Administrators (Then populate the members).
Another thing that strikes me from your initial description is that you were describing a scenario where you wanted to have a subset of machines that had somewhat less restrictive group policy settings than others. The easiest way to accomplish that would be to plop that subset into a SubOU of their current OU, define a GPO for those systems and then apply it to the SubOU. Remember, the GPO applied "closer" to the object (the computer accounts in AD in this case) should take precedence (unless "Enforce" was used on a higher GPO) if there's a conflict between GPO's.
One more thought. If your users are new to the concept of not being an admin all day everyday and you are now trying to lock that down, you had better have a method of remote support figured out. Whether its built-in tools like remote assistance/remote desktop (can be configured via GPO) or a third party tool, make sure you have one and that you and your technicians can use it on a moment's notice.
I've found that users very much dislike not being an admin (because they don't understand the reasoning behind it and assume you're just doing a power play) and will look for any opportunity to say, "Look, I wasn't able to present at this conference because I couldn't install XYZ and YOU couldn't help me over the phone! I need to be an admin!!!" If you have a remote support tool and plan in place, you can be Jonny-on-the-spot and take care of those things and keep the complaints to a dull roar.
You had also better have an idea on how you're going to automate non-Microsoft application updates (like Java, Adobe, etc) because those applications nag the heck out of users each time they have a patch and they will in turn nag you and question your admin policy if you can't patch in a timely manner. So have a method (SCCM, GPO Software push, something) figured out for those things as well.
SCCM is in place. We have remote access when the users are on site. Unfortunately our users are not the most technologically able, some struggle with saving to the default location, so trying to get them to save to a second drive would be "interesting". Our AUP already states that anything not saved in their user area won't be backed up and could be lost if we need to rebuild their machine - we won't go hunting for work to back up. Basically I'm trying to replicate, as far as I can, the RM Privileged User set up, while at the same time making small changes to improve security. I have managed to get my boss to sign off on them not having local admin rights, which they currently have, so I'd like to give them saving to the C drive. I'm expecting a revolt over not saving to the desktop, I'm picking my battles carefully.