I am supporting a few offices across the country running Windows XP. They are stand alone, no Windows Server or Active Directory, anything like that. I just switched them over to Google Apps, and in the process replaced Windows Live Messenger with Google Talk. I really want to stop Windows Live from being used, the platform sends so much spam and seems to have a lot of holes. I have tested making a registry edit to

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun Adding a string value named 1 with the data set to msnmsgr.exe. I did it maually on one machine, and it worked, under both profiles, it wouldn't start Messenger. After my success, I wrote a .REG file thusly:

Windows Registry Editor Version 5.00


And a batch file, run from the same directory, written like this:

@ECHO off

REGEDIT.EXE /S msn.reg

It seems to write to the registry, but Live is starting. No idea what's happening. I also tried going into the group policy editor and trying to list it under software restriction policies; but I have no restrictions defined, and it says go to the Action menu and click Create New Policies. When I click the action menu, GPEDIT.msc crashes. I don't know what to do.

Any help would be greatly appricated

Thanks in advance for any assistance.

  • are you running this as the end user or admin? if as admin and your testing as a user the result won't be what you expect. if you can add it the users login script it would work better. – tony roth Oct 18 '10 at 19:46
  • Can you clarify: What type of spam is Messenger sending and what is it's mechanism for sending spam? Also, what holes have you discovered? – joeqwerty Oct 18 '10 at 19:47
  • I am running this as Admin. @tony roth, are you saying add the .REG command to the users at startup, the script part is throwing me off. @joeqwerty, even Microsoft releases articles about messenger spamming windowsteamblog.com/windows_live/b/windowslive/archive/2010/03/… – Kevin Oct 18 '10 at 20:15
  • I'd focus on why GPEDIT is crashing - SSPs are the way to go. – Simon Catlin Oct 18 '10 at 20:34
  • @Kevin: that article seems to relate to the user receiving spam in messenger, not sending spam. In addition, it requires the end user to accept the spammers invitation so that the spammer can harvest the users contact list and send them spam. The user is the catalyst, not the program. I could do the same thing with any email client or IM program. Is it your position that spammers don't target other IM platforms, like Google Talk? Also, Can you point me at some articles regarding the holes you referenced? – joeqwerty Oct 18 '10 at 20:49

HKEY_CURRENT_USER is dependent on the user profile, did you run it for every user on that machine? The best solution I could imagine in your situation would be calling it during the logon, e.g., if there's no other possibility, via Autostart.

  • Could I run it under HKLM, or will that be fruitless? – Kevin Oct 18 '10 at 20:16
  • That I don't know. You could try, I can't imagine it would hurt, if it wouldn't work. – knitti Oct 18 '10 at 20:21

Depending on how the machines are set up it may not be possible for a user to successfully run regedit to import the registry file and that failure may not produce a visible error. There's not even a need to create the registry file and use regedit to import it. Use the REG ADD command in your batch file instead. From a command prompt type reg add /? for details.

BTW, I'm little confused about your use of the group policy editor for non-domain machines. Perhaps you're referring to the local policy editor?

  • I am using the Group term because it is called that in XP pro. So, if I were to write a batch say like this: – Kevin Oct 19 '10 at 15:39
  • @ECHO off REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun /v 1 /t REG_SZ /d msnmsgr.exe /f And I added it to say HKLM\Software\Microsoft\Windows\CurrentVersion\Run – Kevin Oct 19 '10 at 15:45

Probably too late to the game here, but I've had good success with Trust-No-Exe in workgroup/standalone environments.


Another approach would be to set the permissions on the EXE file itself so that Users cannot execute it. Cacls or Xcacls can be used to do this from a batch file running as admin. Of course, this can be done with the GUI as well.

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.