Restore customizations in SharePoint Server 2010

Artykuł
07/22/2014

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

This article describes how to restore customizations that have been made to sites in a Microsoft SharePoint Server farm.

This article assumes that you are familiar with the concepts and procedures in Back up customizations in SharePoint Server 2010.

In this article:

Restoring solution packages
Restoring authored site elements
Restoring workflows
Restoring changes to the Web.config file
Recovering changes made by direct editing
Restoring developed customizations that are not packaged as solutions

Restoring solution packages in SharePoint Server

The method that you use to restore solution packages is determined by whether the customizations were deployed as trusted solutions or sandboxed solutions.

Trusted solutions are solutions that farm administrators deploy. They are deployed to the entire farm, and can be used on any site within the farm. Trusted solutions are stored in the configuration database. Trusted solutions are backed up when a farm is backed up by using SharePoint Server 2010 backup, and are included in configuration-only backups, and can also be backed up as a group, or individually. They are visible in the restore hierarchy.

Sandboxed solutions are solutions that site collection administrators can deploy to a single site collection. Sandboxed solutions are stored in the content database associated with the site collection that they are deployed to. They are included in SharePoint Server 2010 farm, Web application, content database, and site collection backups, but are not visible in the restore hierarchy, and cannot be selected or restored individually.

We recommend that you keep a backup of the original .wsp file as well as the source code used to build the .wsp file for both trusted and sandboxed solutions.

To restore a trusted solution by using Central Administration

Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
In Central Administration, on the Home page, in the Backup and Restore section, click Restore from a backup.
On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the solution package, and then click Next. You can view more details about each backup by clicking the (+) next to the backup.

Note

If the correct backup job does not appear, in the Backup Directory Location text box, type the Universal Naming Convention (UNC) path of the correct backup folder, and then click Refresh.
On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the solution, and then click Next.
On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, ensure that Solution appears in the Restore the following component list.

In the Restore Only Configuration Settings section, ensure that the Restore content and configuration settings option is selected.

In the Restore Options section, under Type of Restore, select the Same configuration option. A dialog box appears that asks you to confirm the operation. Click OK.

Click Start Restore.
You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 3.

To restore a trusted solution by using Windows PowerShell

Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
On the Start menu, click All Programs.
Click Microsoft SharePoint 2010 Products.
Click SharePoint 2010 Management Shell.
At the Windows PowerShell command prompt, type the following command:
```
Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite -BackupId <GUID> -Item <SolutionPath>
```
Where:
- <BackupFolder> is the UNC location of the directory that you want to restore from.
- <GUID> is the GUID of the backup ID that you want to restore from. If you do not specify a backup, the most recent one is used.
- <SolutionPath> is the path of the solution within the backup tree (usually farm\solutions\SolutionName).

For more information, see Restore-SPFarm.

Note

We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

Restoring a sandboxed solution

You cannot restore only customizations that were deployed as sandboxed solutions. Instead, you must restore the farm, Web application, content database, or site collection with which the customization is associated. For more information about these methods of restoring, see Related content later in this article.

Restoring authored site elements in SharePoint

You cannot restore only authored site elements. Instead, you must restore the farm, Web application, or content database with which the authored site element is associated. For more information about these methods of backing up, see Related content.

Restoring workflows in SharePoint

Workflows are a special case of customizations that you can restore. Make sure that the backup and recovery plan includes any of the following scenarios that apply to the environment:

Declarative workflows, such as those created in Microsoft SharePoint Designer 2010, are stored in the content database for the site collection to which they are they are deployed. Restoring the content database or site collection restores these workflows.
Custom declarative workflow actions have components in the following three locations:
1. The Microsoft Visual Studio 2010 assemblies for the actions are stored in the global assembly cache (GAC).
2. The XML definition files (.actions files) are stored in the 14\TEMPLATE\<LCID>\Workflow directory.
3. An XML entry to mark the action as an authorized type is stored in the Web.config file for the Web applications in which it is used.
If the farm workflows use custom actions, you should use a file restore system to restore these files and XML entries. You can reapply the files as needed after recovery.
Workflows that depend on custom code, such as those that are created by using Visual Studio 2010, are stored in two locations. The Visual Studio 2010 assemblies for the workflow are stored in the GAC, and the XML definition files are stored in the Features directory. This is the same as other types of SharePoint Server features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, follow the instructions for restoring solution packages.
If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must restore both site collections to recover the workflow. Restoring a farm is sufficient to recover all site collections in the farm and all workflows that are associated with them.
Workflows that have not been deployed must be restored separately by using a file system backup application.

Restoring changes to the Web.config file in SharePoint

You can recover changes to the Web.config file made by using Central Administration or the SharePoint Server 2010 APIs and object model by performing a farm or configuration-only restore.

You should use a file system backup to protect changes to the Web.config file that are not made by using Central Administration or the SharePoint APIs and object model. You can recover the backup by using a file system restore.

Recovering changes made by direct editing in SharePoint

Changes made directly to a site by directly editing through the browser can be difficult to recover. The following table describes recovery strategies for specific objects.

Edited object	Backup strategy
List	If you have used SharePoint Designer 2010 to save as a template, you can deploy and activate the template. For more information, see Save a SharePoint site as a template (https://go.microsoft.com/fwlink/p/?LinkID=199515).
Site	If you have used SharePoint Designer 2010 to save as a template, you can deploy and activate the template. For more information, see Save a SharePoint site as a template (https://go.microsoft.com/fwlink/p/?LinkID=199515).
Site collection	Use site collection recovery. For more information, see Restore a site collection in SharePoint Server 2010.

Restoring developed customizations that are not packaged as solutions in SharePoint

Restoring developed customizations that are not packaged as solutions can be a complex process because the customization file locations are not standardized.

Consult with the development team or customization vendor to determine whether the customizations involve additional add-in software or files in other locations. We recommend that you restore directories with a file system restore solution. The following table lists locations where customizations are typically stored on Web servers.

Location	Description
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14	Commonly updated files, custom assemblies, custom templates, custom site definitions
Inetpub	Location of IIS virtual directories
%WINDIR%\Assembly	Global assembly cache (GAC): a protected operating system location where the Microsoft .NET Framework code assemblies are installed to provide full system access