Remoting problems while migrating to IIS 7

I am trying to move an application from out IIS 6 server to our IIS 7 server. The application provides remote objects to clients. I basically copied over dll's, config files, etc. in order to deploy it to the new server and updated the URLs on the client side to point to the new server.

I can pull up the trace file for the remote virtual directory and see the calls to the remoting service whenever we try to get a proxy class. But calling any method on the proxy class results in a 404 error returned to the client. While looking through the old IIS 6 web logs, I can see the requests being handled that look something like this:

2011-05-25 16:03:50 W3SVC1 160.0.0.1 POST /Host/b3b4bde0_7589_4bff_b44b_e1793f392d8f/sziv3p5a8+zkofa0v_bsvgdv_251.rem - 80 - 128.104.151.220 Mozilla/4.0+开发者_开发百科(compatible;+MSIE+6.0;+Windows+6.1.7601.65536;+MS+.NET+Remoting;+MS+.NET+CLR+2.0.50727.5444+) 200 0 0

Looking through the IIS 7 logs, I don't see any entries like that, just the requests that fire up the remoting service :

2011-05-25 15:57:15 160.0.0.1 POST /Host/RemotingService.rem - 80 - 128.104.150.27 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+6.1.7601.65536;+MS+.NET+Remoting;+MS+.NET+CLR+2.0.50727.5444+) 200 0 0 0

At the server level, I've enabled 'Allow double escaping' and upped the Maximum allowed content length (Bytes) to 56700000 as was suggested in other articles. The Request handler mapping is set up (which is why I can see the logs for the RemotingService.rem return correctly) but I can't seem to get any of the remote objects to do anything. I've tried putting the virtual directory that hosts the remoting object into either the Classic ASP Pool or the Integrated but still no luck.

Is there anything else I'm missing in order to get remoting to work on IIS 7 ?

---

Figured it out. The default IIS website was set up with a binding to a domain name only...no blank entries. All remoting requests get resolved to IPs before being sent. Because IIS did not have a wildcard, so to speak, in its entries, it only accepted requests at the domain name level, not the IP level. This would explain why the trace.axd files would get picked up and logged but the actual method calls failed with not so much as a log entry. Adding a blank entry to IIS's bindings fixed it right up.