I work part time as a network/system administrator for a small school. The school uses a commercial student information system that gets updated quarterly. After the server is updated users cannot access the SIS without an administrator manually running the update installer on each machine. Its been this way for as long as anyone can remember.

My predecessor(s) went to great lengths to lock down the desktops. I assume to try to prevent users from accidentally installing viruses and such (Their efforts failed I might add). This appears to be the reason the SIS cannot automatically update each desktop without an administrator logged in. After a recent update its become worse. Now users can't even use the program as normal without elevated privileges, let alone install updates.

Being unable to locate the setting(s) that are restricting the users, I've had to manually add each user to the administrators group for their own local machine. Of course, this means if one malfunctions that user can't use another user's machine until I get it repaired.

I'm assuming the security setting(s) I need to change are define in group policy editor but I can't seem to find where. Any help would be appreciated.

P.S. In case you haven't guessed, I'm not trained in Windows administration. I've learned enough by reading help files to get by but my day job is software development.

  • What version on windows is running on the desktops? Oct 9 '09 at 16:00
  • Windows XP Professional Oct 9 '09 at 16:12
  • so only a select number of users require admin access? Oct 9 '09 at 16:33
  • Does the vendor have a workaround other than granting local admin privileges?
    – tomjedrz
    Oct 9 '09 at 16:59

The best advice is to contact the software vendor of the student information system & pressure them into creating a version of their software that doesn't require local admin access on the pc. This is a design fault on their part & they should fix it.

Your other option is of course to try to break windows in a careful way to only allow the application to run, in which case you will need Process Monitor and a good eye for figuring out permission denied errors.

EDIT: I think the simplest work around for this is to put all your users that require admin access for this application into a domain security group & then add the domain group to the list of local administrators on the PC's they need to access.

If you want to get even more sophisticated you can create a group policy and assign it to an OU of computers where you want your security group to be permitted admin access.

If you want to poke around with group policies then use the Group Policy Management console. The reports make it easy to see what has been set in the policy & where in the domain it's been applied.

  • Being a software developer myself, I know that better than anyone. They're pretty responsive when it comes to day-to-day support but not so much with software bugs. I've suggested finding another product that's a little more mature but we're stuck with this one for the immediate future. Oct 9 '09 at 16:19

If the Windows computer is joined to an Active Directory domain there might be AD Group Policies that are restricting each user. It's a very efficient way to lock down desktops.


Much of the time, local admin privileges are needed to run a program only because the program writes or updates data in the "Program Files" folder. This folder is generally read-only for non-admins. Typically config files are the culprit!

I suggest an experiment. Use a local admin to grant all users full rights to the folder into which the program is installed. Then try and run it, and try and run the update installer.

If this is successful, then you can use GP to globally adjust the permissions, or you can put a CACLS command in the login script.


Managing Local Admins

IMHO best way to manage local admin privileges in a domain is as follows.
1- Create a domain group (say "Desktop Admins")
2- On each workstation, add the domain "Desktop Admins" group to the Local Administrators group.
--> This can be done via GPO, although my use of it predates GPO
3- As necessary, put individual domain users into and out of the "Desktop Admin" domain group.

Note: Nick suggests the same thing, but I fleshed it out for posterity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.