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

I have a user who is playing games all day at work and I want to discretely control if and when he is able to run his game.

Is there a way to set up a schedule for when the program is allowed to run and when it is not allowed to run?

share|improve this question
Is there a policy around playing games? Perhaps this issue is better addressed through management rather than expending resources adding more IT solutions to maintain, just to benefit of a misbehaving user. – condiosluzverde Jul 22 '09 at 14:22
I honestly couldn't think of a worse way to resolve this situation. If someone is playing games during business hours, and that is not acceptable, I would insist that it is the managers job (not IT) to resolve this. – Kyle Brandt Jul 22 '09 at 14:22
What if, say, it were to support management policy? Would it be worthwhile to expend resources to find the kind of solution Jeff is looking for? – thepocketwade Jul 22 '09 at 14:27
I don't want to limit answers to any specific behavior, other than whatever happens shouldn't be too obviously an administrative restriction. – Jeff Leonard Jul 22 '09 at 15:18
You could go BOFH style and make a shortcut that looks like the game, but actually is hooked up to a device connected to the user's chair, this could then shock them when they click the shortcut. If they click the shortcut for a work program, a device could dispense a Banana. – Kyle Brandt Jul 22 '09 at 15:27
up vote 3 down vote accepted

I had this exact issue with someone on my network a while back.

In an effort to control this behavior during core hours I wrote the script below. By running this in a Cygwin shell with the shceduled tasks in windows you can have it run whenever you choose and have the scheduler just kill the job when you want the user's programs to start working again. This will not work on from a unix box as this is a hybrid script that uses both windows commands and a BASH shell script. Also worth noting, you can set this up as a CRON job in the cygwin shell if you want to avoid using the windows scheduler.

1) Cygwin loaded on a system you control on the same network as the user. (I used my admin system for this as I already have Cygwin) 2) A user account with administrative priveledges on the system where the software is being run.

I recommend not using the administrator account for the domain or the local admin as if your script is compromised it will expose your admin passwords. Creating a discrete sounding local account. I recommend using one that sounds like it is from the computer vendor.

Detailed Breakdown of the Script
In this example HQ-WS-599 is the workstation the user is on hpassistant is the local user account I created on this users system and the /P references the account password. warcraft.exe and the two listed below it in the code are the three programs which I decided to restrict. The sleepytime variable determines how often it attempts to reach across the network and kill the processes you have defined.

How Did it Work?
When I began to use this script I found it to work like a champ. Even an extremely technically savvy user will have a hard time figuring out this one. Short of a sniffer or other insightful tool, you won't see any evidence of it running other than the process spontaneously going away without notification.

Now on to the script...



while [ "$var0" -eq "$LIMIT" ]
#      ^                    ^
# Spaces, because these are "test-brackets" . . .
  taskkill /S HQ-WS-599 /U hpassistant /P hpassistpw!2 /IM "warcraft.exe"
  taskkill /S HQ-WS-599 /U hpassistant /P hpassistpw!2 /IM "solataire.exe"
  taskkill /S HQ-WS-599 /U hpassistant /P hpassistpw!2 /IM "freecell.exe"

  #             ^           Space, to separate printed out numbers.

  # var0=`expr $var0 + 1`   # var0=$(($var0+1))  also works.
                          # var0=$((var0 + 1)) also works.
                          # let "var0 += 1"    also works.
  sleep $SleepyTime
done                      # Various other methods also work.


exit 0

I hope you find this helpful

share|improve this answer
Will this work if the user copies+renames the game binary? – John Barrett Jul 22 '09 at 15:04
John Barrett: Exactly, so basically, you end up replacing the games Warcraft and solitaire with the game of 'Trying to get Warcraft and solitaire to run'. Which, sounds like... a game that is more fun! :-) – Kyle Brandt Jul 22 '09 at 15:33
@John: Probably not. This is a pretty terrible idea. – Evan Anderson Jul 22 '09 at 15:56
I think this wins the prize for being discrete, in a BOFH kind of way. – Jeff Leonard Jul 22 '09 at 17:10
I've never seen a software restriction done in a more convoluted way and with more effort. At a very least you could use the unix subsystem available for windows to run a bash script to simplify it. – Jim B Jul 22 '09 at 17:30

I'll weigh in with an answer, but I'll echo what's been said in the comments, too. This is a horrible idea. You have a management problem, not a technical problem. While I understand that your "bosses" are asking you to solve their problem for them I'd argue that you need to let them know that there isn't a technical solution to this problem.

The Microsoft solution for what you're looking at is Software Restriction Policies. You can define various criteria to allow / disallow program execution.

Running in its "allow everything, block exceptions" mode (called "Unrestricted mode" by Microsoft) won't help. Users can rename files or copy them with a byte of garbage appended at the end to throw off the cryptographic hash.

In "Disallowed mode", where only explicitly allowed programs or paths are permitted to run, Software Restriction Policy really has teeth. (With the caveat that if the users have "Administrator" rights then your attempts at stopping them will be toothless, no matter how you configure it.) With a non-Administrator user and some well-define paths in "Disallowed mode" (paths where the user can't write files) you can do a wonderful job of making Windows XP prevent unauthorized software from running.

Obviously, being a "deny all, permit explicit" architecture means more work setting it up, but the "win" is that it really can keep almost all unwanted software from working on a computer (even software that "lives" in folders the user has rights to write to-- a trick that Google Chrome does, for example).

I can't stress enough that you're trying to solve a management problem with technical means. That's a recipe for wasting time, wasting effort, and creating more problems than you'll "solve". Unless you do something very drastic like Software Restriction Policies in Disallowed mode (and strip the user's Administrator rights) you won't really get anywhere. If you do go to such drastic measures you'll end up spending vastly more time and money than would be spent if management would just "man up" (or "woman up", as the case may be) and do their job.

share|improve this answer
I like this solution best if I was allowed to be upfront about the restriction. I definitely agree this is a band-aid on a management problem and the best solution is to keep trying to give the people who decided to do this a backbone injection. – Jeff Leonard Jul 22 '09 at 17:09
@Jeff This shouldn't be obtrusive. It's applied via group policy generally. The way is as soon as the policy is applied it blocks the app and tells the user that the system policy restricted it. If you can't tell the user you're blocking the game at all- won't he get suspicious when the game exits by itself? – Jim B Jul 22 '09 at 17:30

+1 to all the "it's a people problem, not a technical problem" comments.

But... If you must, this would be a good place to use Sysinternal's PsTools. You could use PsList to show running processes on the remote box, and PsKill to remotely kill the game process(es).

share|improve this answer

PSKILL from sysinternals will allow you to remotely kill processes. You can setup a .cmd on your system and put it in the task scheduler to execute every 5, 10, or 15 minutes.

share|improve this answer

If management won't take care of this as they should, then tell them that yes, you can take care of it, but not in a half-assed way like restricting when they can play games. Tip-toeing around the problem isn't gonna help in the long run.

I'd delete or rename the executable. If it's minesweeper or hearts or something like that, you should be done. If it's a game they installed themselves, remind them sometime that they shouldn't install their own software on company computers. Remove their admin access if necessary.

share|improve this answer

I would CYA by keeping documentation of what you're asked to do, by whom and when and the steps you take to implement it plus any other related communication or actions/reactions.

share|improve this answer

Use a GPO and implement a software restriction policy. unfortunately it's either off or on. Using taskkill doesn't stop users from starting the application again.

share|improve this answer

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.