Part 2 - Restore Prod to Test (backup and restore)

If you are completely new to backup and restore you might want to review my rant here: http://paisleypoint.blogspot.com/2009/03/back-up-and-restore-repeatable-process.html

Part 2 - Restore Prod to Test – for data population Assumptions – there is an existing instance of a test server – that will get the prod content db written over it. Ensure you have the same updates and services packs as on the test server as were installed on the prod server. (Make sure you run the configuration updates after the service packs)
Preparation
If you have a website for the portal – use the central admin web ui to delete it – and any databases associated with it

1. Create a new web application
Central Admin -> Application Management -> Create or Extend Web Application -> Create a new Web Application DON’T forget the Host Header
Host header: Lab-Portal
Pool ID: spdev\!spFarmAcct
1.1 When you get to the database name, put in a temporary name such as WSS_Portal_DeleteMe. You will delete this database later.

2. Restore your prod content database (leave the existing shared services database). Don’t worry about the search database. You will have to recrawl your website anyway. --MAKE SURE THE DATABASE NAMES ARE EXACTLY THE SAME AS THEY WERE ORIGINALLY

If you get an error like so: SPException: Cannot attach database to Web application, you can use the Central Administration ui (or if you enjoy torture use the command line tool) to attach the database manually to the proper Web Application.

3. Next step is to remove the temp database from each web application and attach the real database you restored in step 2 --To do this Go to Central Administration -> Application Management -> Content Databases
3.1 Remove the temp db - Select the web application you would like to change. Select the database name (for example WSS_Portal_DeleteMe). Check the box in the next screen to remove content database. You should now see no database attached to the web application (it also remove it off the sql server).

4 Connect to the restored db - Select add a content database. For the database name put the name in EXACTLY as you restored it which should be EXACTLY like it originally was.

5. Don’t worry about the Search Server field since you have not started that service yet.
6. Start required services on new server. Go to Central Administration -> Operations -> Services on Server. Start the Windows SharePoint and Office SharePoint searches. Let it create a new database.
7. Recreate the SSP -Central Admin -> App Management -> Manage this farm's shared services (Click in the Shared Services link on the left!).
8. Select Create SSP – You can use the same name before SharedServices1 or change it. I would leave it so it matches the DB name) Make sure you select your SSPadmin and MySite web applications your created earlier and your restored database names. Do I have to mention again to make sure the names are exact!
9. Select the index server (it is now available since you started the service). You will get a warning stating you are changing the association of the existing web applications. Click OK.
10. Install Branding customizations
11. Open your SSP website and start a full crawl and user import. You should notice that all your SSP settings are still there.
12. Since you did not restore the Sharepoint_AdminContent database you will have recreate things like smtp server names. These are all easy things that can be found off the main Central Admin Page. You should even go through the steps they list and complete each one.You should now have a fully functioning SharePoint site on a new server with a new sql server.

Back up and restore -Repeatable Process

Note this is a rant - it has some good background info for those who are pretty green at Sharepoint Admin -BUT if you know already know your way around an stsadm script - or the central admin UI you can skip to the actual steps in the Step by Step instructions

OBVIOUSLY we know that it's not a good idea to do development on a production sharepoint server- but the sharepoint platform makes it a bit tricky to avoid the temptation, since it seems that is what the tool was intended to be used for, and since you never quite have the same stuff on dev that you have in prod, you just might succumb to such tempations. Here are MY reasons why you should NEVER do it...

