If you choose not to make a user’s domain account a member of the local Administrators group on their machine, the user is likely to complain loudly for a number of reasons including the following:
* When they try and install software on their machine, the install will usually fail with an error of some sort.
* When they try to adjust the Date and Time in Control Panel, they get a dialog box saying they don’t have sufficient privileges to do so.
* When they try and configure Power Options in Control Panel, they can change the setting in the GUI but when they click OK to apply changes they get an Access Denied message.
* When they want to share a folder on their machine so another user can access their files, they can’t because there is no Share tab on the properties sheet for the folder they want to share.
Working around the last three complaints is fairly straightforward (I’ll show you how in a moment), but the problem of not being able to install software is a complex issue for several reasons. First, most software (including many of Microsoft’s own applications) requires local administrator privileges in order to install under any version of Microsoft Windows. On the face of it, this requirement is due to the fact that applications need to write to special areas of the file system and registry. But that’s not the real reason applications need admin privileges to install—the real reason is that developers are generally too lazy to bother creating Setup or Windows Installer packages that will work under non-admin privileges. This is because doing so involves going through a number of hoops as a developer, and that means extra work (which most developers want to avoid). But it also means developing these apps while running under non-admin privileges yourself, and again that involves lots of bother so most developers don’t bother—it’s much easier to develop an application if you are logged on as Administrator, so most apps are de facto designed to run under admin privileges as well.