It’s actually quite simple to get the answer:

1. Open SQL Server Management Studio (SSMS).
2. Click on the “New Query” button to open a new query window.
3. Enter the following query and click on “Execute”:

PRINT @@VERSION

You should see a query result similar to the following:

Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64)
Apr 2 2010 15:48:46
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)

You have an old SharePoint 2010 site and you need to copy its content to another SharePoint farm.  The site is heavily customized and moving it using traditional methods (backup/restore, export/import, save site as a template) are not going to work well.  Plus you only want content – no need to bring in all of that custom branding baggage.

You can copy the content using PowerShell and two scripts shown below.

Script # 1:   Export all lists and libraries from the source site.

add-pssnapin microsoft.sharepoint.powershell

# specify the site URL to export

$web = Get-SPWeb "http://sharepointURL/sites/site1/web1"

# specify output folder to store exported lists

$path = "c:\admin\export\"

foreach($list in $web.lists)

{

"Exporting " + $list.RootFolder.URL

export-spweb $web.URL -ItemUrl $list.RootFolder.URL -IncludeUserSecurity -IncludeVersions All -path ($path + $list + ".cmp") -nologfile

}

The output of this script should be a number of CMP files in the output directory.  Review these files and remove the lists that should not be imported (such as various Gallery lists).

Script # 2:  Import CMP files into the destination site.

add-pssnapin microsoft.sharepoint.powershell

# specify target SharePoint site to import into

$site = "http://sharepoint/sites/test1"

# specify folder containing exported lists

$folder = "C:\Admin\Import\"

$Files = Get-ChildItem $folder

foreach ($file in $files)
{

$name = $file.Name

"Importing: " + "$folder$name"

import-spweb $site -path ("$folder$name") -includeusersecurity -nologfile

}

http://blogs.msdn.com/b/jjameson/archive/2011/02/28/powershell-script-to-configure-search-in-sharepoint-server-2010.aspx

I was even able to use it to configure search on a SharePoint 2010 server which was not joined to the domain (as sometimes is required for DMZ deployments).  It worked beautifully using local computer accounts.   There is a change that needs to be made to the script if you’re using local accounts:

Add ShareName and Index arguments as shown below.

$queryComponent = New-SPEnterpriseSearchQueryComponent -QueryTopology $queryTopology -IndexPartition $indexPartition -SearchServiceInstance $queryInstance -Debug:$false -ShareName  <SHARENAME>  -IndexLocation <INDEXLOCATION>

http://blogs.msdn.com/b/jjameson/archive/2011/02/28/powershell-script-to-configure-search-in-sharepoint-server-2010.aspx

I was even able to use it to configure search on a SharePoint 2010 server which was not joined to the domain (as sometimes is required for DMZ deployments).  It worked beautifully using local computer accounts.

