Blog

26

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).

  1. 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.
  2. 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.
  3. 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.
  4.  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.

  1. On the Documents tab, make sure that default.aspx is the top option (or the only option).
  2.  On the ASP.NET tab, make sure that version 2.0.50727 is selected.
  3.  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.
  4.  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.
  5.  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.
  6.  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: 

DNN Site
Portal Aliases
FugaziDesigns.com

fugazidesigns.com

www.fugazidesigns.com

fugazidesigns.local

MichaelKizer.com

michaelkizer.com

www.michaelkizer.com

michaelkizer.local

 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:

127.0.0.1            localhost
127.0.0.1            fugazidesigns.local
127.0.0.1            michaelkizer.local
 

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!

 Conclusion

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!

Posted in: DotNetNuke

Post Rating

Comments

ultrasound gel
Thursday, October 09, 2008 10:34 PM
very useful
Brian
# Brian
Saturday, November 22, 2008 4:41 AM
Dude,

I searched for HOURS on how to test a parent portal locally. What you have here toward the end of your article with the hosts file was the HOT TICKET.

Just to clarify and help anyone else out:

I first created the new parent portal (called "testportal" with a portal alias of "testportal.local") in DNN using the host account. Then I added 127.0.0.1 testportal.local to the hosts file. It still wasn't working. Then I added a new website in IIS. Home directory points to the default DNN location (e.g. C:\Inetpub\defaultwebsite\DNN). *VERY IMPORTANT* Click on the ASP.NET tab of your web site properties and make sure it is on a 2.0 version (I had 1.1 in there as the default and got error message). I can't believe it took HOURS to get this simple little issue figured out. Hope the rest of DNN is a little easier.

THANKS!
Chandrakant
# Chandrakant
Wednesday, June 24, 2009 3:41 AM
Hey, the information is in great detail and very useful. I think the step you are missing here is how to create a new entry in the IIS for additional parent portal that you have created in DNN.

Thanks.
Abhay
Sunday, August 23, 2009 8:01 PM
while updating the PortalAlia Table, Do Not Specify "HTTP://..."

I made that mistake. Just specift the "localhost" or the server address
Larry Aultman
Sunday, September 27, 2009 9:01 AM
I found everything here to be accurate. However to calrify for those wanting a quick fix. Follow Mitchell's instructions. The one thing that should be clearly noted is that you should create a NEW WEB SITE in your local machine as noted in Brian's comment. This new web site is NOT a virtual under your "Default site" in your local development machine.
If you want to test all the portals you will need to have in the HOST file, names for EACH alias and you will need to add EACH of these to the IIS web site so that it will resolve multiple host names. This is the same way it is set up in the live server environment.
vinod
Thursday, October 08, 2009 6:35 AM
Having a problem here,
I have Backedup of my live dnn site and database backup from 2005(.bak), Now i have to installed SQLExpress 2008 locally and want to setup the site locally and then move to live server.
Ii configured iis to the live site copy stored on my pc and created a empty database and restored the .bak file and changed the portal alias to my localhost ip address,
I am doing mistake in web.config as i believe. What are the main changes i have to do.
vinod
Tuesday, November 03, 2009 7:12 AM
Hi,
I have came through this site in search of DNN moving i done it successfully the problem raises at host login, i make a local copy of same which works even with host login not for live version can you send me the sort out from this
brian
Monday, September 06, 2010 9:07 PM
Thanks for the set up on local host article. I had been struggling for a while. I'm installing on windows 7 pro using SQL Express 2008 and IIS7. The steps were the same except I used ALTER USER user_name WITH LOGIN = login_name instead of sp_change_users_login when I received the error while adding the DB user. sp_change_users_login kept giving me errors. Make sure youelete the user first before running Alter user or it will complain.
Paul
Thursday, September 16, 2010 10:06 PM
Thanks you for this article! I have been asked to present to staff the meaning of DNN, it products and capability as part of ongoing training and development. Although I have fundamental comprehension of the content management being able to present to a group of critical staff required some meaningful and formal data.
Ryan
Tuesday, September 28, 2010 10:47 PM
Thanks for the handy guide. I had already figured most of the steps out for myself but got hung up on the portal alias (silly I know). Anyway thanks for the great tips. You and Mitchell Sellers are always good for saving my bacon!
Dimz85
Friday, May 06, 2011 2:51 AM
Thanks for the handy guide. I am new to web development and this really helped me :)
Kevin
Tuesday, September 20, 2011 7:57 AM
If you're upgrading your DotNetNuke instance, here is a list of simple steps to follow during the upgrade process. First tip, test the upgrade on a staging site first, pull a copy of the database and files down, try the upgrade, make sure all your functionality is still there. Then upgrade production.
K-Log
Friday, February 10, 2012 12:21 AM
So, now in addition to my regular portal aliases I've added: domain1.local, domain2.local

Added some references in my HOSTS file:

127.0.0.1 domain1.local

127.0.0.1 domain2.local

and fired up the browser... go to the .local address to get the "local" version of the .com
Daniel Comp
Monday, February 18, 2013 2:34 PM
Funny that all it takes is a single character error and the whole transfer effort is frustrated. Thanks for walking me through what i already 'knew' and yet flubbed up. (webconfig) server name is in the db connection path... duh!

Post Comment

Name (required)

Email (required)

Website

CAPTCHA image
Enter the code shown above:

  
christian louboutin outlet christian louboutin outlet cheap canada goose