When creating new content-centric Web sites using something like ASP.NET, developers usually follow a set lifecycle. I’ve been involved in my share of content-centric sites using tools like Microsoft Content Management Server 2002 and Office SharePoint Server 2007 Web Content Management . The process is pretty easy getting a site off the ground:
Figure AA
We first create a basic site with the core templates, just enough to enter some dummy content in. We need this for things like content rollups and the like. We then continue building out the site. Finally we reach a point where our site is created enough to where the content owners can start loading content into the site (or we migrate content from an existing site).
Ultimately we’ll take the development codebase and deploy it to production and migrate all the content (or as many of us do, just deploy the development site to production).
The Challenge
The next thing that comes up is when you want to keep doing development. We all would want to develop against the production system in order to work with real world content. With an ASP.NET 2.0 site, this isn’t too hard as it usually means you are just backing up and restoring a SQL Server database.
However when you toss Office SharePoint Server 2007 into the mix, you quickly find this isn’t the most intuitive task. I get a lot of questions about how you’re supposed to do this. Suffice to say, where are a few ways to skin this cat, but I’ve got a way that works for me and is pretty simple. There are few manual tasks, but most of this could be scripted to automate it.
This article will explain how you can do this. I’ll be using my company’s site, Critical Path Training which is a Office SharePoint Server 2007 Web Content Management site as my sample in this process.
Overview of the Process
Before diving into the details, let’s look at the high level steps.
Figure BB
First step is to get a copy of the site from production and restore it into development. Once that’s complete, you then need to create the local development SharePoint site(s). With the site created, you need to deploy all your custom code and files to the development site, so development will not only have the same content, but same code as production. Next, you need to associate the restored production databases with the new development site. Finally, depending on your implementation, you need to do any last minute cleanup (I’ll explain this more later).
Moving Databases
The biggest piece of this whole process is the goal of getting the production site restored into your development environment. To do this you need to get a copy of your content database from production and restore it into your development environment. Once that’s done, after the sites are created and custom code redeployed, you’ll associate it with the development site. I guess you could punt this step (restoring DBs) down a little bit when you deal with the content DBs later, but I like doing this up front so I don’t have to jump between systems.
Backup Production Content Databases
Pretty straightforward here… just go backup the database using the standard SQL Server backup tools in SQL Server Management Studio.
Restore Production Content Databases in Development Environment
Next, take the backed up databases and restore them into your development environment.
With the database restored, now go and grant the following SQL users DBO rights to the restored database:
- The account you use as your SQL Serve farm administrator
- The account configured as the identity of the application pool that you’ll use for the development site
- The account configured as the search crawl account (if you’re leveraging SharePoint search in your site)
For me I also have a FBA database for my site members so I had to restore that and grant the identity of the app pool the necessary rights into it.
Create Development Site
Now its time to create site that will host the restored site collection.
Set up DNS/Host Entries
Some like DNS entries, others like host entries and some don’t mind port numbers in their domains. For development, I hate ports and go with the old tried and true HOSTS file. Open the c:\Windows\System32\drivers\etc\HOSTS file. For me, my site has two Web applications: one the world uses (that’s anonymous) and one we use for authoring content (NTLM only). Here’s what I put in my site (note the last bit on the domain… always like making it obvious they are the local dev site and not production):
127.0.0.1 private.criticalpathtraining.comdev
127.0.0.1 www.criticalpathtraining.comdev
Create Web Application(s)
Now venture into Central Administration and create the Web application(s). I first create the one that will be used for the authoring site using these settings:
Figure CC
The only other points to make here is to ensure you pick the right app pool (the one that uses the identity that you granted DBO rights to your restored content database) and the name of your database Central Admin will create. You don’t need this content DB… in fact we’ll delete it in a moment. I usually name this WSS_Content_Garbage.
When prompted, skip the step to create a new site collection. No need… we’ve already got one and it’s very nice!
For me, I then create a 2nd Web app that extends this one that uses the other host name (www.*).
Deploy Custom Code and Files to Development
I’m sure you’ve got at least some custom code in your site. So before you go further, add all WSP’s to the farm’s solution store and deploy them to the new site. This will do all the web.config updates.
Didn’t use WSP’s? SHAME ON YOU! Here’s yet another classic reason why you should have!
Associate Restored Production DB’s with New Development Site(s)
Now where the magic happens… time to do the old switch-a-roo! You are first going to remove the content database from the Web application you created as the dev site and replace it with the one you restored from production:
From Central Administration, select Application Management > Content Databases.
Switch to the Web app you created for the dev site (
private.criticalpathtraining.comdevfor me).
Figure DD
Select the only content database in use and remove it from the Web app.
Now select Add a content database and enter the name of the database you restored (WSS_Content_CriticalPathTraining in my case). Leave all options as the default.
If you get an error here, it’s likely you didn’t grant the necessary logins access. See the previous section above about restoring the database.
That’s it! Your site is now restored in development!
Fix-up Site Collection Owner
Now I bet your production and development sites are in different domains. Mine are so I always need to change the site collection owner so I can get back in.
- From Central Administration, select Application Management > Site collection administrators.
- Switch to the site collection you created for the dev site (
private.criticalpathtraining.comdevfor me). - Change the primary administrator to an account on your dev machine.
Additional Site-Specific Cleanup
At this point you’re good to go. You might have some additional stuff you need to set up. For instance a custom FBA set up, like we use for site members, or configuration info with the BDC or links to other external systems.
Re-establishing FBA
We use standard the OOTB ASP.NET membership stuff and FBA for our public site for people to sign in and get protected content. When replicating the development environment, I need to do the following steps after everything above is complete:
- Restore the FBA database from a backup taken from production.
- Add the connection string, membership and role providers to the web.config files of both Web applications & Central Administration (with the extra little default role provider fixup).
- From within Central Administration, configure the Web application membership & role providers from within Central Administration.
Conclusion
That’s it! At this point you should have a restored production site in development. You’ll likely have a few permission issues popping up here and there… I find I need to disable anonymous access and re-establish it at times. Most issues can be rooted in the fact that content was created and managed by identities in a different AD than you’re in down in your development environment. Nothing major… just a hassle.