A server failure caused us to have to restore our site's DNN database and files to a new server. We restored the site to a temporary IP, so that we can test it before making it live. I changed the PortalAlias db table's HTTPAlias field to the temporary IP address for testing purposes. The site home page comes up fine when we enter the IP address, but all secondary pages come up as missing when the TabPath is used in the URL. The only way they work is if we enter the URL in the format "http://000.000.000.000/default.aspx?tabid=66."

For example, the following URLs work:
http://66.155.114.247
http://66.155.114.247/default.aspx
http://66.155.114.247/derfault.aspx?tabid=66 (our Sports & Fitness page)

But the following URL, which is what is automatically generated by DNN using the Tab's TabPath in the site's breadcrumb, returns a missing page error:
http://66.155.114.247/SportsFitness.aspx

Usually, the URL in the latter format would work. What is it that I have not set correctly in the site rebuild that could cause the standard URLs to be failing?

Thank you,
Kurt

---

Actually DNN does create a url in this format when the urlFormat property is set to humanfriendly (urlFormat="humanfriendly") in the web.config.

This only affects the writing of the url and not the parsing of it and would not be the problem here.
Do the pages show when using the DNN menu for navigation.
If so are they displaying friendly url’s?
If not check “Use Friendly Url’s” under host settings (again this will not affect parsing of the url).

Also did you restore both the files and database of the same site backup?
Or did you install a new DNN install and then restore the backup database?
What version of DNN are you working with?

---

Robert Harriman
WEBMAZING.NET
AutoWebSuite / BrokerWebSuite
DNN Modules for Auto Dealers and Real Estate Professionals.

Thank you all for your input. Believe me, we had looked at everything, including the Friendly URL settings.

We tried creating a fresh, new DNN site install using the exact same installation files as the site that we were working on and set it up exactly the same. When it worked perfectly, we realized that all of the pieces were working, so the problem must be something absolutely unique to the site that was having the problem. After exhausting every avenue and getting nowhere, one of us had the brilliant idea to just remove the IIS virtual directory and then create a fresh one. That turned out to be the problem--as soon as we created a new virtual directory for the site, the problem went away. All those days of troubleshooting and the issue was a corrupt virtual directory all along. What a lesson!

---