You have a claims-based web application (let’s call it https://mywebapp.com) running on SharePoint Server 2010. You’ve set up the Search Service application and it’s crawling your content without issues. Your shared search scopes are working great (search All Sites, search All People), but the contextual search scopes (search This Site or search This List) are returning no results. How do we fix this?

Solution:

Step 1. Extend web app to an NTLM auth site. (If you’ve already extended your web app to NTLM, skip to Step 2.)

As you probably already know, SharePoint 2010 cannot crawl claims-based web applications directly. So the first thing to do is to extend https://mywebapp.com application to another IIS site which uses only NTLM authentication.

Navigate to Central Administration > Application Management > Manage web applications

Select your web application > click on Extend button in the ribbon. Fill out the “Extend web application” form and make sure that for Claims Authentication Types you only select “Enable Windows Authentication” and check “Integrated Windows Authentication” NTLM checkbox.

All other fields can be left with their default values. Make sure to take note of the Public URL, it will look something like this:

http://myservername:43374

Step 2. Modify Search Service app content sources to crawl the NTLM site.

In Central Admin, open Application Management > Manage service applications > click on your Search Service application. Click on Content Sources and edit your content source to crawl the NTLM site you just created (http://myservername:43374).

Step 3. Add Server mapping (This is important!)

Within your Search Service Application, click on “Server Name Mappings” and creating a mapping between your NTLM site and the public URL.

Address in index: http://myservername:43374

Address in search results: https://mywebapp.com

Note: Some blog posts online will skip the server name mapping step and instead tell you to change your Default Alternate Access Mapping to point to http://myservername:43374. While it may work in some cases, there are times when you cannot (or should not) change your Default AAM. The server name mapping in SSA helps you avoid changing the AAM.

Step 4. Indexing.

Finally, in your Search Service Application, reset the index and perform a full crawl. Review the crawl log and make sure that there are no top level errors.

You need to remove a webpart from a SharePoint page in your farm.   Easy, right?  Go to the page, enter the Edit mode, click on the webpart, select Delete.  No problem!   Now what if you had 1000 sites to remove the webpart from?   Doing it by hand is impractical, so we’ll need to use Powershell.

This will be a two step process:

Step 1, you need to run an inventory script which will generate a list of webparts and their GUIDs.

Step 2, you will use the webpart GUIDs from step 1 to run a removal script to remove the webparts.

STEP 1. INVENTORY SCRIPT

Execute the script below using the SharePoint 2010 Management Shell (PowerShell console).  This script does the following:

1. Iterate through all web applications in the farm and open every every site collection in each web app

2. For each site collection, access the homepage  “default.aspx” and capture a list of webparts on the page and their GUIDs.

3. Write the results to a file called “results.txt”, located in the same directory as the Powershell script.

The page name “default.aspx” is hard-coded in the script but can be easily changed to another page name or page path.

Script source code

[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") | out-null

$oContentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;

[Microsoft.SharePoint.Administration.SPWebApplicationCollection]$waColl = $oContentService.WebApplications;

$log = ".\results.txt"    # output file name and path
$pagepath = "/default.aspx"    # change page name or page path here

"Site URL; WebPart Title ; Webpart ID" | out-file $log

$waColl1 = $waColl | where-object {$_.IsAdministrationWebApplication -eq $FALSE}

foreach ($wa in $waColl1)
{

foreach ($obj in $wa.Sites) 
{

write-host "Processing: " , $siteURL

$siteURL = $obj.URL

$site=new-object Microsoft.SharePoint.SPSite($siteURL)

$pageURL = $siteURL + $pagepath  
$web=$site.Openweb()   
$webpartmanager=$web.GetLimitedWebPartManager($pageURL,  [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)   
foreach ($webpart in $webpartmanager.WebParts)
{   
$siteURL + "; " + $webpart.Title + " ;  " + $webpart.ID | out-file $log -append   
}                           
}

}

write-host "Finished."

STEP 2. WEBPART REMOVAL SCRIPT

This script  will programmatically remove a webpart from a SharePoint page.  It takes as arguments the target site URL and the webpart GUID.   The script targets the main page “default.aspx” but can be changed to accept any other page name or page path.

Notes: Use the results from the INVENTORY SCRIPT to create a list of webparts and their GUIDs to remove. Then build a script which calls out the WEBPART REMOVAL SCRIPT using the site URLs and webpart GUIDs as arguments.

The syntax is the following:

Execute the following command in SharePoint 2010 Management shell (Powershell console):

[WEBPART REMOVAL script file name] [site URL] [webpart GUID]

Example:

remove.ps1     http://mysharepointsite     a1b83-8tyu-6897-oiy8

Script source code

[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") | out-null [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.WebPartPages") [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Publishing")

$siteURL = $args[0]  # first argument: site URL

$webpartId = $args[1]   # second argument:  webpart GUID

$pagepath =  "/default.aspx"        # change page name or page path here

$pageURL = $siteURL + $pagepath

write-host "Processing site: ", $siteURL

Write-host "Processing page: " , $pageURL

write-host "Processing webpart ID: " , $webpartID

$site=new-object Microsoft.SharePoint.SPSite($siteURL)

$web=$site.Openweb()

$webpartmanager=$web.GetLimitedWebPartManager($pageURL, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

$webpartmanager.DeleteWebPart($webpartmanager.Webparts[$webpartId])

$web.Update()

$web.Dispose()

write-host "Finished."

The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.InteropServices.COMException: <nativehr>0×80004005</nativehr><nativestack></nativestack>The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator.

I got this error while trying to change the site URL in Site Settings.

The resolution to this error is:

1. Navigate to Central Administration.

2. Go to Application Management > Manage Web Application and click on your web application to select it.

3. In the Ribbon, click on General Settings drop-down and choose “Resource Throttling”.

4. In the “List View Threshold”, increase the value (by a factor of 2, for example) and click OK.

5. Try to replicate the error.  If the error persists, increase the value again until the error goes away.

Here are the steps to do it:

You must edit several “web.config” files:

1. Each SharePoint web application you created will have its own “web.config”.  You can find these in the respective folders under “C:\inetpub\wwwroot\wss\VirtualDirectories”.

In the XML section <system.web> you have two changes to make:               

CHANGE #1:  <customErrors mode=”Off” />

( This is normally set to “On” so change it to “Off”)           

CHANGE #2:  <compilation batch=”false” debug=”true”>

(The ‘debug’ attribute is normally set to “false” so change it to “true”)
               
In the XML section <SharePoint> you have a single change to make:
CHANGE #3:  <SafeMode MaxControls=”200″ CallStack=”true”…>

(The ‘CallStack’ attribute is normally set to “false” so change it to “true”)

Remember, you must make these THREE changes in EACH of the web.config files found in the folder for each of your web applications!

2. You must also change the “web.config” that is global to SharePoint (ie:  applies to all web applications).  This file is located here:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.config

In the XML section <system.web> you have a single change to make:
CHANGE #1:  <customErrors mode=”Off” />

(This is normally set to “On” so change it to “Off”)

*** Thanks go to David Biersach for providing detailed background information for this post. ***

Crawl log error:  Error in the Site Data Web Service. (Value does not fall within the expected range.)
ULS log error:   “Error from SharePoint site: Data is Null. This method or property cannot be called on Null values.”

If you turn your diagnostic logging to Verbose, you might see the following error in the ULS log file:

GetSite fail. error 2147755542, strSiteUrl

I was able to fix the problem with the following steps:

1) Ran stsadm -o export command with -includeusersecurity switch to export the site.

2) Additionally, created a full backup of the site (just in case I needed to roll back) using stsadm -o backup command.

3) Deleted the original site collection.

4) Re-created a blank site collection with the same URL and using the same site template.

5) Ran stsadm -o import command with -includeusersecurity switch to import the site.

6) In the Search service application, deleted the original content source containing the problem site collection URL and re-created it with a different name.

