Net Data Design, LLC Blog

An alternative method of installing DotNetNuke on IIS 7.5 9or IIS 7) is using the free helper application by Mike van der Meulen. MakeDNNSite is a nice little package that will give you a new DNN install without a lot of hassle. There is no manual web.config editing, Application Pool creating or setting of permissions (see note below). It will even download the latest build for you or use a package that you already have downloaded.

I have used this method several time in testing and found it to be flawless (2008 R2, 64-bit). It does come with a few restriction, such as you can’t install using a sub-domain. It said to work on IIS 7 and 7.5 both 32-bit and 64-bit and SQL Server 2005 and 2008 both full and Express editions.

Because MakeDNNSite works on both IIS 7 and 7.5, the Application Pool created uses the NetworkService account. While this is fine for IIS 7, however it is not the preferred account for IIS 7.5, rather the IIS AppPool Idently account should be used. This can be simply changed by right-clicking the newly created AppPool and selecting ‘Advanced Setting’. There, under Process Model, change the identity to ‘ApplicationPoolIdentity’.

If you opt to use the ApplicationPoolIdentity you will need to update you permissions on the website directory as well. I have blogged about this in detail (IIS 7.5 AppPool Identities).

In short, it’s a really nice tool at a great price (Free.) I highly recommend it for all DNN users, regardless of your environment or skill level.

There have been many questions on how to install and configure DotNetNuke on IIS 7.5 which ships in Windows 7 and Windows 2008 R2. I will outline the procedure I use to do so. For this example I will be using Windows 2008 R2 64-bit.

When you first login to 2008 R2 you will be greeted with the Server Manager.

Server Manager

After you expand the Roles node and the Web Server node in the left pane you will be in the main IIS Manager.

IIS Manager 7.5

Right Click on the “Sites” folder and select “Add Web Site.”

Add Web Site

In the next screen we enter the web sites specifics. Fill in the highlighted areas with your information. Note that as you enter your site name an new Application Pool is created.

Web Site Details

During the above process you will create a new directory to which you will deploy your DNN code.

Create Website Directory

After this is complete, select Application Pools from the IIS Manager node. The detailed view should indicate that the AppPool is in Integrated Pipeline mode.

AppPool View

If you have not already done so, copy your DNN files to your website directory. In IIS Manager right click your new website and:

1. Select “Edit Permissions.”
2. Select the “Security” tab.
3. Click the “Edit” and then “Add” button
4. Click the “Locations” button and make sure you select your machine.
5. Enter “IIS AppPool\<YourAppPoolName>” in the “Enter the object names to select:” text box.
6. Click the “Check Names” button and click “OK”.
7. Grant <YourAppPoolName> modify permissions on the directory.

Securing Resources for your Process Identity

At this point you are ready to edit your web.config for your database connection., and get started.

If you have any questions on the Application pool details, I have covered this in an earlier Blog, you can read that here.

So, what do I mean by new look? Well, the powers-that-be have moved DotNetNuke (DNN) to an open repository. Since it’s inception from the iBuySpy days the repository has been closed.  I should note that the project has always released a “source” version of the application to the public, and for the first few years this system worked for a majority of the DNN community.

Times change however, and DotNetNuke Corporation is adapting to these changes. For instance the Issue Tracking has been reworked, and the new “Just like Clockwork” release dates. The later replacing the “When it’s Ready” policy. I was never a big fan of this policy but I do understand that a project that relied on a largely volunteer staff, this was a best fit model for DNN. Again, times change.

A few personal observations from someone (me) who has used, developed to and profited from DNN since version 1.5, the iBuySpy fork:

1. I have noticed that the quality of releases since DNN incorporated has risen greatly. There seems to be more attention paid to details and the QA/Testing group appears to have things well in hand.
2. The security of a DNN build has always been handled well, but the newer releases have been outstanding with no critical issues in well over a year. Kudos go to Cathal Connolly for an outstanding effort.

If you haven’t installed and tested this rich development platform, or perhaps you have in the past and lost favor; you need to check-it out. You’ll find a robust community and user-groups world-wide. Give it a shot.

While the newest DotNetNuke release (5.2.1) is primarily a stabilization release, it does pack a much needed new caching provider that allows the application to run much better under load with improved performance. There have been a few cases, from what I can see, with some minor upgrade issues but as a whole this is a worthwhile upgrade.

The major highlights are:

• Fixed issue where banners were not properly rotated according to the specified views/clicks.
• Fixed issue where upgrades could fail if the the user account did not have permission to update objects in some db schemas.
• Fixed issue where list values were visible outside of the Portal where they were created.
• Fixed issue where caching providers were not rendering unicode characters properly.
• Fixed issue with missing Telerik assembly in the source package.
• Fixed issue where Ajax HostSetting was not properly set on upgrade from 4.x installations.
• Fixed issues where upgrades would fail with a unique index violation.
• Fixed issue with the Starter Kit which was missing HTML module files.
• Fixed issue where page templates were not working correctly.
• Fixed default settings for the module and output caching providers.
• Fixed issue which prevented Blog module from working after some upgrades to 5.x.
• Fixed issue when creating a new module in the Module Definition Wizard if the .ascx extension was not specified.
• Fixed issue where localization was not working if the application virtual directory name was also part of the module name.
• Fixed issue where the FriendlyName for Schedule Items was not being saved.
• Fixed issue where GetUserCountByPortal was making excessive database calls instead of using cached values.
• Added binding redirect setting in web.config to prevent versioning issues with Telerik assembly.

Providers:

• FileModuleCachingProvider 05.02.01
• MemoryModuleCachingProvider 05.02.01
• SchedulingProvider 05.02.01