Setting up a local test copy of your hosted DNN site
In order to upgrade to the latest version of DotNetNuke (DNN), rework the layout/skin or test out some nifty new module, it is usually a good idea to do so on a local copy of DNN before pushing those changes out to your live site. Unfortunately, getting a copy of an existing hosted site down to your computer seems like quite a chore (but it really isn't that bad). In this article I'll walk you through the steps that I took to get my multi-portal DNN site copied down to my local computer, and up and running.
Backing up your DNN site
Note: Before backing up your existing DNN site, be sure to add a localhost portal alias for your primary portal. This will allow you to get into your system once it is running locally on your computer. I'll discuss some additional tips for the portal alias later in this article.
The first step is to get a complete copy of your current hosted DNN site. Depending upon your hosting provider this can be fairly easily, or if you have complete control of the server it's even easier. My hosting provider is 3Essentials, and I highly recommend them if you are in need of a great DNN friendly hosting provider. These guys have outstanding support service and good prices. For me to get a complete copy of my DNN site (file system and database backup file), I simply had to submit a support ticket with my hosting provider. Within an hour or so, they have backed up my database and zipped up the contents of my site...ready for me to grab via FTP. For more info on backing up yoru DNN site, see this excellent article by Mitchel Sellers.
Now that w have the file system backup and the database backup file on your computer, it's time to start restoring it so it can run locally. In this case we'll start with the database.
Restoring the database from a backup
In this example I'll be using Microsoft SQL Server Management Studio since i am running a full version of SQL Server 2005 on my computer. If you are using SQL Express as your database, your steps will be different (I haven't tried it personally).
- Open SQL Server Management Studio and connect to your local database. Right-click on Databases and choose "Restore Database...". Pick a name for your database (I chose to keep the same name as it appears on my remote host) and put it in the "To Database" field. Select the "From Device" option under Source for Restore, and locate the .BAK file from your database backup. Check the restore column next to your database.
- Next, click the Options page and choose "Overwrite the existing database" option. You may also choose to place your database files in a specific location from this page. The path where these files were stored on your remote host is stored in the back up file, and more than likely this path will not exist on your local computer. I chose to place the database files in the default location of C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL (your location may differ based upon where your SQL Server product was installed). Then click OK to begin the restore process.
- Once the restore completes, you should be able to browse through your tables just to make sure everything is working. The next step is to create the database account that DNN uses to access your database. From SQL Server Management Studio, expand the Security section, right-click on Logins and choose "New Login...". Fill in the login name ( I chose to keep the same account as I used on my remote site for consistency), select SQL Server Authentication, and fill in the password for this account. Uncheck "Enforce Password Policy" and select your newly restored DNN database as the default database for this account.
- Next choose the "User Mapping" page, select your DNN database and select the db_owner role. Then click OK to proceed.
Note: If you receive the following error:
Then you may have an orphaned database account (this can happen depending on how the backup of the database was made). To fix this problem, open a "New Query" window, select your DNN database from the drop-down list, and execute the following SQL statement (fill in the appropriate values where indicated):
EXEC sp_change_users_login 'Update_One', '<your DNN database account name>', '<your DNN database account name>', '<your DNN database account password>';
That completes the database restore, now on to the file system portion.
Restoring the DNN files and configuring IIS
In this step, you will take all of your DNN files (in my case the ones zipped into an archive by my hosting provider) and place them into you IIS root directory (default is C:\Inetpub\wwwroot , but yours might vary). I place the files in the root like this to prevent any issues with paths and to make the local testing of multiple portal sites easier. I usually delete everything from this directory first, then extract the contents of my backup archive file (include all folders) to the IIS root directory.
Next, we'll verify some IIS settings. Launch the Internet Information Services application, expand the websites entry, right-click on "Default Web Site", and choose Properties.
- On the Documents tab, make sure that default.aspx is the top option (or the only option).
- On the ASP.NET tab, make sure that version 2.0.50727 is selected.
- On the Directory Security tab, select Edit in the Anonymous Access and Authentication Control section. Make sure that the ISR_<your computer name> account is allowed anonymous access.
- Next, make sure that the security settings for your IIS root directory (typically C:\Inetpub\wwwroot) grant full access to the ASPNET user account on your computer. To do this, right click on the directory from within Windows Explorer and choose Properties, then Security. You should see an ASP.NET Machine Account listed, with full access rights granted to it. If not, you'll have to add this account.
- Next, we'll have to edit the web.config file (in the IIS root directory) a bit to get it to connect to the proper database. If you kept the same database name and account information as what is used on your remote host, then you simpy have to change the references to the server name in the connection strings. Change the server name to localhost and save this file. If you used different a database name and/or database account information, then you'll have to make sure that your local connection string matches those values.
- At this point it is probably a good idea to run the IIS Reset commandline utility. Just go to Start->Run, type in CMD, and click OK. From the command prompt, type in IISRESET and hit enter. This will stop and restart IIS on your computer.
You should now be able to launch your browser and use http://localhost to bring up your local copy of your DNN site. Sometimes it takes a bit of tweaking the PortalAlias table, using the IIS Reset command, and closing/reopening your browser to get the local site to come up successfully. I initially ran into http://localhost bringing up my hosted site, until I deleted the PortalAlias entries in the table, reset IIS and tried it again. Once you get it up and working though, it isn't that bad.
Portal Alias Tip
The methods discussed so far in this article allow you to get at least your main portal running locally, but they do not address what to do if you have multiple parent portals under one DNN installation. This last section will attempt to address that issue.
Here is how I setup my Portal Alias entries along with entries in my computer's HOSTS file, to make access my local DNN sites much easier. I have a single DNN installation that hosts a few parent portal sites, my company site (fugazidesigns.com) is the main site, while this personal site (michaelkizer.com) is another parent portal under the same DNN installation. I'm sure this is a fairly common setup for most people running personal sites under DNN. The two key ingredients that keepthis running smoothly when I restore these sites locally are properly defined portal aliases and entries in my computer's HOSTS file.
My portal aliases
Before backing up and restoring your DNN site locally, it is a great idea to get your portal alias entries all setup, here are mine as an example:
The first two portal alias entries for each site are used when accessing my remote hosted site, the third entry is only valid when access the local copy of my site on my computer. The reason the .local entry works is due to some entries in my computer's HOSTS file.
The HOSTS file is typically located in your C:\Windows\System32\drivers\etc directory (note that this file has no extension). Entries in this file will perform a local resolution of name to an IP address. In my case I've defined the .local addresses to point to my local computer. Here is how they look inside the HOSTS file:
As you can see they all point back to my computer's home address (127.0.0.1). Entering one of these .local names into my browser results in the HOSTS file redirecting it to my local IIS installation (which is a copy of my remotely hosted DNN site). DNN then uses the portal alias that matches this name to launch the correct portal. I use the .local extension on my local entries just to ensure that I am looking at my local DNN site (and not accidentally trouncing all over my live site). It sounds a bit more complicated than it really is...once you experiment with it and get it working, you'll wonder why you didn't do this sooner!
Hopefully, this aticle provides a good, working example of how to get your remotely hosted DNN site up and running locally. Fee free to comment on this page if you have any questions or suggestions on how to refine this process.
I have to give thanks to Mitchel Sellers (MitchelSellers.com) for showing me the HOSTS file trick, and for providing some of the best step-by-step DNN installation/upgrade/backup articles on the internets. Go check out his site!
Also, thanks to my wife for walking me through the database restore process and solving my orphaned user account problem. It's nice to have a SQL Server DBA and Microsoft MVP in the house!