To emphasize what Gail and Lowell have already written...

Gail has the near perfect solution for #1. It's simple and it's effective. Killing SPIDs may cause a problem, though. You'll see more on that in a second.

#2 and #3 are a different story. As Lowell stated, rollbacks from killing a query (SPID) can take a whole lot longer than you might expect. In fact, if the query relates to a linked server or has something like an OPENQUERY in it, SQL Server has a fault that may cause a rollback that runs forever until the next bounce of the service. These are easily identified as a rollback that has done 0% work but shows no work being accomplished in the log. The big problem with these rollbacks is that they will typically consume the resources of an entire CPU and they can't be fixed without bouncing the service.

Further, killing long running queries doesn't really address the root problem of that issue. The root problem is that it [font="Arial Black"]IS[/font] a long running query and it needs to be fixed. If the users need to run the same query every night, then helping them by writing an optimized stored procedure and scheduling it for them would be the way to go.

If the users typically write nonrepeatable ad hoc queries a lot and they take a long time to run, then consider creating a "reporting" server that's kept up to date either by SQL Server replication or, better yet, SAN replication.