By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
We used group policy editor to disable the messenger service, but that made it possible for a user with local admin permissions to re-enable it and start it. We then adjusted group policy to set permissions on messenger service to give users only 'read' permission. We also had to remove the 'system' account from the permission list because it's possible for a script to be run in system context and re-enable messenger. The problem we now have is that every time group policy gets applied (every 15 minutes), it tries to disable the messenger service again (even though already disabled), but gets access denied. Not a big issue, but it does mean two entries in the application log every 15 minutes.
First of all, let's remember that the messenger service has nothing to do with MSN messenger. Next, you've done everything right, and there's not a whole lot more advice I can give you. However, I'm guessing that you might not be doing this on user machines, but perhaps rather on kiosk or lab machines. If that's the case, you might want to consider rounding them up into an organizational unit, then setting a policy that turns off the background refresh policy on those machines. This will eliminate the event ID, but could make the machine a bit more insecure. So, only do this if the machine is otherwise sufficiently locked down. It's really hard to get rid of the local administrator (or someone hijacking "system") from doing bad stuff on your local machines; tread lightly and test often.