SharePoint 4.0: Attach Content Database to Web Application

An especially important administrative capability for disaster recovery, upgrading from SharePoint 3.0, and general administration of Web applications is the ability to attach a content database to a Web application.

Here are the steps:

1. Attach the content datbase to the SQL Server instance. If moving a content database in from a different farm, then this may require doing a SQL Server database restore. Be sure that the MDF and LDF files are created in a location which is consistent with your other content datbases.

2. Open PowerShell. With the security context of an administrator account having shell access, open PowerShell on a SharePoint 2010 server.
Start > Administrative Tools > SharePoint 2010 Management Shell

3. Test the content database.
Type the following command:
Test-SPContentDatabase -Name %ContentDbName% -WebApplication %WebApplicationName%

4. Attach the content database to SharePoint Web Application.
Type the following command:
Mount-SPContentDatabase -Name %ContentDbName% -WebApplication %WebApplicationName%

5. Verify the attached content database. Navigate to SharePoint Central Administration > Application Management > Manage Content Databases. Verify the database name, database status, and current number of site collections. If necessary, adjust the Site Collection Level Warning and Maximum Number of Site Collections settings appropriately.


Reference

Microsoft Technet (2010). Add a content database (SharePoint Server 2010). Retrieved June 2, 2010, from http://technet.microsoft.com/en-us/library/cc825314.aspx.

SharePoint V2: Error: Upgrade Pre-Scan Error, Orphaned Site

Description:

During preparation for an upgrade to Microsoft Office SharePoint Server 2007, after running prescan.exe on a SharePoint Portal Server 2003 environment, the pre-upgrade report lists an error such as the one below.

06/04/2007 16:26:59 Error: Cannot get content database Id for SPSite: http://servername/sites/sitename
06/04/2007 16:26:59 Microsoft.SharePoint.SPException: There is no Web named "/sites/sitename". ---> System.Runtime.InteropServices.COMException (0x81070504): There is no Web named "/sites/sitename". at Microsoft.SharePoint.Library.SPRequestInternalClass.OpenSite(String bstrUrl, Boolean bGetUrlOnly, String& pbstrServerRelativeUrl, Guid& pgSiteId, Int32& pOwnerID, Int32& pSecondaryContactID, DateTime& pdtLastContentChange, DateTime& pdtLastSecurityChange) at Microsoft.SharePoint.Library.a.a(String A_0, Boolean A_1, String& A_2, Guid& A_3, Int32& A_4, Int32& A_5, DateTime& A_6, DateTime& A_7) --- End of inner exception stack trace --- at Microsoft.SharePoint.Library.a.a(String A_0, Boolean A_1, String& A_2, Guid& A_3, Int32& A_4, Int32& A_5, DateTime& A_6, DateTime& A_7) at Microsoft.SharePoint.SPSite.c() at Microsoft.SharePoint.SPSite.get_ID() at Microsoft.SharePoint.PreupgradeReport.Scan.GetContentDBBySite(SPSite site, SPVirtualServer vs)

Solution:

Windows SharePoint Services 2.0 and SharePoint Portal Server 2003 each have their own approach to cleaning up orphaned records. The KB articles below provide information on related hotfixes and explain how to use command line utilities to clean up corrupted databases.

Windows SharePoint Services 2.0
http://support.microsoft.com/kb/924881
http://support.microsoft.com/kb/918744
From: \program files\common files\microsoft shared\web server extensions\60\bin
To Detect: stsadm -o databaserepair -url http://ServerName -databasename DatabaseName
To Repair: stsadm -o databaserepair -url http://ServerName -databasename DatabaseName -deletecorruption

SharePoint Portal Server 2003
http://support.microsoft.com/kb/919175
http://support.microsoft.com/kb/918742
From: \programfiles\Sharepoint Portal Server\Bin
To Repair: spsadm repairorphans http://ServerName

Upgrading to Sharepoint V3: The "Other" Option

Microsoft offers four options for upgrading SharePoint V2 to SharePoint V3. These approaches describe how to take your V2 Portal or Site Collections and upgrade the underlying software to V3.

In-Place Upgrade
Gradual Upgrade
Gradual upgrade for Shared Services
Content Database Migration

To view detailed comparison of these options, visit Microsoft TechNet's Determine upgrade approach [Office SharePoint Server].
http://technet2.microsoft.com/Office/en-us/library/f11e6c4f-dc2a-4d17-a2c8-9455792b4b9b1033.mspx

I want to also introduce another option. In fact I like to refer to it as the "other upgrade option." The way I describe this is that you install a fresh V3 portal and you recreate manually, then migrate data and content. This allows you an opportunity to first re-think the design of each part of the new portal, instead of automatically inheriting the limited configurations that you have in V2.

In some cases, I think that running an upgrade can be a mistake. As you know, performing a software upgrade to V3 doesn't automatically result in a robust V3 environment that suddenly fulfills all of your needs and desires...it just puts your same old portal on new software that happens to be capable of doing more. You still have to due necessary diligence to figure out how you are going to leverage the new functionality to meet business needs. This is a manual process. There are no short cuts. And, in some cases, by upgrading content from V3 to V7 you are actually creating more work for yourself.

Implementing new portal technology is kind of like traveling from point A to point B. Point A represents the portal concept and design that you arrive at after you analyze the business requirements, draw scribbles on the whiteboard, and have some meaningful discussions about the portal you are going to build.

A (idea) -----> B (reality)

Point B is reality. It is the end product; an actual, tangible Sharepoint 2007 environment configured the best possible way to resemble your concept.

And, the V2 portal is simply an outdated Point B.

Consider too, that the business requirements that drove the V2 portal probably have become more complex. V2 users may be wanting more sophisticated functionality by now. If time and budgets allow, don't automatically assume the limitations of a V2 portal when the subject of Sharepoint V3 comes up. Implementing V3 may be a great opportunity to re-engineer the portal solution and selecting the "other" upgrade option of redefining and creating your V3 portal from your ideas instead of from your V2 portal may result in a better solution.