7) Reset search index and run a full crawl job.

Issue : Content database with modified database schemas       
User modifications to the SharePoint content database, including but not limited to table schemas, index, stored procedures, are not supported and will cause upgrade to future versions of SharePoint to fail. The databases in the following list seem to have been modified from the original schema:

Data Source=YourDBServer;Initial Catalog=ProblemDB;Integrated Security=True;Enlist=False;Connect Timeout=15

If you did not make any manual changes to your database schemas, then see MS article http://technet.microsoft.com/en-us/library/cc262967.aspx.  

Otherwise, you can resolve this issue by following the steps below. Make sure to test this out in your test environment and create backups of all production databases before making any changes. 

1. Let’s say your problem database is called “ProblemDB”.  In Central Administration, in the same web application where your ProblemDB resides, add a blank content database.   Go to Central Admin site > Application Management > Content Databases.  Switch to the web application in question, click on “Add a content database”.  Use the same settings as your ProblemDB, but let’s call this database “GoodDB”.

2. Run the following command for each site collection found in the ProblemDB.  This command will move site collections from ProblemDB to GoodDB.

stsadm -o mergecontentdbs -url <site collection URL> -sourcedatabasename ProblemDB -destinationdatabasename GoodDB -operation 2

3. Go to Central Admin site > Application Management > Content Databases and confirm that ProblemDB does not contain any sites. Remove ProblemDB in CA.

4. Restart IIS.

5. Run stsadm preupgradecheck tool again to confirm that the issue has been resolved. 

Acknowledgements:  I’d like to thank Joseph Yi (Datacure, Inc.) for proposing and developing this solution.

Note:    If you did not make any manual changes to the database schema, you may want to reference the following Microsoft article:

From http://technet.microsoft.com/en-us/library/cc262967.aspx:

Upgrading data from SharePoint Portal Server 2003: pre-upgrade checker reports corrupted databases