Blocking AIM on Corporate Network Laptops Running Windows XP

Recently, my company's vice president of sales asked me whether we could block AOL Instant Messenger (AIM) on our corporate network. Unfortunately, the easy answer was no. Because our staff is distributed around the world, using AIM between far-flung users makes brief communications simple and inexpensive. On top of that, all of our sales department users have administrative rights on their laptop computers—a requirement that lets sales staff demonstrate the application they're selling. The fact that the sales staff laptop users aren't always attached to the corporate network makes using Group Policy Objects (GPOs) focused on software-allowed lists (the method we would use to block AIM) problematical.

After my brief discussion with the vice president, I realized that a way does exist to block AIM on a network. In our company, all the sales staff laptop users are running Windows XP, and there's a very simple way to use software restriction policies in XP.

I decided that when a sales-department laptop passed through IT's hands for a regular backup, we would configure the laptop with a local policy that did nothing but stop the AIM executable from running. By default, security restrictions apply to all users on a computer. Typically, you'd exempt local administrators from such restrictions because they have access to the local security policy editor and can change whatever they like. But because the local security policy editor isn't obvious to a typical user, I decided that hiding the AIM-blocking policy in plain sight was a workable plan. (The users in question aren't very technical, so I knew that they probably wouldn't figure out what we were doing.)

Within the AIM-blocking policy, we created a hash rule. In this particular case, the OS creates a hash, or cryptographic fingerprint, that identifies the program file that you want to prevent from running. The hash identifies the file even if someone moves the file to another location or tries to execute the file after a new OS installation.

Because we didn't apply rules to any other files, the hash rule stopped only the AIM executable. The users in the sales group had been told not to use AIM, so they really couldn't complain when the application didn't work for them. I watched a couple of users try to figure out what was going on, but after a short time they accepted that they weren't going to be able to run that application. Because the policy we applied is local, users can't run AIM even when they aren't on the corporate network. A few figured out how to create a new user account and run AIM from that account, but because those users aren't part of our corporate Active Directory (AD), they can use the user account they created only while traveling or at home, which suited us fine.

To experiment with these restrictions on your own XP computer, perform these steps:

Remember that the rules apply to all users by default; you might want to exempt local administrators while experimenting with the security policy editor.