FYI – I have successfully installed DNN (version 4.4.1) – but not without issues that should be documented (the purpose of my original post). Below I have documented the process that worked for me.
First, I want to thank all of those who were generous enough to help me (you kindly asked me to give it another go and offered your guidance during that process). I was truly surprised by how helpful, professional and eager you all were. This doesn’t include NukeAlexS; however, NukeAlexS’s response to me generated a response from “Brian” (thanks bro!) whose comments about having to delete web files and the database after each failed installation actually gave me a clue to the issue…and there was an issue, contrary to NukeAlexS’s rant. To NukeAlexS I say this – you’re right. I’m not your boss. If I were you’d be fired.
Steps I took for a successful install of 4.4.1:
Based on a recommendation from a forum member (thanks Geert!) I used the setup utility for 4.4.1. I performed the setup on a Windows 2003 Server machine against a SQL Server 2005 Enterprise edition instance. I used SQL Server authentication. I’m running IIS 6 with the default website set to port 80 and with no headers (not needed at this point). I launched the setup utility and let it create the database and copy the files to c:\inetpub\dotnetnuke. I let it create the website and set appropriate permissions. When the utility was finished it presented a dialog screen asking whether I wanted to continue with the web based install. I chose yes (clicked “finished”). The web based installation progressed nicely until it reached the step for “Configuring SuperUser”. During this step an error was thrown: EXECUTE permission denied on object 'aspnet_CheckSchemaVersion', database 'DotNetNuke', schema 'dbo'. I went to the database and found that the user “dotnetnuke” did not have the db_owner role mapped to it (yes, I did this during manual installs). The utility did not set it so my SQL Server user did not have execute permissions on stored procedures. I went ahead and set this manually and refreshed the web page only to have the page render totally blank.
It was absolutely necessary for me to delete all web files and the database in order to run the utility again. This simple action should be documented somewhere – I don’t care if it’s documented with a crayon on a grocery bag but a simple message after a failed install would help tremendously! I executed the utility again. After it created the database, web site and folder/permissions, etc., I was again prompted to initiate the web based install. But before doing so I entered the database and mapped the db_owner role to the user manually (this was key). Only then did I click “finish” to initiate the web based install. This completed successfully and I was able to enter the newly created portal. Case closed.
To conclude, I understand that this product is still in its infancy stage. But this is an install and as most of you were quick to note it should be easy. Yet, as my post has proven, people out there are experiencing the same frustration as I did. This should be taken as certification that the install is inferior and not indicative of the installer’s skills. I was criticized that I simply used a book to step through the installation – yet the book was authored by the father of DNN himself and I somehow expected that this would be the only source I would need to get up and running. I was wrong. I was also criticized that I mentioned spending hundreds of hours studying DNN only to fail installing it. However, the majority of that time was spent learning about the history and philosophy of DNN before diving into the technology itself. I’m thorough, I’m a perfectionist and I bleed Microsoft blue - but DNN’s install failed me…I didn’t fail it.
Go Cardinals!