After deploying a solution-you will need to do an IISReset -- be prepared to get a scathing email (with your boss cc'd) from that unix admin type who hates sharepoint becuase he JUST happened to hit the site during that 5 second period. Worse yet - what if you screwed something up? - Be prepared to get an email from everybody in the company saying - "I can't get to my documents - sharepoint is down" (as if you didn't already know you screwed yourself)

SO - that said, I set out to follow Joel's recommendations on WHAT to do from the following article: http://blogs.msdn.com/joelo/archive/2008/01/15/pilots-proof-of-concepts-test-and-pre-production-environments.aspx Where Joel says "Although you may not find many references to dev, test, staging, environments (in sharepoint development), these are critical to large deployments..." I couldn't agree more --HOWEVER I had to piece together my own version of HOW to do it. Here is what I came up with - complete with some of the sharepoint hate I experienced along the way - maybe I can shield some others of you from some of that pain...

On the Official Microsoft Technet site, there are some failry helpful instructions here:
http://technet.microsoft.com/en-us/library/cc262946.aspx
These are aimed at people actually doing recovery of content howvere - after something got lost (probably becuase they were doing dev on production). This is not exactly what I was after so I had to do some extrapolation to get it to serve my purposes...

Basically there were 2 very basic steps I wanted to follow:
1. backup the prod server
2. restore the prod server to a dev site

Couldn't be simpler right?
1. backup the prod server (BUT WHAT?)
If you look into sql server you will see several db's
--the config db (whichs stores all the enviroment specific stuff. So you DON'T want to copy that over because that is what you are trying to change)
-- the content db for The central admin (the the one with the long guid in it which you don't need - central admin is central admin)
-- the content db for the ssp(s) (I don't have alot configured in my ssp yet so I didn't need that especially since the dev server I am restoring to is on a different domain - I wanted to keep the configurations in my dev enviro and the dev user store)
-- The content db for the site collection(s) - That is the content I was after the actual data in the portal.

If you need help seeing what you have, go the the Central Admin -> Operations -> Perform a backup (under "Backup and Restore) this gives a nice visual of what there is to backup. From the first screen - you can look at it without actually doing any backing up yet.

So the three ways to do this are:
::backup the content db in the sqlmanagment studio (which is fine if you are a dba type - but "not so much" for me)
::backup using the stsadm command line tool (fine if you are a command line type -even better if you are trying to create a script to automate this - but again - not so much for me)
::backup using the Central Admin Web UI -(this is a great way if you want to walk through the steps as they are happening-unfortunatley the Central Admin UI makes it damn near impossible to do this without pulling you hair out for a week because as we know when you get errors, Sharepoint will send you on a wild goose chase tring to decipher what is going on (wrong) in the background, burrying any actual useful information in log files or behind the custom error - stack trace curtain. Here are some tips for better deciphearge -- http://furuknap.blogspot.com/2008/11/debugging-tips-for-sharepoint.html

Oh you thought that was it? No thats just the backup part - the restore part is equally fun
2. restore the prod server to a dev site
Once you have your precious backup files - then you will need to restore them and get sharepoint to make the adjustments to read the content from your dev server's point of view. Just wave the magic wand! Or if that doesn't work, try the following...

Again the three ways to do this are:
::restore the content db in the sqlmanagment studio
::restore using the stsadm command line tool
::restore using the Central Admin UI (guess which one I like?)

This post should probably be officially labeled a "RANT" so I decided to put the actual steps into a separate "step by step" post for use when actually performing the steps

Step by Step instructions

References for Backup and Restore

Man did this give me fits!
Until I have time to write out what I came up with
here are the articles I am referencing:

yea - this is what I want to do...
http://blogs.msdn.com/joelo/archive/2008/01/15/pilots-proof-of-concepts-test-and-pre-production-environments.aspx

but how????

I tried the command line - got errors:
backup
http://technet.microsoft.com/en-us/library/cc263441.aspx
restore
http://technet.microsoft.com/en-us/library/cc671617.aspx
How to Recover a Windows SharePoint Services Farm
http://technet.microsoft.com/en-us/library/bb795596.aspx
Back up a farm by using built-in tools (Office SharePoint Server 2007)
http://technet.microsoft.com/en-us/library/cc263298.aspx
Move content databases between instances of SQL Server (Windows SharePoint Services 3.0)
http://technet.microsoft.com/en-us/library/cc288554.aspx

I tried to use the backup and restore utils in sharepoint central admin
-got access denied errors
http://technet.microsoft.com/en-us/library/cc262946.aspx
http://www.windows-tech.info/15/b0dffeee963e602d.php



this is a good comprehensive one - but I did not like having to re run the config wizard
http://lkar.blogspot.com/2008/05/moving-moss-project-server-2007.html

this one is even better - step by step (simple) NOTE THE PART ABOUT NOT CHANGING THE DB NAME??? not sure if that is true
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_23185385.html#a21129547

this is a good one
http://office12.blogspot.com/2007/05/when-sharepoint-2007-restore-fails.html

at the end I was getting an error while restoring (after the restore - but during the attch to the website)-http://www.sharepoint-girl.com/2007/12/error-on-restoring-wsscontent-database.html

restore MOSS 2007 problem: IIS Web Site already in use by Sharepoint
http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/6f75daf7-1b84-43ed-a98c-280d5afc35b4/

others
http://www.eggheadcafe.com/software/aspnet/33771569/backup-and-restore-from-t.aspx

this one is backwards
http://blogs.msdn.com/priyo/archive/2008/01/14/move-moss-2007-from-test-to-production.aspx


this guy had fits too
http://wss.made4the.net/archive/2008/05/26/solution-development-in-sharepoint-2007.aspx

cool deployment tool - on codeplex
http://www.codeplex.com/SPDeploymentWizard

Configuring SharePoint (part 2)

>>Read previous article: Configuring SharePoint (part 1)

1. Log-in to the Central Admin (USE THE SETUP ACCOUNT that the configuration wizard ran as)
2. Give yourself and any other admins Farm Administrators rights to central admin and other farm resources: Central Admin -> Operations -> Update Farm Administrators Group
   
   Note: to avoid having specific users listed in the persmissions sections of SharePoint it would be a good idea to have a Domain Group to store all the folks who should have access to sharepoint, and specify that group here)

Configuring Sharepoint (part 1)

Wizard? Sounds easy right? What it doesn't say is there is a set of 10 or so choices which will greatly affect how things go, from here on out. So I suggest you take some time to plan your configuration, so you can get it right the first time.

1. Log into the server as the spsetup account
   (I might have said this already - but be sure you DO NOT run the wizard as yourself - Create a seaparate account to log in as when you run it)
   
   Required Permissions:
   a. on the sharepoint server(s) spetup must be a local admin
   b. on the sql server - if spsetup is not a local admin it must have a login in SQL with at least securityadmin and dbcreator roles (better if it's SA and best if it's a local admin)
   
2. Open the Cofiguration Wizard
   Start -> All Programs -> Microsoft Office SharePoint Server -> SharePoint Products and Technologies Configuration Wizard
   
3. Welcome screen, click "Next"
   
4. Warning box, click - "Yes" (it is explaining that you will be resetting IIS and some SharePoint services and asking if that is okay)
   
5. Connect to Server Farm - if this is not a farm or if this is the first server as part of a farm - then choose create new farm (if it is one of the others in the farm choose connect to existing)
   
6. Specify Configuration Database Settings
   :: Database Server: the server name of your SQL server (assumes it is on another server)
   :: Database Name: the Configuration Database name (you might want to put more info in the name so your test and prod db's are recognizable)
   :: Username/password: This account will need the following priveleges (strong pwd)
   - local admin on sql (or at least dbcreator - since it creates the config db)
   - local admin on the webserver (becomes the Apppool identity for the central admin website)
   
7. Completeing Screen - confirming the entries you made
   
8. The last screen allows you to specify the port for your Central Admin site (not your portal) It is a good idea to keep the port for Central Admin consitent in each enviro (for simplicity). I use 10101
   
9. The config wizard will then spin for quite some time - and will show you the progress it's making.

TROUBLESHOOTING:
If you get an error like this:

"failed to create the configuration database" - ensure that the account specified in "username/login" is either a local admin on the SQL box, or is an SA in SQL (or at least has dbcreator rights)

Upon completion the Central Administration website will open
>> Configuring Sharepoint (part 2)

This posting is provided "AS IS" with no warranties, and confers no rights.

Getting started with SharePoint: Learn to install the thing

Getting started with SharePoint:
The first step is to install sharepoint on the server

Since Sharepoint is a .net web app with a sql backend
you will need SQL and IIS with .net

Technet article with the step by step instructions for the first 2 steps below

1. Create a Server Virtual Machine
2. Install SharePoint (and prerequisites) on the Server
   2.1. IIS and .net 3.5 framework
   2.2. Install SharePoint (with SP1 - or whatever the most recent upgrade is)
   2.3. Set the Path Environment Variable (so you can use stsadm from anywhere)
   
   See how easy that was!
   Ah but now it gets interesting...
   Once the software is installed, you need to run the configuration wizard
   
   PREPARE to configure
   It is important to take time to prepare for configuration as you will quickly become overwhelmed by the number of crucial decisions you will have to make when stepping through the wizard. These are things that will constantly affect you going forward so be ready to make each choice with confidence.
   
3. Create the Service Accounts in AD for least privilege administration
   
   Technet article about this subject
   
   For least privilege administration each Service in Sharepoint "SHOULD" be run as it's own account. If you plan to follow this "Best Practice" in production, you SHOULD do it in dev as well because it's tricky to set this up.
   
   You will need several service accounts.
   
   :: SharePoint Server Setup Account (acct to run the configuration wizard as DO NOT RUN CONFIGURATION AS YOURSELF!)
   :: SQL Server Account (SQL_Service)
   :: Farm Database Access Account (Cent Admin)
   :: Shared Service Provider (SSP1_svc) You will need one for each SSP
   :: Office SharePoint Server Search (Search_svc)
   :: Default Content Access Account (SSP1ContentAccess_svc) one for each SSP
   :: Content Access Account (Portal_Content_svc) one for each site collection
   :: Windows SharePoint Services Search Account (WSSSearch_Service) -None if MOSS
   :: Application Pool Process Account (PortalAppPool_svc) one for each webapp
   
4. Create DNS Alias' (CNames)
   :: One for the portal Host Header (possibly for each Site Collection as well)
   :: One for MySite Host Header
   
5. Run Config wizard
   Did I mention DO NOT RUN the config wiz AS YOURSELF?
   A whole post in itself! >> Configuring SharePoint (part1)
   
   After the config wiz runs, Central Admin will open with a list of tasks
   
6. Step through the Config instructions from Central Admin (Tasks)
   >> Configuring SharePoint (part2)
   
   Follow the steps in the "quick start guide" (found in central admin after config wiz runs)
   
   6.1. Update Farm Adminstrators Group
   
   Configure services
   6.2. Configure the SharePoint Server 2007 Search Service
   6.3 Configure the Shared Services Provider
   6.4. Create the SSP Website
   6.5. Create the MySites Website
   6.6 Finish creating the SSP Service
   6.7. Add the spadmins and spadmins dev groups to the ssp site permissions
   6.8 Configure indexing
   6.9 Configure default content access account
   6.10. Manage content sources
   6.11. Manage Permissions for MySites Settings:
   6.12. Alternate Access Mappings
   6.13. Configure the User Profile StorE
   6.14. Start and configure Excel Calculation
   6.15. Create alternate access mappings
   6.16. Configure incoming e-mail settings
   6.17. Configure outgoing e-mail settings (SMTP) pointing to the NA exchange server
   6.18. Configure diagnostic logging
   6.19. Configure antivirus protection settings
   
7. Create the Portal
   7.1. Create the Web Application
   7.2. Create the Site Collection
   
8. Grant Access to Admins and Developers
   8.1. Accounts to Use
   8.1.1. spadmin - Virtual domain account with email - for managing the portal
   8.1.2. Actual domain account for the person responsible for the installation
   8.1.3. Actual domain account of the person responsible for the Content
   8.1.4. Actual domain account for the person responsible for development
   8.1.5. spadmins group (spadmin, install admin and content admin)
   8.1.6. spadminsdev group (spadmins + developer)
   8.2. The Servers
   8.2.1. Sharepoint server
   8.2.2. Sql Server
   8.2.3. Client
   8.3. Permissions
   8.3.1. SharePoint server (in computer management)
   8.3.2. The SQL server
   8.3.3. On the Portal
   8.3.4. In Central Admin
   8.3.5. Permissions on the SSP Site
   8.3.6. Permissions on the “MySites SiteCollection”
   8.3.7. Matrix for Setting up Security according to Environment
   
9. Backup and Restore
   9.1. Techniques
   9.2. Permissions

This posting is provided "AS IS" with no warranties, and confers no rights.

Here we go - Creating a blog was much easier than I thought it would be

Stay tuned for a multi part series on installing and configuring SharePoint for the least privilege possible. Then another on how to set up a dev, prod environment and create features to deploy V1 of your site. Can't wait to get this stuff out there!


This posting is provided "AS IS" with no warranties, and confers no rights.