Restoring a DotNetNuke Database

In development I find myself restoring databases every once in a while and as much as I always hope its going to be a quick “pull the backup – restore the db – start coding” kind of process; it doesn’t normally work out this way.

Recently I had to restore a production database on my local machine and once again had to go through several steps to get everything in working order and stop getting the security, “Install wizard”, 404, and 501 errors that always make me groan.

When restoring a database and you get these inexplicable and weird errors keep in mind the following steps that need to be completed before you can stop saying, “DotNetNuke is killing me.”

Step 1: Restore the Database

Okay, I’m not going into this one.  I’m assuming if you’ve come this far you already know how to restore a database through SQL Server Management Studio

Step 2: Fix the Connection String in the Web.Config

This one is optional.  Depending on your naming set up the web.config might be just fine.  But if the database has a different name, username, or password, you’ll want to update the connection string in the web.config.  Remember it shows up in two sections; connectionStrings and appSettings.

Step 3: Fix the User Account

I have a whole blog post on how to fix orphaned users.  Whenever you restore a database you create the orphaned user error.

Step 4: Fix the portal Alias

You have to do this manually.  Open the PortalAlias table so you can edit the records directly.  Depending on how many portals you have you need to edit the alias’s so they reflect the URL pattern of your local setup.

So, if your production site is http://www.mywebsite.com the alias is “www.mywebsite.com” and “mywebsite.com”

On your local setup you will need to change the alias to match your setup.  If you’re using localhost it would be “localhost/mywebsite”.  If you’re using host headers than it would just be “mywebsite”

If you have a child portal the production alias would be something like “www.mywebsite.com/childweb”.

On your local setup you will need to change the child portal alias to “localhost/mywebsite/childweb” or “mywebsite/childweb” if you’re using hostheaders.

Step 5: Fix the SSL

If you’re production site is using SSL it’s likely that you’re not using SSL on the local development version.

For that you need to run a couple queries to fix the SSL.

First; update the Portal Settings.  This query will fix the parent and all child portals.

Update PortalSettings
Set SettingValue = 'False'
Where SettingName = 'SSLEnabled' or SettingName = 'SSLEnforced'

Second; update the Tabs. This query will fix all tabs in the parent and all child portals.

Update Tabs
set IsSecure = 0

Step 6: Restart IIS

Restarting IIS is always a good idea to clear the cache, so the website starts up fresh.

And that’s it.  You should be good to go now.  Happy coding!