After talking to many different developers, I appear to be one of the few ones that have gotten remote debugging to work with a reasonable success rate. That is why I have decided to post on it today. Everything I am writing today is based upon my experience in what has worked and may not necessarily be a best practice. I actually posted about this once in the past, but I think its worth going into more detail.
Preparing Your Server
The first step is to install the remote debugging tools on your server. To do this, run rdbgsetup.exe contained in the Remote Debugger folder of your Visual Studio 2008 or Visual Studio 2005 installation media. Be sure and pick the correct processor architecture (x86, x64, or ia64). To use remote debugging, you can either install a Windows service or run an application. Although, the service is more convenient if you are going to be debugging a lot, the application is a lot easier to get up and running.
Running the Remote Debugger
Once you have got the remote debugger installed, I typically use remote desktop to log into the server and start the Visual Studio 2008 Remote Debugger. This really will only work right if the account you are logging into the server with is also the same account you log into on your client machine that is doing the remote debugging. If its not, there are some complications and you'll legitimately get the error I have posted about here.
One thing to note. The Visual Studio 2008 Remote Debugger is not backwards compatible with Visual Studio 2005. Therefore, you need to be sure and install the Remote Debugger from the same version of Visual Studio you are debugging with. It is ok to have them both installed at the same time, but I don't believe you can have both running at the same time (need to confirm though).
Preparing your environment
When you are ready to start remote debugging, start by compiling your web application. You then need to copy the DLL and PDB file from your bin/debug folder to the bin folder of the web application on your server. Not doing this is one of the most common causes for a breakpoint to never be hit when remote debugging. If the DLL and PDB do not match between the client and the server, the breakpoint will never be hit.
Once everything is in place, it is time to start debugging. To do this, click on Debug -> Attach to Process in Visual Studio when you have your web project open. If everything is good and all the permissions match up, you should be able to type your server name into the Qualifier box and view its processes. Typically, when I do this, I am a local administrator on both the client and the server. I think this is more permission than needed though. I believe there is a Remote Debuggers security group that can be used.
The way you start debugging is by attaching to w3wp.exe. However, it is more than likely that you will have multiple application pools on your server (especially if you are using SharePoint) which means more than one w3wp.exe process. To determine which w3wp.exe to use, you can just pick one arbitrarily and then examine the modules window in Visual Studio and look for your DLL. You can also look at the username on the process and see if it matches the one on the application pool you want, or you can use a cscsript command to get a list of the w3wp.exe processes and which site they match in IIS.
Once you have attached to the correct w3wp.exe, set a breakpoint open a web browser and hit the page you want to debug. Assuming you set a breakpoint and did everything correctly, the breakpoint wont give you a message that the symbols could not be loaded and the breakpoint cannot be hit. If you were able to set your breakpoint, open a web browser and hit the page you wanted to debug. If all goes well, your breakpoint will be hit and you can debug just like it was on your local machine.