It’s something that just about every website owner will face sooner or later : the need to make a copy of their website for testing or development purposes. Sometimes it’s just not feasible or smart to try things straight in your live website. Sometimes you need to pull down a copy to work out a bug, or test an important upgrade.
This blog post is a step-by-step guide on how to take a copy of your live website, and recreate it as authentically as possible running on either another server or your development workstation.
This procedure isn’t very difficult, but there are a few steps to follow. Take a minute to check that you have everything you need:
Software you’ll need:
- test environment must have the same IIS version as the live environment*
- test environment must have the same Sql Server version as the live environment*
- an FTP program
- Sql Server Management Studio to connect to test machine database server
- IIS Manager for connecting to test server
- text editor for config changes
- compression utility – winzip, 7z or similar
Things you’ll need:
- copy of your live server database backup + complete copy of the http files for the site
- ftp access if you have to download the backups
- copy of your host password
- an ‘SA’ or similar administrator Sql Server account on your test database.
* note : a later version on the test environment is [usually] fine. If you live server is running IIS 7 and Sql Server 2005, and your Dev environment has IIS 7.5 and Sql Server 2008, it should be OK. However, try and install on IIS6 and Sql Server 2000 and you’re guaranteed problems – it’s not really worth setting out if you’re facing this challenge – take the time to ugprade your test environment instead.
Take a minute to check you’ve got all that, and let’s get started!
Note: throughout this post, I’m going to pretend to backup ‘example.com’ – just substitute in your domain name whenever you see this.
Creating a test DotNetNuke installation
Step 0 : Plan your install.
When I do a test install of a live site, I normally scribble down a few things before getting started. Referring back to these notes helps to avoid making mistakes.
Some of these are (square brackets show values used in this example):
- test server name [testServer01]
- test server database name [example.test]
- test server database user id + password (the user Id you’ll use to connect to the database) [dnnAdmin/password]
- test server domain name. [example.test/www.example.test]
- test server install location [d:\DotNetNuke\example.test]
- database owner [dbo]
- database prefix [dnn_]
When I test locally, I always give my test installs a new domain name – I normally do this by removing the tld and replacing it with ‘.test’. Thus, example.com becomes example.test. If you’re installing to a remote server (ie, on the internet) then I would recommend using a subdomain, so you might create with ‘test.example.com’.
Throughout this example, I’ll be using example.test to refer to the local install of example.com.
Step 1 : Obtain the backups of your live server
If you have a dedicated or Virtual private server hosting, this should be no problem. Just take a backup of your database, and zip it and all of the files in the website into one zip (or 7z) file. Then download that file to the test server using FTP. If you’re restoring to a remote machine, then you may have to download to your local machine and upload to your test machine.
If you’re on shared hosting, you may have to ask your hosting provider to gather this information for you. If your site is being backed up effectively, this should be no problem. If you can’t lay your hands on a backup – ask yourself what would happen if your site died! They should provide a location you can download the file from, either using FTP or as a web download.
Step 2 : Create local path on your test environment and copy in the files
When I create new DotNetNuke instances, I put them all in a single folder called \DotNetNuke\ on my machine. So I would create a new folder called \example.test to put my copy in.
Once this folder is created, then unzip all of the files from the backup of the website. Check to make sure they’ve gone into the right folder – \dotnetnuke\example.test\ and not \dotnetnuke\example.test\httpdocs or something like that. Some zip archives contain relative path information that will be replicated when extracted. Check this now.
Step 3 : Restore your Database
If your site uses a file-based database connection (ie, the database is in the /App_Data directory, and Sql Express connects directly) then you can skip this step.
For those with ‘proper’ Sql Server based databases, restore the database by going to Sql Server Management conolse, right-clicking on the ‘Databases’ node of your test server, and choosing ‘Restore Database’.
In the ‘To database’ field, type in the name of your test database – in this example I type in ‘example.test’ (using the name decided in Step 0)
Choose the ‘From Device’ option, and click on the … button, and locate your database backup file (from Step 1). Choose a ‘backup media’ type of ‘File’, and click on the ‘Add’ button to locate the actual backup file. Click OK when finished.
Make sure the ‘Restore’ button is ticked next to the listed database backup. There may be more than one backup in the file – take care to choose the right one.
You might also like to click on the ‘Options’ properties on the Sql Server restore dialog, and check the file paths for the restoration – these will probably default to the default Data location for your install – this is fine, but you may wish them to restore to a different location.
When it’s all ready, just click ‘OK’ to restore the database.
Step 4 : Prepare your database for local connections
Assuming Step 3 went OK, you will now have a valid database in your test server. But things aren’t ready yet. This is because the database contains security information from your live server, and things won’t work correctly until you set up a new user.
To do this, find your restored database in the list of databases on the test server (restored databases usually are on the bottom of the list), and expand the tree to find example.test->Security-Users. Right click on the ‘Users’ node, and select ‘New User…’.
Once the New User dialog comes up, type in the user name and login name. I generally use a login I have already created on the database server (I always use a generic ‘dnnAdmin’ user for all test sites).
At the bottom, under ‘Role Members’, scroll down until you find ‘db_owner’. Tick this option.
When the user is ready, click ‘OK’ to create.
Step 4.5: If you get an error creating a new user…
You may find that you receive an error called something like ‘User, Group or role ‘dnnAdmin’ already exsists in the current database’. If this is the case, you’re re-using a user that you’ve already created in the live system. No problem.
In this case, cancel out the New User dialog. Open up a new query window connected to your test database. Enter the following Sql Script:
EXEC sp_change_users_login 'Auto_Fix', 'dnnAdmin'
This bit of Sql will re-link your local ‘dnnAdmin’ account with the ‘dnnAdmin’ account from your live server.
Step 5: Test your Sql authentication out
This step is just about eliminating potential problems before you get further down the track. In your Sql Management Studio app, click the ‘New Query’ button to open a new query window. When the new query window opens, right click and choose ‘Connection – Change Connection…’.
This will open up the ‘Connect to Database Engine’ window. Select your Test server [TestServer01], choose ‘Sql Server Authentication’ and enter your login (ie, dnnAdmin)
Click connect, and it should connect OK. If it connects OK, select the correct databse (example.test) from the database drop-down, then write this piece of Sql:
select * from dbo.dnn_Users
(note I’m using the database owner and prefix that my live site uses).
If this executes OK and returns a list of users, you’re ready to move on. If you’ve got errors, you need to solve them before you move on. You must be able to at least get a simple query running using the same server/authentication type/authentication user/password before moving forwards. Sort any problems out before moving on!
Step 6 : Update your database with the new test domains
There are a few places in a DotNetNuke site where the portal alias (domain name) is saved within the DNN database. If you don’t fix these up, you’re going to have problems with your test site – either it flat out isn’t going to work, or you’re going to end up on your live site accidentally.
You just need to update these values now. With your Sql Query window open, run this Sql:
select * from dbo.dnn_PortalAlias
You should end up with something like this:
PortalAliasID PortalID HTTPAlias
1 0 www.example.com
3 0 example.com
You need to update these values. Do so with a bit of Update:
set HttpAlias = ‘www.example.test’
where POrtalAliasID = 1
set HttpAlias = ‘example.test’
where PortalAliasId= 3
Run this Sql, then run the select statement again, to check that the values updated correctly.
You may also need to update the Portal Settings, if you have marked one of the portal aliases as the canonical alias for the site.
Check this by running the following Sql:
Select * from dbo.dnn_PortalSettings
where SettingName = ‘DefaultPortalAlias’
You may get back a result like this:
PortalID SettingName SettingValue
0 DefaultPortalAlias www.example.com
You may also get more than one portal listing if there are multiple portals on the site. You can either fix them all, or just the particular portal you’re testing.
Fix the setting using this update Sql:
set SettingValue = ‘www.example.test’
where settingName = ‘DefaultPortalAlias’
and PortalId = 0
Run the select statement for the portal settings again, to check you have got this correctly set up. If it’s all setup correctly, time to move to the next step.
Step 7: Create the IIS website
Open your IIS Manager for the test server (in Windows 7 + 2008, you can just type in ‘IIS’ in the start->search box. This will bring up the start item.
When it opens, expand out the list of sites for the test server, and then right-click on ‘Sites’ and choose ‘Add Web Site…’ This will bring up the new website dialog box:
Enter the following values:
- site name : example.test
- physical path : d:\dotnetnuke\example.test
- host name : example.test
All these values are taken from Step 0.
When this is done, click ‘Ok’ to create the new website.
This should list the page for the new example.test site. Find the ‘bindings’ link on the right hand side, and click on that.
Add in any extra bindings that you might need – in my example, I’ve added example.test and www.example.test to reflect the two different domains that I will be setting up. Note that if your DotNetNuke install has more than one portal (and you wish to test out the various portals) you’ll need to enter any domains for the other portals here now.
Step 8 : Configure the Application Pool
Note that when you created a new site, you also created a new Application Pool with the same name. You can find this by going to the ‘Application Pools’ node of the IIS manager tree. You should see your new pool in the list. Select it and then click on ‘Basic Settings…’ in the right hand menu.
Here you must configure the Application Pool to be the same (or as close as possible) to your live server. In my case, I’m choosing .NET 4.0 as the framework, and running it in Integrated Mode. If you don’t know what these settings should be, you can ask whoever got your backup. If you got your own backup, log on to the live server and check. Running a 4.0 server in 2.0 isn’t going to work, and while you can upgrade a 2.0 to 4.0 – it kind of defeats the purpose of creating a test copy of your site. Get them the same.
Step 8 : Modify the web.config
Now you’ve got your site set up, your database set up, and you’re on the home straight. You just need to change the web.config file.
Go to the d:\dotnetnuke\example.test location, and open up the web.config file in a text editor.
Find the <connectionStrings> section, and locate the entry for DotNetNuke – then update the values for your test server, database, userid and pasword.
<add name="SiteSqlServer" connectionString="Data Source=TestServer01;Initial Catalog=example.test;User ID=dnnAdmin;Password=password" providerName="System.Data.SqlClient" />
Repeat this for the old ‘SiteSqlServer’ entry if you have it at the top of the <appSettings> section (this value is being phased out)
<add key="SiteSqlServer" value="Data Source=TestServer01;Initial Catalog=example.test;User ID=dnnAdmin;Password=password" />
Step 8.5 : Url Master settings
If you’re reading my blog, you might have the Url Master module installed. If you’ve got that installed, you might have configured it to control the portal aliases for your site. If this is the case, find the <friendlyUrl> section in the web.config file, and locate the <portals> entry for the particular portal. You may have an entry something like this:
<portal portalId="0" log404s="true" tabId404="625" usePortalAlias="0,www.example.com,,Normal," />
All you need to do here is update the portal alias to the new version:
<portal portalId="0" log404s="true" tabId404="625" usePortalAlias="0,www.example.test,,Normal," />
Save the web.config file
Step 9 : Check DNS settings
If you’re just using a subdomain for your test site (ie test.example.com) you can try pinging it (using the cmd window->Ping test.example.com) to see if it has been set up OK. If not, take it up with whomever configures your DNS.
If you’re just using a local ‘made up’ domain name (which is what I generally do) then you need to modify your HOSTS file to dummy in the entry – there is no such tld as ‘.test’, but you can use it locally.
To do this, open up a copy of Notepad : I recommend running it in ‘Administrator’ mode so that it has the authority to make the required changes (find notepad in the start menu, then right click and choose ‘Run as Administrator’).
Using the File->open, locate the HOSTS file, it’s in C:\windows\system32\drivers\etc – with notepad you’ll have to change the file filter to (*.* all files) to find it, as the HOSTS file has no extension.
In your hosts file, under any other entries, add this entry:
Repeat this for every domain you’re using with your test site. 127.0.0.1 is the ‘loopback’ address for your local machine. Of course, if you have configured a remote machine, just put the IP address of that machine in.
Save the HOSTS file and exit out of notepad. Time for the moment of truth.
Step 10 : Test out the site
Go to your Browser and enter http://www.example.test/ – fingers crossed, the site should start up and load OK. It will run slow as everything has to be initialised – this is a cold, cold start. Also, note that many modern browsers try and do tricky things like loading up the site it thinks you typed, or going to a search if it doesn’t immediately recognise the address – circumvent all this by requesting the fully qualified Url, or bypass the browser altogether and use something like Fiddler to request the site.
Hopefully now your site has loaded up in the browser and you can click around things. You’ve got your test site going, but there’s a few more recommendations I want to make.
Step 11 : Mark your test site clearly as a test site
One of the ‘gotchas’ is that you can silently go from your test site back to your live site just by following a hardcoded link, or something like that (blog posts in the Blog module, for example, use ‘permalinks’, so your test site will link to the links on your live site). You don’t want to be hacking around, silently transfer to your live site, and keep hacking things up. Bad, very bad. It’s entirely possible if you’ve logged onto both sites as an administrator – you won’t even notice the switch.
The way I like to do it is to either open up the skin file and deface it , by adding something like this:
<div style=”width:100%;height:20px;background-color:yellow;color:black;text-align:centre;”>THIS IS A TEST VERSION OF EXAMPLE.TEXT</div>
Or you can open up the logo file of the test site and deface it with a giant red “TEST” using an image editor. The idea is to make it very clear that you’re looking at the test site. If you swap to the live site, you should pick up straight away that the defacing has disappeared.
Above : my defaced logo for testing this site
Step 12 : Check any licensing
Some third party module vendors may have domain or IP based licensing schemes with their products. Hopefully the products will continue to work OK, just with ‘nag’ messages, but in some cases the modules will stop working altogether. You may have to contact the vendor to arrange a test licence if necessary.
Note : all iFinity licences allow for free test/development licences : you can add a test site to your licence any time by going to http://www.ifinity.com.au/Licensing and choosing the option to add a new domain. Or you can just leave the unlicensed messages showing – the modules will still work exactly the same as before.
Step 13 : Obfuscate any user data, particularly email address.
You may be doing some testing on the site which will interact with the copies of the user accounts in your site. In an age of DotNetNuke social sites, this is important, because many actions trigger emails. It’s entirely possible to create outgoing emails which a bewildered user will think is coming from the actual site.
The easiest way to obfuscate the data is to go into your Sql Management Studio, open up a new query window, and issue the following Sql:
set email = ‘firstname.lastname@example.org’
This will destroy the email addresses for all the registered users on your test site, preventing any of them from getting an actual username.
If there is sensitive user / financial / other information in the site, you may also wish to obfuscate / delete this data if unauthorised people will be given access to the test site.
Step 14: Take a backup (and a bow)
You’ve done it – created a test site. Now, to save yourself grief, take a backup of both the file system and the database now. This is especially important if you’re going to be testing ‘destructive’ things like new upgrades or code changes. You want to be able to roll back to the original state of your test site, when it matched the live site as closely as possible.
Hopefully this information is enough for the average DotNetNuke administrator to get their own test site copy working. Once you have done this, you’ll be able to perform upgrades, changes, test out new ideas and modules with much more confidence. If you’re into debugging the DNN Core, you can also download the source and open up your Visual Studio and debug your actual live site. These are all things that will assist the DNN administrator greatly – you can really get stuck into the core of the site and fiddle around if you know no permanent damage will result. If you get it all messed up – just restore your test backups and start again.