Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In this question, I outlined the situation at my workplace regarding some of the office workers' children and the computers that we've provided for them to use. Long story short, it turned out that they had fallen into the habit of clicking on every flashy banner that said "FREE GAMES JUST INSTALL THIS MALWARE", so I switched them to Limited accounts.

Well, I recently came across some of my old PC games from when I was their age, and they've made it quite clear to me that they would be extremely interested in playing them. However, the games in question (mostly LEGO Media titles) won't run correctly on a Limited account. I don't want to give them full administrative access because they'll definitely get bored and start installing crap again, so is there any way that I can restrict them only from running installers?

share|improve this question
Using tools like procmon you can audit an application's activity and see where the "admin" access is required. Typically, you have to open up the ACLs on some directories or registry keys, but it is quite doable. – jscott Apr 27 '11 at 13:54

Similar to what the previous poster said, you could use AutoIT to create an exe that when ran, it pops up a message pox and asks for the path to the exe which then runs it using Run as, the password then wouldn't be stored in plain text it'd be within a complied exe, although i've no idea how easy it is to get out of there, but easier than a vbscript anyway.

It's pretty simple to use RunAs in AutoIT just

RunAs("anadminaccount", @ComputerName/"domainname", "adminpass", 0, "myprogram.exe")
share|improve this answer

The solution should be transparent to the user (remember this will be kids using it). I don't think they should need a lesson on how to type out a path for an exe in order to play a game.

You may want to look into what JScott suggested. Finding out how to run those games under a limited account will likely be the best way to prevent further installs. You could try giving a limited account Modify rights to the Install directory of the game and see if that resolves the issue. Try a google search on the game to see if someone else has already figured out how to run the game under a limited account.

share|improve this answer
up vote 0 down vote accepted

I was originally going to go with the suggestion to write an AutoIt script, but I came across something that was much easier and faster to implement:

Windows SteadyState

I created an Administrator account called Games, and locked it down with SteadyState such that the only thing that the kids can really do is run programs from whatever desktop icons I have set up. I'm not really worried about them growing a brain and bringing in a copy of the FireFox installer on a flash drive or whatever - they have Internet access with the Limited account, so that should keep them happy. (They're not exactly 'hacker material', else I'd be a little more cautious.)

I'd have opted for a more robust solution, but I'm pretty sure that this will Just Work, and I have other (and much more important) things to attend to than making sure that some kids can play games.

Plus, once they start playing RollerCoaster Tycoon 2, little else in life will continue to matter. ;D

share|improve this answer

I think this VBScript may do the trick for you, instead of always manually typing in your admin password using the run as command, try this:

How to use or perform “Run as..” feature automatically ?

You can user a simple VBS script for word around of the usual process of “Run as” where an administrator presence is required.

If you need to run a certain program, for example, CPU Z software from a limited of guest account but the said software may need administrative access to run.

From any administrative account, navigate to the installation directory or folder of the software “exe” and place the below VBS script.

Option explicit
dim oShell
set oShell= Wscript.CreateObject(“WScript.Shell”)
oShell.Run “runas /user:administrator “”software.exe“”"
WScript.Sleep 100
oShell.Sendkeys “yourpassword~”

Use notepad to copy-paste the above script. Please replace the word “software.exe” with the program which needs to be run, and “yourpassword~” with the administrative password for the windows. Dont forget to add / keep the “~” after your password string.

Please save the file as software-name.vbs (replace with the name of your software in use) and create a start menu or desktop shortcut of it (the vbs file). Now rather than running it from the program’s own shortcut, please run the VBS file for automatic administrative execution.


Write the script using the free verison of vbsedit Then using the convert script to executable feature of vbedit, create an executable file of the script, which will hide the code and password and create a little "program" of the script that the user can just click. Place that in the start menu or as a shortcut.

share|improve this answer
Gah, Never store the password of an account with administrative access in plain text, let alone that of the administrator account. You may as well just give the users the password! – Rob Apr 27 '11 at 14:18
I'd have to agree with Rob. It would be terrible practice to leave the admin password in cleartext on the machine. – HostBits Apr 27 '11 at 14:33
Brain fart on my part, I typed that out faster than I really thought about it at first. You could use the program Vbsedit to write the script (the free version should work just fine) and then convert the script to an executable file (vbsedit can do that) which will then hide the code and password from everyone. And you won't have to spend money on a third-party tool. – djl236 Apr 27 '11 at 15:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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