We have been developing a site recently with DNN and did not have any trouble with the HumanFriendly URL setting on any of our development servers (both XP with IIS 5) or our staging server (Windows Server 2003 with IIS 6).  We bundled up the site and passed it off to the client for install on their own development server/production server, however, all requests for pages result in a 404 "page not found" type error page from DNN.

On all our development servers, we have both "Use Friendly Urls" turned on in the host settings, along with the urlFormat="HumanFriendly" attribute in the web.config for the DNNFriendlyUrl provider.  On the client's servers, however, the site works fine when neither of these are set, or if the host settings "Use Friendly Urls" is set, but once the HumanFriendly attribute is added to the web.config, that's when we get the 404 error pages along with an HttpException in the DNN Event Viewer.

The only difference between the client's setup and our own development/staging setup is that there is a Microsoft ISA firewall involved on their setup.  I am not sure if that's causing any issues, though, as the client is seeing the same 404 error pages as we are and they are behind the firewall.  We've also had the client add both IPs to the PortalAlias table (the one we are using from outside the firewall, and the one they are using inside the firewall) but it doesn't seem to have made a difference.  We've also had them check to make sure that the "Verify that file exists" setting in IIS is turned off, which it is... and I'm pretty sure we wouldn't even be getting to the point where we get a 404 HttpException in the DNN log if that was enabled in IIS.

Does this problem sound familiar to anyone?  We are kind of at a loss on how to fix it... we've tried just about everything we can think of.

In your clients setup, are they running the site through the asp.net development server using VS 2005 rather than IIS or are you using a specific port in IIS ?

I've seen the same problem on an XP development machine I think this is a slight bug with the DNN URL Friendly provider where the port number (as used by the asp.net development server) is omitted in the rewritten url, I.e localhost:3276/default.aspx?TabId=30 gets re-written to localhost/home.aspx  notice the missing port number. Run this through IIS or replace the port number manually and it works fine .  NB You may experience the same issue if a specific port is used in IIS although I haven't tested that. Someone needs to fix the code in the provider.

After days of debugging...

My personal dev server had always been running on port 80, and only had localhost in my PortalAlias table. My co-worker's dev server was at one point running on port 8080, but he switched it to port 80 later on.  He still had both localhost:8080 and localhost in his PortalAlias table, though. Our staging server was running on port 80, as well.  The client was trying to set up under an alternate port on their dev server, so we gave them instructions on how to edit the PortalAlias table to include their ip:port info.  They never attempted to set it up under port 80, so only had the alternate port info in the PortalAlias table.  Everything worked but the human friendly URLs, as described in the original post.

In an attempt to reproduce their problem, I downloaded the exact files we'd sent them from our staging server to my local dev server and set it up also using an alternate port, 8080.  I was now able to reproduce the 404 errors from the human friendly URLs.  I switched back to port 80, and everything was fine.  My co-worker double checked his setup running on 8080, and it was still fine.  We set up a second instance of the site on our staging server on port 8080, and it was also fine.

So, now we have a staging server that works fine on the regular and an alternate port, we have 1 dev server that works fine on an alternate port, and we have my dev server that works on the regular port but not on an alternate port.  So, my boss says, "try running your server on both 80 and 8080."  So, I set up IIS to run on both ports, I added the second entry to the PortalAlias table, and restarted IIS.  The site now worked on both ports!  I then removed port 80 from IIS so that it was only running on 8080 again, and it still works.  Whaaaaat?

Then I realized, the only thing that was different was before when I was swapping between 80 and 8080, I was changing the same entry in the PortalAlias table from localhost to localhost:8080 and back again, but when I set it up to run on both ports, I had 2 entries.  When I went back to only running on 8080, I left both entries in the table.  To confirm that having both the address with the alternate port and with no port at all was the issue, I removed the localhost entry from PortalAlias (leaving localhost:8080) and the site promptly broke.

So, to summarize all this craziness: 

We needed to have both "server.com" and "server.com:8080" in the PortalAlias table so that URLs like "http://server.com:8080/home.aspx" would work, even if we weren't even running a server on port 80.

I hope this helps someone else in the future!