After many sleepless nights, head banging, etc., my searching has finally provided me with a solution!

Mike van der Meulen at Softel vdm has created a brilliant little program, MakeDNNSite.exe. It's available for FREE download at:

MakeDNNSite will install DotNetNuke on your system, so you don't have to worry about all the little details. Specifically, it does all of the following:

• Defines your new website in IIS (your web server)

• Creates the necessary folders with appropriate permissions
• Defines logging options (simple) and places the log file with your website's folder
• Defines a new database in your database server
  • Creates the appropriate database permissions
• Downloads the ZIP file to install DotNetNuke
  • Or you can use a ZIP file that is already on your system
  • Unpacks the Installation ZIP file
• Updates your system's Hosts file so you can access your website with a real URL (website name)
• Updates your Web.config file so the DotNetNuke Install Wizard doesn't have to do much magic

I used Mike's program to setup a new site, then opened the site in Expression Web 3, and.... all the links work! No more 404 errors.

I owe a debt of gratitude to Mike as I've been frustrated by this problem for quite a while now. I plan on using MakeDNNSite.exe for all my future installs. Bigger question, though is why did it take Mike to come up with this??

Jim

I have just performed a clean install v5.3.0.183 on VS2008 SP1, SQL Server Express 2008, Windows 7, asp.net 3.5 sp1
This problem continues to exist.
One thing I have noticed, is that once I log in using ?ctl=login, then I am able to access only pages like:

• localhost:12345/dnn/tabid/1/default.aspx, which is how all the items under host use,

all items under admin use the human friendly form:

• localhost:12345/dnn/admin/pagename.aspx  or localhost:12345/dnn/home.aspx - fail with 404 error.

That would lead me to believe the Friendly URL rewriter is having issues. So, I changed the urlFormat in ' <add name = "DNNFriendlyUrl" ... urlFormat="humanfriendly">' back to 'searchFriendly' fixed it for me.

Solutions should be: a rethink of the url rewriter or DNN url interpreter.

I hope this helps.