Archive
Monthly
Go
|
|
DNN Blog
Feb
7
Posted by:
Erik van Ballegoij
2/7/2007 9:25 PM
A lot of posts in the Install It! forum are from people wonder how to move their DNN installation from their development environment to production. In a nutshell, this is the process:
- in your dev environment add a new http alias for the production environment. You can do this in Admin > Site Settings, but only when logged on as host. For instance, if your dev site runs under http://localhost/dotnetnuke, and your production site will run under http://www.mydomain.com, you should add www.mydomain.com as http alias. Why is this important? Always, when DNN receives the first page request, a lookup against the defined portal aliases is done. If the hostname that is used to request pages from DNN is not found in the list of portal aliases, DNN will redirect to the first available portal alias of the first portal. Quite often this will be your dev environment. A common mistake is to not add the portal alias, and thus be redirected to your devsite when browsing to your production site for the first time
- Move your database to the production database server. There are a couple of ways of doing this. You can do a backup of your dev DB, and restore it (or have your provider restore it) on your production db server. The problem i have with this approach is twofold: if the db collation of the production server is different than the collation of your dev db server, you could get into troubles when using modules that use temporary tables. The collation of TempDB is always the same as the server collation, while the collation of the database is copied over from the dev db during the restore. The other problem you might run into with this approach is the fact that although usernames might match on both servers, in reality they are not the same. The security id (SID) will be different, so you will not be able to use the same user, and also, you will have an orphaned user in your production database.
Alternatively, you can simply detach your db from your dev sql server and attach it to the production server. This might also cause issues with collation and user id's.
The method i like myself is a bit more expensive: database comparison, but works very good. I almost always use the tools from Red-Gate, SQL Compare and SQL Data Compare. These tools automate the comparison between to databases to a very high degree. A great plus of these tools is that you can use them to keep your development database and your production database in sync as well. Just run Data Compare, and the contents of the 2 db's will be the same again.
- Move all the files in your dnn application folder to the production folder. This can be done by ftp or any other method you use to copy files.
- Make the appropriate changes to web.config. At the very least you should change the sql connection string, to have dnn look at your production db
- Browse to your production site... done
I found a couple third party blog posts about moving DNN and moving databases:
Please, no questions / discussion in comments to this blog. I am going to maintain a FAQ about this in the forums, if you have any further questions, please ask them in the Install It! forums, i will pick them up there and answer in the Faq post.
21 comment(s) so far...
Re: HOW TO: Move a DotNetNuke installation
Thank you for writing this blog entry, it will be very helpful to many people.
I wonder if these articles by Scott Guthrie can be applied to moving DNN databases??
Recipe: Deploying a SQL Database to a Remote Hosting Environment (Part 1), at http://weblogs.asp.net/scottgu/archive/2006/12/22/recipe-deploying-a-sql-database-to-a-remote-hosting-environment-part-1.aspx
and / or
Tip/Trick: How to upload a .SQL file to a Hoster and Execute it to Deploy a SQL Database at
http://weblogs.asp.net/scottgu/archive/2007/01/11/tip-trick-how-to-upload-a-sql-file-to-a-hoster-and-execute-it-to-deploy-a-sql-database.aspx
They make use of something called the Database Publishing Wizard at
http://www.codeplex.com/sqlhost/Wiki/View.aspx?title=Database%20Publishing%20Wizard
More comments and suggestions would be much appreciated.
Thank you, Tom
By tlyczko on
2/8/2007 12:53 AM
|
Re: HOW TO: Move a DotNetNuke installation
I forgot to ask, What is one is developing on an XP box and deploying to an IIS shared hosting situaiton??
What is one is using SQL Server Express rather than SQL 2005??
How should one set up things and proceed??
Thank you, Tom
By tlyczko on
2/8/2007 12:59 AM
|
Re: HOW TO: Move a DotNetNuke installation
Good stuff, but how does one move a single portal from a DNN database to another, especially when the portal ID has to change, and you don't want to lose any portal content in the database?
By Rask on
2/8/2007 1:50 AM
|
Re: HOW TO: Move a DotNetNuke installation
Rask, if you're trying to move to a new instance, follow Erik's post and remove all the other portals. If you need to move from one instance, to another existing instance, you better hope all the modules you used support export/import, then you can export your portal as a template w/content. Otherwise you'll have to do a lot of manual configuration and data entry.
By christoc on
2/8/2007 2:42 AM
|
Re: HOW TO: Move a DotNetNuke installation
Erik, I think the SID whould only be a problem if you are using windows authtenication. Most people use SQL auth. and then the SID shouldn't be a problem...?
Timo Breumelhof
By messmail on
2/8/2007 10:46 AM
|
Re: HOW TO: Move a DotNetNuke installation
Timo: no, when you use SQL authentication, SQL server also uses its internal security id's. See my previous blog about moving databases between servers. You'd need a way to synch users exactly between servers.
By ErikVB on
2/8/2007 10:59 AM
|
Re: HOW TO: Move a DotNetNuke installation
You might want to mention another method to move the acual db: Detaching and re-attaching it on the production server. Very simple and straightforward.
By proeder on
2/8/2007 2:15 PM
|
Re: HOW TO: Move a DotNetNuke installation
This article seems to address the issue of moving your uncompiled code to your front end web server (including all .vb files). From a security standpoint, this is an unwise practice. It opens the door wide for a hacker to exploit. I have yet to find any way to compile and successfully deploy your 4.x version of the portal (tried everything from creating setup projects to site publishing). Everyone says just "Copy" your development files, but that is not the answer. There has to be a way to secure the base code, in a compiled fashion. There are several posts on the forum (including mine), but no one seems to have a clue about how to deal with the problem or offer any possible solutons (at least who have spoken up). The 3.x version did this seamlessly and with no difficulty. It would be great for someone from the core team to address this and provide some direction.
By mtndwell on
2/12/2007 9:14 PM
|
Re: HOW TO: Move a DotNetNuke installation
Hi mtndwell
I must say, I agree wholeheartedly!! Being one of the most important steps in deploying not just DotNetNuke, but any website for that matter, I am highly suprised not being able to find any information regarding the deployment of a source version of a 4.x DotNetNuke solution. With DotNetNuke 3.x it use to be a breeze using Nant, but we have been struggling................. to get a source version of DNN 4.0 compiled and deployed without any hiccups
If someone could shed some light on this, please do. It seems to be an obvious issue not addressed in plain English..anywhere.
By raldo on
2/15/2007 1:01 PM
|
Re: HOW TO: Move a DotNetNuke installation
To move a SQL DB from development to the production server, it seems like one should create the database, no tables, etc., and just at least one login to it, then follow this procedure.
This whole explanation leaves out how to manage users and logins and connection strings between the two different servers, dev and production.
Is this correct??
Thank you, Tom
By tlyczko on
2/20/2007 9:23 PM
|
Re: HOW TO: Move a DotNetNuke installation
Yes Raldo,
I have tried these instructions - using the (very good) Red Gate tools - and you will end up creating a DB on the target host with exactly the login issues that are ascribed to the more typical, and far less laborious, 'basic DB restore' at the target host.
Using the machine keys from the source host up at the target host's web config doesn't help.
This needs to be sorted before using DNN in any kind of commercial context. I think the benefit of the SQL Compare approach is that you can leave these key security fields untouched in the target DB.
I'll let you know if I have any success with this.
HTH-
Pat.
By Pat Cusack on
2/25/2007 6:39 AM
|
Re: HOW TO: Move a DotNetNuke installation
Here's how to fix the HOST password after moving your DNN DB into a new host environment:
Register as a new 'regular' User and use a unique email address like password_change@mail.com to make this account visible in the subsequent steps.
Use the View dbo.vw_aspnet_MembershipUsers to find your HOST login's UserName (hopefully known!) Change the PasswordFormat from 2 (encrypted) to 0 (plain text).
Then go to the dbo.aspnet_Membership table and look for the only row with a '0' password format. This will be your old HOST login.
Change the PasswordFormat field's value back to '2' and copy the Password and PasswordSalt values from your new known (by password_change@ email address) user login.
Login using the new user's password for your old HOST account.
Now you can update all the Aliases for your new portals in the target environment and see if the passwords for those still work . Joy.
HTH-
Pat
By Pat Cusack on
2/25/2007 9:02 AM
|
Re: HOW TO: Move a DotNetNuke installation
Pat.. the issue you describe can indeed be solved by making sure you have the same web config on the target machine as on the source machine. If you forgot to copy the machine keys prior to firing up DNN, you might have been caught by the Caching Beast. Did you try recycling the app pool on the target machine after you changed the machine keys?
By ErikVB on
2/26/2007 8:53 PM
|
Re: HOW TO: Move a DotNetNuke installation
Could someone please post about the machine keys, what are they, how to make sure this is working properly on the production server??
Thank you, Tom
By tlyczko on
3/7/2007 2:39 AM
|
Re: HOW TO: Move a DotNetNuke installation
thanks tom
By prasoon on
3/14/2007 3:48 PM
|
Re: HOW TO: Move a DotNetNuke installation
This article, its subject matter and the very fact that any of us are talking about it @ release 4.X , illustrates the biggest weakness of DNN: namely its design is HOBBY-LIKE rather than commercial and it clearly lacks any form of an engineered approach. I'd hoped that using the DNN effort rather than the HOBBY-LIKE PHP stuff would give me the advantage of professional admin and workflow for woring with a CMS, but not! way not!
Here is what needs to happen quick, the longer we wait the worse it will get, till this thing suffers the fate of ISPYBUY
REVAMP the use of the DB and make it completely MS_SQL .net X like, meaning providers, drivers, configuration and so on, now more (this is the way dnn does it stuff)
REVAMP the notion of IDENTITY and TABLE to Object Abastraction so the thing is not an island and can be backed up and moved at a commercial level.
This could be accomplished in part by creating a WEB MIGRATION or PUBLICATION module that consists of a services that is brought up on the target and is controled by the source. The service can play the role of the ADMIN and make appropriate UID changes as it copies content
By TheBadEye on
4/9/2007 8:34 AM
|
Re: HOW TO: Move a DotNetNuke installation
What happens in a situation (say) when I'm upgrading from 4.3.7 to 4.5.0. Let's say I use the Red-Gate approach. Let's say I want to minimise downtime. I would:
1) Copy database/files from live server to local environment.
2) Upgrade locally, make sure everything is working.
3) Copy database/files to live environment, syncing up the database using red-gate products as a tool.
Do I need to buy both their products for this (SQL Compare/SQL Data Compare) or can I get away with one using this method, if so which redgate product do I use? Traditionally I've instructed the hosting provider to detach/attach/copy databases and brought sites down for periods of time whilst this has happened.
I'm looking for the very best upgrade solution..
This appears to be a very useful post/thread - thanks.
By NukeAlexS on
4/9/2007 8:35 AM
|
Re: HOW TO: Move a DotNetNuke installation
@Alex,
Not sure what you mean here. If it's just upgrading, you are not moving your db at all are you? In general: if you are looking for a tool that allows you to keep local and remote copies of your db in sync, then you'd need both SQL Compare and SQL data compare. The first just sync's data structure, the second syncs data. From all the tools I've used, the Red-Gate tools are by far the easiest to use. It comes with a price though....
By ErikVB on
4/9/2007 8:39 AM
|
Re: HOW TO: Move a DotNetNuke installation
Good information. Thanks.
By vdung on
6/12/2007 8:11 PM
|
Re: HOW TO: Move a DotNetNuke installation
If you forget step 1 (http alias), you can also fix this in the database by changing the property HostURL in table HostSettings and also all the HTTPAlias fields in table PortalAlias. I hope i did not forget a table...
By gverbake on
7/25/2007 9:32 PM
|
Re: HOW TO: Move a DotNetNuke installation
I have a guide about this as well!
http://www.mitchelsellers.com/Blogs/tabid/54/articleType/ArticleView/articleId/204/Default.aspx
By mitchel.sellers@gmail.com on
6/26/2008 8:41 AM
|
|