I would like to start by expressing my gratitude for the tremendous efforts of the entire DotNetNuke community.
DotNetNuke is a great product and this forum is a tremendous resource!
That being said, I would like to express my dismay at the tremendous waste of resources that occur by the lack of documentation
and what seems to be the laziness of many people who do not bother to read the existing documentation and search the archives on this forum
before asking questions.
I believe the amount of time required to compile an adequate set of documentation would be far less than the amount of time wasted assisting with the same problems, over and over again, on this forum.
Perhaps we should create a browser helper object (BHO) to send 20 volts of electricity to a users left mouse button every time they ask a question without first doing the research! :-)
I think a “best practices” document should be included with each download of DotNetNuke.
To that end, I offer the following
“Best Practices":
1.
Follow Microsoft's security guidance recommendation to operate under "Least Privileged" security rights.
2.
Procedures for creating a clean installation of DNN 3.x.
--------------------------------------------------------------------------------------
Due to the plethora of viruses and spy-ware lurking, I highly discourage using a Windows Administrator user account for non-Administrator tasks.
It is relatively painless to
follow Microsoft's security guidance recommendation to operate under "Least Privileged" security rights.
There are really only 2 situations where you need Windows Administrative privileges:
-- to setup your environment for debugging in Visual Studio.
-- to create a virtual directory in IIS.
How often do you create a new virtual directory?
--------------------------------------------------------
In order to debug in Visual Studio with a non-Administrator <LeastPrivileged> user account, you must do 2 things:
1.
Add your <LeastPrivileged> user account to the Windows Debugger Users and VS Developers user groups.
In the Windows Administrative Tools, you will find a shortcut to the Computer Management MMC. In this MMC, open System Tools | Local Users and Groups. If you have not yet created a <LeastPrivileged> user account, right click on the Users folder and select New User. Add the "Debugger Users" and "VS Developers" user groups to your <LeastPrivileged> user account.
2.
Run the aspnet_wp.exe worker process under your <LeastPrivileged> user account.
Open x:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config in notepad. Search for the <processModel> key. Replace the userName="machine" and the password="AutoGenerate" attributes with your <LeastPrivileged> user name and password.
That’s it - You no longer need Administrative rights to debug in VS!
--------------------------------------------------------
Procedures for creating a clean installation of DNN 3.x.
If performed properly, DNN 3.011 installs without a hitch.
Log in under your <LeastPrivileged> user account. Open Windows Explorer and create a "root" folder, say x:\DNNWeb. Right click on this folder and click on the security tab.
Add the ASP.NET machine account as a user & assign to your aspnet user account the modify, read & execute, list, read, write permissions.
You may add as many instances of DNN as you want to this folder, and they will all inherit their permissions from DNNWeb. This step eliminates having to add Windows permissions to every new instance of DNN that you create.
I keep an un-zipped, un-modified, never-been-installed DNN solution in my x:\downloads folder. Copy x:\downloads\DNN3011 to x:\DNNWeb\ThisInstance.
Right-click the IIS MMC icon on your desktop (you have already created this shortcut) and select "Run as". Enter your Windows Administrator user credentials. Right-click
"Default Web Site" and select New Virtual Directory. Name your virtual directory <ThisInstance>. After the virtual directory is created, right click on it and select properties. Click on Documents and move default.aspx to the top of the list.
Create the database. At this time, I will open SqlServer Enterprise, select my local "SqlServer Registration" and create a new database, named <ThisInstance>. Right-click on your newly created database, and select New Database User. Click the Login Name dropdown and select your Windows user account. Assign your user account db_owner permissions.
If you are using oSQL, you will need to write the appropriate t-sql scripts to create the database, add the user and assign the user db_owner permissions. Life is so much easier with SqlServer Enterprise!
The last thing to do before populating the database is to update web.config with your connection string and object qualifier. The {ObjectQualifier} is used by the installation process to assign a prefix to table and stored procedure names. I use my virtual directory name as my {ObjectQualifier}.
Here is a connection string example for using SqlServer Security:
<add key="SiteSqlServer" value="Server=(local);Database=ThisInstance;uid=UserName;pwd=Password;" />
Here is a connection string example for using Windows Integrated Security:
<add key="SiteSqlServer" value="Server=(local);Database=ThisInstance;trusted_connection=true;" />
Open Internet Explorer and enter the URL, in my case, localhost\ThisInstance.
DNN will now automatically populate the database.
You should now have a fully functional instance of DotNetNuke.
References:
why you should always enter an {ObjectQualifier}.
sql scripts for converting DNN 2.x users to the DNN 3.x Membership Provider.
The DotNetNuke Membership.doc explains how DNN was modified to accomodate Microsoft's Membership Provider.