You have to bless all the people in the world who have contributed all of this time and energy into this fantastic project DNN.  I have installed over a hundred DNN sites and have gotten all kinds of errors.  Almost all of them were my fault.  But this latest one really kicked me in @#$.  I had to go to the DNN Forums to get the fix.  I had to add an appkey to the web.config:

<!-- I added this key to fix the redirect issue-->
<add key="UsePortNumber" value="True" />

Hope it helps.

 This article was the best, easiest, and to the point fix for a corrupted Exchange IIS Virtual directories.  I spent hours trying to track this issue down.  It seems that the secret was to enter in the correct search terminology in Google.  I was using words like reinstall, fix, OWA, Outlook Web Access, etc.  At the last minute I used "repair outlook web access 2003" and the second search result was it.  The website requires that you register, for free, and go through a whole series of questions.  It was well worth it in the long run.

Brien Posey was the guy who wrote the article.  His picture made him look like a twenty something but his resume was rockin'.  I will definitely use any of his technical articles.

Link to Step-by-Step Guide: How to repair Exchange-related IIS virtual directories

I have been using Visual Studio 2005 for over eight (8) months now.  I have noticed peaks and valleys in performance.  It seems that the best performance comes from using a different harddrive for the project files, not the same physical harddrive that VS2005 is installed on.  Second, kill this ctfmon process using they link below.  It runs even if you opt out of the language bar.   

Link to Frequently asked questions about Ctfmon.exe

This is an interesting challenge.  We are still in the process of namespacing and adapting our first DNN agenda items to our web services.  After reviewing much of the DNN code you find that there is little in the way of notifications.  You create the controller tell it to create the portal and you are done.  You do not get any error codes that the function succeed or failed.  The assumption is that it worked, otherwise an exception would be thrown.  In the Portal Controller class there are no Try..Catch blocks.  We are trying to develop a series of error codes to go along with the web services.  Since the applications using the web services do not have a state in the matter we need to let them know if they succeed or failed.  We will look at using Datasets and Begin/End Trans for the remote calls.