Discretely restrict users from running certain programs on Windows computers

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.

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.

Prerequisites
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.

Background
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...

#!/usr/bin/bash

var0=1
LIMIT=1
SleepyTime=45

while [ "$var0" -eq "$LIMIT" ]
#      ^                    ^
# Spaces, because these are "test-brackets" . . .
do
  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.

echo

exit 0

I hope you find this helpful

+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).

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.

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.

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.

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.