Installing Dotnetnuke and .NET 2.0 on a Windows 2003 domain controller with service pack 1. by Steve Schofield

Many smaller and medium size companies run ‘multi-purpose’ machines.  These machines can hold the ‘domain controller’ role because applications like Exchange require it to work.  The folder permissions on a domain controller are locked down more than a regular ‘member’ server or ‘workgroup’ machine.  This can make getting applications like Dotnetnuke to work more complicated because of the added folder security.   There wasn’t much information about getting .NET 2.0 working on a domain controller.  I got this working on my test DC and thought it would be helpful in sharing the steps I used. 

Below are my raw notes about getting DNN installed on a Windows 2003 domain controller with service pack 1 running ASP. NET 2.0.  There are probably other methods but this was pretty straight forward.  My test DC used the default website but you can easily setup a virtual directory called ‘dnn’ or whatever that can run the dotnetnuke instance.  Hopefully this is helpful in getting your DNN instance working on a domain controller.  If you have additional steps or workarounds, please let me know and I’ll add them to the article.

Assumptions

• SQL 2000 is installed on the machine (sql2005 could also work)
• IIS is installed on the domain controller
• dnn402 virtual directory is marked as an application using its own App pool
• IUSR setting for the dnn402 virtual directory runs as the domain user
  

Here are the steps. 

• Downloaded dnn 4.x
• Extracted to c:inetpubwwwrootdnn402
• Renamed release.config to web.config
• Created domain user called ‘domaindnn’, password ‘p@SS!w0rd‘
• Added domaindnn to DC’s IIS_wpg group
• Create database called ‘dotnetnuke’
• Used SQL Enterprise Manager to add this domain user to the sql database and grant dbo permissions on the dotnetnuke database.
• Commented out the sql2005 section in web.config
• Added this to connectionStrings section to do trusted authentication.
  <add name="SiteSqlServer" connectionString="Data Source=IPofMachine;Initial Catalog=dotnetnuke;Integrated Security=SSPI;" providerName="System.Data.SqlClient" />
• Granted ‘write’ permissions on the c:inetpubwwwrootdnn402 folder for domaindnn user
• Verified the domaindnn user had at list/read permissions on C:, C:inetpub and c:inetpubwwwroot folders.
• Verified the domaindnn user had write permissions on temp environment folder (usually c:temp or c:windowstemp)
• Setup an application pool called ‘dnn’. Configured application pool to run as domaindnn (done inside Internet svc manager)
• Marked the ‘dnn402’ virtual directory as an Application
• Setup the anonymous user for the ‘dnn402’ virtual directory to run as domaindnn
• Ran http://machinename/dnn402/Install/Install.aspx?mode=Install
• Opened a browser, logged in as admin/admin
  
  ————
  
  One gotcha I found was the ‘temp’ folders was restricting the install from finishing successfully. The error listed below. I deleted all the tables and stored procedures, granted ‘write’ permissions on the temp folders and re-ran the DNN install.
  
  File:
  Error Unable to generate a temporary class (result=1). error CS2001: Source file ‘C:WINDOWSTEMPxhjl4ajw.0.cs’ could not be found error CS2008: No inputs specified



• Thanks to Michael J. van Zwieten for passing this along.  Here is Michaels comments.

  ————————————-

  I finally found an article that worked for me…

  http://forums.asp.net/1153547/ShowPost.aspx
   
  Specifically this part:
  
  After many hours of looking for the problem I discovered that when you use the configuration editors for asp.net 2.x they add an attribute to the configuration  element of the web.config file
  
  ( xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" )

  
  
  I removed the Attribute and ran the website once again and much to my surprise the website compiled and ran all the installation scripts.web.config file.