First of all check the requirements: DNN Platform Requirements -- DNN Docs (dnncommunity.org) - regarding SQL Server, this is not valid anymore, it must be at least 2016 (even if this version is out of mainstream support already, so better take 2019 or 2022). Regarding .Net I would recommend to use version 4.8.1.

Then:

Please (double) check if the AppPoolIdentity is selected as the anonymous user identity - open IIS Manager, select the site, double click "Authentication" in the IIS section, select "Anonymous Authentication" and click "Edit..." on the right side. Make sure the option "Application pool identity" is the selected option. To be sure, select the Application Pool, open "Advanced settings..." and check if "ApplicationPoolIdentity" is selected as Identity in the Process Model section. Also check if the selected .Net CLR version is set to v4.0, and the managed pipeline mode is set to "Integrated".

Also (double) check in the Windows Explorer if the application pool identity has Modify permissions in the complete tree starting from the web root. Sometimes I disabled inheritance from the root folder, selecting "Convert inherited permissions into explicit permissions on this object", and the re-enabled inheritance, and then it worked.

Then (double) check in SQL Server Management Studio (SSMS) if the application pool is in the db_owner database role for the database. Start SSMS, open the "Security" and then "Logins" node on the left, right click the Application Pool login, select "Properties", select "User Mapping", select the database in the upper half of the dialog and check if "db_owner" is selected in the lower part of the dialog.

If all of this is done, then the thing should work.

Happy DNNing!
Michael

When the installation succeeded, please remove the db_owner role for the Application Pool Identity, and allow executing Stored Procedures and Function. Read Secure your DNN Database by some simple steps (dnncommunity.org) to achieve this important security step.

Happy DNNing!
Michael

No luck. Have tried multiple times. We even stood up a brand new server, Windows 2019 with .NET 4.8, nothing else on it and it hangs at 48% "Creating Site" every time. 

Our SQL Server is 2017, and we've already successfully installed this version of DNN on an older test server without a problem! 

I went through the suggested steps and made sure the AppPoolIdentiy was selected as the anonymous user ID, and doublechecked it from the AppPool advanced settings as suggested. (It was not originally, so I thought pehaps this might be the problem, but after configuring this it still didn't work.) 

Confirmed the .Net CLR version is v4.0; managed pipeline mode is "Integrated". 

I gave the AppPool account Full Control permissions at the site root, and tried disabling inheritance with "convert inherited permissions, etc..." then reinherited. 

The only thing I couldn't do is give the application pool the db_owner database role. As mentioned, the database is on a different server and so the AppPool Identity account isn't present on that server to give it any roles or permissions. We're using a dedicated account on the SQL server as db_owner and using it's credentials to connect to the SQL server and database during installation (which is how we've done every other DNN installation we've ever done going back 10+ years). 

Any additional suggestions? At this point I don't know what else to do except give up and install an older version of DNN. (Though I haven't tried that yet... for all I know that won't install either.) 

Do you have any other programs installed that might be getting in the way?  Antivirus, for example, can sometimes wreak havoc on a dynamic website application like DNN.  

Try disabling any such software first to see if it's the culprit.  

Then, turn it back on when you're done.  ;)  

Posted By Will Strohl on 4/13/2023 12:56 AM

Do you have any other programs installed that might be getting in the way?  Antivirus, for example, can sometimes wreak havoc on a dynamic website application like DNN.  

Try disabling any such software first to see if it's the culprit.  

Then, turn it back on when you're done.  ;)  

Just my two cents: You should define an exclusion for the web root and all subfolders in the anti-virus software you are using, otherwise you could run into serious performance issues. Regarding SQL Server you should follow these guidelines: How to choose antivirus software to run on computers that are running SQL Server - Microsoft Support - the chapter titled "Directories and file name extensions to exclude from virus scanning".

Happy DNNing!
Michael

Thanks for the additional suggestions. We use Crowdstrike to monitor all our servers for malware and viruses; I've been assured by our team that manages the software that isn't blocking anything on that server. I checked and noticed that Windows Defender was active on it as well, so I added an exclusion for the root folder & subfolders as you suggested. Unfortunately all of this has made no difference; DNN simply will not install. I even tried installing the previous version of the DNN platform on it, and it still stalled (at 56% instead of 48%, but still won't finish the install). 

These are the exact specs of the servers involved; maybe you'll see something we're not that's a red flag:

Application Server:

Windows Server 2019
Intel Xeon Gold 6240 CPU @ 2.60GHz 2.59 GHz
Installed memory (RAM): 8.00 GB
System type: 64-bit OS, x64-based processor

IIS version 10.0.17763.1

Database Server:

Windows Server 2019
64-bit OS, 16 GB RAM
SQL Server 2017, v14.0.3257.3
10 GB SQL RAM
 

Just for kicks I also tried it using our older development SQL server, with these specs:

Windows Server 2012 R2 Standard
Intex Xeon CPU E5-2690 v4 @ 2.60GHz 2.60 GHz (2 processors)
Installed memory: 32.0 GB
64-bit OS, x64-based processor

SQL Server 2016

Well, this is certainly an odd issue.  It sounds like you may need to monitor the processes running on the server to see what in your environment is blocking this.  

Finally found some time to get our database admin and systems engineer together at the same time to do some testing, and nailed down what the problem was. 

SCOM 2016 Sharepoint 2013 PerfMon64.dll crash W3wp.exe (microsoft.com)

SCOM is part of our default setup for new servers, and this was a known issue with this version of SCOM that causes W3WP.exe to crash. When we monitored the server during an install attempt we saw this exact issue occur; turned off SCOM for the install and DNN installed without a hitch. 

Ah, that's good to know. What's old is new again.  DNN & SharePoint have always liked to battle each other in the past!  😆 (Mostly, when we debated it years ago.)