• Deployment guide for Microsoft SharePoint 2013

Posted on by escapebusinesssolutions in Uncategorized
  1. Prepare the servers
  2. Create the farm
  3. Configure settings, services, solutions, and sites

    Note:

The farm that you create and deploy will undergo significant changes in size, topology, and complexity as you move through the different deployment stages illustrated in the SharePoint 2013 Products Deployment model. This is typical and the expected result of a phased deployment. This is why we recommend that you follow all of the stages described in the “Deployment stages” section of this article.

  • Prepare the servers

In this phase, you get your servers ready to host the product. This includes the supporting servers and the servers that will have SharePoint 2013 installed. The following servers must be configured to support and host a farm:

    Important:

SharePoint 2013 does not support installation on to a domain controller in a production environment. A single label domain (SLD) names or single label forests is also not supported. Because the use of SLD names is not a recommended practice, SharePoint 2013 is not tested in this scenario. Therefore, there may be incompatibility issues when SharePoint 2013 are implemented in a single label domain environment. For more information, see Information about configuring Windows for domains with single-label DNS names and the DNS Namespace Planning Solution Center.

For information about required accounts, see:

In this phase, you install the product and configure each server to support its role in the farm. You also create the configuration database and the SharePoint Central Administration Web site. The following servers are required for a SharePoint 2013 farm:

  • Database server: Unless you plan to use DBA-created databases, the configuration database, content database, and other required databases are created when you run the SharePoint Products Configuration Wizard.
  • Application server: After you prepare the application server, install any additional components that are required to support functions such as Information Rights Management (IRM) and decision support. Install SharePoint 2013 on the server that will host SharePoint Central Administration Web site and then run the SharePoint Products Configuration Wizard to create and configure the farm.
  • Front-end Web server: Install SharePoint 2013 on each Web server, install language packs, and then run the SharePoint Products Configuration Wizard to add the Web servers to the farm.

    Note:

After you add and configure all the front-end Web servers, you can add any additional application servers that are part of your topology design to the farm.

For more information about supported deployment scenarios, see Install SharePoint 2013.

  • Configure settings, services, solutions, and sites

In this phase, you prepare the farm to host your site content by completing the following tasks:

    Note:

Farm configuration steps are not isolated to a specific tier in the server infrastructure.

  1. Verify that the user account that is performing this procedure is a member of either the sysadmin or the serveradmin fixed server role.
  2. On the computer that is running SQL Server, open SQL Server Configuration Manager.
  3. In the navigation pane, expand SQL Server Network Configuration.
  4. Click the corresponding entry for the instance that you are configuring.

    The default instance is listed as Protocols for MSSQLSERVER. Named instances will appear as Protocols for named_instance.

  5. In the main window in the Protocol Name column, right-click TCP/IP, and then click Properties.
  6. Click the IP Addresses tab.

    For every IP address that is assigned to the computer that is running SQL Server, there is a corresponding entry on this tab. By default, SQL Server listens on all IP addresses that are assigned to the computer.

  7. To globally change the port that the default instance is listening on, follow these steps:
  • For each IP address except IPAll, clear all values for both TCP dynamic ports and TCP Port.
  • For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.
  1. To globally change the port that a named instance is listening on, follow these steps:
  • For each IP address including IPAll, clear all values for TCP dynamic ports. A value of 0 for this field indicates that SQL Server uses a dynamic TCP port for the IP address. A blank entry for this value means that SQL Server will not use a dynamic TCP port for the IP address.
  • For each IP address except IPAll, clear all values for TCP Port.
  • For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.
  1. Click OK.

    A message indicates that that the change will not take effect until the SQL Server service is restarted. Click OK.

  2. Close SQL Server Configuration Manager.
  3. Restart the SQL Server service and confirm that the computer that is running SQL Server is listening on the port that you selected.

    You can confirm this by looking in the Event Viewer log after you restart the SQL Server service. Look for an information event similar to the following event:

    Event Type:Information

    Event Source:MSSQL$MSSQLSERVER

    Event Category:(2)

    Event ID:26022

    Date:3/6/2008

    Time:1:46:11 PM

    User:N/A

    Computer:computer_name

    Description:

    Server is listening on [ ‘any’ <ipv4>50000]

  4. Verification: Optionally, include steps that users should perform to verify that the operation was successful.
  1. Verify that the user account that is performing this procedure is a member of either the sysadmin or the serveradmin fixed server role.
  2. In Control Panel, open System and Security.
  3. Click Windows Firewall, and then click Advanced Settings to open the Windows Firewall with Advanced Security dialog box.
  4. In the navigation pane, click Inbound Rules to display the available options in the Actions pane.
  5. Click New Rule to open the New Inbound Rule Wizard.
  6. Use the wizard to complete the steps that are required to allow access to the port that you defined in Configuring a SQL Server instance to listen on a non-default port.

    Note:

You can configure the Internet Protocol security (IPsec) to help secure communication to and from your computer that is running SQL Server by configuring the Windows firewall. You do this by selecting Connection Security Rules in the navigation pane of the Windows Firewall with Advanced Security dialog box.

  1. Verify that the user account that is performing this procedure is a member of either the sysadmin or the serveradmin fixed server role.
  2. Run Setup for SQL Server on the target computer, and install the following client components:
  • Connectivity Components
  • Management Tools
  1. Open SQL Server Configuration Manager.
  2. In the navigation pane, click SQL Native Client Configuration.
  3. In the main window under Items, right-click Aliases, and select New Alias.
  4. In the Alias – New dialog box, in the Alias Name field, enter a name for the alias. For example, enter SharePoint_alias.
  5. In the Port No field, enter the port number for the database instance. For example, enter 40000. Make sure that the protocol is set to TCP/IP.
  6. In the Server field, enter the name of the computer that is running SQL Server.
  7. Click Apply, and then click OK.
  8. Verification: You can test the SQL Server client alias by using SQL Server Management Studio, which is available when you install SQL Server client components.
  9. Open SQL ServerManagement Studio.
  10. When you are prompted to enter a server name, enter the name of the alias that you created, and then click Connect. If the connection is successful, SQL ServerManagement Studio is populated with objects that correspond to the remote database.
  11. To check connectivity to additional database instances from SQL ServerManagement Studio, click Connect, and then click Database Engine.

 

 
  1. Refer to Hardware and software requirements (SharePoint 2013), which lists all the required and optional software for SharePoint 2013. Additionally, this document provides the download location for each prerequisite that is available for download on the Internet.
  2. From the command prompt, navigate to the root of the SharePoint 2013 installation media or folder location.
  3. At the command prompt, type the following command and then press ENTER:

    PrerequisiteInstaller.exe /?

    This displays a list of the command-line options and switches and their corresponding arguments for installing a prerequisite from the command-line.

    Tip:

To copy the contents of the active About window to the Clipboard, press CTRL+C.

  1. Verify that you have an accurate list of the required software. Compare the output from the prerequisite installer to the list of prerequisites in step 1.
  2. Download the prerequisites to a computer that has Internet access.

Next, follow these steps to create a central location that you can use for installing SharePoint 2013 prerequisites on all the farm servers.

To combine prerequisites

  1. Create a shared folder on a computer that can be accessed by the servers on which the prerequisites will be installed.
  2. Copy the files that you downloaded from the Internet to the shared folder.

After you finish creating an available network location for the prerequisites, use the procedure in the following section to install SharePoint 2013 prerequisites on a server.

  1. From the Start menu, open the Command Prompt window using the Run as administrator option.
  2. Navigate to the SharePoint 2013 source directory.
  3. Type the prerequisite program switch and corresponding argument for the program that you want to install, and then press ENTER, for example:

    PrerequisiteInstaller.exe /SQLNCli: “\\o15-sf-admin\SP_prereqs\sqlncli.msi”

    Note:

To install more than one prerequisite, type each switch and argument pair. Be sure to separate each pair by a space, for example:

PrerequisiteInstaller.exe /IDFX: “\\<path>\Windows6.1-KB974405-x64.msu” /sqlncli:”\\<path>\sqlncli.msi” /Sync:”\\<path>\Synchronization.msi”

  1. PrerequisiteInstaller.exe reads the argument file to verify that each switch is valid and that the program identified in the path statement exists.

    Note:

If you specify an argument, PrerequisiteInstaller.exe ignores the arguments file and only processes the command-line argument.

  1. PrerequisiteInstaller.exe scans the local system to determine whether any of the prerequisites are already installed.
  2. PrerequisiteInstaller.exe installs the programs in the argument file and returns one of the following exit codes:
  • 0 – Success
  • 1 – Another instance of this application is already running
  • 2 – Invalid command line parameter
  • 1001 – A pending restart blocks installation
  • 3010 – A restart is needed
  1. If a prerequisite requires a restart, a 3010 code is generated and you are prompted to click Finish to restart the system. The behavior of the installer after a 3010 code is different depending on which of the following conditions are true on the computer:

Use the following procedure to create an arguments file.

To create an arguments file

  1. Using a text editor, create a new text document named PrerequisiteInstaller.Arguments.txt. Save this file to the same location as PrerequisiteInstaller.exe. This file will contain the switches and arguments that are used when you run the Microsoft SharePoint Products Preparation Tool.
  2. Using a text editor, edit PrerequisiteInstaller.Arguments.txt and provide file paths to the installation source for each prerequisite switch by using the following syntax:

    /switch: <path>

    Where /switch is a valid switch and <path> is a path of the installation source.

    The following example shows a complete arguments file that uses a file share as a common installation point. Do not include carriage returns in your file.

    /PowerShell:”<path>\WINDOWS6.1-KB2506143-x64.msu” /NETFX:”<path>\dotNetFx45_Full_x86_x64.exe” /IDFX:”<path>\Windows6.1-KB974405-x64.msu” /sqlncli:”<path>\sqlncli.msi” /Sync:”<path>\Synchronization.msi” /AppFabric:”<path>\setup.exe” /IDFX11:”<path>\Microsoft Identity Extensions.msi” /MSIPCClient:”<path>\msipc.msi” /WCFDataServices:”<path>\WcfDataServices.exe” /KB2671763:”<path>\AppFabric1.1-RTM-KB2671763-x64-ENU.exe

  3. After you finish editing PrerequisiteInstaller.Arguments.txt, save your edits, and verify that this file is in the same directory as PrerequisiteInstaller.exe.

Use the following procedure to install the prerequisites.

To install the prerequisites using an arguments file

  1. Run PrerequisiteInstaller.exe at the command prompt to install the prerequisites.

    Caution:

If you are prompted to click Finish to restart the system, do not do so. Instead, click Cancel. For more information, see Known issues you continue with the next step.

  1. Restart the system manually.
  2. At the command prompt type the following command and then press Enter:

    PrerequisiteInstaller.exe

There are two known issues that affect the use of an arguments file:

  • Using line breaks in the arguments file

    If you create an arguments file and use line breaks to put each switch and argument on a separate line, the prerequisite installer fails. The workaround is to enter all the switch and argument pairs on a single line.

  • After a computer restart, the arguments file is not used

    After a restart, PrerequisiteInstaller.exe executes the startup command file, which contains a /continue flag. The /continue flag forces the installer to ignore the arguments file.

    You must prevent a restart by deleting the startup task in this command file by using one of the following options:

    Option 1

  1. Run PrerequisiteInstaller.exe by double-clicking it. The program will display the first screen with the list of prerequisites.
  2. Click Cancel. PrerequisiteInstaller.exe deletes the startup task.

    Option 2

  3. From the Start menu, choose Run and then type regedit to open the registry.
  4. Open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders.
  5. Check the value for “Common Startup”. This shows the directory where the startup tasks are listed.
  6. Close the registry editor without making any changes.
  7. Navigate to the startup directory, which is usually <systemdir>\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.
  8. Delete the startup task by deleting “SharePointServerPreparationToolStartup_0FF1CE14-0000-0000-0000-000000000000.cmd”.

 

 
  1. Run the Microsoft SharePoint Products Preparation Tool.
  2. Run Setup, which installs Microsoft SQL Server 2008 R2 SP1 Express Edition and the SharePoint product.
  3. Run the SharePoint Products Configuration Wizard, which installs and configures the configuration database, the content database, and installs the SharePoint Central Administration website. This wizard also creates your first SharePoint site collection.
  4. Configure browser settings.
  5. Perform post-installation steps.

    Important:

To complete the following procedures, you must be a member of the Administrators group on the computer on which you are installing SharePoint 2013.

  • Run the Microsoft SharePoint Products Preparation Tool

Because the prerequisite installer downloads components from the Microsoft Download Center, you must have Internet access on the computer on which you are running the installer. Use the following procedure to install software prerequisites for SharePoint 2013.

To run the Microsoft SharePoint Products Preparation Tool

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. In the folder where you downloaded the SharePoint 2013 software, locate and then run prerequisiteinstaller.exe.
  3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.
  4. On the License Terms for software products page, review the terms, select the I accept the terms of the License Agreement(s) check box, and then click Next.
  5. On the Installation Complete page, click Finish.
  6. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the following:

The following procedure installs Microsoft SQL Server 2008 R2 SP1 Express Edition and the SharePoint product. At the end of Setup, you can choose to start the SharePoint Products Configuration Wizard, which is described later in this section.

To run Setup

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. On the SharePoint Server 2013 or SharePoint Foundation 2013 Start page, click Install SharePoint Server or Install SharePoint Foundation.
  3. On the Enter Your Product Key page, enter your product key, and then click Continue.
  4. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.
  5. On the Server Type tab, click Standalone.
  6. When Setup finishes, a dialog box prompts you to complete the configuration of your server. Ensure that the Run the SharePoint Products Configuration Wizard now check box is selected.
  7. Click Close to start the configuration wizard.

    Note:

If Setup fails, check log files in the Temp folder of the user account that you used to run Setup. Ensure that you are logged in using the same user account, and then type %temp% in the location bar in Windows Explorer. If the path in Windows Explorer resolves to a location that ends in a “1” or “2”, you will have to navigate up one level to view the log files. The log file name is SharePoint Server Setup (<time stamp>).

  • Run the SharePoint Products Configuration Wizard

Use the following procedure to install and configure the configuration database and the content database, and install the SharePoint Central Administration website.

To run the SharePoint Products Configuration Wizard

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. If you have closed the SharePoint Products Configuration Wizard, you can access it by clicking Start, point to All Programs, click SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard. If the User Account Control dialog box appears, click Continue.
  3. On the Welcome to SharePoint Products page, click Next.
  4. In the dialog box that notifies you that some services might have to be restarted during configuration, click Yes.
  5. On the Configuration Successful page, click Finish.

    Note:

If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are located on the drive on which SharePoint 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS folder.

  1. On the Template Selection page, select one of the following options, and then click OK:
  • In the Template Selection section, click a predefined template.
  • In the Solutions Gallery section, click Solutions Gallery, and customize your own site template.
  1. On the Set Up Groups for this Site page, specify who should have access to your site, and then either create a new group or use an existing group for these users by doing one of the following:
  • To create a new group, click Create a new group, and then type the name of the group and the members that you want to be part of this group.
  • To use an existing group, click Use an existing group, and then select the user group in the Item list.
  1. Click OK.

    Note:

If you are prompted for your user name and password, you might have to add the SharePoint Central Administration website to the list of trusted sites and configure user authentication settings in Internet Explorer. You might also want to disable the Internet Explorer Enhanced Security settings. If you see a proxy server error message, you might have to configure proxy server settings so that local addresses bypass the proxy server. For more information about how to configure browser and proxy settings, see Configure browser settings.

After you run the SharePoint Products Configuration Wizard, you should confirm that SharePoint 2013 works correctly by configuring additional settings in Internet Explorer.

If you are not using Internet Explorer, you might have to configure additional settings for your browser. For information about supported browsers, see Plan browser support (SharePoint 2013).

To confirm that you have configured browser settings correctly, log on to the server by using an account that has local administrative credentials. Next, connect to the SharePoint Central Administration website. If you are prompted for your user name and password when you connect, perform the following procedures:

  • Add the SharePoint Central Administration website to the list of trusted sites
  • Disable Internet Explorer Enhanced Security settings

If you receive a proxy server error message, perform the following procedure:

  • Configure proxy server settings to bypass the proxy server for local addresses

To add the SharePoint Central Administration website to the list of trusted sites

  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account is a member of the Administrators group on the computer on which you are performing the procedure.
  1. In Internet Explorer, on the Tools menu, click Internet Options.
  2. On the Security tab, in the Select a zone to view or change security settings area, click Trusted Sites, and then click Sites.
  3. Clear the Require server verification (https:) for all sites in this zone check box.
  4. In the Add this web site to the zone box, type the URL to your site, and then click Add.
  5. Click Close to close the Trusted Sites dialog box.
  6. Click OK to close the Internet Options dialog box.

To disable Internet Explorer Enhanced Security settings

  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account is a member of the Administrators group on the computer on which you are performing the procedure.
  1. Click Start, point to All Programs, point to Administrative Tools, and then click Server Manager.
  2. In Server Manager, select the root of Server Manager.
  3. In the Security Information section, click Configure IE ESC.

    The Internet Explorer Enhanced Security Configuration dialog box appears.

  4. In the Administrators section, click Off to disable the Internet Explorer Enhanced Security settings, and then click OK.

To configure proxy server settings to bypass the proxy server for local addresses

  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account is a member of the Administrators group on the computer on which you are performing the procedure.
  1. In Internet Explorer, on the Tools menu, click Internet Options.
  2. On the Connections tab, in the Local Area Network (LAN) settings area, click LAN Settings.
  3. In the Automatic configuration area, clear the Automatically detect settings check box.
  4. In the Proxy Server area, select the Use a proxy server for your LAN check box.
  5. Type the address of the proxy server in the Address box.
  6. Type the port number of the proxy server in the Port box.
  7. Select the Bypass proxy server for local addresses check box.
  8. Click OK to close the Local Area Network (LAN) Settings dialog box.
  9. Click OK to close the Internet Options dialog box.
  1. Run the Microsoft SharePoint Products Preparation Tool, which installs all prerequisites to use SharePoint 2013.
  2. Run Setup, which installs binaries, configures security permissions, and edits registry settings for SharePoint 2013.
  3. Run SharePoint Products Configuration Wizard, which installs and configures the configuration database, installs and configures the content database, and installs the SharePoint Central Administration web site.
  4. Configure browser settings.
  5. Run the Farm Configuration Wizard, which configures the farm, creates the first site collection, and selects the services that you want to use in the farm.
  6. Perform post-installation steps.

    Important:

To complete the following procedures, the account that you use must be a member of the Administrators group on the computer on which you are installing SharePoint 2013. For information about user accounts, see Initial deployment administrative and service accounts in SharePoint 2013.

  • Run the Microsoft SharePoint Products Preparation Tool

Because the prerequisite installer downloads components from the Microsoft Download Center, you must have Internet access on the computer on which you are running the installer. Use the following procedure to install software prerequisites for SharePoint 2013.

To run the Microsoft SharePoint Products Preparation Tool

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. In the folder where you downloaded the SharePoint 2013 software, locate and then run prerequisiteinstaller.exe.
  3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.
  4. On the License Terms for software products page, review the terms, select the I accept the terms of the License Agreement(s) check box, and then click Next.
  5. On the Installation Complete page, click Finish.
  6. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the following:

The following procedure installs binaries, configures security permissions, and edits registry settings for SharePoint 2013. At the end of Setup, you can choose to start the SharePoint Products Configuration Wizard, which is described later in this section.

To run Setup

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. On the SharePoint Server 2013 Start page, click Install SharePoint Server.
  3. On the Enter Your Product Key page, enter your product key, and then click Continue.
  4. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.
  5. On the Server Type tab, click Complete.

    The stand-alone option is used to install a single server that has a built-in database.

  6. Optional: To install SharePoint 2013 at a custom location, click the File Location tab, and then either type the location or click Browse to find the location.
  7. Click Install Now.
  8. When Setup finishes, a dialog box prompts you to complete the configuration of your server. Ensure that the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.
  9. Click Close to start the configuration wizard.

    Note:

If Setup fails, check log files in the Temp folder of the user account you used to run Setup. Ensure that you are logged in using the same user account and then type %temp% in the location bar in Windows Explorer. If the path in Windows Explorer resolves to a location that ends in a “1” or “2”, you have to navigate up one level to view the log files. The log file name is SharePoint Server Setup (<time stamp>).

  • Run the SharePoint Products Configuration Wizard

Use the following procedure to install and configure the configuration database and the content database, and to install the SharePoint Central Administration website.

To run the SharePoint Products Configuration Wizard

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. If you have closed the SharePoint Products Configuration Wizard, you can access it by clicking Start, point to All Programs, click SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard. If the User Account Control dialog box appears, click Continue.
  3. On the Welcome to SharePoint Products page, click Next.
  4. In the dialog box that notifies you that some services might have to be restarted during configuration, click Yes.
  5. On the Connect to a server farm page, click Create a new server farm, and then click Next.
  6. On the Specify Configuration Database Settings page, do the following:
    1. In the Database server box, type the name of the computer that is running SQL Server.
    2. In the Database name box, type a name for your configuration database or use the default database name. The default name is SharePoint_Config.
    3. In the Username box, type the user name of the server farm account. Ensure that you type the user name in the format DOMAIN\user name.

    Security

The server farm account is used to create and access your configuration database. It also acts as the application pool identity account for the SharePoint Central Administration application pool, and it is the account under which the Microsoft SharePoint Foundation Workflow Timer service runs. The SharePoint Products Configuration Wizard adds this account to the SQL Server Login accounts, the SQL Serverdbcreator server role, and the SQL Serversecurityadmin server role. The user account that you specify as the service account has to be a domain user account. However, it does not have to be a member of any specific security group on your front-end web servers or your database servers. We recommend that you follow the principle of least-privilege and specify a user account that is not a member of the Administrators group on your front-end web servers or your database servers.

  1. In the Password box, type the user password.
  1. Click Next.
  2. On the Specify Farm Security Settings page, type a passphrase, and then click Next.

    Although a passphrase resembles a password, it is usually longer to improve security. It is used to encrypt credentials of accounts that are registered in SharePoint 2013. For example, the SharePoint 2013 system account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that you remember the passphrase, because you must use it every time that you add a server to the farm.

    Ensure that the passphrase meets the following criteria:

  • Contains at least eight characters
  • Contains at least three of the following four character groups:
    • English uppercase characters (from A through Z)
    • English lowercase characters (from a through z)
    • Numerals (from 0 through 9)
    • Nonalphabetic characters (such as !, $, #, %)
  1. On the Configure SharePoint Central Administration Web Application page, do the following:
    1. Either select the Specify port number check box and type the port number that you want the SharePoint Central Administration web application to use, or leave the Specify port number check box cleared if you want to use the default port number.
    2. Click either NTLM or Negotiate (Kerberos).
  2. Click Next.
  3. After you complete the SharePoint Products Configuration Wizard page, review your configuration settings to verify that they are correct, and then click Next.

    Note:

The Advanced Settings option is not available in SharePoint 2013.

  1. On the Configuration Successful page, click Finish. When the wizard closes, setup opens the web browser and connects to Central Administration.

    If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are located on the drive on which SharePoint 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS folder.

    If you are prompted for your user name and password, you might have to add the SharePoint Central Administration web site to the list of trusted sites and configure user authentication settings in Internet Explorer. You might also want to disable the Internet Explorer Enhanced Security settings. If you see a proxy server error message, you might have to configure proxy server settings so that local addresses bypass the proxy server. Instructions for configuring proxy server settings are provided in the following section. For more information about how to configure browser and proxy settings, see Configure browser settings.

  • Configure browser settings

After you run the SharePoint Products Configuration Wizard, you should confirm that SharePoint 2013 works correctly by configuring additional settings in Internet Explorer.

If you are not using Internet Explorer, you might have to configure additional settings for your browser. For information about supported browsers, see Plan browser support (SharePoint 2013).

To confirm that you have configured browser settings correctly, log on to the server by using an account that has local administrative credentials. Next, connect to the SharePoint Central Administration web site. If you are prompted for your user name and password when you connect, perform the following procedures:

  • Add the SharePoint Central Administration website to the list of trusted sites
  • Disable Internet Explorer Enhanced Security settings

If you receive a proxy server error message, perform the following procedure:

  • Configure proxy server settings to bypass the proxy server for local addresses

To add the SharePoint Central Administration website to the list of trusted sites

  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account is a member of the Administrators group on the computer on which you are performing the procedure.
  1. In Internet Explorer, on the Tools menu, click Internet Options.
  2. On the Security tab, in the Select a zone to view or change security settings area, click Trusted Sites, and then click Sites.
  3. Clear the Require server verification (https:) for all sites in this zone check box.
  4. In the Add this web site to the zone box, type the URL to your site, and then click Add.
  5. Click Close to close the Trusted Sites dialog box.
  6. Click OK to close the Internet Options dialog box.

To disable Internet Explorer Enhanced Security settings

  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account is a member of the Administrators group on the computer on which you are performing the procedure.
  1. Click Start, point to All Programs, point to Administrative Tools, and then click Server Manager.
  2. In Server Manager, select the root of Server Manager.
  3. In the Security Information section, click Configure IE ESC.

    The Internet Explorer Enhanced Security Configuration dialog box appears.

  4. In the Administrators section, click Off to disable the Internet Explorer Enhanced Security settings, and then click OK.

To configure proxy server settings to bypass the proxy server for local addresses

  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account is a member of the Administrators group on the computer on which you are performing the procedure.
  1. In Internet Explorer, on the Tools menu, click Internet Options.
  2. On the Connections tab, in the Local Area Network (LAN) settings area, click LAN Settings.
  3. In the Automatic configuration area, clear the Automatically detect settings check box.
  4. In the Proxy Server area, select the Use a proxy server for your LAN check box.
  5. Type the address of the proxy server in the Address box.
  6. Type the port number of the proxy server in the Port box.
  7. Select the Bypass proxy server for local addresses check box.
  8. Click OK to close the Local Area Network (LAN) Settings dialog box.
  9. Click OK to close the Internet Options dialog box.

  • Run the Farm Configuration Wizard

You have now completed setup and the initial configuration of SharePoint 2013. You have created the SharePoint Central Administration web site. You can now create your farm and sites, and you can select services by using the Farm Configuration Wizard.

To run the Farm Configuration Wizard

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. On the SharePoint Central Administration home page, on the Quick Launch, click Configuration Wizards, and then click Launch the Farm Configuration Wizard.
  3. On the Help Make SharePoint Better page, click one of the following options, and then click OK:
  • Yes, I am willing to participate (Recommended.)
  • No, I don’t want to participate.
  1. On the Configure your SharePoint farm page, next to Yes, walk me through the configuration of my farm using this wizard, click Start the Wizard.
  2. On the Configure your SharePoint farm page, in the Service Account section, click the service account option that you want to use to configure your services.

    Security

For security reasons, we recommend that you use a different account from the farm administrator account to configure services in the farm.

If you decide to use an existing managed account — that is, an account of which SharePoint 2013 is aware — make sure that you click that option before you continue.

  1. In the Services section, review the services that you want to use in the farm, and then click Next.

    Note:

For more information, see Configure services and service applications in SharePoint 2013. If you are using Office Web Apps, see Office Web Apps (SharePoint 2013).

  1. On the Create Site Collection page, do the following:
    1. In the Title and Description section, in the Title box, type the name of your new site.
    2. Optional: In the Description box, type a description of what the site contains.
    3. In the Web Site Address section, select a URL path for the site.
    4. In the Template Selection section, in the Select a template list, select the template that you want to use for the top-level site in the site collection.

    Note:

To view a template or a description of a template, click any template in the Select a template list.

  1. Click OK.
  2. On the Configure your SharePoint farm page, review the summary of the farm configuration, and then click Finish.
  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. In the folder where you downloaded the SharePoint 2013 software, locate and then run prerequisiteinstaller.exe.
  3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.

    Note:

The preparation tool may have to restart the local server to complete the installation of some prerequisites. The installer will continue to run after the server is restarted without manual intervention. However, you will have to log on to the server again.

  1. On the License Terms for software products page, review the terms, select the I accept the terms of the License Agreement(s) check box, and then click Next.
  2. On the Installation Complete page, click Finish.
  3. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the following:
  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. On the SharePoint 2013 Start page, click Install SharePoint Server.
  3. On the Enter Your Product Key page, enter your product key, and then click Continue.
  4. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.
  5. On the Choose the installation you want page, click Server Farm.
  6. On the Server Type tab, click Complete.
  7. On the File Location tab, accept the default location or change the installation path, and then click Install Now.

    Note:

As a best practice, we recommend that you install SharePoint 2013 on a non-system drive.

  1. When the Setup program is finished, a dialog box prompts you to complete the configuration of your server. Clear the Run the SharePoint Products and Technologies Configuration Wizard now check box.

    Note:

For consistency of approach, we recommend that you do not run the configuration wizard until you have installed SharePoint 2013 all application and front-end web servers that will participate in the server farm.

  1. Click Close to finish Setup.
  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. On the server that will host Central Administration (the application server), click Start, point to All Programs, and then click SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard. If the User Account Control dialog box appears, click Continue.
  3. On the Welcome to SharePoint Products page, click Next.
  4. In the dialog box that notifies you that some services might have to be restarted during configuration, click Yes.
  5. On the Connect to a server farm page, click Create a new server farm, and then click Next.
  6. On the Specify Configuration Database Settings page, do the following:
    1. In the Database server box, type the name of the computer that is running SQL Server.
    2. In the Database name box, type a name for your configuration database, or use the default database name. The default name is SharePoint_Config.
    3. In the Username box, type the user name of the server farm account in DOMAIN\user name format.

    Important:

The server farm account is used to create and access your configuration database. It also acts as the application pool identity account for the SharePoint Central Administration application pool, and it is the account under which the SharePoint Timer service runs. The SharePoint Products Configuration Wizard adds this account to the SQL Server Login accounts, the SQL Serverdbcreator server role, and the SQL Serversecurityadmin server role. The user account that you specify as the service account has to be a domain user account. However, it does not have to be a member of any specific security group on your web servers or your database servers. We recommend that you follow the principle of least-privilege, and specify a user account that is not a member of the Administrators group on your front-end web servers or your database servers.

  1. In the Password box, type the user password.
  1. Click Next.
  2. On the Specify Farm Security Settings page, type a passphrase, and then click Next.

    Although a passphrase resembles a password, it is usually longer to improve security. It is used to encrypt credentials of accounts that are registered in SharePoint 2013. For example, the SharePoint 2013 system account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that you remember the passphrase, because you must use it every time that you add a server to the farm.

    Ensure that the passphrase meets the following criteria:

  • Contains at least eight characters
  • Contains at least three of the following four character groups:
    • English uppercase characters (from A through Z)
    • English lowercase characters (from a through z)
    • Numerals (from 0 through 9)
    • Nonalphabetic characters (such as !, $, #, %)
  1. On the Configure SharePoint Central Administration Web Application page, do the following:
    1. Either select the Specify port number check box and type the port number that you want the SharePoint Central Administration web application to use, or leave the Specify port number check box cleared if you want to use the default port number.

    Note:

If you want to access the SharePoint Central Administration website from a remote computer, make sure that you allow access to the port number that you configure in this step. You do this by configuring the inbound rule for SharePoint Central Administration v4 in Windows Firewall with Advanced Security.

  1. Click either NTLM or Negotiate (Kerberos).
  1. Click Next.
  2. On the Completing the SharePoint Products Configuration Wizard page, click Next.
  3. On the Configuration Successful page, click Finish.

    Note:

If the SharePoint Products Configuration Wizard fails, check the log files on the drive on which SharePoint 2013 is installed, which are located in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS folder.

  1. The Central Administration website will open in a new browser window.

    On the Help Make SharePoint Better page, click one of the following options and then click OK.

    1. Yes, I am willing to participate (Recommended).
    2. No, I don’t wish to participate.
  2. On the Initial Farm Configuration Wizard page, you have the option to use a wizard to configure services or you can decide to configure services manually. For the purpose of this article, we use the manual option. Click Cancel.

    The choice that you make here is a matter of personal preference. The Farm Configuration Wizard will configure some services automatically when you run it. However, if you configure services manually, you have greater flexibility in designing your logical architecture.

    For information about how to use the wizard to configure services, see Configure services and service applications in SharePoint 2013. If you are using Microsoft Office Web Apps, see Office Web Apps overview (Installed on SharePoint 2013).

    Important:

If you are using a DBA-created database, you cannot use the Farm Configuration Wizard, you must use SharePoint Products Configuration Wizard.

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. In the folder where you downloaded the language pack, run setup.exe.
  3. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.
  4. The Setup wizard runs and installs the language pack.
  5. Rerun the SharePoint Products Configuration Wizard by using the default settings. If you do not run the SharePoint Products Configuration Wizard after you install a language pack, the language pack will not be installed correctly.

    The SharePoint Products Configuration Wizard runs in the language of the base installation of SharePoint 2013, not in the language of the language pack that you just installed.

To rerun the SharePoint 2013 Configuration Wizard

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. Click Start, point to All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard.
  3. On the Welcome to SharePoint Products page, click Next.
  4. Click Yes in the dialog box that alerts you that some services might have to be restarted during configuration.
  5. On the Modify Server Farm Settings page, click Do not disconnect from this server farm, and then click Next.
  6. If the Modify SharePoint Central Administration Web Administration Settings page appears, do not change any of the default settings, and then click Next.
  7. After you complete the Completing the SharePoint Products and Technologies Configuration Wizard, click Next.
  8. On the Configuration Successful page, click Finish.
  9. After you install a new language pack and rerun the Rerun the SharePoint 2013 Configuration Wizard, you must deactivate and then reactivate any language-specific features before you use the new language pack.

When you install language packs, the language-specific site templates are installed in the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\TEMPLATE\LanguageID directory, where LanguageID is the Language ID number for the language that you are installing. For example, the United States English language pack installs to the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\1033 directory. After you install a language pack, site owners and site collection administrators can create sites and site collections based on the language-specific site templates by specifying a language when they are creating a new SharePoint site or site collection.

  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. From the product media or a file share that contains the SharePoint 2013 Products installation files, run Setup.exe.
  3. On the Start page, click the link to install SharePoint 2013.
  4. Review and accept the Microsoft License Terms.
  5. On the Server Type tab, select Complete.

    Note:

You can choose to install only the components that are required for a front-end web server. However, if you perform a complete installation, you have more flexibility to re-purpose the server role in the farm in the future.

  1. Accept the default file location where SharePoint 2013 will be installed or change the installation path in order to suit your requirements.

    Tip:

As a best practice, we recommend that you install SharePoint 2013 on a drive that does not contain the operating system.

  1. When Setup finishes, a dialog box prompts you to run the SharePoint Products Configuration Wizard. You can start the wizard immediately or from the Windows command prompt later.
  1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
  2. Start the SharePoint 2013 Products Configuration Wizard.
  • For Windows Server 2008 R2:
    • On the new server, click Start, point to All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard.
  • For Windows Server 2012:
    • On the new server, on the Start screen, click SharePoint 2013 Products Configuration Wizard.

      If SharePoint 2013 Products Configuration Wizard is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Products Configuration Wizard.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. On the Welcome to SharePoint Products page, click Next.
  2. On the Connect to a server farm page, click Connect to an existing server farm.
  3. Click Next.
  4. On the Specify Configuration Database settings page, type the name of the instance of SQL Server in the Database server box, and then click Retrieve Database Names.
  5. Select the name of the configuration database in the Database name list, and then click Next.
  6. On the Specify Farm Security Settings page, type the name of the farm passphrase in the Passphrase box, and then click Next.
  7. On the Completing the SharePoint Products Configuration Wizard page, click Next.
  8. On the server that hosts Central Administration, click Manage servers in this farm to verify that the new server is part of the farm.

    Note:

You can also verify a successful server addition or troubleshoot a failed addition by examining the log files. These files are located on the drive on which SharePoint 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS folder. For more information, see Monitor health in SharePoint 2013.

  1. On the Servers in Farm page, click the name of the new server. Use the list of available services on the Services on Server page to start the services that you want to run on the new server.
  2. Configure SharePoint 2013 so that the new server can accommodate the role for which it was intended. For more information, see Configure the new server.

To add a new SharePoint 2013 server to the farm by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:Right-click

    • Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command to connect the server to a configuration database:

    Connect-SPConfigurationDatabase -DatabaseServer “<$DatabaseServer>” -DatabaseName “<$RunSettings.ConfigurationDatabaseName>” -Passphrase “<$Passphrase>“

    Where:

  • <$DatabaseServer> is the name of the server that hosts the configuration database
  • <$RunSettings.ConfigurationDatabaseName> is the name of the configuration database
  • <$Passphrase> is the passphrase for the farm
  1. At the Windows PowerShell command prompt, type the following command to install the Help File Collections:

    Install-SPHelpCollection -All

  2. At the Windows PowerShell command prompt, type the following command to install the Security Resource for SharePoint 2013:

    Initialize-SPResourceSecurity

  3. At the Windows PowerShell command prompt, type the following command to install the basic services:

    Install-SPService

  4. At the Windows PowerShell command prompt, type the following command to install all the features:

    Install-SPFeature -AllExistingFeatures

  5. At the Windows PowerShell command prompt, type the following command to install application content:

    Install-SPApplicationContent

  6. At the Windows PowerShell command prompt, type the following command to get a list of servers in the farm.

    Get-SPFarm | select Servers

    Note:

You can also verify a successful server addition or troubleshoot a failed addition by examining the log files. These files are located on the drive on which SharePoint 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS folder. For more information, see Monitor health in SharePoint 2013.

  1. Configure SharePoint 2013 so that the new server can accommodate the role for which it was intended. For more information, see Configure the new server.
  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account that performs this procedure is a member of the Administrators group on the server.
  1. Stop the services that are running on the server. For information about how to determine which services are running on a specific server and stopping services, see Start or Stop a service (SharePoint 2013).
  2. On the server that you want to remove from the farm, click Start, click Control Panel, and then double-click Programs and Features.
  3. In the list of currently installed programs, click SharePoint 2013, and then click Uninstall.
  4. Click Continue at the confirmation prompt to uninstall the program.
  1. Verify that the user account that completes this procedure has the following credentials:
  • The user account that performs this procedure is a member of the Farm Administrators SharePoint group.
  • The user account that performs this procedure is a member of the Administrators group on the server.
  1. Stop the services that are running on the server. For information about how to determine which services are running on a specific server and stopping services, see Start or Stop a service (SharePoint 2013).
  2. On the SharePoint Central Administration website, in the System Settings section, click Manage servers in this farm.
  3. On the Servers in Farm page, locate the row that contains the name of the server that you want to remove, and then click Remove Server.
  4. In the warning that appears, click OK to remove the server or click Cancel to stop the operation.

    The page updates, and the server that you removed no longer appears in the list of servers.

 

 

  1. Verify that you are a member of the Farm Administrators group or a member of the Administrators group on the local computer.
  2. On the computer that runs SharePoint 2013, log on as a local or domain administrator.
  3. Start Control Panel.
  1. In the Programs area, click Uninstall a program.
  2. In the Uninstall or change a program dialog box, click Microsoft SharePoint Server 2013.
  3. Click Change.
  4. On the Change your installation of Microsoft SharePoint Server 2013 page, click Remove, and then click Continue.

    A confirmation message appears.

  5. Click Yes to remove SharePoint 2013.

    A warning message appears.

  6. Click OK to continue.

    A confirmation message appears.

  7. Click OK.

    You might be prompted to restart the server.

    Note:

If you did not remove the language template packs before you uninstalled and then reinstalled SharePoint 2013, you must run Repair from the SharePoint Products Configuration Wizard for each language template pack on the server. After the repair operation is complete, you must restart the server. Finally, complete the language template pack configuration by running the SharePoint Products Configuration Wizard.

 

 

  1. Verify that the user account that is performing this procedure is a site collection administrator.
  2. Start SharePoint 2013 Central Administration.
  • For Windows Server 2008 R2:
    • Click Start, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Central Administration.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Central Administration.

      If SharePoint 2013 Central Administration is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Central Administration.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. In Central Administration, in the Application Management section, click Manage web applications.
  2. In the Contribute group of the ribbon, click New.
  3. In the Claims Authentication Types section of the Create New Web Application dialog box, select Enable Forms Based Authentication (FBA).
  4. Type a membership provider name in ASP.NET Membership provider name and a role manager name in ASP.NET Role manager name.

    In the example Web.Config files depicted in this article, the membership provider is membership and the role manager is rolemanager.

  5. Configure the other settings for this new web application as needed, and then click OK to create it.
  6. When prompted with the Application Created dialog box, click OK.
  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
  2. In the console tree, open the server name, and then Sites.
  3. Right-click the SharePoint Central Administration v4 site, and then click Explore.
  4. In the folder window, double-click the Web.Config file.
  5. In the <Configuration> section, find the <system.web> section and add the following example entry:

    <membership defaultProvider=”AspNetSqlMembershipProvider”>
    <providers>
    <add name=”membership”
    type=”Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
    server=”yourserver.com”
    port=”389″
    useSSL=”false”
    userDNAttribute=”distinguishedName”
    userNameAttribute=”sAMAccountName”
    userContainer=”OU=UserAccounts,DC=internal,DC=yourcompany,DC=distinguishedName (of your userContainer)”
    userObjectClass=”person”
    userFilter=”(ObjectClass=person)”
    scope=”Subtree”
    otherRequiredUserAttributes=”sn,givenname,cn” />
    </providers>
    </membership>
    <roleManager enabled=”true” defaultProvider=”AspNetWindowsTokenRoleProvider” >
    <providers>
    <add name=”roleManager”
    type=”Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
    server=”yourserver.com”
    port=”389″
    useSSL=”false”
    groupContainer=”DC=internal,DC=yourcompany,DC=distinguishedName (of your groupContainer)”
    groupNameAttribute=”cn”
    groupNameAlternateSearchAttribute=”samAccountName”
    groupMemberAttribute=”member”
    userNameAttribute=”sAMAccountName”
    dnAttribute=”distinguishedName”
    groupFilter=”((ObjectClass=group)”
    userFilter=”((ObjectClass=person)”
    scope=”Subtree” />
    </providers>
    </roleManager>

 

In the preceding entry, substitute the following:

  • The name of your membership provider in <add name=”membership”.
  • The fully qualified domain name (FQDN) of your domain controller (your LDAP server) in server=”yourserver.com”.
  • The distinguished name of your user container in userContainer=”OU=UserAccounts,DC=internal,DC=yourcompany,DC=distinguishedName (of your userContainer)”.
  • The name of your role manager in <add name=”roleManager”.
  • The distinguished name of your group container in groupContainer=”DC=internal,DC=yourcompany,DC=distinguishedName (of your groupContainer)”.

After you add this entry, save and close the Web.Config file.

  • Configure the Security Token Service Web.Config file

The following procedure configures the Security Token Service to recognize and use the new forms-based membership provider and role manager.

To configure the Security Token Service Web.Config file

  1. In the console tree of Internet Information Services (IIS) Manager, open the SharePoint Web Services site.
  2. In the console tree, right-click SecurityTokenServiceApplication, and then click Explore.
  3. In the folder window, double-click the Web.Config file.
  4. In the <Configuration> section, create a new <system.web> section and add the following example entry:

    <membership>
    <providers>
    <add name=”membership”
    type=”Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
    server=”yourserver.com”
    port=”389″
    useSSL=”false”
    userDNAttribute=”distinguishedName”
    userNameAttribute=”sAMAccountName”
    userContainer=”OU=UserAccounts,DC=internal,DC=yourcompany,DC=com”
    userObjectClass=”person”
    userFilter=”(&amp;(ObjectClass=person))”
    scope=”Subtree”
    otherRequiredUserAttributes=”sn,givenname,cn” />
    </providers>
    </membership>
    <roleManager enabled=”true” >
    <providers>
    <add name=”rolemanager”
    type=”Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
    server=”yourserver.com”
    port=”389″
    useSSL=”false”
    groupContainer=”DC=internal,DC=yourcompany,DC=com”
    groupNameAttribute=”cn”
    groupNameAlternateSearchAttribute=”samAccountName”
    groupMemberAttribute=”member”
    userNameAttribute=”sAMAccountName”
    dnAttribute=”distinguishedName”
    groupFilter=”(&amp;(ObjectClass=group))”
    userFilter=”(&amp;(ObjectClass=person))”
    scope=”Subtree” />
    </providers>
    </roleManager>

 

In the preceding entry, substitute the following:

  • The name of your membership provider in <add name=”membership”.
  • The FQDN of your domain controller (your LDAP server) in server=”yourserver.com”.
  • The distinguished name of your user container in userContainer=”OU=UserAccounts,DC=internal,DC=yourcompany,DC=com”.
  • The name of your role manager in <add name=”roleManager”.
  • The distinguished name of your group container in groupContainer=”DC=internal,DC=yourcompany,DC=com”.

After you add this entry, save and close the Web.Config file.

  • Configure the new web application Web.Config file

The following procedure configures the new web application to recognize and use the new forms-based membership provider and role manager.

To configure the new web application Web.Config file

  1. In the console tree of Internet Information Services (IIS) Manager, right-click the site that corresponds to the name of the web applications that you just created, and then click Explore.
  2. In the folder window, double-click the Web.Config file.
  3. In the <Configuration> section, find the <system.web> section.
  4. Find the <membership defaultProvider=”i”> section and add the following example entry to the <Providers> section:

    <add name=”membership”
    type=”Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
    server=”yourserver.com”
    port=”389″
    useSSL=”false”
    userDNAttribute=”distinguishedName”
    userNameAttribute=”sAMAccountName”
    userContainer=”OU=UserAccounts,DC=internal,DC=yourcompany,DC=com”
    userObjectClass=”person”
    userFilter=”(&amp;(ObjectClass=person))”
    scope=”Subtree”
    otherRequiredUserAttributes=”sn,givenname,cn” />

 

In the preceding entry, substitute the following:

  • The name of your membership provider in <add name=”membership”.
  • The FQDN of your domain controller (your LDAP server) in server=”yourserver.com”.
  • The distinguished name of your user container in userContainer=”OU=UserAccounts,DC=internal,DC=yourcompany,DC=com”.
  1. Find the <roleManager defaultProvider=”c” enabled=”true” cacheRolesInCookie=”false”> section and add the following example entry to the <Providers> section:

<add name=”roleManager”
type=”Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
server=”yourserver.com”
port=”389″
useSSL=”false”
groupContainer=”DC=internal,DC=yourcompany,DC=com”
groupNameAttribute=”cn”
groupNameAlternateSearchAttribute=”samAccountName”
groupMemberAttribute=”member”
userNameAttribute=”sAMAccountName”
dnAttribute=”distinguishedName”
groupFilter=”(&amp;(ObjectClass=group))”
userFilter=”(&amp;(ObjectClass=person))”
scope=”Subtree” />

 

In the preceding entry, substitute the following:

  • The name of your role manager in <add name=”roleManager”.
  • The FQDN of your domain controller (your LDAP server) in server=”yourserver.com”.
  • The distinguished name of your group container in groupContainer=”DC=internal,DC=yourcompany,DC=com”.

After you add the preceding entry, save and close the Web.Config file.

    Warning:

Do not overwrite any existing entries in this Web.Config file.

  • Create a new web application that uses forms-based authentication with Windows PowerShell

    Perform the following procedure to create a web application that uses forms-based authentication with Windows PowerShell.

    To create a new web application that uses forms-based authentication with Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. From the Windows PowerShell command prompt, type the following:

    $ap = New-SPAuthenticationProvider -Name <Name> -ASPNETMembershipProvider <Membership Provider Name> -ASPNETRoleProviderName <Role Manager Name>
    $wa = New-SPWebApplication -Name     <Name> -ApplicationPool <ApplicationPool> -ApplicationPoolAccount <ApplicationPoolAccount> -Url <URL> -Port <Port> -AuthenticationProvider $ap

    Example

    $ap = New-SPAuthenticationProvider -Name “ClaimsForms” -ASPNETMembershipProvider “membership” -ASPNETRoleProviderName “rolemanager”
    $wa = New-SPWebApplication -Name “FBA Web App” -ApplicationPool “Claims App Pool” -ApplicationPoolAccount “internal\appool” -Url http://contoso.com -Port 1234 -AuthenticationProvider $ap

    Note:

The value of the ApplicationPoolAccount parameter must be a managed account on the farm.

  1. After you successfully create the new web application, modify the following Web.Config files:
  1. After you change the Web.Config files, create a SPClaimsPrincipal and a site collection, as shown in the following example:

    $cp = New-SPClaimsPrincipal -Identity “membership:SiteOwner” -IdentityType FormsUser
    $sp = New-SPSite http://servername:port -OwnerAlias $cp.Encode() -Template “STS#0”

    For more information, see New-SPClaimsPrincipal.

    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.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. From the Windows PowerShell command prompt, type the following:

    $svc = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
    $svc.MembershipUserKeyType=[Microsoft.SharePoint.Administration.SPMembershipUserKeyType]::ProviderUserKey
    $svc.Update()

 

 

  1. Configure AD FS for a relying party
  2. Configure the claim rule
  3. Export the token signing certificate

Use the procedure in this section to configure a relying party. The relying party defines how the AD FS recognizes the relying party application and issues claims to it.

To configure AD FS for a relying party

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups
  2. On the AD FS server, open the Active Directory Federation Services (AD FS) 2.0 Management console.
  3. In the navigation pane, expand Trust Relationships, and then double-click the Relying Party Trusts folder.
  4. In the right pane, click Add Relying Party Trust.

    This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

  5. On the Welcome to the Add Relying Party Trust Wizard page, click Start.
  6. Select Enter data about the relying party manually, and then click next.
  7. Type a relying party name and then click Next.
  8. Make sure Active Directory Federation Services (AD FS) 2.0 Profile is selected, and then click Next.
  9. Do not use an encryption certificate. Click Next.
  10. Click to select the Enable support for the WS-Federation Passive protocol check box.
  11. In the WS-Federation Passive protocol URL field, type the name of the web application URL, and append /_trust/ (for example, https://WebAppName/_trust/). Click Next.

    Note:

The name of the URL has to use Secure Sockets Layer (SSL).

  1. Type the name of the relying party trust identifier (for example, urn:sharepoint:WebAppName), and then click Add. Click Next. Note that this will be the realm value when you configure a new SPTrustedIdentityTokenIssuer in Phase 3.
  2. Select Permit all users to access this relying party. Click Next.
  3. On the Ready to Add Trust page, there is no action required, click Next.
  4. On the Finish page, click Close. This opens the Rules Editor Management console. Use this console and the next procedure to configure the mapping of claims from your chosen directory source to SharePoint 2013.

Use the procedure in this step to send values of a Lightweight Directory Access Protocol (LDAP) attribute as claims and specify how the attributes will map to the outgoing claim type.

To configure a claim rule

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups
  2. On the Issuance Transform Rules tab, click Add Rule.
  3. On the Select Rule Template page, select Send LDAP Attributes as Claims. Click Next.
  4. On the Configure Rule page, type the name of the claim rule in the Claim rule name field.
  5. From the Attribute Store drop-down list, select Active Directory.
  6. In the Mapping of LDAP attributes to outgoing claim types section, under LDAP Attribute, select SAM-Account-Name.
  7. Under Outgoing Claim Type, select E-Mail Address.
  8. Under LDAP Attribute, select User-Principal-Name.
  9. Under Outgoing Claim Type, select UPN.
  10. Click Finish, and then click OK.

Use the procedure in this section to export the token signing certificate of the AD FS server with which you want to establish a trust relationship, and then copy the certificate to a location that SharePoint 2013 can access.

To export a token signing certificate

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups
  2. On the AD FS server, open the Active Directory Federation Services (AD FS) 2.0 Management console.
  3. In the navigation pane, expand Service, and then click the Certificates folder.
  4. Under Token signing, click the primary token certificate as indicated in the Primary column.
  5. In the right pane, click View Certificate link. This displays the properties of the certificate.
  6. Click the Details tab.
  7. Click Copy to File. This starts the Certificate Export Wizard.
  8. On the Welcome to the Certificate Export Wizard page, click Next.
  9. On the Export Private Key page, click No, do not export the private key, and then click Next.
  10. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.
  11. On the File to Export page, type the name and location of the file that you want to export, and then click Next. For example, enter C:\ADFS.cer.
  12. On the Completing the Certificate Export Wizard page, click Finish.
  1. Exporting multiple parent certificates
  2. Import a token signing certificate by using Windows PowerShell
  3. Define a unique identifier for claims mapping by using Windows PowerShell
  4. Create a new authentication provider

To complete the configuration of the AD FS server, copy the .CER file to the computer that is running AD FS.

The token signing certificate may have one or more parent certificates in its chain. If it does, every certificate in that chain has to be added to the SharePoint 2013 list of trusted root authorities.

To determine whether one or more parent certificates exist, follow these steps.

    Note:

These steps should be repeated until all certificates are exported up to the root authority certificate.

To export multiple parent certificates

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups
  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.
  3. In the navigation pane, expand Service, and then click the Certificates folder.
  4. Under Token signing, click the primary token certificate as indicated in the Primary column.
  5. In the right pane, click View Certificate link. This displays the properties of the certificate.
  6. Click the Certification tab. This displays any other certificate(s) in the chain.
  7. Click the Details tab.
  8. Click Copy to File. This starts the Certificate Export Wizard.
  9. On the Welcome to the Certificate Export Wizard page, click Next.
  10. On the Export Private Key page, click No, do not export the private key, and then click Next.
  11. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.
  12. On the File to Export page, type the name and location of the file that you want to export, and then click Next. For example, enter C:\adfsParent.cer.
  13. On the Completing the Certificate Export Wizard page, click Finish.

Use this section to import the token signing certificates to the trusted root authority list that resides on the SharePoint Server. This step must be repeated for every token signing certificate in the chain until the root certification authority is reached.

To import a token signing certificate by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. From the Windows PowerShell command prompt, import the parent certificate of the token signing certificate (that is, the root authority certificate), as shown in the following syntax:

    $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<PathToParentCert>“)

    New-SPTrustedRootAuthority -Name “Token Signing Cert Parent” -Certificate $root

  2. From the Windows PowerShell command prompt, import the token signing certificate that was copied from the AD FS server, as shown in the following syntax:

    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<PathToSigningCert>“)

    New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $cert

For additional information about the New-SPTrustedRootAuthority cmdlet, see New-SPTrustedRootAuthority

Use the procedure in this section to define a unique identifier for claims mapping. Typically, this information is in the form of an e-mail address and the administrator of the trusted STS will have to provide this information because only the owner of the STS knows which claim type will be always unique for each user.

To define a unique identifier for claims mapping by using Windows PowerShell

  1. Start the SharePoint 2013 Management Shell.
  1. From the Windows PowerShell command prompt, create an identity claim mapping, as shown in the following syntax:

    $emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221; -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

  2. From the Windows PowerShell command prompt, create the UPN claim mapping as shown in the following syntax:

    $upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&#8221; -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming

For additional information about the New-SPClaimTypeMapping cmdlet, see New-SPClaimTypeMapping

Use the procedure in this section to create a new SPTrustedIdentityTokenIssuer.

To create a new authentication provider by using Windows PowerShell

  1. Start the SharePoint 2013 Management Shell.
  1. From the Windows PowerShell command prompt, create a new authentication provider, as shown in the following syntax.

    Note:

The $realm variable defines the trusted STS that identifies a specific SharePoint farm and the $cert variable is the one that was used from the Import a token signing certificate by using Windows PowerShell section. The SignInUrl parameter is to the AD FS server.

$realm = “urn:sharepoint:<WebAppName>“

$signInURL = “https://<YourADFSServerName>/adfs/ls”

$ap = New-SPTrustedIdentityTokenIssuer -Name <ProviderName> -Description <ProviderDescription> -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $emailClaimMap,$upnClaimMap -SignInUrl $signInURL -IdentifierClaim $emailClaimmap.InputClaimType

For additional information about the New-SPTrustedIdentityTokenIssuer cmdlet, see New-SPTrustedIdentityTokenIssuer

  1. Associate an existing web application with the AD FS identity provider
  2. Create a new web application with the AD FS identity provider

To configure an existing web application to use SAML sign-in, the trusted identity provider in the claims authentication type section must be changed.

To configure an existing web application to use the AD FS identity provider

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. In Central Administration, on the home page, click Application Management.
  3. On the Application Management page, in the Web Applications section, click Manage web applications.
  4. Click the appropriate web application.
  5. From the ribbon, click Authentication Providers.
  6. Under Zone, click the name of the zone. For example, Default.
  7. On the Edit Authentication page in the Claims Authentication Types section, select Trusted Identity provider, and then click the name of your SAML provider (<ProviderName> from the New-SPTrustedIdentityTokenIssuer command). Click OK.
  8. Next, you must enable SSL for this web application. You can do this by adding an alternate access mapping for the “https://“ version of the web application‘s URL and then configuring the web site in the Internet Information Services (IIS) Manager console for an https binding. For more information about how to set up SSL for IIS, see How to Setup SSL on IIS 7.0.

When creating a new web application to use SAML sign-in, you must configure claims authentication for the AD FS trusted identity provider. See Create claims-based web applications in SharePoint 2013 and do the following:

  • In the Security Configuration section of the New Web Application dialog box, for Use Secure Sockets Layer (SSL), select Yes.

    For information about how to set up SSL for IIS, see How to Setup SSL on IIS 7.0.

  • In the Claims Authentication Types section of the New Web Application dialog box, select Trusted Identity provider, and then click the name of your SAML provider (<ProviderName> from the New-SPTrustedIdentityTokenIssuer command).

 

 

  1. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • Securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. In the SharePoint 2013 environment on the farm that is receiving server-to-server requests, start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    New-SPTrustedSecurityTokenIssuer –MetadataEndpoint “https://<HostName>/_layouts/15/metadata/json/1&#8221; –IsTrustBroker –Name “<FriendlyName>”

    Where:

  • <HostName> is the name and port of any SSL-enabled web application of the farm that will be sending server-to-server requests.
  • <FriendlyName> is a friendly name for the sending SharePoint 2013 farm.
  1. Repeat step 3 for all SharePoint 2013 farms that will be sending server-to-server requests.

    Note:

For more information, see New-SPTrustedSecurityTokenIssuer.

The recommended best practice for server-to-server authentication is that each server-to-server application that establishes trust with a SharePoint farm must use a different certificate. In a cross-farm SharePoint topology, if you are required to use the same certificate across the farms, you must also set the name identifier of the SharePoint Security Token Service (STS) to be the same across those farms. The following procedure describes how to synchronize the STS name identifier across two SharePoint farms.

To synchronize the STS name identifier across SharePoint farms

  1. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • Securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. In the SharePoint 2013 environment on one of the farms, start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    Get-SPSecurityTokenServiceConfig

  2. In the display of the Get-SPSecurityTokenServiceConfig command, note the value of the NameIdentifier field, which starts with “00000003-0000-0ff1-ce00-000000000000@“. This is the name identifier of the SharePoint STS.
  3. To set the name identifier of the SharePoint STS in the other SharePoint farm, use the following Windows PowerShell commands on a server in that farm:

    $config = Get-SPSecurityTokenServiceConfig
    $config.NameIdentifier=<CommonNameIdentifier>
    $config.Update();

    Where <CommonNameIdentifier> is the value of the NameIdentifier field from step 4.

 

 

  1. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following commands:

    New-SPTrustedSecurityTokenIssuer –MetadataEndpoint “https://<HostName>/metadata/json/1&#8221; –IsTrustBroker –Name “<FriendlyName>”

    Where:

  • <HostName> is the name or address of the Exchange Server 2013 server.
  • <FriendlyName> is a friendly name for the Exchange Server 2013 server.

To configure permissions on the SharePoint 2013 server

To configure the Exchange Server 2013 server to trust the SharePoint 2013 server

  1. Start the Exchange Management Shell.
  • For Windows Server 2008 R2:
    • In the Exchange Server 2013 environment, on the Start menu, click All Programs, click Microsoft Exchange Server 2013, and then click Exchange Management Shell.
  • For Windows Server 2012:
    • In the Exchange Server 2013 environment, on the Start screen, click Exchange Management Shell.

      If Exchange Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click Exchange Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following commands:

    cd c:\’Program Files’\Microsoft\’Exchange Server’\V15\Scripts
    .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl https://<HostName>/_layouts/15/metadata/json/1 -ApplicationType SharePoint

    Where:

  • <HostName> is the name and port of any SSL-enabled web application of the SharePoint farm.

Configure server-to-server authentication in SharePoint 2013

 

 

  1. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen, right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following commands:

    New-SPTrustedSecurityTokenIssuer –MetadataEndpoint “https://<HostName>/metadata/json/1″ –IsTrustBroker –Name “<FriendlyName>“

    Where:

  • <HostName> is name or address of the server that runs Lync Server 2013.
  • <FriendlyName> is a friendly name for the server that runs Lync Server 2013.

To configure the Lync Server 2013 server to trust the SharePoint 2013 server

  1. If you have not already done this, assign a server-to-server authentication certificate to Lync Server 2013. Follow the instructions in Assigning a Server-to-Server Authentication Certificate to Microsoft Lync Server 2013.
  2. Configure the server that runs Lync Server 2013 for a new SharePoint partner application that corresponds to the SharePoint farm. For the instructions in Configuring an On-Premises Partner Application for Microsoft Lync Server 2013, change the metadata URL string in the embedded script from:

 

 

  1. Configure the SharePoint Server 2013 app authentication trust.
  2. Register the app with the Application Management service.
  3. Configure app permissions.

For information about apps for SharePoint, see Overview of apps for SharePoint 2013.

    Note:

Because SharePoint Server 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint Server 2013 supports the accessibility features of supported browsers. For more information, see the following resources:

  • Step 1. Configure the SharePoint Server 2013 app authentication trust

    There are two ways to configure an app authentication trust with SharePoint Server 2013:

    • If you have an Office 365 subscription and the app is also using Windows Azure Access Control Service (ACS) for authentication, you configure the SharePoint farm to trust the ACS instance that corresponds to your Office 365 subscription. ACS then acts as a common authentication broker between the on-premises SharePoint farm and the app and as the online security token service (STS). ACS generates the context tokens when the app requests access to a SharePoint resource.

      In this case, configure SharePoint Server 2013 to trust ACS.

    • If you do not have an Office 365 subscription or if the app does not use ACS for authentication, you must configure a server-to-server trust relationship between the SharePoint farm and the app, known as a high-trust app. A high-trust app generates its own context tokens when it requests access to a SharePoint resource. This must be done for each high-trust app that a SharePoint farm must trust. For example, if multiple apps are running on one server and if they all use different token signing certificates, you must create a separate trust with each one.

      In this case, configure SharePoint Server 2013 to trust the app.

      • Configure SharePoint Server 2013 to trust ACS

    Use the following procedure to configure SharePoint Server 2013 to trust ACS.

    To configure a SharePoint Server 2013 trust relationship with ACS

  1. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint Server 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • In the SharePoint 2013 environment, on the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    $New-SPTrustedSecurityTokenIssuer –MetadataEndpoint “<Metadata endpoint URL of ACS>” –IsTrustBroker –Name “ACS”

    Where:

  1. Keep the Windows PowerShell command prompt open for the Step 2. Register the app with the Application Management service.

  • Configure SharePoint Server 2013 to trust the app

Use the following procedure to configure SharePoint Server 2013 to trust the app.

To configure a SharePoint Server 2013 trust relationship with a high-trust app

  1. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint Server 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. In Central Administration on the SharePoint Server 2013 server in the farm, on the Quick Launch, click System Settings, and then click Manage services on server.
  2. In the list of services on the server, make sure that that User Profile Service is started.
  3. In Central Administration, on the Quick Launch, click Application Management, and then click Manage service applications.
  4. In the list of service applications, make sure that that the App Management Service and User Profile Service Application are started.
  5. Obtain a .CER version of the signing certificate of the high-trust app and store it in a location that can be accessed during the rest of this procedure.
  6. Verify that you are a member of the Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint Server 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Click Start menu, click All Programs, click SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  2. At the Windows PowerShell command prompt, type the following commands:

    $appId = “<AppID>“

    $spweb = Get-SPWeb “<AppURL>“

    $realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site

    $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<CERFilePath>“)

    $fullAppIdentifier = $appId + ‘@’ + $realm

    New-SPTrustedSecurityTokenIssuer -Name “<FriendlyName>” -Certificate $certificate -RegisteredIssuerName $fullAppIdentifier

    Where:

  • <AppID> is the client ID assigned to the high-trust app when it was created.

        Important:

All of the letters in the AppID must be in lowercase.

  • <AppURL> is the URL to the high-trust app‘s location on the app server.
  • <CERFilePath> is the path of the .CER version of the signing certificate of the high-trust app.
  • <FriendlyName> is a friendly name that identifies the app.
  1. Keep the Windows PowerShell command prompt open for the next procedure.
  1. At the Windows PowerShell command prompt, type the following command:

    $appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spweb -DisplayName “<DisplayName>”

    Where:

  • <DisplayName> is the name of the app as displayed in Central Administration.
  1. Keep the Windows PowerShell command prompt open for the next procedure.
  1. Configure AD FS to support claims-based authentication.

    For more information, see AD FS 2.0 – How to change the local authentication type (http://go.microsoft.com/fwlink/p/?LinkId=212513).

  2. Configure SharePoint 2013 to support SAML-based claims authentication using AD FS.

    For more information, see Configure SAML-based claims authentication with AD FS in SharePoint 2013.

  3. Create a web application that uses SAML-based claims authentication.

    For more information, see Create claims-based web applications in SharePoint 2013.

    Note:

These steps will be similar for a third-party STS.

 

 

  1. Install SQL Server 2012 prerequisites on each cluster node.

    For more information, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server).

  2. Install SQL Server on each cluster node.

    For more information, see Installation for SQL Server 2012.

  • Enable Named Pipes

Named Pipes is required for an AlwaysOn Availability Group. Use the following procedure to enable Named Pipes for SQL Server.

To enable Named Pipes

  1. Make sure that the logon has the required credentials. To change a network configuration for the database engine, you must be a member of the sysadmin fixed server role.
  2. Log on to the server that will host the primary replica and start SQL Server Management Studio.
  3. Expand SQL Server Network Configuration and then click Protocols for<instance name>.
  4. In the details pane, right-click Named Pipes and then click Enable from the list of available options.
  5. In the console pane, click SQL Server Services.
  6. In the details pane, right-click SQL Server ( <instance name> ) and then click Restart, to stop and restart SQL Server.
  7. Repeat the previous steps to enable Named Pipes for SQL Server on the other cluster nodes.

  • Enable AlwaysOn

After you enable Named Pipes, you must enable AlwaysOn for each of the database servers in the cluster.

    Note:

You can enable AlwaysOn by using SQL Server Management Studio, Transact-SQL, or Windows PowerShell 3.0.

To enable AlwaysOn

  1. Make sure that your logon account has the required permissions to create an availability group. The account must have membership in the db_owner fixed database role and either CREATE AVAILABILITY GROUP server permission, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.
  2. Log on to the server that will host the primary replica and start SQL Server Management Studio.
  3. In Object Explorer, select SQL Server Services, right-click SQL Server (<instance name>), where <instance name> is the name of a local server instance for which you want to enable AlwaysOn Availability Groups, and then click Properties.
  4. Select the AlwaysOn High Availability tab.
  5. Select the Enable AlwaysOn Availability Groups check box, and then click OK.
  6. Although the change is saved you must manually restart the SQL Server service (MSSQLSERVER) to commit the change. The manual restart enables you to choose a restart time that is best for your business requirements.
  7. Repeat the previous steps to enable AlwaysOn for SQL Server on the other cluster nodes.

For more information, see Enable and Disable AlwaysOn Availability Groups (SQL Server).

  • Create and configure the availability group

Depending on the SQL Server 2012 environment where you plan to create the Availability Group, you might have to create a temporary database to before you create the Availability Group.

The process that creates an availability group requires you to provide a name for the availability group and then select an eligible user database on the connected server instance as an availability database.

    Note:

To be eligible to be added to an availability group, a database must be a user database. System databases cannot belong to an availability group. For more information, see the “Availability Database Prerequisites and Restrictions” section of Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server) and see Creation and Configuration of Availability Groups (SQL Server).

If there no user databases are on the instance of the connected server, which is the case in our example, you need to create one.

Use the following procedure to create a temporary user database that will be a temporary primary replica for the group.

To create a temporary user database

  1. Make sure that your logon account has the correct permissions for this task. You require one of the following permissions in the master database to create the new database:
  • CREATE DATABASE
  • CREATE ANY DATABASE
  • ALTER ANY DATABASE
  1. Log on to the server that will host the primary replica, which is SP-SRV1 in our example.
  2. Start Management Studio.
  3. In Object Explorer, right-click Databases and then click New Database.
  4. In the New Database dialog box, type the Database name:, which is “TemporaryUserDB” for this example.

    Because this is a temporary database that you delete after you create the availability group, you can use the default settings. Click OK.

    Because the New Availability Group Wizard will not create an availability group unless the user database was backed up, you have to back up the temporary database.

  5. In Object Explorer expand Databases and right-click the temporary database that you just created. Pick Tasks and then choose Back Up.
  6. In the Back Up Database dialog box, click OK to accept all the default settings and create the back up.

  • About replicas and data synchronization

About replicas

Every availability replica is assigned an initial role—either the primary role or the secondary role, which the availability databases of that replica inherit. The role of a given replica determines whether it hosts read-write databases or read-only databases, the type of failover and whether it uses synchronous commit or asynchronous commit.

The following table shows the information that you have to provide for each replica, either when you first create the availability group, or when you add secondary replicas.

  • Replica configuration requirements

 

Replica information

Description

Server Instance

Displays the name of the instance of the server that will host the availability replica.

Initial Role

Indicates the role that the new replica will first perform: Primary or Secondary.

Automatic Failover (Up to 2)

Indicates the type of failover that the replica uses: automatic or manual.

Synchronous Commit (Up to 3)

Indicates the type of commit that is used for the replica.

Readable Secondary

Indicates whether a secondary replica can be read.

The configuration options are unavailable for read access, read-only, and read-only intent. For more information, see Readable Secondary Replicas (AlwaysOn Availability Groups).

    Important:

Readable secondary replicas are currently not supported for SharePoint 2013 runtime usage.

 

    Note:

When you add replicas to a group, you will also provide the endpoint for each replica and configure backup preferences. For more information, see Specify the Endpoint URL When Adding or Modifying an Availability Replica (SQL Server) and Backup on Secondary Replicas (AlwaysOn Availability Groups).

Data synchronization

As part of the availability group creation process, you have to make an exact copy of the data on the primary replica and install the copy on the secondary replica. This is the initial data synchronization for the Availability Group. For more information, see Select Initial Data Synchronization Page (AlwaysOn Availability Group Wizards).

A network share must exist and must be accessed by all the nodes in the AlwaysOn configuration to do the initial data synchronization between all the cluster nodes that host a replica. For more information, see Network Shares Extension and File Services.

The following restrictions exist when you use the New Availability Group wizard to start data synchronization:

  • If the file paths on the secondary replica location differ from the file paths on the primary location, you have to start data synchronization manually.
  • If any secondary database exists on a secondary replica, you have to manually delete the secondary databases before you start data synchronization in the New Availability Group. However, if you want to use existing secondary databases, exit the New Availability Group wizard and start data synchronization manually.
  • To use the availability group wizard to synchronize data, you have to have a backup share that all the replicas can write to. You can specify the share by browsing to it or by entering its fully qualified universal naming convention (UNC) path name, \\Systemname\ShareName\Path\, in the Specify a shared network location accessible by all replicas box.

For each database in the availability group, the Start Data Synchronization page shows the progress of the following operations:

  • Creating a full database backup of the primary database on the network share.
  • Creating a full database backup of the primary database on the network share.
  • Restoring these backups to the secondary replica location.

    These restore operations both use RESTORE WITH NORECOVERY option and leave the new secondary database in the RESTORING state.

  • Joining the secondary database to the availability group.

    This step puts the secondary database in the ONLINE state and starts data synchronization for this database.

Login replication

SharePoint logins that are created by using the same approach as in previous releases of SQL Server are not replicated in an availability group. This occurs because login information is stored in the MasterDB database, which is not replicated. Although the farm accounts are created when replicas are synchronized, login information is not available after a failover.

If you have already created an availability group and synchronized the primary and secondary replicas, the workaround is to manually copy the logins from the primary replica to the secondary replicas.

SQL Server 2012 introduces the concept of Users with Passwords for Contained Databases. The database itself stores all the database metadata and user information, and a user who is defined in this database does not have to have a corresponding login. The information in this database is replicated by the availability group and is available after a failover. For more information, see Contained Databases.

    Important:

If you create a new SharePoint login to use for an existing availability group, make sure to add the login to the contained database so it is replicated to each server that is hosting a SQL Server instance for the availability group. For example, if you create another application pool for a Web App and give it a new identity (an application pool account that you have not used), then you need to add that account as a login.

  • Create and configure the availability group

Use the following procedure to create an availability group on the primary replica, which is SP-SRV1 in our example.

  • Create the availability group

  1. Make sure that your logon account has the required permissions to create an availability group. This requires membership in the db_owner fixed database role and either CREATE AVAILABILITY GROUP server permission, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.
  2. Log on to the server that will host the primary replica and start SQL Server Management Studio.
  3. To start the New Availability Group Wizard, right-click AlwaysOn High Availability and then click New Availability Group Wizard.
  4. Click Next to advance to the Specify Name page. Enter SP-AG1 as the name of the new availability group in the Availability group name: box.

    This name must be: a valid SQL Server identifier, unique on the Windows Server Failover Clustering cluster and unique on the domain.

  5. On the Select Databases page, all user databases that are eligible to become the primary database for the new availability group are listed on the User databases on this instance of SQL Server grid. Select TemporaryUserDB, and then click Next.
  6. On the Specify Replicas page, use the following tabs to configure the replicas for SP-AG1: Replicas, Endpoints, and Backup Preferences.
  7. On the Listener tab, configure an availability group listener for our example.

    An availability group listener is a server name to which clients can connect r to access a database in a primary or secondary replica of an availability group. Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica. The listener provides fast application failover after an availability group fails over. For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

    Important:

Intermittent, unusually high latency might occur when you use availability groups that have replicas that are deployed on multiple subnets.

As a best practice, connections to SharePoint availability groups in a multi-subnet environment should configure specifyMultiSubnetFailover=True to avoid issues caused by high network latency. For more information, see Supporting Availability Group Multi-Subnet Failovers.

You cannot directly specify MultiSubnetFailover=True because a SharePoint client cannot directly modify a connection string. You must use Windows PowerShell to set this value on the MultiSubnetFailover database property. The following example shows how to do this.

C# 

$dbs = Get-SPDatabase | ?{$_.MultiSubnetFailover –ne $true}
foreach ($db in $dbs)
{
$db.MultiSubnetFailover = $true
$db.Update()
}

  1. Select the desired configuration for each instance in the Selected instances grid, and then click Next.
  2. Click Finish to create the availability group.
  3. The Select Initial Data Synchronization page lets you select a synchronization preference and specify the shared network location that all replicas can access. For our environment accept the default, Full, which performs full database and log backups. Click Next.
  4. The Validation page of the wizard displays the results of six checks before it lets you continue with availability group creation. If all checks pass, click Next to continue. If any tests fail, you cannot continue until you correct the error and then click Re-run Validation to run the validation tests again. When all the tests pass, click Next to continue.
  5. On the Summary page, verify the configuration of the replica that you are adding and then click Finish to save it. To change the configuration, click Previous to return to previous wizard pages.

  • Install and configure SharePoint 2013

At this point in the process, you can install SharePoint 2013 and create the farm. Use the following procedure as a guide to install and configure SharePoint 2013.

    Note:

For detailed installation and configuration instructions, see Prepare for installation of SharePoint 2013 and Install SharePoint 2013.

To install SharePoint 2013

  1. Copy the SharePoint 2013 program files to a local disk on the computer where you plan to install SharePoint products or to a network file share.
  2. Run the Microsoft SharePoint Products Preparation Tool to install all the prerequisites to set up and use SharePoint 2013.
  3. Run Setup to install binaries, configure security permissions, and edit registry settings for SharePoint 2013.
  4. Run the SharePoint Products Configuration Wizard to install and configure the configuration database, install and configure the content database, and install the SharePoint Central Administration website.

    Note:

When you run the configuration wizard, you have to identify the server that will host the SharePoint databases. On the Specify Configuration Database Settings page, in the Database server box, type SP-SRV1 as the name of the computer that is running SQL Server.

To finalize setup of AlwaysOn for a SharePoint 2013 farm, add the SharePoint databases to the availability group and synchronize secondary replicas to the primary replica.

    Important:

Only add the databases that are supported for use with a SQL Server AlwaysOn Availability Group.

On the server that hosts the primary replica, you have to run the Add Databases to Availability Group wizard to add all the SharePoint databases to the availability group. The following procedure is the same as the procedure that we described to create the availability group.

To add SharePoint databases to the availability group

  1. Log on to the server that will host the primary replica and start SQL Server Management Studio.

    The account that that you use must be a member of the Local Administrators group for each server where you install SharePoint 2013

    In addition, the account must have at least one of the following permissions:

  • ALTER AVAILABILITY GROUP permission on the availability group
  • CONTROL AVAILABILITY GROUP permission
  • ALTER ANY AVAILABILITY GROUP permission
  • CONTROL SERVER permission

    To join a database to availability group requires membership in the db_owner fixed database role.

  1. In Object Explorer, browse to, and if it is necessary expand the Availability Groups.
  2. Right-click the example group, SP-AG1, and then click Add Database.
  3. On the Select Databases page, all user databases that are eligible to become the primary database for the new availability group are listed on the User databases on this instance of SQL Server grid. Use the checkboxes to select all the databases that you want to add to the group, and then click Next.
  4. The Select Initial Data Synchronization page lets you select a synchronization preference and specify the shared network location that all replicas can access. For our environment we’ll accept the default, Full, which performs full database and log backups. Click Next.
  5. The Validation page of the wizard displays the results of six checks before it lets you continue with availability group creation. If any tests fail, you cannot continue until you correct the error and then click Re-run Validation to run the validation tests again. When all the tests pass, click Next to continue.
  6. On the Summary page, verify the configuration of the replica that you are adding, and then click Finish to keep it. To change the configuration, click Previous to return to previous wizard pages.

    Important:

Databases that you add to a SharePoint farm are not automatically added to the availability group. You must add them by using the steps described in this article or by using scripts to automate the procedure.

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the front-end web server.
  2. Click Start, point to Administrative Tools, and then click Server Manager.
  3. In Server Manager, click Features.
  4. In Features Summary, click Add Features to open the Add Features Wizard.
  5. On the Select Features page, select SMTP Server.
  6. In the Add Features Wizard dialog box, click Add Required Roll Services, and then click Next.
  7. On the Confirm Installation Selections page, click Install.
  8. On the Installation Results page, ensure that the installation finished successfully, and then click Close.

  • Install IIS 6.0 Management tools

To manage the SMTP service on Windows Server 2008 and Windows Server 2008 R2, you must use Internet Information Services (IIS) 6.0 Manager.

To install IIS 6.0 Manager

  1. Verify that you have the following administrative credentials:
  • You must be a member of the Administrators group on the front-end web server.
  1. Click Start, point to Administrative Tools, and then click Server Manager.
  2. In Server Manager, click Roles.
  3. In Application Server section, click Add Role Services.
  4. On the Select Role Services page, select Management Tools and IIS 6 Management compatibility, and then click Install.

  • Configure the SMTP service

After you install the SMTP service, you configure it to accept email from the mail server for the domain. You can decide to accept relayed email from all servers except those that you specifically exclude. Alternatively, you can block email from all servers except those that you specifically include. You can include servers individually, in groups by subnet, or in groups by domain.

After you configure the service, set it to start automatically.

To configure the SMTP service

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the front-end web server.
  2. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) 6.0 Manager.
  3. In IIS Manager, expand the server name that contains the SMTP server that you want to configure.
  4. Right-click the SMTP virtual server that you want to configure, and then click Start.
  5. Right-click the SMTP virtual server that you want to configure, and then click Properties.
  6. On the Access tab, in the Access control area, click Authentication.
  7. In the Authentication dialog box, verify that Anonymous access is selected.
  8. Click OK.
  9. On the Access tab, in the Relay restrictions area, click Relay.
  10. To enable relaying from any server, click All except the list below.
  11. To accept relaying from one or more specific servers, follow these steps:
    1. Click Only the list below.
    2. Click Add, and then add servers one at a time by IP address, or in groups by using a subnet or domain.
    3. Click OK to close the Computer dialog box.
  12. Click OK to close the Relay Restrictions dialog box.
  13. Click OK to close the Properties dialog box.

To set the SMTP service to start automatically

  1. Click Start, point to Administrative Tools, and then click Services.
  2. In Services, right-click Simple Mail Transfer Protocol (SMTP), and then select Properties.
  3. In the Simple Mail Transfer Protocol (SMTP) Properties dialog box, on the General tab, in the Startup type list, select Automatic.
  4. Click OK.

  • Configure incoming email in a basic scenario

    You can use the following procedure to configure incoming email in a basic scenario by selecting the Automatic settings mode and using the default settings. After you complete the procedure, users can send email to lists and libraries.

    To configure incoming email in a basic scenario

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the server that is running the SharePoint Central Administration website.
  2. In Central Administration, click System Settings.
  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure incoming e-mail settings.
  4. If you want to enable sites on this server to receive email, on the Configure Incoming E-Mail Settings page, in the Enable Incoming E-Mail section, click Yes.
  5. Select the Automatic settings mode.
  6. In the Incoming E-Mail Server Display Address section, in the E-mail server display address box, type a display name for the email server, for example, mail.fabrikam.com.
  7. Use the default settings for all other sections, and then click OK.

After you configure incoming email, users who have Manage Lists permissions can configure email–enabled lists and document libraries.

  • Configure incoming email in an advanced scenario

    You can use the following procedure to configure incoming email in an advanced scenario by selecting the Advanced settings mode and additional options that you want to use for your incoming email environment. After you complete the procedure, users can send email to lists and libraries.

    You can also use the Automatic settings mode in an advanced scenario. In the Automatic settings mode, you can select to receive email that has been routed through a safe-email server application. In the Advanced settings mode, you can instead specify a drop folder. For more information, see Plan incoming email (SharePoint 2013 Preview).

    Several of these steps mention prerequisite procedures that are documented in Prepare your environment for incoming email in an advanced scenario later in this article.

    To configure incoming email in an advanced scenario

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the server that is running the SharePoint Central Administration website.
  2. In Central Administration, click System Settings.
  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure incoming e-mail settings.
  4. If you want to enable sites on this server to receive email, on the Configure Incoming E-mail Settings page, in the Enable Incoming E-Mail section, click Yes.
  5. Select the Advanced settings mode.

    You can specify a drop folder instead of using an SMTP server.

    Note:

You can also select the Automatic settings mode and select whether to use Directory Management Service and whether to accept email from all email servers or from several specified email servers. For more information, see Plan incoming email (SharePoint 2013 Preview).

  1. If you want to connect to Directory Management Service, in the Directory Management Service section, click Yes.

    If you select this option, you must first configure Active Directory Domain Services (AD DS). If you use Exchange Server, you must also configure the DNS Manager and add an SMTP connector. For more information, see Configure AD DS to be used with Directory Management Service, Configure DNS Manager, and Add an SMTP connector in Microsoft Exchange Server 2010 later in this article.

    1. In the Active Directory container where new distribution groups and contacts will be created box, type the name of the container in the format OU=ContainerName, DC=domain, DC=com, where ContainerName is the name of the OU in AD DS, domain is the second-level domain, and com is the top-level domain.

    The application pool identity account for Central Administration must be delegated the Create, delete, and manage user accounts task for the container. Access is configured in the properties for the OU in AD DS.

    1. In the SMTP mail server for incoming mail box, type the name of the SMTP mail server. The server name must match the FQDN in the A resource record entry for the mail server in DNS Manager.
    2. To accept messages only from authenticated users, click Yes for Accept messages from authenticated users only. Otherwise, click No.
    3. To enable users to create distribution groups from SharePoint sites, click Yes for Allow creation of distribution groups from SharePoint sites. Otherwise, click No.
    4. Under Distribution group request approval settings, select the actions that will require approval. Actions include the following:
  • Create new distribution group
  • Change distribution group e-mail address
  • Change distribution group title and description
  • Delete distribution group
  1. If you want to use a remote Directory Management Service, select Use remote and complete the remainder of this step. Otherwise, click No and proceed to step 8.

    If you select this option and you are using Exchange Server, you must configure the DNS Manager and add an SMTP connector. For more information, see Configure DNS Manager and Add an SMTP connector in Microsoft Exchange Server 2010 later in this article. The AD DS has most likely already been configured, so you do not need to do this.

    1. In the Directory Management Service URL box, type the URL of the Directory Management Service that you want to use. The URL is typically in the following format: http://server:adminport/_vti_bin/SharePointEmailWS.asmx.
    2. In the SMTP mail server for incoming mail box, type the name of the SMTP mail server. The server name must match the FQDN in the A resource record entry for the mail server in DNS Manager on the domain server.
    3. To accept messages from authenticated users only, click Yes for Accept messages from authenticated users only. Otherwise, click No.
    4. To allow creation of distribution groups from SharePoint sites, click Yes for Allow creation of distribution groups from SharePoint sites. Otherwise, click No.
  2. In the Incoming E-Mail Server Display Address section, in the E-mail server display address box, type a display name for the email server (for example, mail.fabrikam.com). You typically use this option together with the Directory Management Service.

    Tip:

You can specify the email server address that is displayed when users create an incoming email address for a list or group. Use this setting together with Directory Management Service to provide an email server address that is easy to remember.

  1. In the E-Mail Drop Folder section, in the E-mail drop folder box, type the name of the folder from which the Windows SharePoint Services Timer service retrieves incoming email from the SMTP service. This option is available only if you selected Advanced settings mode. If you select this option, ensure that you configure the necessary permissions to the email drop folder. For more information, see Configure permissions to the email drop folder later in this article.

    It is useful to have a dedicated email drop folder if the default email drop folder is full or almost full.

    Ensure that the logon account for the SharePoint Timer service has Modify permissions on the email drop folder. For more information, see To configure email drop folder permissions for the logon account for the SharePoint Timer service later in this article.

  2. In the Safe E-Mail Servers section, select whether you want to accept email from all email servers or from specific email servers.

    This option is available only if you selected Automatic settings mode.

  3. Click OK.

After you configure incoming email, site administrators can configure email–enabled lists and document libraries.

If you selected Directory Management Service, contact addresses that are created for document libraries appear automatically in Active Directory Users and Computers. The addresses are displayed in the OU of AD DS for SharePoint 2013 and must be managed by the administrator of AD DS. The AD DS administrator can add more email addresses for each contact. For more information about AD DS, see Using Active Directory Service in the TechNet Library.

Alternatively, you can configure the computer running Exchange Server by adding a new Exchange Server Global recipient policy. The policy automatically adds external addresses that use the second-level domain name and not the subdomain or host name for SharePoint 2013. For more information about how to manage Exchange Server, see Recipient Configuration Node in the Exchange Server Technical Library.

  1. Verify that the user account that is performing this procedure is a member of the Domain Administrators group or a delegated authority for domain administration on the domain controller that is running DNS Manager.
  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  3. In Active Directory Users and Computers, right-click the folder for the second-level domain that contains your server farm, point to New, and then click Organizational Unit.
  4. Type the name of the OU, and then click OK.

    After you create the OU, you must delegate the Create, delete, and manage user accounts right to the container of the OU to manage the user accounts.

To delegate the right to the application pool identity account for Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Domain Administrators group or the Enterprise Administrators group in AD DS, or a delegated authority for domain administration.
  2. In Active Directory Users and Computers, find the OU that you created.
  3. Right-click the OU, and then click Delegate control.
  4. On the Welcome page of the Delegation of Control Wizard, click Next.
  5. On the Users and Groups page, click Add, and then type the name of the application pool identity account that the Central Administration uses.
  6. In the Select Users, Computers, and Groups dialog box, click OK.
  7. On the Users or Groups page of the Delegation of Control Wizard, click Next.
  8. On the Tasks to Delegate page of the Delegation of Control Wizard, select the Create, delete, and manage user accounts check box, and then click Next.
  9. On the last page of the Delegation of Control Wizard, click Finish to exit the wizard.

To create and delete child objects, you must also delegate Create all Child Objects and Delete all Child Objects control of the OU to the application pool identity account for Central Administration. After you complete this procedure, the application pool identity account for Central Administration has Create all Child Objects and Delete all Child Objects control on the OU, and you can enable incoming email.

To delegate Create all Child Objects and Delete all Child Objects control of the OU to the application pool identity account for Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Domain Administrators group or the Enterprise Administrators group in AD DS, or a delegated authority for domain administration.
  2. Right-click the OU, and then click Delegate control.
  3. In the Delegation of Control Wizard, click Next.
  4. Click Add, and then type the name of the application pool identity account for Central Administration.
  5. Click OK.
  6. Click Next.
  7. On the Tasks to Delegate page of the Delegation of Control Wizard, select Create a custom task to delegate, and then click Next.
  8. Click This folder, existing objects in this folder, and creation of new objects in this folder, and then click Next.
  9. In the Permissions section, select Create all Child Objects and Delete all Child Objects.
  10. Click Next.
  11. On the last page of the Delegation of Control Wizard, click Finish to exit the wizard.

Delegating Create all Child Objects and Delete all Child Objects control of the OU to the application pool identity account for Central Administration enables administrators to enable email for a list. After these controls have been delegated, administrators cannot disable email for the list or document library because the Central Administration account tries to delete the contact from the whole OU instead of from the list.

To avoid this problem, you must add Delete Subtree permissions for the application pool identity account for Central Administration. Use the following procedure to add these permissions. After this procedure is complete, you can disable incoming email for a list.

To add Delete Subtree permissions for the application pool identity account for Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Domain Administrators group or the Enterprise Administrators group in AD DS, or a delegated authority for domain administration.
  2. In Active Directory Users and Computers, click the View menu, and then click Advanced Features.
  3. Right-click the OU, and then click Properties.
  4. In the Properties dialog box, click the Security tab, and then click Advanced.
  5. In the Permission Entries area, double-click the application pool identity account for Central Administration.

    If the application pool identity account is listed more than once, select the first one.

  6. In the Permissions area, select Allow, for Delete Subtree.
  7. Click OK to close the Permissions dialog box.
  8. Click OK to close the Properties dialog box.
  9. Click OK to close Active Directory Users and Computers.

After you add these permissions, you must restart Internet Information Services (IIS) for the farm.

For more information, see Active Directory Users, Computers, and Groups in the TechNet Library.

If you are using Exchange Server and are routing email internally in your organization, you must create a host (A) resource record in DNS Manager to associate DNS domain names of computers (or hosts) to their IP addresses. Your organization might already have a configured DNS Manager and an A resource record. If not, then use the following procedure.

To create an A resource record for a subdomain

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.
  2. In DNS Manager, select the forward lookup zone for the domain that contains the subdomain for SharePoint 2013.
  3. Right-click the zone, and then click New Host (A or AAAA).
  4. In the New Host dialog box, in the Name text box, type the host or subdomain name for SharePoint 2013.
  5. In the Fully qualified domain name (FQDN) text box, type the FQDN for the server that is running SharePoint 2013. This is typically in the format subdomain.domain.com.
  6. Ensure that the domains that are listed under the SMTP server in IIS match the FQDN of the server that receives email. If they do not match, you must create a local domain. For instructions, see To create a local domain later in this article.
  7. In the IP address text box, type the IP address to which you want the FQDN to resolve.
  8. Click Add Host.
  9. In the message that confirms the creation of the host record, click OK.
  10. In the New Host dialog box, click Done.

    The A resource record now appears in DNS Manager.

If you use the E-mail server display address option and if the email address to which you are sending email messages is not the same as your server name, you must create a local domain.

To create a local domain

  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) 6.0 Manager.
  2. In IIS Manager, expand the SMTP server.
  3. Right-click Domains, and on the Action menu, point to New, and then click Domain.
  4. In the New SMTP Domain Wizard dialog box, select Alias, and then click Next.
  5. In the Domain Name area, in the Name box, type the address of the mail that is to be received by this domain.

    This address must be the same as the one that you specified in step 4 in To create an A resource record for a subdomain, and in step 6b in To configure incoming email in an advanced scenario.

  6. Click Finish.
  7. In the message that confirms the creation of the host record, click OK.
  8. Restart the SMTP server so that all email messages that are still in the Queue folder move to the Drop folder. The messages are then sent by the Windows SharePoint Services Timer service to their destination list or library.

    Note:

If you are routing email from outside your organization to an SMTP server, you must use an MX record. For more information, see Add a mail exchanger (MX) resource record to a zone in the Windows Server Technical Library.

An SMTP connector gives you more control over the message flow in your organization. Other reasons to use an SMTP connector are to set delivery restrictions or to specify a specific address space. If you use Exchange Server to route incoming email to SharePoint lists and libraries, you must have an SMTP connector so that all mail that is sent to the SharePoint domain uses the servers that are running the SMTP service.

Use the following procedure to add an SMTP connector in Exchange Server. After you complete the procedure, the SMTP connector ensures that incoming email messages are sent to the correct list and library in the farm.

To add an SMTP connector in Exchange Server

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the server that is running Exchange Server.
  2. In Exchange Management Console, expand the Organization Configuration group, right-click Hub Transport, point to New Send Connector.

    The New Send Connector wizard appears.

  3. On the Introduction page, do the following and then click Next:
    1. In the Name box, type a name for the SMTP connector.
    2. In the Select the intended use for this Send connector box, select the Custom usage type for the connector.
  4. On the Address Space page, click Add, and then click SMTP Address Space.
  5. In the SMTP Address Space dialog box, do the following:
    1. In the Address box, type an email domain for the connector.
    2. In the Cost box, assign an appropriate cost. By default, the cost is 1.
  6. Click OK to return to the Address Space page, and then click Next.
  7. On the Network settings page, select Use domain name system (DNS) “MX” records to route mail automatically, and then click Next.
  8. On the Source Server page, click Next.

    The Source server page only appears on Hub Transport servers. By default, the Hub Transport server that you are currently working on is listed as a source server.

  9. On the New Connector page, review your options and then click New to create the new send connector.
  10. On the Completion page, ensure that the send connector was created, and then click Finish.

    In the Hub Transport pane, you can see that the send connector has been enabled automatically.

For more information, see Create an SMTP Send Connector in the Exchange Server Technical Library.

You can specify a particular email drop folder, which enables SharePoint 2013 to retrieve incoming email from a network share on another server. You can use this option if you do not want to use an SMTP service. However, the drawback of using this option is that SharePoint 2013 cannot detect configuration changes on the remote email server that is delivering email to the drop folder. The result is that SharePoint 2013 cannot retrieve email if the location of the email messages has changed. However, this feature is useful if the default email drop folder is full or almost full.

If you specified an email drop folder, you must ensure that the application pool identity accounts for Central Administration and for the web application have the required permissions to the email drop folder.

  • Configure email drop folder permissions for the application pool identity account for a web application

If your deployment uses different application pool identity accounts for Central Administration and for one or more web applications, each application pool identity account must have permissions to the email drop folder. If the application pool identity account for the web application does not have the required permissions, email will not be delivered to document libraries on that web application.

In most cases, when you configure incoming email and select an email drop folder, permissions are added for the following worker process groups:

  • WSS_Admin_WPG, which includes the application pool identity account for Central Administration and the logon account for the SharePoint Timer service, and has Full Control permissions.
  • WSS_WPG, which includes the application pool accounts for web applications, and has Read & Execute, List Folder Contents, and Read permissions.

In some cases, these groups might not be configured automatically for the email drop folder. For example, if Central Administration is running as the Network Service account, the groups or accounts that are needed for incoming email will not be added when the email drop folder is created. Check to determine whether these groups have been added automatically to the email drop folder. If the groups have not been added automatically, you can add them or add the specific accounts that are required.

To configure email drop folder permissions for the application pool identity account for a web application

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the server that contains the email drop folder.
  2. In Windows Explorer, right-click the drop folder, click Properties, and then click the Security tab.
  3. On the Security tab, under the Group or user names box, click Edit.
  4. In the Permissions for Windows Explorer dialog box, click Add.
  5. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type the name of the worker process group or application pool identity account for the web application, and then click OK.

    This account is listed on the Identity tab of the Properties dialog box for the application pool in IIS.

  6. In the Permissions for User or Group box, next to Modify, select Allow.
  7. Click OK.

  • Configure email drop folder permissions for the logon account for the SharePoint Timer service

Ensure that the logon account for the Windows SharePoint Services Timer service has Modify permissions on the email drop folder. If the logon account for the service does not have Modify permissions, email–enabled document libraries will receive duplicate email messages.

To configure email drop folder permissions for the logon account for the SharePoint Timer service

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the server that contains the email drop folder.
  2. In Windows Explorer, right-click the drop folder, click Properties, and then click the Security tab.
  3. On the Security tab, under the Group or user names box, click Edit.
  4. In the Permissions for Windows Explorer dialog box, click Add.
  5. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type the name of the logon account for the SharePoint Timer service, and then click OK.

    This account is listed on the Log On tab of the Properties dialog box for the service in the Services snap-in.

  6. In the Permissions for User or Group box, next to Modify, select Allow.
  7. Click OK.
  1. Click Start, and then click Run.
  2. In the Run dialog box, type Adsiedit.msc, and then click OK.
  3. In the ADSI Edit window, expand ADSI Edit, expand Domain [DomainName], expand DC=DomainName, DC=com, and then expand CN=Users.
  4. Right-click the user name to which you want to add the missing attributes, and then click Properties.
  5. In the Properties dialog box, double-click Internet Encoding on the Attribute Editor tab.
  6. In the Integer Attribute Editor dialog box, type 1310720 in the Value box, and then click OK.
  7. In the Properties dialog box, double-click mAPIRecipient on the Attribute Editor tab.
  8. In the Boolean Attribute Editor dialog box, click False, and then click OK two times.

 

 

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the front-end web server.
  2. Click Start, point to Administrative Tools, and then click Server Manager.
  3. In Server Manager, click Features.
  4. In Features Summary, click Add Features to open the Add Features Wizard.
  5. On the Select Features page, select SMTP Server.
  6. In the Add Features Wizard dialog box, click Add Required Roll Services, and then click Next.
  7. On the Confirm Installation Selections page, click Install.
  8. On the Installation Results page, ensure that the installation is complete, and then click Close.

After you install the SMTP service, you configure it to send email messages from servers in the farm.

You can decide to send relayed email messages to all servers except those that you specifically exclude. Alternatively, you can block messages to all servers except those that you specifically include. You can include servers individually or in groups by subnet or domain.

If you enable anonymous access and relayed email messages, you increase the possibility that the SMTP server will be used to relay unsolicited commercial email messages (spam). It is important to limit this possibility by carefully configuring mail servers to help protect against spam. One way that you can do this is by limiting relayed email messages to a list of specific servers or to a domain, and by preventing relayed email messages from all other servers.

    Note:

To manage the SMTP service on Windows Server 2008, you must use Internet Information Services (IIS) 6.0 Manager. Ensure that you install IIS 6.0 Management tools in Server Manager.

To install IIS 6.0 Management tools

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the front-end web server.
  2. Click Start, point to Administrative Tools, and then click Server Manager.
  3. In Server Manager, click Roles.
  4. In the Application Server section, click Add Role Services.
  5. On the Select Role Services page, select Management Tools and IIS 6 Management compatibility, and then click Install.

To configure the SMTP service

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the front-end web server.
  2. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) 6.0 Manager.
  3. In IIS Manager, expand the server name that contains the SMTP server that you want to configure.
  4. Right-click the SMTP virtual server that you want to configure, and then click Start.
  5. Right-click the SMTP virtual server that you want to configure, and then click Properties.
  6. On the Access tab, in the Access control area, click Authentication.
  7. In the Authentication dialog box, verify that Anonymous access is selected.
  8. Click OK.
  9. On the Access tab, in the Relay restrictions area, click Relay.
  10. To enable relayed email messages to any server, click All except the list below.
  11. To accept relayed email messages from one or more specific servers, follow these steps:
    1. Click Only the list below.
    2. Click Add, and then add servers one at a time by IP address, or in groups by using a subnet or domain.
    3. Click OK to close the Computer dialog box.
  12. Click OK to close the Relay Restrictions dialog box.
  13. Click OK to close the Properties dialog box.

Ensure that the SMTP service is running and set to start automatically. To do this, use the following procedure.

To set the SMTP service to start automatically

  1. Click Start, point to Administrative Tools, and then click Services.
  2. In Services, right-click Simple Mail Transfer Protocol (SMTP), and then select Properties.
  3. In the Simple Mail Transfer Protocol (SMTP) Properties dialog box, on the General tab, in the Startup type list, select Automatic.
  4. Click OK.

  • Configure outgoing email for a farm

    You can configure outgoing email for a farm by using the SharePoint Central Administration website. Use the following procedures to configure outgoing email. After you complete the procedures, users can track changes and updates to individual site collections. In addition, site administrators can, for example, receive notices when users request access to a site.

    To configure outgoing email for a farm by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group on the server that is running the SharePoint Central Administration website.
  2. In Central Administration, click System Settings.
  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure outgoing e-mail settings.
  4. On the Outgoing E-Mail Settings page, in the Mail Settings section, type the SMTP server name for outgoing email (for example, mail.example.com) in the Outbound SMTP server box.
  5. In the From address box, type the email address as you want it to be displayed to email recipients.
  6. In the Reply-to address box, type the email address to which you want email recipients to reply.
  7. In the Character set list, select the character set that is appropriate for your language.
  8. Click OK.
  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group on the server that is running the SharePoint Central Administration website.
  2. In Central Administration, in the Application Management section, click Manage web applications.
  3. On the Web Applications Management page, select a web application, and then in the General Settings group on the ribbon, click Outgoing E-mail.
  4. On the Web Application Outgoing E-Mail Settings page, in the Mail Settings section, type the name of the SMTP server for outgoing email (for example, mail.fabrikam.com) in the Outbound SMTP server box.
  5. In the From address box, type the email address (for example, the site administrator alias) as you want it to be displayed to email recipients.
  6. In the Reply-to address box, type the email address (for example, a help desk alias) to which you want email recipients to reply.
  7. In the Character set list, click the character set that is appropriate for your language.
  8. Click OK.

 

 
  1. Register a managed account in SharePoint Server 2013 to run the Secure Store application pool.
  2. Start the Secure Store Service on an application server in the farm.
  3. Create a Secure Store Service service application.

To run the application pool, you must have a standard domain account. No specific permissions are required for this account. Once the account has been created in Active Directory, follow these steps to register it with SharePoint Server 2013.

To register a managed account

  1. On the SharePoint Central Administration Web site home page, in the left navigation, click Security.
  2. On the Security page, in the General Security section, click Configure managed accounts.
  3. On the Managed Accounts page, click Register Managed Account.
  4. In the User name box, type the name of the account.
  5. In the Password box, type the password for the Contoso\ExcelAppPool account.
  6. If you want SharePoint Server 2013 to handle changing the password for the account, select the Enable automatic password change box and specify the password change parameters that you want to use.
  7. Click OK.

Once you have configured the registered account, you must start the Secure Store Service on an application server in the farm. Because Secure Store deals with sensitive information, we recommend that you use a separate application server just for the Secure Store Service for better security.

To start the Secure Store Service

  1. On the Central Administration home page, in the System Settings section, click Manage services on server.
  2. Above the Service list, click the Server drop-down list, and then click Change Server.
  3. Select the application server where you want to run the Secure Store Service.
  4. In the Service list, click Start next to Secure Store Service.

Once the service is started, you must create a Secure Store Service service application. Use the following procedure to create the service application.

To create a Secure Store Service service application

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.
  2. On the Manage Service Applications page, click New, and then click Secure Store Service.
  3. In the Service Application Name box, type a name for the service application (for example, Secure Store Service).
  4. In the Database Server box, type the instance of SQL Server where you want to create the Secure Store database.

    Note:

Because the Secure Store database contains sensitive information, we recommend that you deploy the Secure Store database to a different instance of SQL Server from the rest of SharePoint Server 2013.

  1. Select the Create new application pool option and type a name for the application pool in the text box.
  2. Select the Configurable option, and, from the drop-down list, select the account for which you created the managed account earlier.
  3. Click OK.

The Secure Store Service has now been configured. The next step is to generate an encryption key for encrypting the Secure Store database.

  • Work with encryption keys

    Before using the Secure Store Service, you must generate an encryption key. The key is used to encrypt and decrypt the credentials that are stored in the Secure Store Service database.

    • Generate an encryption key

    The first time that you access the Secure Store service application, your only option is to generate a new encryption key. Once the key has been generated, the rest of the Secure Store functionality becomes available.

    To generate a new encryption key

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.
  2. Click the Secure Store service application.
  3. In the Key Management group, click Generate New Key.
  4. On the Generate New Key page, type a pass phrase string in the Pass Phrase box, and type the same string in the Confirm Pass Phrase box. This pass phrase is used to encrypt the Secure Store database.

    Important:

A pass phrase string must be at least eight characters and must have at least three of the following four elements:

  • Uppercase characters
  • Lowercase characters
  • Numerals
  • Any of the following special characters

“! ” # $ % & ‘ ( ) * + , – . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

    Important:

The pass phrase that you enter is not stored. Make sure that you write this down and store it in a safe place. You must have it to refresh the key, such as when you add a new application server to the server farm.

  1. Click OK.

For security precautions or as part of regular maintenance you may decide to generate a new encryption key and force the Secure Store Service to be re-encrypted based on the new key. You can use this same procedure to do this.

    Caution:

You should back up the database of the Secure Store Service application before generating a new key.

Refreshing the encryption key propagates the key to all the application servers in the farm. You may be required to refresh the encryption key if any of the following things are true:

  • You add a new application server to the server farm.
  • You restore a previously backed up Secure Store Service database and have since changed the encryption key.
  • You receive an “Unable to get master key” error message.
  • You have upgraded your farm from SharePoint Server 2010.

To refresh the encryption key

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.
  2. Click the Secure Store service application.
  3. In the Key Management group, click Refresh Key.
  4. In the Pass Phrase box, type the pass phrase that you first used to generate the encryption key.

    This phrase is either the pass phrase that you used when you initialized the Secure Store Service service application or one that you used when you created a new key by using the Generate a New Key command.

  5. Click OK.

  • Store credentials in Secure Store

    Storing credentials in Secure Store is accomplished by using a Secure Store target application. A target application maps the credentials of a user, group, or claim to a set of encrypted credentials stored in the Secure Store database. After a target application is created, you can associate it with an external content type or application model, or use it with a business intelligence service application such as Excel Services or Visio Services to provide access to an external data source. When a SharePoint Server 2013 service application calls the target application, Secure Store confirms that the user making the request is an authorized user of the target application and then retrieves the encrypted credentials. The credentials are then used on the user’s behalf by the SharePoint Server 2013 service application.

    To create a target application, you must do the following:

  1. Create the target application itself, specifying the type of credentials that you want to store in the Secure Store database, the administrators for the target application, and the credential owners.
  2. Specify the credentials that you want to store.

Target applications are configured on the Secure Store Service Application page in Central Administration. Use the following procedure to create a target application.

To create a target application

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.
  2. Click the Secure Store service application.
  3. In the Manage Target Applications group, click New.
  4. In the Target Application ID box, type a text string.

    This is the unique string that you will use externally to identify this target application.

  5. In the Display Name box, type a text string that will be used to display the identifier of the target application in the user interface.
  6. In the Contact Email box, type the e-mail address of the primary contact for this target application.

    This can be any legitimate e-mail address and does not have to be the identity of an administrator of the Secure Store Service application.

  7. When you create a target application of type Individual (see below), you can implement a custom Web page that lets users add individual credentials for the destination data source. This requires custom code to pass the credentials to the target application. If you did this, type the full URL of this page in the Target Application Page URL field. There are three options:
  • Use default page: Any Web sites that use the target application to access external data will have an individual sign-up page that was added automatically. The URL of this page will be http:/<samplesite>/_layouts/SecureStoreSetCredentials.aspx?TargetAppId=<TargetApplicationID>, where <TargetApplicationID> is the string typed in the Target Application ID box. By publicizing the location of this page, you can enable users to add their credentials for the external data source.
  • Use custom page: You provide a custom Web page that lets users provide individual credentials. Type the URL of the custom page in this field.
  • None: There is no sign-up page. Individual credentials are added only by a Secure Store Service administrator who is using the Secure Store Service application.
  1. In the Target Application Type drop-down list, choose the target application type: Group, for group credentials, or Individual, if each user is to be mapped to a unique set of credentials on the external data source.

    Note:

There are two primary types for creating a target application:

  • Group, for mapping all the members of one or more groups to a single set of credentials on the external data source.
  • Individual, for mapping each user to a unique set of credentials on the external data source.
  1. Click Next.
  2. Use the Specify the credential fields for your Secure Store Target Application page to configure the various fields which may be required to provide credentials to the external data source. By default, two fields are listed: Windows User Name and Windows Password.

    To add an additional field for supplying credentials to the external data source, on the Specify the credential fields for your Secure Store Target Application page, click Add Field.

    By default, the type of the new field is Generic. The following field types are available:

  • Field

Description

Generic

Values that do not fit in any of the other categories.

User Name

A user account that identifies the user.

Password

A secret word or phrase.

PIN

A personal identification number.

Key

A parameter that determines the functional output of a cryptographic algorithm or cipher.

Windows User Name

A Windows user account that identifies the user.

Windows Password

A secret word or phrase for a Windows account.

Certificate

A certificate.

Certificate Password

The password for the certificate.
  • To change the type of a new or existing field, click the arrow that appears next to the type of the field, and then select the new type of field.

        Note:

Every field that you add will be required to have data when you set the credentials for this target application.

  • You can change the name that a user sees when interacting with a field. In the Field Name column of the Specify the credential fields for your Secure Store Target Application page, change a field name by selecting the current text and typing new text.
  • When a field is masked, each character that a user types is not displayed but is replaced with a mask character such as the asterisk “*”. To mask a field, click the check box for that field in the Masked column of the page.
  • To delete a field, click the delete icon for that field in the Delete column of the page.

    When you have finished editing the credential fields, click Next.

  1. In the Specify the membership settings page, in the Target Application Administrators Field, list all users who have access to manage the target application settings.
  2. If the target application type is group, in the Members field, list the user groups to map to a set of credentials for this target application.
  3. Click OK to complete configuring the target application.

  • Set credentials for a target application

After creating a target application, an administrator of that target application can set credentials for it. These credentials are used by the calling application to provide access to an external data source. If the target application is of type Individual, you can also enable users to supply their own credentials.

To set credentials for a target application

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.
  2. Click the Secure Store service application.
  3. In the target application list, point at the target application for which you want to set credentials, click the arrow that appears, and then, in the menu, click Set credentials.

    If the target application is of type Group, type the credentials for the external data source. Depending on the information that is required by the external data source, the fields for setting credentials will vary.

    If the target application is of type Individual, type the user name of the individual who will be mapped to this set of credentials on the external data source, and type the credentials for the external data source. Depending on the information that is required by the external data source, the fields for setting credentials will vary.

  4. Click OK.

Once you have set the credentials for the target application, it is ready to be used by a SharePoint Server 2013 service such as Business Connectivity Services or Excel Services.

  • Enable the audit log

    Audit entries for the Secure Store service are stored in the Secure Store Service database. By default, the audit log file is disabled.

    An audit log entry stores information about a Secure Store Service action, such as when it was performed, whether it succeeded, why it failed if it didn’t succeed, the Secure Store Service user who performed it, and optionally the Secure Store Service user on whose behalf it was performed. Therefore, a valid reason to enable an audit log file is to troubleshoot an authentication issue.

     

    To enable the audit log by using Central Administration

  1. On the Central Administration home page, in the Application Management section, click Manage service applications.
  2. Select the Secure Store service application. (That is, select the service application, but do not click the link to go to the Secure Store Service application settings page.)
  3. On the ribbon, click Properties.
  4. From the Enable Audit section, click to select the Audit log enabled box.
  5. To change the number of days that entries will be purged from the audit log file, specify a number in days in the Days Until Purge field. The default value is 30 days.
  6. Click OK.
  1. Create accounts — Certain domain user accounts are required specifically for a Search service application.
  2. Create a Search service application — A Search service application provides enterprise search features and functionality.
  3. Configure the Search service application — Basic configuration of a Search service application includes configuring a default content access account, an email contact, and content sources.
  4. Configure the Search service application topology — You can deploy search components on different servers in the farm. You can also specify which instance of SQL Server is used to host the search-related databases.

  • Step 1: Create accounts that are required for a SharePoint Search service application

    The following table lists the accounts that are required when a Search service application is created.

     

    Account

    Description

    Notes

    Search service

    Windows user credentials for the SharePoint Server Search service, which is a Windows service

    This setting applies to all Search service applications in the farm. You can change this account at any time by clicking Configure service accounts in the Security section on the Central Administration home page.
  • Search Admin Web Service application pool
    • Search Query and Site Settings Web Service application pool
    		•

    Windows user credentials

    For each of these accounts, you can use the same credentials that you specified for the Search service. Or, you can assign different credentials to each account according to the principle of least-privilege administration.

    Default content access

    Windows user credentials for the Search service application to use to access content when crawling

    We recommend that you specify a separate account for the default content access account according to the principle of least-privilege administration.

     

    The accounts that you use for the Search service, the Search Admin Web Service application pool, and the Search Query and Site Settings Web Service application pool must be registered as managed accounts in SharePoint Server 2013 so that they are available when you create the Search service application. Use the following procedure to register each of these accounts as a managed account.

    To register a managed account

  1. On the Central Administration home page, in the Quick Launch, click Security.
  2. On the Security page, in the General Security section, click Configure managed accounts.
  3. On the Managed Accounts page, click Register Managed Account.
  4. On the Register Managed Account page, in the Account Registration section, type the user name and password that you want to use as credentials for the service account.
  5. If you want SharePoint Server 2013 to manage password changes for this account, select the Enable automatic password change check box and configure the parameters for automatic password change.
  6. Click OK.

  • Step 2: Create a SharePoint Search service application

    Each Search service application has a separate content index. You can create multiple Search service applications if you want to have different content indexes for different sets of content. For example, if you want to segregate sensitive content (such as employee benefits information) into a separate content index, you can create a separate Search service application to correspond to that set of content.

    Use the following procedure to create a Search service application.

    To create a Search service application

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group for the farm for which you want to create the service application.
  2. On the Central Administration home page, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, on the ribbon, click New, and then click Search Service Application.
  4. On the Create New Search Service Application page, do the following:
    1. Accept the default value for Service Application name, or type a new name for the Search service application.
    2. In the Search Service Account list, select the managed account that you registered in the previous procedure to run the Search service.
    3. In the Application Pool for Search Admin Web Service section, do the following:
      1. Select the Create new application pool option, and then specify a name for the application pool in the Application pool name text box.
      2. In the Select a security account for this application pool section, select the Configurable option, and then from the list select the account that you registered to run the application pool for the Search Admin Web Service.
    4. In the Application Pool for Search Query and Site Settings Web Service section, do the following:
      1. Choose the Create new application pool option, and then specify a name for the application pool in the Application pool name text box.
      2. In the Select a security account for this application pool section, select the Configurable option, and then from the list select the account that you registered to run the application pool for the Search Query and Site Settings Web Service.
  5. Click OK.

  • Step 3: Configure the SharePoint Search service application

    You configure a Search service application on the Search Administration page for that service application. Use the following procedure to go to the Search Administration page for a particular Search service application.

    To go to the Search Administration page

  1. Verify that the user account that is performing this procedure is an administrator for the Search service application that you want to configure.
  2. On the home page of the Central Administration website, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click the Search service application that you want to configure.

On the Search Administration page, configure the settings as described in the following sections:

  • Specify the default content access account
  • Specify the contact email address
  • Create content sources

    • Specify the default content access account

When you create a Search service application, the account that you specify for the Search service is automatically configured as the default content access account. The crawler uses this account to crawl content that does not have an associated crawl rule that specifies a different account. For the default content access account, we recommend that you specify a domain user account that has read access to as much of the content that you want to crawl as possible. You can change the default content access account at any time.

If you have to crawl certain content by using a different account, you can create a crawl rule and specify a different account for crawling. For information about how to create a crawl rule, see Manage crawl rules (SharePoint Server 2013 Preview).

Use the following procedure to specify the default content access account.

 

To specify the default content access account

  1. On the Search Administration page, in the System Status section, click the link in the Default content access account row.
  2. In the Default Content Access Account dialog box, in the Account box, type the account that you created for content access in the form domain\user name.
  3. Type the password for this account in the Password and Confirm Password boxes.
  4. Click OK.

  • Specify the contact email address

The Search service writes the contact email address to the logs of crawled servers. The default contact email address, someone@example.com, is a placeholder. We recommend that you change this to an account that an external administrator can contact when a crawl might be contributing to a problem such as a decrease in performance on a server that the search system is crawling.

Use the following procedure to specify the contact email address.

To specify the contact email address

  1. On the Search Administration page, in the System Status section, click the link for the Contact e-mail address.
  2. In the Search E-mail Setting dialog box, in the E-mail Address box, type the email address that you want to appear in the logs of servers that are crawled by the search system.
  3. Click OK.

  • Create content sources in a SharePoint Search service application

Crawling requires at least one content source. A content source is a set of options that you use to specify the type of content to crawl, the starting URLs to crawl, and when and how deep to crawl. When a Search service application is created, a content source named “Local SharePoint sites” is automatically created and configured for crawling all SharePoint sites in the local server farm. You can create content sources to specify other content to crawl and how the system will crawl that content. For more information, see Add, edit, or delete a content source (SharePoint Server 2013 Preview). However, you do not have to create other content sources if you do not want to crawl content other than the SharePoint sites in the local farm.

If you choose the Standalone installation option when you install SharePoint Server 2013, a full crawl of all SharePoint sites in the farm is automatically performed after installation and an incremental crawl is scheduled to occur every 20 minutes after that. If you choose the Server Farm installation option when you install SharePoint Server 2013, no crawls are automatically scheduled or performed.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
  2. On the home page of the Central Administration website, in the Application Management section, click Create site collections.
  3. On the Create Site Collection page, do the following:
    1. In the Web Application section, select a web application to contain the new site collection. To use a web application other than the one that is displayed, click the web application that is displayed, and then click Change Web Application.
    2. In the Title and Description section, in the Title box, type the name for the new Search Center site. Optionally, type a description in the Description box.
    3. In the Web Site Address section, for the part of the URL immediately after the web application address, select /sites/, or select a managed path that was previously defined, and then type the final part of the URL.

      Note the address of the new Search Center for future reference.

    4. In the Template Selection section, do the following:
      1. In the Select the experience version drop-down list, select 2013 to create a Search Center site that provides the SharePoint Server 2013 user experience, or select 2010 to create a Search Center site that provides the SharePoint 2010 Products user experience.
      2. In the Select a template subsection, click the Enterprise tab, and then do one of the following:
  • If you are using SharePoint Foundation 2013, select the Basic Search Center template.
  • Otherwise, if you are using SharePoint Server 2013, select the Enterprise Search Center template.
  1. In the Primary Site Collection Administrator section, in the User name box, type the user name of the primary site collection administrator for this site collection in the form domain\user name.
  2. (Optional) In the Secondary Site Collection Administrator section, type the user name of a secondary site collection administrator in the form domain\user name.
  3. In the Quota Template section, select No Quota.

    A Search Center site is not intended to be a data repository. Therefore, you do not have to select a quota template.

  4. Click OK.
  1. On the Top-Level Site Successfully Created page, click the link to the Search Center site that you created.

After you create the Search Center site, you must grant site access to users so that they can perform search queries and view search results. Use the following procedure to grant site access to users.

To grant access to the SharePoint Search Center

  1. Verify that the user account that is performing this procedure is a member of the Owners group on the Search Center site.
  2. In a web browser, go to the Search Center site.
  3. Open the Site menu by clicking the gear icon in the upper-right portion of the page, and then click Site Permissions.
  4. In the Shared with dialog box, click Invite people.
  5. In the Share <SearchCenterName> dialog box, in the Enter users separated with semicolons text box, type the names of the Windows user groups and Windows users to whom you want to grant permissions for submitting queries and viewing search results in the Search Center.

    For example, to grant access to the Search Center to all Windows users, type NT Authority\authenticated users.

  6. Click Show options.
  7. Clear the Send an email invitation check box.
  8. In the Select a group or permission level drop-down list, select <SearchCenterName> Visitors [Read].
  9. Click Share.

 

 

 

  1. Verify that the user account that is performing this procedure is an administrator for the Search service application.
  2. Start SharePoint 2013 Central Administration.
  • For Windows Server 2008 R2:
    • Click Start, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Central Administration.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Central Administration.

      If SharePoint 2013 Central Administration is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Central Administration.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. In Central Administration, in the Application Management section, click Manage service applications.
  2. On the Manage Service Applications page, click the row that contains the User Profile service application, and then in the ribbon, click Administrators.
  3. In the Administrators for User Profile Service Application dialog box, in the To add an account box, type a user account in the form domain\user name.
  4. Click Add.
  5. In the Permissions list, select the Retrieve People Data for Search Crawlers check box.
  6. Click OK.

After you give the account access to crawl the profile store, you must create a crawl rule to specify that you want to use that account when you crawl the profile store. Use the following procedure to create a crawl rule for this purpose.

To create a crawl rule to authenticate to the User Profile service application

  1. Verify that the user account that is performing this procedure is an administrator for the Search service application.
  2. In Central Administration, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click the Search service application for which you want to create a crawl rule.
  4. On the Search Administration page, in the Quick Launch, in the Crawling section, click Crawl Rules.
  5. On the Manage Crawl Rules page, click New Crawl Rule.
  6. In the Path section, in the Path box, type the start address for the User Profile service application in the form sps3://<hostname>, where <hostname> is the URL for the Web application where you deployed the My Sites site collection.
  7. Click Use regular expression syntax for matching this rule if you want to use regular expression syntax in the path.
  8. In the Crawl Configuration section, select Include all items in this path.
  9. In the Specify Authentication section, select Specify a different content access account.
  10. In the Account box that appears, type the user account to which you gave access to the profile store in the form domain\user name.
  11. Type the password for the account that you specified in the Password and Confirm Password boxes.
  12. Clear the Do not allow Basic Authentication check box only if you want to allow the user account credentials to be sent as plaintext.

    Note:

You should not clear the Do not allow Basic Authentication check box unless you are using SSL to encrypt the website traffic. For more information, see Plan for user authentication methods in SharePoint 2013.

  1. Click OK.

For more information, see Manage crawl rules.

When you configure My Sites, the starting URL to crawl the profile store (sps3://<hostname>) is automatically added to the default content source. We recommend that you remove the URL of the profile store from the default content source and then create a separate content source to crawl only the profile store. This allows you to crawl the profile store on a different schedule from other crawls.

Use the following procedure to remove the URL of the profile store from the default content source.

To remove the profile store URL from the default content source

  1. Verify that the user account that is performing this procedure is an administrator for the Search service application.
  2. In Central Administration, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click Search Service Application.
  4. On the Search Administration page, in the Quick Launch, in the Crawling section, click Content Sources.
  5. On the Manage Content Sources page, click the link to the default content source (Local SharePoint sites).
  6. In the Start Addresses section, remove the URL for the profile store (sps3://<hostname>, where <hostname> is the URL for the web application where you deployed the My Sites site collection).
  7. Click OK.

    Use the following procedure to create a content source that specifies how to crawl the profile store.

To create a content source that specifies how to crawl the profile store

  1. Verify that the user account that is performing this procedure is an administrator for the Search service application.
  2. In Central Administration, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click Search Service Application.
  4. On the Search Administration page, in the Quick Launch, in the Crawling section, click Content Sources.
  5. On the Manage Content Sources page, click New Content Source.
  6. On the Add Content Source page, in the Name section, type a name for this content source.
  7. In the Content Source Type section, ensure that SharePoint Sites is selected.
  8. In the Start Addresses section, type the start address in the form sps3://<hostname>, where <hostname> is the URL for the web application where you deployed the My Sites site collection.
  9. In the Crawl Settings section, leave the default value of Crawl everything under the host name for each start address.
  10. In the Crawl Schedules section, do the following:
  • Select Enable Continuous Crawls or Enable Incremental Crawls.

    A continuous crawl automatically provides maximum freshness for the content source without an incremental crawl schedule. For more information, see Manage continuous crawls in SharePoint 2013.

    If you select Enable Incremental Crawls, create an incremental crawl schedule.

  • Optionally create a schedule for full crawls.
  1. If you selected Enable Incremental Crawls, in the Content Source Priority section, select the priority for this content source.

    Note:

The Content Source Priority section does not appear when you specify the content source type as SharePoint Sites and you select Enable Continuous Crawls.

  1. Click OK.
  1. Verify that the user account that is performing this procedure is an administrator for the User Profile service application.
  2. In Central Administration, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click the User Profile service application.
  4. On the Manage Profile Service page, in the People section, click Manage User Profiles.
  5. On the Manage User Profiles page, in the Find profiles box, type the name of the domain of which the users are members.

    Do not type the fully qualified domain name. For example, if users are members of the Contoso.com domain, type Contoso in the Find profiles box.

  6. Click Find.

  • Add information to My Sites

My Sites keep information in the User Profile service application databases. The User Profile service application stores much of the information that appears in results for people search. People search results become more useful as users add more information to their My Sites.

The first time that a user accesses their My Site, also known as their personal site, a My Site is created for them and a profile is automatically added to the User Profile service application.

To add information to a user’s My Site, log on as a user for whom a user profile was created in the User Profile service application, and then go to that user‘s My Site. In the user‘s My Site, you can provide information about the user‘s expertise and interests. To see how the information that you added affects the people search results that appear, perform a crawl of the profile store, and then search on the user’s name.

  1. Depending on the level at which you want to create the result source, do one of the following:
  • To create a result source for a Search service application:
  • Verify that the user account that performs this procedure is an administrator on the Search service application.
  • In Central Administration, in the Application Management section, click Manage service application.
  • Click the Search service application for which you want to create a result source.
  • On the Search Administration page for the Search service application, on the Quick Launch, in the Queries and Results section, click Result Sources.
  • To create a result source for a site collection:
  • Verify that the user account that performs this procedure is an administrator for the site collection.
  • On the Settings menu for the site collection, click Site Settings.
  • On the Site Settings page, in the Site Collection Administration section, click Search Result Sources.
  • To create a result source for a site:
  • Verify that the user account that performs this procedure is a member of the Owners group for the site.
  • On the Settings menu for the site, click Site Settings.
  • On the Site Settings page, in the Search section, click Result Sources.
  1. On the Manage Result Sources page, click New Result Source.
  2. On the Add Result Source page, in the General Information section, do the following:
    1. In the Name box, type a name for the result source.
    2. In the Description box, type a description of the result source.
  3. In the Protocol section, select one of the following protocols for retrieving search results:
  • Local SharePoint, the default protocol, provides results from the search index for this Search service application.
  • Remote SharePoint provides results from the index of a search service in another farm.
  • OpenSearch provides results from a search engine that uses the OpenSearch 1.0/1.1 protocol.
  • Exchange provides results from Microsoft Exchange Server. Click Use AutoDiscover to have the search system find an Exchange Server endpoint automatically, or type the URL of the Exchange web service to retrieve results from — for example, https://contoso.com/ews/exchange.asmx.

        Note:

Note: The Exchange Web Services Managed API must be installed on the computer on which the search service is running. For more information, see Optional software in Hardware and software requirements for SharePoint 2013.

  1. In the Type section, select SharePoint Search Results to search the whole index, or People Search Results to enable query processing that is specific to people search.
  2. In the Query Transform field, do one of the following:
  • Leave the default query transform (searchTerms) as is. In this case, the query will be unchanged since the previous transform.
  • Type a different query transform in the text box.
  • Use the Query Builder to configure a query transform by doing the following:
  • Click Launch Query Builder.
  • In the Build Your Query dialog box, optionally build the query by specifying filters, sorting, and testing on the tabs as shown in the following tables.

  • On the BASICS tab

Keyword filter

You can use keyword filters to add pre-defined query variables to the query transform. You can select pre-defined query variables from the drop-down list, and then add them to the query by clicking Add keyword filter.

Property filter

You can use property filters to query the content of managed properties that are set to queryable in the search schema.

You can select managed properties from the Property filter drop-down list. Click Add property filter to add the filter to the query.

  • On the SORTING tab

Sort results

In the Sort by menu, you can select a managed property from the list of managed properties that are set as sortable in the search schema, and then select Descending or Ascending. To sort by relevance, that is, to use a ranking model, select Rank. You can click Add sort level to specify a property for a secondary level of sorting for search results.

Ranking Model

If you selected Rank from the Sort by list, you can select the ranking model to use for sorting.

Dynamic ordering

You can click Add dynamic ordering rule to specify additional ranking by adding rules that change the order of results within the result block when certain conditions are satisfied.

  • On the TEST tab

Query text

You can view the final query text, which is based on the original query template, the applicable query rules, and the variable values.

Click Show more to display the options in the following rows of this table.

  

Query template

You can view the query as it is defined in the BASICS tab or in the text box in the Query transform section on the Add Result Source page.

Query template variables

You can test the query template by specifying values for the query variables.
  1. On the Add Result Source page, in the Credentials Information section, select the authentication type that you want for users to connect to the result source.
  1. Perform the appropriate procedures in the following list depending on the level at which the result source was configured.
  • If the result source was created at the Search service application level, do the following:
  • Verify that the user account that performs this procedure is an administrator for the Search service application.
  • In Central Administration, in the Application Management section, click Manage service applications.
  • Click the Search service application for which you want to set the result source as default.
  • On the Search Administration page, in the Queries and Results section, click Result Sources.
  • If the result source is at the site collection level, do the following:
  • Verify that the user account that performs this procedure is an administrator for the site collection administrator.
  • On the Settings menu for the site collection, click Site Settings.
  • On the Site Settings page, in the Site Collection Administration section, click Search Result Sources.
  • If the result source is at the site level, do the following:
  • Verify that the user account that performs this procedure is a member of the Owners group for the site.
  • On the Settings menu for the site, click Site Settings.
  • On the Site Settings page, in the Search section, click Result Sources.
  1. On the Manage Result Sources page, point to the result source that you want to set as default, click the arrow that appears, and then click Set as Default.

 

 

  1. Create a Machine Translation service application.
  2. Configure the Machine Translation Service.
  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group and the Administrators group on the computer that is running Central Administration.
  2. On the Central Administration home page, in the Application Management section, click Manage service applications.
  3. On the ribbon, click New, and then click Machine Translation Service.
  4. In the Create New Machine Translation Service Application pane, in the Name section, type a name for the service application.
  5. In the Application Pool section, do one of the following:
  • Click Use existing application pool, and then select the application pool that you want to use from the drop-down list.
  • Click Create a new application pool, type the name of the new application pool, and then under Select a security account for this application pool do one of the following:
    • Click Predefined to use a predefined security account, and then select the security account from the drop-down list.
    • Click Configurable to specify a new security account to be used for an existing application pool. You can create a new account by clicking the Register new managed account link.

    Important:

The account that is used by the application pool must also have Full Control permissions to the User Profile service application. If you create a new application pool and a new account, make sure that you add the account to the list of accounts that can use the User Profile Service Application, and grant Full Control permissions to the account. For more information, see Restrict or enable access to a service application (SharePoint Server 2010).

  1. In the Partitioned Mode section, select Run in partitioned mode only if you will be providing hosting services for other sites, and the sites using it have site subscriptions.
  2. In the Add to Default Proxy List section, select Add this service application’s proxy to the farm’s default proxy list. If you have multiple Web applications, and want them to use different sets of services, clear this check box.
  3. In the Database section, specify the database server, database name, and authentication method for the new service application as described in the following table. The database is used to hold the work items for the Machine Translation service.

  • Database section properties

Item

Action

Database Server

Type the name of the database server and SQL Server 2012 instance that you want to use in the format ServerName\Instance. You can also use the default entry.

Database Name

Type the name of the database.

    Important:

The database name must be a unique name.

Database Authentication

Select the authentication that you want to use by doing one of the following:

  • If you want to use Windows authentication, leave this option selected. We recommend this option because Windows authentication automatically encrypts the password when it connects to SQL Server.
  • If you want to use SQL authentication, click SQL authentication. In the Account box, type the name of the account that you want the service application to use to authenticate to the SQL Server database, and then type the password in the Password box.

    Note:

In SQL authentication, an unencrypted password is sent to SQL Server. We recommend that you use SQL authentication only if you force protocol encryption to SQL Server or encrypt network traffic by using IPsec.

  1. Click OK.
  2. Start the Machine Translation Service. For more information, see “Starting or stopping a service” in Manage services on the server (SharePoint Server 2010).

To create a Machine Translation service application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    New-SPTranslationServiceApplication -Name “<ServiceApplicationName>” -DatabaseName “<DatabaseName>” -DatabaseServer “<DatabaseServer>” -ApplicationPool “<ApplicationPoolName>” -Default

    Where:

  • <ServiceApplicationName> is name of the new Machine Translation Service application.
  • <DatabaseName> is the name of the database that will host the Machine Translation Service logs. To create a new database, provide a new name.

        Important:

The database name must be a unique name.

  • <DatabaseServer> is the name of the database server that will hold the work items for the Machine Translation Service.
  • <ApplicationPoolName> is the name of an existing application pool in which the new Machine Translation Service should run.

        Important:

The account that is used by the application pool must also have Full Control permissions to the User Profile service application. If you create a new application pool and a new account, make sure that you add the account to the list of accounts that can use the User Profile service application, and grant it Full Control permissions. For more information, see Restrict or enable access to a service application (SharePoint Server 2010).

Example

New-SPTranslationServiceApplication -Name “Machine Translation Service Application” -DatabaseName “MachineTranslationDB” -DatabaseServer “ContosoDBServer” -ApplicationPool “ContosoAppPool” -Default

  1. Start the Machine Translation Service. For more information, see “Starting or stopping a service” in Manage services on the server (SharePoint Server 2010).

For more information, see New-SPTranslationServiceApplication.

  • Configure the Machine Translation Service

    You can configure the Machine Translation Service by using either Central Administration or Windows PowerShell.

        Caution:

    Changing the default settings for the Machine Translation Service can potentially affect server performance. For example, increasing item size limits can result in the translation job taking longer to run, and increasing the number of processes will consume more resources on the server. Be sure to carefully consider any possible server effects before you change these settings.

    To configure the Machine Translation Service by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group in SharePoint Server 2013.
  2. On the Central Administration home page, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click the link that corresponds to the name of the Machine Translation service application.
  4. On the Machine Translation Service page, in the Enabled File Extensions section, clear the check box for any file name extensions that you want to disable. By default, all file name extensions are enabled.
  5. In the Item Size Limits section, do the following:
  • In the Maximum file size for binary files in KB. Microsoft Word documents are binary files box, type the maximum file size (100-524288), in KB, for binary files. The default is 51200. Files that exceed this limit will not be translated.
  • In the Maximum file size for text files in KB. Plain-text, HTML, and XLIFF documents are text files box, type the maximum file size (100-15360), in KB, for text files. The default is 5120. Files that exceed this limit will not be translated.
  • In the Maximum character count for Microsoft Word documents box, type the maximum character count (10000-10000000) for Word documents. The default is 500000.
  1. In the Online Translation Connection section, do one of the following:
  • Click Use default internet settings. This is the default.
  • Click Use the proxy specified, and type a web proxy server and port number.

        Note:

If you change this setting, you must stop and restart the Machine Translation Service after you configure it.

  1. In the Translation Processes section, type the number of translation processes (1-5). The default is 1.

    Note:

If you change this setting, you must stop and restart the Machine Translation Service after you configure it.

  1. In the Translation Throughput section, do the following:
  • In the Frequency with which to start translations (minutes) box, type the frequency with which groups of translations are started, in minutes (1-59). The default is 15.
  • In the Number of translations to start (per translation process) box, type the number of translations (1-1000) per process. This number represents the number of translations started per process every time translations are started. The default is 200.
  1. In the Maximum Translation Attempts section, type the maximum number of times (1-10) a translation is tried before its status is set to Failed. The default is 2.
  2. In the Maximum Synchronous Translation Requests section, type the maximum number of synchronous translation requests (0-300). The default is 10.

    Note:

You can also set this value to 0 so that no synchronous jobs are accepted.

  1. In the Translation Quota section, do the following:
  • In the Maximum number of items which can be queued in a 24-hour period section, do one of the following:
    • Click No limit. This is the default.
    • Click Limit per 24 hours, and then type the maximum number of items (100-1000000) that can be queued in a 24-hour period.
  • In the Maximum number of items which can be queued in a 24-hour period per site subscription section, do one of the following:
    • Click No limit. This is the default.
    • Click Limit per 24 hours, and then type the maximum number of items (100-1000000) that can be queued in a 24-hour period per site subscription.

    Note:

This setting applies only if you will be providing hosting services for other sites, and the sites using it have site subscriptions.

  1. In the Completed Job Expiration Time section, do one of the following:
  • Click Days, and then type the number of days (1-1000) completed jobs are kept in the job history log. The default is 7.
  • Click No expiration.
  1. In the Recycled Threshold section, type the number of documents (1-1000) to be converted before the conversion process is restarted. The default is 100.

    Note:

If you change this setting, you must stop and restart the Machine Translation Service after you configure it.

  1. In the Office 97-2003 Document Scanning section, specify whether to disable security scanning for Office 97-2003 documents. Only enable this setting if you trust the documents that will be converted. The default is No.
  2. Click OK.
  3. If you changed any settings that require you to restart the Machine Translation Service, restart the service now. For more information, see “Starting or stopping a service” in Manage services on the server (SharePoint Server 2010).

To configure the Machine Translation Service by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Set-SPTranslationServiceApplication -Identity “<ServiceApplicationName>” -EnableAllFileExtensions -UseDefaultlnternetSettings -TimerJobFrequency <TimerJobFrequency> -MaximumTranslationAttempts <MaximumTranslationAttempts> -JobExpirationDays <JobExpirationDays> -MaximumSyncTranslationRequests <MaximumSyncTranslationRequests> -RecycleProcessThreshold <RecycleProcessThreshold> -DisableBinaryFileScan <DisableBinaryFileScan>

    Where:

  • <ServiceApplicationName> is name of the Machine Translation service application.
  • <TimerJobFrequency> is the frequency, in minutes (1-59), with which groups of translations are started.
  • <MaximumTranslationAttempts> is the maximum number of times (1-10) a translation is tried before its status is set to Failed.
  • <JobExpirationDays> is the number of days (1-1000) completed jobs are kept in the job history log.
  • <MaximumSyncTranslationRequests> is the maximum number of synchronous translation requests (0-300).
  • <RecycleProcessThreshold> is the number of documents (1-1000) to be converted before the conversion process is restarted.
  • <DisableBinaryFileScan> is either 0 (false) or 1 (true).

    Example

    Set-SPTranslationServiceApplication -Identity “Machine Translation Service Application” -EnableAllFileExtensions -UseDefaultlnternetSettings -TimerJobFrequency 30 -MaximumTranslationAttempts 3 -JobExpirationDays 14 -MaximumSyncTranslationRequests 20 -RecycleProcessThreshold 300 -DisableBinaryFileScan 1

        Note:

Changes to any of the following parameters will require that you restart the Machine Translation Service: KeepAliveTimeout, MaximumTranslationTime, TotalActiveProcesses, RecycleProcessThreshold, WebProxyAddress, MachineTranslationAddress, UseDefaultInternetSettings.

  1. If you changed any settings that require you to restart the Machine Translation Service, restart the service now. For more information, see “Starting or stopping a service” in Manage services on the server (SharePoint Server 2010).

For more information, see Set-SPTranslationServiceApplication.

The Microsoft Translator Hub is an extension of Microsoft Translator, and allows you to build automatic language translation systems that integrate with your website. After you build a custom system, the Test System page on the Projects tab in the Microsoft Translator Hub displays a category ID. You can configure the Machine Translation Service to use the custom translation system by passing the category ID in the MachineTranslationCategory parameter. For more information about the Microsoft Translator Hub, see http://hub.microsofttranslator.com.

  • Additional steps

    If the account that is used by the application pool that was assigned to the Machine Translation service application differs from the one used by the User Profile service application, you must add it to the list of accounts that can use the User Profile service application, and grant it Full Control permissions. For more information, see Restrict or enable access to a service application (SharePoint Server 2010).

     

     

  • Configure Request Manager in SharePoint Server 2013

    Published: October 2, 2012

    Summary: Learn how Request Manager in SharePoint Server 2013 can route and throttle incoming requests to help improve performance and availability.

    Applies to:  SharePoint Server 2013 

    Request Manager is functionality in SharePoint Server 2013 that enables administrators to manage incoming requests and determine how SharePoint Server 2013 routes these requests.

    In this article:

  • Overview

    Request Manager uses configured rules to perform the following tasks when it encounters requests:

    • Deny potentially harmful requests from entering a SharePoint farm.
    • Route good requests to an available server.
    • Manually optimize performance.

    Information that administrators or an automated process provide to Request Manager determine the effectiveness of routed requests.

    To learn about how to use performance data to plan and manage the capacity of a SharePoint Server 2013 environment, see Capacity management and sizing overview for SharePoint Server 2013

  • Scenarios

    The following table describes possible scenarios and resolutions that Request Manager can address.

     

    Area

    Scenario

    Resolution

    Reliability and performance

    Routing new requests to web front end with low performance can increase latency and cause timeouts.

    Request Manager can route to front-end web servers that have better performance, keeping low performance front-end web servers available.

    Requests from users and bots have equal priority.

    Prioritize requests by throttling requests from bots to instead serve requests from end-users).

    Manageability, accountability, and capacity planning

    SharePoint Server fails or generally responds slowly, but it‘s difficult to identify the cause of a failure or slowdown.

    Request Manager can send all requests of a specific type, for example, Search, User Profiles, or Office Web Apps, to specific computers. When a computer is failing or slow, Request Manager can locate the problem.

    All front-end web servers must be able to handle the requests because they could be sent to any front-end web server.

    Request Manager can send multiple or single requests to front-end web servers that are designated to handle them.

    Scaling limits

    Hardware scaling limited by load balancer

    Request Manager can perform application routing and scale out as needed so that a load balancer can quickly balance loads at the network level.

     

  • Setup and Deployment

    Request Manager’s task is to decide two things: a SharePoint farm will accept a request, and if the answer is “yes”, to which front-end web server SharePoint Server will send it. The three major functional components of Request Manager are Request Routing, Request Throttling and Prioritizing, and Request Load Balancing. These components determine how to handle requests. Request Manager manages all requests on a per-web-application basis. Because Request Manager is part of the SharePoint Server 2013 Internet Information Services (IIS) module, it only affects requests that IIS hosts.

    When a new request is received, Request Manager is the first code that runs in a SharePoint farm. Although Request Manager is installed during setup of SharePoint Server on a front-end web server, the Request Management service is not enabled. You can use the Start-SPServiceInstance and Stop-SPServiceInstance cmdlets to start and stop the Request Management service instance respectively or the Manage services on server page on the the SharePoint Central Administration website. You can use the RoutingEnabled or ThrottlingEnabled parameters of the Set-SPRequestManagementSettings Windows PowerShell cmdlet to change properties of Request Manager.

        Note:

    There is no user interface to configure properties of Request Manager. The Windows PowerShell cmdlet is the only way to perform this task.

    Request Manager has two supported deployment modes: Dedicated and Integrated.

    • Dedicated mode

    Figure 1 shows a dedicated mode deployment.

    Figure 1: Dedicated mode

    A set of front-end web servers is dedicated to managing requests exclusively. The front-end web servers that are dedicated to Request Manager are in their own farm that is located between the hardware load balancers (HLBs) and the SharePoint farm. The HLBs send all requests to the Request Manager front-end web servers. Request Manager that runs on these front-end web servers decides to which SharePoint front-end web servers it will send the requests and then routes the requests. Depending on the routing and throttling rules, Request Manager might ignore some requests without sending them to another server. The SharePoint front-end web servers do their normal tasks in processing requests and then send responses back through the front-end web servers that run Request Manager and to the clients.

    Note that all farms are set up as SharePoint farms. All front-end web servers in Figure 1 are SharePoint front-end web servers, each of which can do the same work as any other. The difference between the farms is that the Request Manager front-end web servers have Request Manager enabled.

    Dedicated mode is good for larger-scale deployments when physical computers are readily available. The ability to create a separate farm for Request manager provides two benefits: Request Manager and SharePoint processes do not compete for resources and you can scale out one without having to also scale out the other. This allows you to have more control over the performance of each role.

    • Request Manager and SharePoint processes do not compete for resources.
    • You can scale out each farm separately, which provides more control over the performance of each farm.

      • Integrated mode

    Figure 2 shows an integrated mode deployment.

    Figure 2: Integrated mode

    In an integrated mode deployment, all SharePoint front-end web servers run Request Manager. Hardware load balancers send requests to all front-end web servers. When a front-end web server receives a request, Request Manager decides how to handle it: .

    • Allow it to be processed locally.
    • Route it to a different front-end web server.
    • Deny the request.

    Integrated mode is good for small-scale deployments when many physical computers are not readily available. This mode lets Request Manager and the rest of SharePoint Server to run on all computers. This mode is common for on-premises deployments.

  • Configuration

    Request Manager has two configurable parts: General settings and Decision information. General settings are parameters that make Request Manager ready to use, such as enabling or disabling Request Routing and Request Throttling and Prioritizing. Decision information is all of the information that is used during the routing and throttling processes, such as routing and throttling rules.

        Note:

    You configure Request Manager on a farm and functionality occurs at a web application level.

    • General settings

    By default, request routing and request throttling and prioritizing are enabled. You use the Set-SPRequestManagementSettings cmdlet to change the properties of request routing, request throttling and prioritizing, and select a routing weight scheme.

    The table describes the configuration situation and Windows PowerShell syntax to use.

    • Windows PowerShell examples to enable routing and throttling

     

    Situation

    Windows PowerShell syntax

    Enable routing and throttling for all web applications

    Get-SPWebApplication | Set-SPRequestManagementSettings –RoutingEnabled $true –ThrottlingEnabled $true

    Enable routing with static weighting for all web applications

    Get-SPWebApplication | Get-SPRequestManagementSettings | Set-SPRequestManagementSettings –RoutingEnabled $true –ThrottlingEnabled $false –RoutingWeightScheme Static

     

    In some situations, multiple front-end web servers will be suitable destinations for a particular request. In this case, by default, SharePoint Server selects one server randomly and uniformly.

    One routing weight scheme is static-weighted routing. In this scheme, static weights are associated with front-end web servers so that Request Manager always favors a higher static weight during the selection process. This scheme is useful to give added weight to more powerful front-end web servers and produce less strain on less powerful ones. Each front-end web server will have a static weight associated with it. The values of the weights are any integer value, where 1 is the default. A value less than 1 represents lower weight, and greater than 1 represents higher weight.

    Another weighting scheme is health-weighted. In health-weighted routing, front-end web servers that have health scores closer to zero will be favored, and fewer requests will be sent to front-end web servers that have a higher health score values. The health weights run from 0 to 10, where 0 is the healthiest and therefore will get the most requests. By default, all front-end web servers are set to healthy, and therefore, will have equal weights. SharePoint’s health score based monitoring system assigns weight to server and send a health score value as a header in the response to a request. Request Manager uses same health score and stores it in local memory.

    • Decision information

    Decision information applies to routing targets, routing rules, and throttling rules.

    • Routing targets

    Request routing determines the routing targets that are available when a routing pool is selected for a request. The scope of routing targets is currently for front-end web servers only, but Request Manager‘s design does not exclude routing to application servers, too. A list of front-end web servers in a farm is automatically maintained by using the configuration database. An administrator who wants to change that list, typically in dedicated mode, has to use the appropriate routing cmdlets to get, add, set, and remove routing targets.

    The following table describes the various routing target tasks and the associated Windows PowerShell syntax to use.

    • Windows PowerShell examples routing target tasks

     

    Task

    Windows PowerShell syntax

    Return a list of routing targets for all available web applications.

    Get-SPWebApplication | Get-SPRequestManagementSettings | Get-SPRoutingMachineInfo –Availability Available

    Add a new routing target for a specified web application.

        Note:

    IIS log files will contain all HTTP requests. For additional information about IIS logging, see IIS Logging

    $web=Get-SPWebApplication -Identity <URL of web application>

    $rm=Get-SPRequestManagementSettings -Identity $web

    Add-SPRoutingMachineInfo –RequestManagementSettings $rm -Name <MachineName> -Availability Available

    Where

    • <URL of web application> is the URL of the web application to which you’re adding a new routing target.
    • <MachineName>is the name of the server that hosts the web application.

    Edit an existing routing target‘s availability and static weight for a specified web application

    $web=Get-SPWebApplication -Identity <URL of web application>

    $rm=Get-SPRequestManagementSettings -Identity $web

    $m=Get-SPRoutingMachineInfo -RequestManagementSettings $rm -Name <MachineName>

    Set-SPRoutingMachineInfo -Identity $m -Availability Unavailable

    Where

    • <URL of web application> is the URL of the web application for which you’re editing an existing routing target‘s availability and static weight.

    Remove a routing target from a specified web application

        Note:

    You cannot remove front-end web servers that are in the farm. Instead, you can use the Availability parameter of the Set-SPRoutingMachineInfo cmdlet to make them unavailable.

    $web=Get-SPWebApplication -Identity <URL of web application>

    $rm=Get-SPRequestManagementSettings -Identity $web

    $m=Get-SPRoutingMachineInfo -RequestManagementSettings $rm -Name <MachineName>

    Remove-SPRoutingMachineInfo -Identity $M

    Where

    • <URL of web application> is the URL of the web application from which you’re removing a routing target.

     

    • Routing and throttling rules

    Request routing and request throttling and prioritizing are decision algorithms that use rules to prescribe many actions. The rules determine how Request Manager handles requests.

    Rules are separated into two categories, routing rules and throttling rules, which are used in request routing and request throttling and prioritizing, respectively. Routing rules match criteria and route to a machine pool. Throttling rules match criteria and throttle based on known health score of a computer.

  • Request Routing

    Request processing is all operations that occur sequentially from the time that Request Manager receives a new request to the time that Request Manager sends a response to the client.

    Request processing is divided into the components:

    • request routing
    • incoming request handler
    • request throttling and prioritizing
    • request load balancing

      • Incoming request handler

    The role of the incoming request handler is to determine whether Request Manager should process a request. If request throttling and prioritizing is disabled and the Request Manager queue is empty, Request Manager directs the request to SharePoint Server that is running on the current front-end web server. If request throttling and prioritizing is enabled, request throttling and prioritizing determines whether the request should be allowed or denied on the current front-end web server.

    The processes steps of the incoming request handler are as follows:

  1. Request is determined if it should be throttled or routed
  2. For routed requests, load balance algorithm is run
  3. Request routed to load balancer endpoint

Request routing and Request throttling and prioritizing only run if it is enabled and is routed once per farm. Request load balancer only runs if a request has been determined as routable. The outgoing request handler only runs if the request has to be sent to a different front-end web server. The role of the outgoing request handler is to send the request to the selected front-end web server, wait for a response, and send the response back to the source.

  • Request routing

The role of request routing is to select a front-end web server to route a request. By using no routing rules that are defined, the routing scheme is as easy as randomly selecting an available front-end web server.

The algorithm of request routing is defined by two parts: request-rule matching and front-end web server selection.

  • Request rule matching

Every rule has one or more match criteria, which consist of three things: match property, match type, and match value.

The following table describes the different types of match properties and match types:

 

Match property

Match type

Hostname

RegEx

URL

Equals

Port number

Starts with

MIME Type

Ends with

 

For example, an administrator would use the following match criteria to match http://contoso requests: Match Property=URL; Match value= http://contoso; Match type=RegEx

  • Front-end web server selection

The front-end web server selection uses all routing rules, whether they match or do not match a given request. Rules that match have machine pools, a request sends load balanced to any machine in any matching rule‘s machine pool. If a request does not match any request, it sends load balanced to any available routing target.

  • Request routing and prioritizing

For routing requests that use the health-based monitoring system, the role of request routing and prioritizing is to reduce the routing pool to computers that have a good health score to process requests. If request routing is enabled, the routing pool is whichever front-end web server is selected. If request routing is disabled, the routing pool only contains the current front-end web server.

Request routing and prioritizing can be divided into two parts: request-rule matching and front-end web server filtering. Request-rule matching happens exactly like in request routing. Front-end web server filtering uses the health threshold parameter from the throttling rules in combination with front-end web server health data to determine whether the front-end web servers in the selected routing pool can process the given request.

The front-end web server filtering process follows these steps:

  1. The routing pool is either the current front-end web server or one or more front-end web servers that request routing selects.
  2. All matching rules are checked to find the smallest health threshold value.
  3. Remove front-end web servers in the routing pool that have health scores greater than or equal to the smallest health threshold value.

For example, request routing is disabled and the current front-end web server has a health score of 7 and a rule “Block OneNote“ without a health threshold (that is, health threshold = 0) is created.

The routing pool is the current front-end web server that has a health threshold equal to zero (0). So, the smallest threshold that the front-end web server can serve is zero. Because the current front-end web server has health score of 7, Request Manager denies and removes the request.

  • Request load balancing

The role of request load balancing is to select a single target to which to send the request. Request load balancing uses the routing weight schemes to select the target. All routing targets begin with a weight of 1. If static weighting is enabled, request load balancing uses the static weights set of each routing target to adjust the weights and the value can be valid integer number. If health weighting is enabled, request load balancing uses health information to add weight to healthier targets and remove weight from less healthy targets.
  1. A user goes to an external list on a SharePoint site. The external list creates a request for data by using the user‘s Windows credentials.
  2. The request is sent to the BDC runtime in the SharePoint farm.
  3. The BDC runtime accesses the external content type for the list (in the BDC Metadata Store) to see how to access the external system and which operations can be performed. By using either the user‘s credentials or the credentials from the Secure Store (as defined in the external content type), the BDC runtime passes the request to a connector that can handle the request, in this case the SQL connector.
  4. The SQL connector accesses the external data source and retrieves the data, and applies any formatting and filtering as specified in the external content type. The data is passed back through the request chain to the list where the user can interact with it.
  5. The user wants to take this data on a portable computer in Outlook so the user can use the Connect to Outlook feature on the external list to take the data offline.
  6. The Click Once installation runs and installs the required BDC model on the client. This lets the BDC Client-Side Runtime access the external data directly.
  7. Outlook then connects to the external data by using the configuration in the BDC model and synchronizes it into an Outlook SharePoint external list, formatted as a contacts list.
  8. The user can then interact with the contact data, and any changes that the user makes can be written back to the external data source either by an on-demand synch or by waiting six hours for the automated synchronization.

  • How to use these procedures and a roadmap of the procedures

    The steps to completely deploy this scenario are presented in smaller procedures. Some of the procedures are on TechNet, some are on Office.com, and some are on MSDN. Each procedure is numbered indicating its position in the overall sequence. At the beginning and end of each procedure, links direct you to the preceding and following steps. The following list contains links to all of the procedures, in proper order, for your reference. You must follow them in sequence to build out the scenario. You can also use these procedures individually to build out your own unique scenarios. When you are assembling individual procedures to build out your own scenarios, be sure to test the entire set of procedures, in order, in a lab setting before you attempt them in production.

  1. Prerequisites for deploying a Business Connectivity Services on-premises solution in SharePoint 2013
  2. Create database logins for a Business Connectivity Services on-premises solution in SharePoint 2013
  3. Start the Business Data Connectivity service for a Business Connectivity Services on-premises solution in SharePoint 2013
  4. Create the Business Data Connectivity service application in SharePoint 2013
  5. Set permissions on the BCS Metadata Store for a Business Connectivity Services on-premises solution in SharePoint 2013
  6. Configure the Secure Store Service for a Business Connectivity Services on-premises solution in SharePoint 2013
  7. Create an external content type for a Business Connectivity Services on-premises solution in SharePoint 2013
  8. Configure permission on an external content type for a Business Connectivity Services on-premises solution in SharePoint 2013
  9. Create an external list for a Business Connectivity Services on-premises solution in SharePoint 2013
  10. Manage user permissions on an external list for a Business Connectivity Services on-premises solution in SharePoint 2013
  11. Connect an external list to Outlook for a Business Connectivity Services on-premises solution in SharePoint 2013
  12. Verify offline access and synchronization of external data in Outlook for a Business Connectivity Services on-premises solution in SharePoint 2013

 

 

  1. From a browser, go to AdventureWorks sample database and download the AdventureWorks2008R2_Data.mdf file.
  2. Install the Adventure Works2008R2 sample database by following the procedures in the “Readme for AdventureWorks 2008 R2 Sample Database“ section of the SQL Server Samples Readme (en-US) page.

    Important:

Link to Step 2Create database logins for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Start SQL Server Management Studio.
  2. In the Object Explorer, expand the <database server name>, expand Security, and then expand Logins.
  3. Right-click Logins, and then click New Login
  4. In the Login Name box, enter SharePointGroupAccount.
  5. Select SQL Server authentication, and then enter and confirm a password.
  6. In the Default database box, select AdventureWorks2008R2, and then click OK.

  • Create a SQL Server user on the AdventureWorks database

  1. In the Object Explorer, expand Databases, expand AdventureWorks2008R2, expand Security, and then expand Users.
  2. Right-click Users, and then click New User.
  3. Under the Login Name, with the User name box pre-selected, in the first box, enter AdventureWorksUser
  4. In the second box, click Browse, in the Select Login dialog box, click Browse, select the SQL Server account, SharePointGroupAccount, and then click OK twice.
  5. Under Database Role membership, select db_owner.
  6. Click OK.
  7. Close SQL Server Management Studio.

    Important:

Link to Step 3Start the Business Data Connectivity service for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Open the SharePoint Central Administration website for the server farm that contains your BCS solution.
  2. On the Quick Launch, click System Settings.
  3. On the System Settings page, under Servers, click Manage services on server.
  4. Check the value in the Server field. If the server name shown there is not the server that you want running the Business Data Connectivity Service on, click on the down arrow, click Change Server and select the correct server.
  5. If necessary, next to Business Data Connectivity Service, under the Action column, click Start.

    Note:

If you need to stop the Business Data Connectivity Service after starting it, next to Business Data Connectivity Service in the Action column click Stop.

    Important:

Link to Step 4Create the Business Data Connectivity service application in SharePoint 2013 of the Business Connectivity Services On-Premises deployment procedures

 
  1. Open the SharePoint Central Administration website for your farm with a Farm administrator account. This must be the farm in which you started the Business Data Connectivity Service in the Start the Business Data Connectivity service for a Business Connectivity Services on-premises solution in SharePoint 2013 procedure.
  2. On the Quick start, click, Application Management.
  3. On the Application Management page under Service Applications, click Manage service applications.
  4. If an instance of the Business Data Connectivity Service Application that you will use for this solution is already there, you can skip the rest of this procedure. If not, follow the rest of this procedure to create one.
  5. On the SERVICE APPLICATIONS tab, click New and click Business Data Connectivity Service.
  6. Configure the setting in the Create New Business Data Connectivity Service Application configuration page as follows:
    1. In the Service Application Name box enter the name you want the service to appear as on the Manage Service Applications page. This BCS service application can be used by multiple BCS solutions.
    2. In the Database area, leave the prepopulated values for Database Server, Database Name, and Database authentication, which is Windows authentication (recommended) unless you have specific design needs to change them.
    3. If you have SQL Server database mirroring configured and you want to include the Business Data Connectivity Service database in mirroring, provide the name of the failover database server in the Failover Database Server box.
    4. If you have not already created a new application pool for your service applications, enter a name for a new application pool in the Application pool name box, for example, “SharePointServiceApps“. You can use this application pool for all your service applications. For more information on planning, creating and configuring service applications, see Manage service applications in SharePoint 2013.
    5. Select the account that you configured in the Prerequisites for deploying a Business Connectivity Services on-premises solution in SharePoint 2013 procedure as the SharePoint products application services account in the Configurable drop down.
  7. Click OK to create the new Business Data Connectivity Service Application and click OK again.
  8. Select the row that the Business Data Connectivity Service Application is in, not the proxy row.
  9. Click Administrators in the Operations area and add any accounts that you want to be able to administer the Business Data Connectivity service application granting them full control. When these individuals open Central Administration they will only be able to administer the Business Data Connectivity service application.

    Important:

Link to Step 5Set permissions on the BCS Metadata Store for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Open the SharePoint Central Administration website with either a Farm administrator account or an account that has been delegated permissions to administer the Business Data Connectivity Service Applications.
  2. On the Quick Launch, click Application Management.
  3. On the Application Management page, under Service Applications, click Manage service applications.
  4. In the list of services, select the row of the Business Data Connectivity Service Application that you created in Create the Business Data Connectivity service application in SharePoint 2013 and then click Manage and then Set Metadata Store Permissions.
  5. Enter the Farm Administrator account and any other delegate administrators if you have them and then click Add.
  6. For each account or group that you added that is an administrator of the Business Data Connectivity Service Application, select the Edit, Execute, Selectable In Clients, and Set Permissions checkboxes.
  7. Select the Propagate permissions to all BDC Models, External Systems and External Content Types in the BDC Metadata Store. Doing so will overwrite existing permissions checkbox. For more information on setting permissions on the BDC Metadata Store, see Overview of Business Connectivity Services security tasks in SharePoint 2013.
  8. Click OK.

    Note:

Edit is a highly privileged permission that is required to create or modify external content types in the Business Data Connectivity metadata store. Execute permission is required to query the external content type.

    Important:

Link to Step 6Configure the Secure Store Service for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 

 
  1. Perform all the steps in Configure the Secure Store Services in SharePoint 2013 Preview with the following parameters.
  2. Open the SharePoint Central Administration website for the server farm that your Secure Store Service is in with an account that has Farm Administrator permissions.
  3. In the Configure the Secure Store Services in SharePoint 2013 Preview article, perform all procedures in the Configure Secure Store section with these parameters
    1. For the Register Managed Account, User name type in the name of the service account that you created in the Prerequisites for deploying a Business Connectivity Services on-premises solution in SharePoint 2013 procedure.
    2. Do not select the Enable automatic password change box.
  4. Perform the “To start the Secure Store Service“ procedure
  5. Perform the “To create a Secure Store Service application” procedures using these parameters
    1. In the Service Application Name box enter the name you want the service to appear as on the Manage Service Applications page.
    2. In the Database area, leave the prepopulated values for Database Server, Database Name, and Database authentication, which is Windows authentication (recommended) unless you have specific design needs to change them.
    3. If you have SQL Server database mirroring configured and you want to include the Secure Store Service in mirroring, provide the name of the failover database server in the Failover Database Server box.
    4. For the Configurable dropdown, select the account that you registered as a managed account earlier in this procedure.
  6. Perform the steps in the Work with encryption keys section with these parameters:
    1. Don‘t perform the procedures in the “Refresh the encryption key“ sub-section
  7. Read the Store credentials in Secure Store section and perform the Create a target application procedure using these parameters.
    1. In the Target Application ID box type in a string for the target application; this is not the display name. For example type in AWTargetAppID.
    2. In the Display Name box, enter the display name you want, for example Adventure Works Target Application ID.
    3. In the Target Application Type dropdown, select Group (which indicates the mapping of many credentials to one credential). In this case, the Target Application Page URL is not needed and automatically selects to None.
    4. On the Create New Secure Store Target Application page, under Field Name, change Windows User Name to SQL User Name, and Windows Password to SQL Password.
    5. Under Field Type change Windows User Name to User Name and change Windows Password to Password.
    6. In the Target Application Administrators add the accounts that you want to be administrators of the Target Application. Note that the Farm Administrator has access by default.
    7. In the Members box, add the names of the users whom you want to allow access to the external data source. For this example use the AdventureWorksBCSUsers security group you created in Prerequisites for deploying a Business Connectivity Services on-premises solution in SharePoint 2013.
  8. Perform the steps in the Set credentials for a target application procedure using these parameters:
    1. In the SQL User Name box, type AdventureWorksUser which is the name SQL Server account you created in Create database logins for a Business Connectivity Services on-premises solution in SharePoint 2013.
    2. In the SQL Password, and Confirm SQL Password boxes type the password for that account, which is actually the password for the SharePointGroupAccount account that you created in Create database logins for a Business Connectivity Services on-premises solution in SharePoint 2013.

    Important:

Link to Step 7Create an external content type for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Open How to: Create external content types for SQL Server in SharePoint 2013 Preview
  2. Create a new external content type named AWcustomers with a display name of AdventureWorks Customers.

  • Define general and Office behaviors

  1. Set the Office Item Type to Contact. The Office Item Type determines the Outlook behavior you want to attach to the external content type. In this case, this AWCustomer external content type behaves like a native Contact Item in Outlook.
  2. In the Offline Sync for External List checkbox, make sure Enabled is selected, which is the default.

    Note:

If you disable this option, then the SharePoint Connect to Outlook ribbon command is not available for an external list.

  • Create a connection to the external data

  1. Add a connection using SQL Server as the External Data Source Type.
  2. In the Set the Database Server box, enter <The name of the database server> and in the Set the Database Name box, enter AdventureWorks2008R2. Optionally, in the Name box, enter AdventureWorks Sample Database.
  3. Select Connect with Impersonated Custom Identity.
  4. In the Secure Store Application ID box, enter AWTargetAppID.

    Warning:

If you are prompted to enter a user name and password for AWTargetAppID it may be because when you created the SharePointGroupAccount SQL login, you did not uncheck the User must change password at next login option. To fix this, you must change the password via SQL query ALTER LOGIN <LoginName> WITH PASSWORD = ‘<originalpassword>‘

  • Select a table, view, or routine and Define Operation

  1. In the AdventureWorks Sample Database select the vIndividualCustomer view and right click Create All Operations.

    Note:

Create All Operations is a convenient way to define all basic methods of operations (Create, Read, Read List, Update, and Delete).

    Tip:

Always read carefully the messages in the Errors and Warnings pane. They provide useful information to confirm your actions or troubleshoot any issues.

  • Add columns

  1. In the Parameters Configuration dialog box, by default all columns are selected. To remove unnecessary columns, clear the checkboxes next to the following columns: Suffix and Demographics.
  2. For the BusinessEntityID select the Map to Identifier value.

    Note:

Uncheck the Required box to prevent it from being updated but select the Read Only checkbox, which is needed to retrieve items so you can update other fields.

  • Map Outlook fields and set up the external item picker control

  1. For the FirstName, LastName, EmailAddress, and PhoneNumber fields, do the following:
  2. Click and highlight the field.
  3. Under properties, in the Office property dropdown, select the appropriate matching field: FirstName to First Name (FirstName), LastName to Last Name (LastName), and PhoneNumber to Primary Telephone Phone Number (PrimaryTelephonePhoneNumber), EmailAddress to EmailAddress1 (Email1Address).

    Note:

Unmapped fields, depending on the number, are displayed as extended properties. For two to five fields they are listed as Adjoining meaning that they are appended to the form region at the bottom of an Outlook form’s default page. For six or more fields they are listed as Separate and are added as a new page to an Outlook.

  1. For the following fields, BusinessEntityID, FirstName, LastName, and EmailAddress click and highlight the field, and then under Properties, click Show in Picker.

  • Define filters

  1. Create a Comparison filter named ByRegion, use CountryRegionName for the value.
  2. Under Properties, next to Default Value, enter Canada.
  3. Create Limit filter named AWLimit, use BusinessEntityID for the Filter Field
  4. Set the default value to 200

    Tip:

Click the Errors and Warnings pane and make sure there are no more errors or warnings.

  • Set the Title field for an external list and complete the external content type

  1. Set BusinessEntityID as the Title and save the external content type.

    Important:

Link to Step 8Configure permission on an external content type for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Open the Central Administration page for your site.
  2. On the Quick Launch, click Application Management.
  3. On the Application Management page, under Service Applications, click Manage service applications.
  4. In the list of services, click your Business Data Connectivity (BDC) Service.
  5. Click AWCustomers.
  6. On the ribbon, click Set Object Permissions.
  7. Enter the user accounts to which you want to grant permissions, and then click Add. For this example, you would add the security group that was created in Prerequisites for deploying a Business Connectivity Services on-premises solution in SharePoint 2013AdventureWorksBCSUsers.
  8. Select the user accounts that you just added, and then select Execute check boxe.
  9. Select the Propagate permissions to all BDC Models, External Systems and External Content Types in the BDC Metadata Store check box to overwrite existing permissions.
  10. Click OK.

The external content type is now available for use in SharePoint and Office products to the appropriate users.

    Important:

Link to Step 9Create an external list for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Open Create an external list
  2. Create an external list named AdventureWorksCustomers using the AWCustomers external content type.

  • Create a view of an external list

  1. Create a view for the external list AdventureWorksCustomers. For this example use ByRegionData Source Filter.
  2. Make it the default view, and select your own Sort, Filter, and Limit values.

    Important:

Link to Step 10Manage user permissions on an external list for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. On the List tab, in the Settings group, click List Settings.
  2. Under Permissions and Management, click Permissions for this list…
  3. Apply permissions to the list as you have planned them.

The following table summarizes the default external list permissions for SharePoint user groups:

 

Name

Permission levels

Excel Services Viewers

View Only

<Site Name> Members

Edit

<Site Name> Owners

Full Control

<Site Name> Visitors

Read

 

    Important:

Link to Step 11Connect an external list to Outlook for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. Open the SharePoint 2013 site that contains the external list. In the ribbon, on the List tab, in the Connect & Export group, click Connect to Outlook.
  2. In the Microsoft Office Customization Installer dialog box, click Install.The installation should take a minute or two.
  3. Once the installation is complete, click Close.

  • Link to

Step 12Verify offline access and synchronization of external data in Outlook for a Business Connectivity Services on-premises solution in SharePoint 2013 of the Business Connectivity Services On-Premises scenario deployment procedures.

 

 
  1. To take Outlook 2013 offline, click Send/Receive, and in the Preferences group, click Work Offline.
  2. Make a change or two to one of the AdventureWorks customers.
  3. To bring Outlook 2013 back online, click Send/Receive, and in the Preferences group, click Work Online.
  4. To synchronize the data, on the navigation pane, right-click the <Team Site Name> AWCustomers external list and then click Sync now

 

 

  1. Ensure that the Exchange Web Service managed API is installed on every front-end server that is running SharePoint Server 2013. For more information about the Exchange Web Service managed API, see Hardware and software requirements (SharePoint 2013 Preview).
  2. Configure a trust relationship between SharePoint Server 2013 and Exchange Server. For information about how to configure the trust relationship, see Configure server-to-server authentication in SharePoint 2013.
  3. If you want content from Lync Server 2013 to be discoverable, configure Lync Server 2013 to archive to Exchange Server 2013. For information about how to configure Lync Server 2013 archiving, see Microsoft Lync Server 2013 Archiving Deployment Guide.
  4. Perform the eDiscovery configuration steps for Exchange. For information about how to configure Exchange Server 2013 for eDiscovery, see Configure Exchange for SharePoint eDiscovery Center.
  1. If content in Exchange Server 2013 must be discoverable, add Exchange Server 2013 as a result source. For information about how to configure a result source, see Configure result sources for search in SharePoint Server 2013.
  2. Ensure that all websites that contain discoverable content are being crawled. For information about how to configure a location to be crawled, see Add, edit, or delete a content source (SharePoint Server 2010).
  3. Ensure that all file shares that contain discoverable content are being crawled. For information about how to configure a location to be crawled, see Add, edit, or delete a content source (SharePoint Server 2010).

  • Grant permissions

    The article Plan for eDiscovery recommends that you create a security group to contain all users of the eDiscovery Center. After you create the security group, grant the security group permissions to access all discoverable content.

        Note:

    The article Plan for eDiscovery explains the different ways of granting permissions to discoverable content. You should have chosen to grant permissions at the web application level or at the site collection level.

  1. If you will grant permissions at the web application level, create a user policy that gives the security group full read permissions for each web application that contains discoverable content. For information about how to create a policy for a web application, see Manage permission policies for a Web application (SharePoint Server 2010).

    Note:

When you change permissions at the web application level, Search re-crawls all of the content in the web application.

  1. If you will grant permissions at the site collection level, make the security group a site collection administrator for each site collection that contains discoverable content. For information about how to add a site collection administrator, see Add or change a site collection administrator.

    Important:

A site collection administrator must add the security group as an additional site collection administrator by using the Site Settings menu. You cannot use Central Administration to make a security group a site collection administrator

  1. Ensure that the security group has permissions to access all file shares and other websites that contain discoverable content.
  2. If you will use a SharePoint eDiscovery Center to discover content in Exchange Server, grant the security group permissions to access Exchange Server mailboxes. For information about how to grant permissions in Exchange, see Configure Exchange for SharePoint eDiscovery Center.
  3. Grant the security group permissions to view the crawl log. For information about how to grant permissions to access the crawl log, see Set-SPEnterpriseSearchCrawlLogReadPermission.
  1. Download EWSManagedAPI.msi from the Microsoft Download Center (http://go.microsoft.com/fwlink/p/?LinkId=258305) and save it to a folder on each WFE server.
  2. Open a command window as administrator and navigate to the folder where you saved EWSManagedAPI.msi.
  3. Run the following command:

    msiexec /i EwsManagedApi.msi addlocal=”ExchangeWebServicesApi_Feature,ExchangeWebServicesApi_Gac”

  4. Reset IIS from the command line by typing IISReset.

  • Establish OAuth Trust and Service Permissions on SharePoint Server 2013

    The next step is to copy the following two scripts. The first should be saved as Set-SiteMailboxConfig.ps1 and the second should be saved as Check-SiteMailboxConfig.ps1.

    Set-SiteMailboxConfig.ps1:

    # .SYNOPSIS
    #
    # Set-SiteMailboxConfig helps configure Site Mailboxes for a SharePoint farm
    #
    # .DESCRIPTION
    #
    # Establishes trust with an Exchange Server, sets Site Mailbox settings and enables Site Mailboxes for a farm.
    #
    # .PARAMETER ExchangeSiteMailboxDomain
    #
    # The FQDN of the Exchange Organization where Site Mailboxes will be created
    #
    # .PARAMETER ExchangeAutodiscoverDomain
    #
    # [Optional] The FQDN of an Exchange Autodiscover Virtual Directory
    #
    # .PARAMETER WebApplicationUrl
    #
    # [Optional] The URL of a specific web application to configure. If not specified all Web Applications will be configured
    #
    # .PARAMETER Force
    #
    # [Optional] Indicate that the script should ignore any configuration issues and enable Site Mailboxes anyway
    #

    Param
    (
    [Parameter(Mandatory=$true)]
    [ValidateNotNullOrEmpty()]
    [string]$ExchangeSiteMailboxDomain,
    [Parameter(Mandatory=$false)]
    [ValidateNotNullOrEmpty()]
    [string]$ExchangeAutodiscoverDomain,
    [Parameter(Mandatory=$false)]
    [ValidateNotNullOrEmpty()]
    [string]$WebApplicationUrl,
    [Parameter(Mandatory=$false)]
    [switch]$Force
    )

    $script:currentDirectory = Split-Path $MyInvocation.MyCommand.Path

    if($WebApplicationUrl -ne $NULL -and $WebApplicationUrl -ne “”)
    {
    $webapps = Get-SPWebApplication $WebApplicationUrl
    }
    else
    {
    $webapps = Get-SPWebApplication
    }

    if($webapps -eq $NULL)
    {
    if($WebApplicationUrl -ne $NULL)
    {
    Write-Warning “No Web Application Found at $($WebApplicationUrl). Please create a web application and re-run Set-SiteMailboxConfig”
    }
    else
    {
    Write-Warning “No Web Applications Found. Please create a web application and re-run Set-SiteMailboxConfig”
    }

    return
    }

    $rootWeb = $NULL

    foreach($webapp in $webapps)
    {
    if($rootWeb -eq $NULL)
    {
    $rootWeb = Get-SPWeb $webApp.Url -EA SilentlyContinue
    }
    }

    if($rootWeb -eq $NULL)
    {
    Write-Warning “Unable to find a root site collection. Please create a root site collection on a web application and re-run Set-SiteMailboxConfig”
    return
    }

    $exchangeServer = $ExchangeAutodiscoverDomain

    if($exchangeServer -eq $NULL -or $exchangeServer -eq “”)
    {
    $exchangeServer = “autodiscover.$($ExchangeSiteMailboxDomain)”
    }

    Write-Host “Establishing Trust with Exchange Server: $($exchangeServer)”

    $metadataEndpoint = “https://$($exchangeServer)/autodiscover/metadata/json/1&#8221;

    $exchange = Get-SPTrustedSecurityTokenIssuer | Where-Object { $_.MetadataEndpoint -eq $metadataEndpoint }

    if($exchange -eq $NULL)
    {
    $exchange = New-SPTrustedSecurityTokenIssuer -Name $exchangeServer -MetadataEndPoint $metadataEndpoint
    }

    if($exchange -eq $NULL)
    {
    Write-Warning “Unable to establish trust with Exchange Server $($exchangeServer). Ensure that $($metadataEndpoint) is accessible.”

    if($ExchangeAutodiscoverDomain -eq $NULL -or $ExchangeAutodiscoverDomain -eq “”)
    {
    Write-Warning “If $($metadataEndpoint) does not exist you may specify an alternate FQDN using ExchangeAutodiscoverDomain.”
    }
    return
    }

    Write-Host “Granting Permissions to Exchange Server: $($exchangeServer)”
    $appPrincipal = Get-SPAppPrincipal -Site $rootWeb.Url -NameIdentifier $exchange.NameId
    Set-SPAppPrincipalPermission -AppPrincipal $appPrincipal -Site $rootWeb -Scope SiteSubscription -Right FullControl -EnableAppOnlyPolicy

    Write-Host
    Write-Host

    Write-Host “Verifying Site Mailbox Configuration”
    $warnings = & $script:currentDirectory\Check-SiteMailboxConfig.ps1 -ReturnWarningState

    if($warnings -and -not $Force)
    {
    Write-Warning “Pre-requisites not satisfied. Stopping Set-SiteMailboxConfig. Use -Force to override”
    return
    }
    elseif($warnings)
    {
    Write-Warning “Pre-requisites not satisfied. -Force used to override”
    }

    foreach($webapp in $webapps)
    {
    Write-Host “Configuring Web Application: $($webapp.Url)”
    Write-Host “Setting Exchange Site Mailbox Domain to $($ExchangeSiteMailboxDomain)”
    $webapp.Properties[“ExchangeTeamMailboxDomain”] = $ExchangeSiteMailboxDomain

    if($ExchangeAutodiscoverDomain -ne $NULL -and $ExchangeAutodiscoverDomain -ne “”)
    {
    Write-Host “Setting Exchange Autodiscover Domain to $($ExchangeAutodiscoverDomain)”
    $webapp.Properties[“ExchangeAutodiscoverDomain”] = $ExchangeAutodiscoverDomain;
    }

    $webapp.Update()
    }

    $feature = Get-SPFeature CollaborationMailboxFarm -Farm -ErrorAction Ignore

    if($feature -eq $NULL)
    {
    Write-Host “Enabling Site Mailboxes for Farm”
    Enable-SPFeature CollaborationMailboxFarm
    }
    else
    {
    Write-Host “Site Mailboxes already enabled for Farm”
    }

    CheckSiteMailboxConfig.ps1:

    Param
    (
    [Parameter(Mandatory=$false)]
    [ValidateNotNullOrEmpty()]
    [switch]$ReturnWarningState
    )

    Add-PSSnapin Microsoft.SharePoint.Powershell

    $anyWarnings = $false

    Write-Host “Step 1: Checking for Exchange Web Services”

    try
    {
    $assm = [System.Reflection.Assembly]::Load(“Microsoft.Exchange.WebServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”)
    if($assm.GlobalAssemblyCache)
    {
    Write-Host -Foreground Green “Found Exchange Web Services in Global Assembly Cache”
    Write-Host “Exchange Web Services Version: $([System.Diagnostics.FileVersionInfo]::GetVersionInfo($assm.Location).FileVersion)”
    }
    else
    {
    Write-Warning “Unable to find Exchange Web Services in Global Assembly Cache”
    $anyWarnings = $true
    }
    }
    catch
    {
    Write-Warning “Unable to find Exchange Web Services in Global Assembly Cache”
    $anyWarnings = $true
    }

    Write-Host
    Write-Host

    Write-Host “Step 2: Checking for https web application”

    $webapps = Get-SPWebApplication -EA SilentlyContinue

    $rootWeb = $NULL

    if($webapps -ne $NULL)
    {
    $sslWebAppExists = $false
    foreach($webapp in $webapps)
    {
    if($rootWeb -eq $NULL)
    {
    $rootWeb = Get-SPWeb $webApp.Url -EA SilentlyContinue
    }

    if(-not $webapp.Url.StartsWith(“https://&#8221;))
    {
    Write-Warning “Web Application at $($webapp.Url) does not use HTTPS. Site Mailboxes will not work on this Web Application.”
    }
    else
    {
    $sslWebAppExists = $true
    Write-Host -Foreground Green “Found Web Application at $($webapp.Url) that uses HTTPS”
    }
    }

    if(-not $sslWebAppExists)
    {
    Write-Warning “At least one Web Application must be configured for HTTPS in the default zone.”
    $anyWarnings = $true
    }
    }
    else
    {
    Write-Warning “No Web Applications Found. Please create a web application and re-run Check-SiteMailboxConfig”
    $anyWarnings = $true
    if($ReturnWarningState)
    {
    return $anyWarnings
    }
    return;
    }

    if($rootWeb -eq $NULL)
    {
    Write-Warning “Unable to find any Sites. Please create a root site collection on a web application and re-run Check-SiteMailboxConfig”
    $anyWarnings = $true
    if($ReturnWarningState)
    {
    return $anyWarnings
    }
    return;
    }

    # Get App Permissions Management Objects
    $appPrincipalManager = [Microsoft.SharePoint.SPAppPrincipalManager]::GetManager($rootWeb)
    $appPrincipalPermissionsManager = New-Object -TypeName Microsoft.SharePoint.SPAppPrincipalPermissionsManager -ArgumentList $rootWeb

    Write-Host
    Write-Host
    Write-Host “Step 3: Checking for trusted Exchange Servers”

    $trustedIssuers = Get-SPTrustedSecurityTokenIssuer
    $trustedIssuerHosts = @()

    if($trustedIssuers -ne $NULL)
    {
    $foundTrustedIssuer = $false
    foreach($trustedIssuer in $trustedIssuers)
    {
    if($trustedIssuer.RegisteredIssuerName.StartsWith(“00000002-0000-0ff1-ce00-000000000000@”))
    {
    if($trustedIssuer.IsSelfIssuer)
    {
    $foundTrustedIssuer = $true

    $uri = New-Object -TypeName System.Uri -ArgumentList $trustedIssuer.MetadataEndPoint

    Write-Host -Foreground Green “Found trusted Exchange Server at $($uri.Host)”
    $appPrincipalName = [Microsoft.SharePoint.SPAppPrincipalName]::CreateFromNameIdentifier($trustedIssuer.RegisteredIssuerName)
    $appPrincipal = $appPrincipalManager.LookupAppPrincipal([Microsoft.SharePoint.SPAppPrincipalIdentityProvider]::External, $appPrincipalName);

    if($appPrincipal -ne $NULL)
    {
    $isValidAppPrincipal = $true;

    if($appPrincipalPermissionsManager.GetAppPrincipalSiteSubscriptionContentPermission($appPrincipal) -eq [Microsoft.SharePoint.SPAppPrincipalPermissionKind]::FullControl)
    {
    Write-Host -Foreground Green “Exchange Server at $($uri.Host) has Full Control permissions”

    }
    else
    {
    Write-Warning “Exchange Server at $($uri.Host) does not have Full Control permissions”
    $isValidAppPrincipal = $false;
    $anyWarnings = $true
    }

    if($appPrincipalPermissionsManager.IsAppOnlyPolicyAllowed($appPrincipal))
    {
    Write-Host -Foreground Green “Exchange Server at $($uri.Host) has App Only Permissions”
    }
    else
    {
    Write-Warning “Exchange Server at $($uri.Host) does not have App Only Permissions”
    $isValidAppPrincipal = $false;
    $anyWarnings = $true
    }

    if($isValidAppPrincipal)
    {
    $trustedIssuerHosts += $uri.Host
    }

    }
    else
    {
    Write-Warning “Unable to get App Principal for $($uri.Host). Unable to check permissions for this Exchange Server”
    $anyWarnings = $true
    }
    }
    else
    {
    Write-Warning “Found trusted Exchange Server at $($uri.Host) but it is not a Self Issuer”
    $anyWarnings = $true
    }
    }
    }

    if(-not $foundTrustedIssuer)
    {
    Write-Warning “Unable to find any trusted Exchange Servers”
    $anyWarnings = $true
    }
    }
    else
    {
    Write-Warning “Unable to find any trusted Exchange Servers”
    $anyWarnings = $true
    }

    Write-Host
    Write-Host
    Write-Host “Step 4: Report current Site Mailbox Configuration”

    if($webapps -ne $NULL)
    {
    foreach($webapp in $webapps)
    {
    Write-Host
    Write-Host “Web Application Site Mailbox Configuration: $($webapp.Url)”
    Write-Host “Exchange Site Mailbox Domain: $($webapp.Properties[“ExchangeTeamMailboxDomain”])”

    if($webapp.Properties[“ExchangeAutodiscoverDomain”] -ne $NULL)
    {
    Write-Host “Exchange Autodiscover Domain: $($webapp.Properties[“ExchangeAutodiscoverDomain”])”
    }
    }
    }

    Write-Host
    Write-Host “Trusted Exchange Services: $([String]::Join(“, “, $trustedIssuerHosts))”

    $feature = Get-SPFeature CollaborationMailboxFarm -Farm -ErrorAction Ignore

    if($feature -eq $NULL)
    {
    Write-Host -ForegroundColor Red “Site Mailboxes are NOT enabled for Farm”
    }
    else
    {
    Write-Host -ForegroundColor Green “Site Mailboxes are enabled for Farm”
    }

    if($ReturnWarningState)
    {
    return $anyWarnings
    }

    Save the two .ps1 files to the same folder on a SharePoint 2013 WFE server, as one script calls the other during execution. In a SharePoint PowerShell window (right-click and Run As Administrator to open), navigate to the folder containing the .ps1 files and run the Set-SiteMailboxConfig.ps1 script. This will allow users to retrieve and install the Exchange metadata, giving the Exchange service principal full control permissions to SharePoint site subscription, enable the site mailbox feature in the SharePoint environment and optionally set the Exchange site mailbox target domain, if DNS for the domain has not been configured for AutoDiscover. The Check-SiteMailboxConfig.ps1 is called as part of the Set-SiteMailboxConfig script, and will confirm the configuration has been successful (it can also be run separately).

    The format should be as follows:

    .\Set-SiteMailboxConfig.ps1 <Domain> <Exchange Server> [URL] [FQDN of the Exchange AutoDiscovery virtual directory]

    Where <Domain> will equal the FQDN of the domain your Exchange is in, and <Exchange Server> is the Exchange you intend to connect to. These are required parameters.

    Optional parameters are [URL], which would be a specific URL you may be configuring (typically used in an environment with SSL and non-SSL web applications), while [FQDN of the Exchange AutoDiscovery virtual directory] may need to be configured if DNS AutoDiscovery is not enabled or properly configured.

    Example: .\Set-SiteMailboxConfig.ps1 tailspintoys.com exchange1.tailspintoys.com https://tailspintoys.com https://exchange1.tailspintoys.com/autodiscover/metadata/json/1If while running the script you encounter an error, please refer to the Troubleshooting section below for guidance.

  • Configure Exchange Server 2013 for Site Mailboxes

    The final step is to establish OAuth trust, and service permissions, on the Exchange server.

    • Establish OAuth Trust and Service Permission on Exchange

  1. On your Exchange Server open the Exchange Windows PowerShell window as Administrator and change to the “C:\Program Files\Microsoft\Exchange Server\V15\Scripts” directory.
  2. Run the following command:

    .\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://<SP_FQDN>/_layouts/15/metadata/json/1

    Where <SP_FQDN> is the URL to the SharePoint SSL root site collection you wish to configure.

  • Troubleshooting

    Please review the following if issues are encountered.

    • Table of Error Codes for Reference When Running Configuration Checklist Script

     

    Error Code

    Error

    Notes

    0

    NoError

    Review Prerequisites.

    1

    ExchangeClientNotAvailable

    EWS client was not found on the SharePoint WFE. Run the Check script and ensure the entries are properly in the GAC; you may need to reinstall the EWS client.

    2

    UnsupportedVersion

    EWS client version is incompatible with SharePoint. Run the Check script to ensure the version meets minimum requirements. Alternatively, the Exchange server may be 2010 or earlier.

    3

    InvalidUser

    The TeamMailboxDomain parameter is not a valid FQDN or SMTP address.

    4

    UnauthorizedUser

    The script received a 401 from the Exchange Server, review the Exchange setup steps.

    5

    ServerBusy

    Exchange timed out during AutoDiscovery. It should be intermittent, please retry, but if it is persistent, follow-up with the Exchange Administrator.

    6

    URLNotAvailable

    AutoDiscovery failed to return a URL for ECP/OWA, which means typically that the EWS client version is incompatible with SharePoint. It may also mean Site Mailboxes are not enabled on Exchange, which would require follow-up with the Exchange Administrator.

    7

    OAuthNotSupported

    Unsuccessful in generating an OAuth token on behalf of SharePoint. This is typically caused by claims-based authentication being disabled on the SharePoint web application.

    8

    OAuthException

    An error occurred during the OAuth handshake between SharePoint and Exchange. This is typically caused by server to server configuration issues, such as a realm value mismatch on either side, certificate issues for Exchange or SharePoint, etc. Review certificates and attempt to establish or reestablish trust.

    9

    InvalidAutodiscoverDomain

    The AutoDiscover domain property is not set to a valid FQDN.

    10

    UnknownError

    An unknown error condition has occurred. Run the Check script and confirm that a valid, trusted instance of SharePoint is available, review prerequisites, confirm AutoDiscover has been set-up properly with the Exchange Administrator.

    101

    OAuthNotSupportedOverHttp

    If this error is thrown, your web application‘s default zone is not set to SSL, and AllowOauthoverHttp is also set to false. Run the Check script to ensure that any web application you intend to host site mailboxes are set with SSL in the default zone, as outlined in the prerequisites.

    102

    AssociatedOwnersGroupNull

    One or both of the default Owners and Members groups for the site have been deleted. Each of these two default groups are required to exist on any site where users install site mailboxes. A site administrator should be able to direct a site owner to recreated these required groups.

    103

    ExchangeTeamMailboxDomainNotSet

    The ExchangeTeamMailboxDomain property has not been set.

    104

    ExchangeAppPrincipalNotFound

    No Exchange app principals were found to be trusted. Typically, this means the New-SPTrustedSecureTokenService step was missed. Run the Check script and ensure that the app principal URL(s) outputted are the correct one(s).

    105

    ExchangeAppPrincipalMissingPermissions

    The Exchange app principal being connected to doesn‘t have the right permissions on the SharePoint farm. Run the Check script and ensure that the Exchange app principal has the required permissions on the farm.

     

     

     

  • Configure Exchange task synchronization in SharePoint Server 2013

    Published: August 21, 2012

    Summary: Configure Exchange Server 2013 and SharePoint Server 2013 for task synchronization by using the SharePoint Server 2013 Task Synchronization feature.

    Applies to:  SharePoint Server 2013 Enterprise 

    This article describes how to configure Task Synchronization in SharePoint Server 2013 and Exchange Server 2013. Task Synchronization allows users to synchronize SharePoint Server 2013 and Project Server tasks with Exchange Server and have them appear in Outlook 2013.

  • Before you begin

    Before you begin this operation, review the following information about prerequisites:

        Note:

    You may need to import the SSL certificate from the SharePoint Server 2013 web application. This is only necessary if the certificate is not trusted for the API endpoints (such as a Self-SSL Certificate in a lab environment).

    To import the untrusted SSL certificate from SharePoint Server 2013:

    • Open Internet Explorer on the Exchange server and navigate to the SSL SharePoint site https://<SP_FQDN&gt;, where <SP_FQDN> is the URL to the SSL site.
    • Accept to trust the certificate by clicking Continue to website.
    • Click Certificate Error info in Internet Explorer next to the Address bar, and then click View Certificates.
    • Select Install Certificate and then select Place all certificates in the following store.
    • Select the checkbox to show physical stores.
    • Install the certificate to Trusted Root Certification Authorities > Local Computer.
    • In order to perform these procedures, you must be a member of the SharePoint and Exchange Server administrator groups and have an operational Exchange Server with end-user mailboxes.

        Note:

    Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources:

  • Configure SharePoint for Task Synchronization in SharePoint Server 2013

    The first step in configuring Task Synchronization is to install the Exchange Server Web Services API on each web front-end server in the SharePoint Server 2013 farm.

    • Install Exchange Web Services API on SharePoint Server

  1. Download EWSManagedAPI.msi from the Microsoft Download Center (http://go.microsoft.com/fwlink/p/?LinkId=258305) and save it to a folder on the application server.
  2. Open a command window as administrator and navigate to the folder where you saved EWSManagedAPI.msi.
  3. Run the following command:

    msiexec /i EwsManagedApi.msi addlocal=”ExchangeWebServicesApi_Feature,ExchangeWebServicesApi_Gac”

  4. Reset IIS from the command line by typing IISReset.

  • Configure Exchange Server 2013 for Task Synchronization

    The next step is to establish OAuth trust and service permission on Exchange Server.

    • Establish OAuth Trust and Service Permission on Exchange

  1. On the Exchange server, open Windows PowerShell and change to the “C:\Program Files\Microsoft\Exchange Server\V15\Scripts” directory.
  2. Run the following script:

    .\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://<SP_FQDN>/_layouts/15/metadata/json/1

    Where <SP_FQDN> is the URL to the root site collection.

 

 

  1. Verify that you have the following administrative credentials:
  • To create a My Site host site collection, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website or a service application administrator for the services related to My Sites. If you are a service application administrator, you must also have permission to create site collections in the web application that you dedicate to host My Sites.
  1. In Central Administration, click Application Management, and then click Create site collections.
  2. On the Create Site Collection page, in the Web Application section, ensure that the selected web application is the web application that you want to host My Sites. If it is not, expand the list, and then click Change Web Application. In the Select Web Application dialog box, select a different web application.
  3. In the Title and Description section, type a title and description for the site collection.
  4. In the Web Site Address section, select the URL where you want this site collection created. Generally, you should use the default path (which is displayed as / in the user interface), which is the root of the web application. For more information about this path, see My Sites architecture in Plan for My Sites (SharePoint 2013 Preview).
  5. In the Template Selection section, in the Select experience version list, select 2013. Then, on the Enterprise tab, click My Site Host.
  6. In the Primary Site Collection Administrator section, and optionally in the Secondary Site Collection Administrator section, type an account in the format domain\username to specify an administrator for the site collection.
  7. Optionally, in the Quota Template section, select a quota template for the My Site host site collection. This quota template does not affect the individual site collections that users create for their My Sites. For more information, see Planning for storage requirements in Plan for My Sites (SharePoint 2013 Preview).
  8. Click OK. Copy this site collection URL for later reference.
  1. Verify that you have the following administrative credentials:
  • To add managed paths, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website.
  1. In Central Administration, click Application Management, and then click Manage Web applications.
  2. On the Web Applications Management page, select the web application that you created to host My Sites.
  3. On the Web Applications tab, in the Manage group, click Managed Paths.
  4. In the Define Managed Paths dialog box, in the Add a New Path section, in the Path box, type the path that you want to append to the URL namespace, and then select Wildcard inclusion. For example, if your web application URL is http://mysites.contoso.com/ and you want users’ individual site collections created under a path named “personal”, type personal in the Path box. Separate My Sites site collections will be created for each user under http://mysites.contoso.com/personal/.
  5. Click Add Path, and then click OK.
  6. Copy this managed path for later reference.
  1. Verify that you have the following administrative credentials:
  • To connect a web application to a service application, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website.
  1. In Central Administration, in the Application Management section, click Manage Web applications.
  2. On the Web Applications Management page, select the web application that you created to host My Sites.
  3. On the Web Applications tab, in the Manage group, click Service Connections.
  4. In the Configure Service Application Associations dialog box, in the Edit the following group of connections list, select default if the default group contains the service applications that you want to connect to the web application.
  • If you choose [Custom], select any service applications to which you want to connect the web application, including the User Profile service application, the managed metadata service application, and the Search service application.
  1. Click OK.
  1. Verify that you have the following administrative credentials:
  • To enable self-service site creation, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website.
  1. In Central Administration, in the Application Management section, click Manage Web applications.
  2. On the Web Applications page, select the web application that you created to host My Sites.
  3. On the Web Applications tab, in the Security group, click Self-Service Site Creation.
  4. In the Self-Service Site Creation Management dialog box, in Site Collections, select On. Optionally, in Quota template to apply, select a quota template.
  5. In Start a Site, choose one of the following options:
    1. Prompt users to create a team site under so users can create team sites from their My Site to use site feeds.
    2. Be hidden from users if you do not want users to create team sites from their My Sites to use site feeds.
  6. Click OK to finish.

Perform these additional steps to configure permissions for users to create team sites from their My Sites to use site feeds.

  1. In the Policy group, click Permission Policy.
  2. On Manage Permission Policy Levels dialog box, click Add Permission Policy Level.
  3. Type a name for the permission policy.
  4. Under Permissions, in Site Permissions, select the Grant option for Create Subsites – Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
  5. Click Save.
  6. In the Policy group, click User Policy.
  7. On Policy for Web Application dialog box, click Add Users.
  8. On Add Users, in Zones select (All Zones), then click Next.
  9. In Choose Users, enter the user names of the users that you want to create team sites from their My Site to use site feeds. If all users can create team sites from their My Site to use site feeds, click the Browse icon. In Select People and Groups, click All Users, then click Everyone. Click Add, and then click OK.
  10. In the Choose Permissions section, select the name of the Permission Policy created previously.
  11. Click Finish, and then click OK.
  1. Verify that you have the following administrative credentials:
  • To configure My Site settings for the User Profile service application, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website or a service application administrator for the User Profile service application.
  1. In Central Administration, in the Application Management section, click Manage service applications.
  2. Click the User Profile service application that you connected to the web application hosting My Sites earlier in this task.
  3. On the Manage Profile Service page, in the My Site Settings section, click Setup My Sites.
  4. On the My Sites Settings page, in the Preferred Search Center section, specify settings for the search center to direct users to when they search for people or documents from their About Me profile page. If you do not have a search center set up yet, you can skip this step and complete it later. For more information, see Search service application in Plan for My Sites (SharePoint 2013 Preview).
  5. In the My Site Host section, type the URL of the My Site host site collection that you created earlier in this task.
  6. Optionally, in the My Site Host URL in Active Directory section, type the URL of the My Site host site collection that is returned to client and mobile phone applications that uses Exchange Auto Discovery. When a user is using a client or mobile phone application, credentials are passed in the form of an email address and password. Exchange Auto Discover then finds other required settings, such as SMTP server name, and sends this to the client or mobile phone application. Client and mobile phone applications use Exchange Auto Discovery to find a user’s SharePoint Server 2013My Site based on the My Site host URL stored in Active Directory Domain Services (AD DS).
  7. In the Personal Site Location section, type the wildcard inclusion managed path you configured earlier in this task. By default, personal is prepopulated in the box. However, if you chose a different path for your wildcard inclusion managed path, replace personal with your path.
  8. In the Site Naming Format section, select a naming format for the My Sites site collections that will be created when users view their My Sites for the first time. For more information about these formats, see My Sites architecture in Plan for My Sites (SharePoint 2013 Preview).
  9. In the Language Options section, specify whether users can select a preferred language for their My Site. The available languages correspond to the language packs installed in the farm. All servers in a farm must have the same language packs. For more information about multilingual sites, see Plan for multilingual sites (SharePoint Server 2010). For more information about language packs, see About language IDs and language packs in Install or uninstall language packs for SharePoint 2013.
  10. In the Read Permission Level section, specify the users or groups that can view other users‘ My Sites when they are created. By default, this includes all authenticated users. However, you can select a more specific group or users depending on the needs of your deployment.
  11. In the Security Trimming Options section, specify how system generated posts are checked for permissions before they are displayed in feeds and on the Tags and Notes page.
  12. In the Newsfeed section, enable system generated posts to the feed on My Sites by selecting Enable activities in My Site newsfeeds. This option is selected by default. This is important in hosted environments where tenants can share the same User Profile service but have different requirements on whether they can enable newsfeeds for their users.

    When upgrading from a SharePoint Server 2010 server farm that uses the newsfeed and tags and notes, you enable these legacy features on your SharePoint Server 2013 server farm by selecting Enable SharePoint 2010 activity migration.

  13. In the E-mail Notifications section, specify an email address to use as the sender email address for My Site email notifications. This account does not have to be a real monitored email address. If you want to receive notifications for newsfeed activities, such as replies to your posts or when someone follows you, select Enable newsfeed email notifications.

    Important:

You must add the IP address of the farm’s outbound SMTP server to the safe list in Exchange Server 2013 to prevent My Site email notifications from being sent to the Junk folder. For more information about safe lists in Exchange Server 2013, see Understanding Connection Filtering in the Exchange Server Technical Library.

  1. In the My Site Cleanup section, specify a new owner of a My Site if the existing My Site user is removed from the profile database. For example, if a user leaves the company and is no longer in the profile database, the user‘s My Site will be deleted together with any content. However, before it is deleted, a new owner can recover any important content. Select Enable access delegation for the My Site cleanup job to first attempt to assign ownership of the My Site to the user‘s manager. If no manager is found, the My Site is assigned to the user specified in Secondary Owner. The new owner has two weeks to retrieve content from the My Site before it is deleted.
  2. In the Privacy Settings section, select Make My Sites Public to make all users’ My Sites public. This option is not selected by default.

    Note:

When a user’s My Site is public, the user’s list of followers, the user’s list of people they are following, and all activities (including new follow notifications, social tagging and rating of content, birthdays, job title changes, workplace anniversary, updating Ask Me About, posting on a note board, and new blog posts) will be public. Any policies set within People and Privacy on the Manage Policies page is overridden.

  1. Click OK.

For more information about additional timer jobs for My Sites, see Planning for jobs and schedules in Plan for My Sites (SharePoint 2013 Preview).

  1. Verify that you have the following administrative credentials:
  • To configure timer jobs, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website.
  1. In Central Administration, click Monitoring, and then click Review job definitions.
  2. On the Job Definitions page, in the View list, select Service. The Service list appears.
  • If the Service list does not display User Profile Service, in Service, click No selection, then click Change Service. On the Select Service page, use the arrows in the upper-right corner to locate User Profile Service, and then click it. The Job Definitions page updates with the User Profile service jobs.
  1. Click the activity feed job for the User Profile service application that you created in Prerequisites earlier in this article. The job name is in the format User_Profile_service_name – Activity Feed Job, where User_Profile_service_name is the name that you specified for your User Profile service application.
  2. On the Edit Timer Job page, in the Recurring Schedule section, select the interval that you want the job to run. Available intervals are Minutes, Hourly, Daily, Weekly, and Monthly. Selecting a shorter interval, such as Minutes or Hourly, ensures that activities appear on users’ My Site newsfeeds more frequently. However, it increases load on the system depending on how many activities are available. Selecting a longer interval, such as Daily, Weekly, or Monthly, reduces the number of times the job runs and processes feeds. However, it also means that users receive less frequent updates to activities in their newsfeeds.
  3. Click Enable.
  4. Optionally, click Run Now to run the job immediately without waiting for the next scheduled interval.
  1. Verify that you have the following administrative credentials:
  • To create a site collection by using the Community Site template, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website or a service application administrator. If you are a service application administrator, you must also have permission to create site collections in the web application in which you create the Community Site.
  1. In Central Administration, click Application Management, and then click Create site collections.
  2. On the Create Site Collection page, in the Web Application section, ensure that the selected web application is the web application in which you want to create the Community Site. If it is not, expand the list, and then click Change Web Application. In the Select Web Application dialog box, select a different web application.
  3. In the Title and Description section, type a title and description for the site collection.
  4. In the Web Site Address section, select the URL where you want this site collection created.
  5. In the Template Selection section, in the Select experience version list, select 2013. Then, on the Collaboration tab, click Community Site.
  6. In the Primary Site Collection Administrator section, and optionally in the Secondary Site Collection Administrator section, type an account in the format domain\username to specify an administrator for the site collection.
  7. Optionally, in the Quota Template section, select a quota template.
  8. Click OK.
  9. Verification: After the site collection is created successfully, click the link to open the Community Site.
  1. Verify that you have the following administrative credentials:
  • To create a site collection by using the Community Portal template, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website or a service application administrator. If you are a service application administrator, you must also have permission to create site collections in the web application in which you create the Community Portal.
  1. In Central Administration, click Application Management, and then click Create site collections.
  2. On the Create Site Collection page, in the Web Application section, ensure that the selected web application is the web application in which you want to create the Community Portal. If it is not, expand the list, and then click Change Web Application. In the Select Web Application dialog box, select a different web application.
  3. In the Title and Description section, type a title and description for the site collection.
  4. In the Web Site Address section, select the URL where you want this site collection created.
  5. In the Template Selection section, in the Select experience version list, select 2013. Then, on the Enterprise tab, click Community Portal.
  6. In the Primary Site Collection Administrator section, and optionally in the Secondary Site Collection Administrator section, type an account in the format domain\username to specify an administrator for the site collection.
  7. Optionally, in the Quota Template section, select a quota template.
  8. Click OK.
  9. Verification: After the site collection is created successfully, click the link to open the Community Portal.
  1. Verify that you have the following administrative credentials:
  • To configure Following settings for the User Profile service application, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website or a service application administrator for the User Profile service application.
  1. In Central Administration, in the Application Management section, in the Service Applications group, click Manage service applications.
  2. In the list of service applications, select the User Profile service application.
  3. In the Operations group, click Manage.
  4. On the Manage Profile Service page, in the My Sites Settings section, click Manage Following.
  5. In the Maximum number of followed people box, type the maximum number of people that a user can follow from the user‘s My Site.
  6. In the Maximum number of followed documents box, type the maximum number of documents that a user can follow from the user‘s My Site.
  7. In the Maximum number of followed sites box, type the maximum number of sites that a user can follow from the user‘s My Site.
  8. Click OK.

 

 
  1. Load last modified time information for recent conversations and activities.
  2. Load recent conversations and activities.

    Note:

In the case of planned maintenance and operations, an administrator can preserve cache data by using the graceful shutdown procedure. For more information, see Perform a graceful shutdown of the Distributed Cache service in Manage the Distributed Cache service in SharePoint Server 2013.

To manage the repopulation process, SharePoint Server 2013 includes the Feed Cache Repopulation Job timer job. When the Feed Cache Repopulation Job timer job runs, it first checks whether the Feed Cache and Last Modified Time Cache are empty. If they are empty, it starts repopulating the last modified time information for recent conversations and activities in the Last Modified Time Cache. After the timer job finishes the Last Modified Time Cache repopulation, the Feed Cache is populated with recent conversations and activities the next time any user accesses a feed in SharePoint Server 2013.

In this article:

  1. Verify that you have the following administrative credentials:
  • To configure timer jobs, you must be a member of the Farm Administrators group on the computer running the SharePoint Central Administration website.
  1. In Central Administration, on the Monitoring page, click Review job definitions.
  2. On the Job Definitions page, in the View list, select All.
  3. Use the arrows at the bottom of the page to locate the feed cache repopulation job for the User Profile service application on your server farm. The job name is in the format User_Profile_service_name – Feed Cache Repopulation Job, where User_Profile_service_name is the name that you specified for the User Profile service application.
  4. On the Edit Timer Job page, in the Recurring Schedule section, select the interval that you want the job to run. Available intervals are Minutes, Hourly, Daily, Weekly, and Monthly. Selecting a shorter interval, such as Minutes or Hourly, ensures that checks for an empty cache is performed more frequently. Selecting a longer interval, such as Daily, Weekly, or Monthly, reduces the number of times the job runs. However, it also means that performing cache repopulation checks are done fewer times. We recommend that this timer job runs on shorter intervals.
  5. Click Enable.
  6. Optionally, click Run Now to run the job immediately without waiting for the next scheduled interval.
  1. In Central Administration, click Application Management.
  2. In Service Applications, click Manage Services on Server.
  3. On the Services on Server page, locate the Distributed Cache service.
  4. If the Distributed Cache service is started and you want to stop the service, under Action, click Stop. If the Distributed Cache service is stopped and you want to start the service, under Action, click Start.

To start the Distributed Cache service by using Windows PowerShell

At the Windows PowerShell command prompt, run the following command:

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Provision()

To stop the Distributed Cache service by using Windows PowerShell

At the Windows PowerShell command prompt, run the following command:

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Unprovision()

  1. Determine the total physical memory on the server. For this example, we will use 16 GB as the total physical memory available on the server.
  2. Reserve 2 GB of memory for other processes and services that are running on the cache host. For example, 16 GB – 2 GB = 14 GB. This remaining memory is allocated to the Distributed Cache service.
  3. Take half of the remaining memory, and convert it to MB. For example, 14 GB/2 = 7 GB or 7000 MB. This is the cache size of the Distributed Cache service.
  4. Use the following procedure to update the memory allocation accordingly.

  • Change the memory allocation of the Distributed Cache by using Windows PowerShell

Use this procedure to reconfigure the memory allocation for the Distributed Cache service.

  1. Stop the Distributed Cache service on all cache hosts that are part of the cache cluster. To stop the Distributed Cache service, on all cache hosts, at the Windows PowerShell command prompt, run the following command:

    $instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
    $serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
    $serviceInstance.Unprovision()

  2. Reconfigure the cache size of the Distributed Cache service on the server that is being added or upgraded. On that server only, at the Windows PowerShell command prompt, run the following command:

    Set-CacheHostConfig -Hostname Hostname -cacheport Cacheport -cachesize Cachesize

    Where:

  • Hostname is the FQDN of the application server being reconfigured that runs the Distributed Cache service.
  • Cacheport is equal to the port number of the Distributed Cache (22233).
  • Cachesize is the cache size’s memory allocation assignment in MB. In the previous example, the cache size was calculated at 7000 MB for a server with 16 GB of total physical memory.
  1. Restart the Distributed Cache service. On all servers, at the Windows PowerShell command prompt, run the following command:

    $serviceInstance.Provision()
  1. Create a managed account. For more information, see Configure automatic password change (SharePoint Server 2010).
  2. Set the Managed account as the service account on the AppFabric Caching service. At the Windows PowerShell command prompt, run the following command:

    $farm = Get-SPFarm
    $cacheService = $farm.Services | where {$_.Name -eq “AppFabricCachingService”}
    $accnt = Get-SPManagedAccount -Identity     domain_name\user_name
    $cacheService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
    $cacheService.ProcessIdentity.ManagedAccount = $accnt
    $cacheService.ProcessIdentity.Update()
    $cacheService.ProcessIdentity.Deploy()

    Where Domain_name\user_name is the domain name and user name of the managed account.

 

 

  1. Verify that you have the following administrative credentials:
  1. In Central Administration, in the Application Management section, click Manage service applications.
  2. In the list of service applications, click User Profile Service Application.
  3. On the Manage Profile Service: User Profile Service Application page, in the People group, click Manage User Permissions.
  4. On the Permissions for User Profile Service Application page, type or select a user or group account, and then click Add.
  5. In the Permissions for box, check the feature or features that you want the user or group to be able to use, and then click OK.

 

 

  1. Verify that the user account that performs this procedure is a site collection administrator on the authoring site collection.
  2. On the top-level site of the authoring site collection, on the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Site Collection Administration section, click Site collection features.
  4. On the Site Collection Features page, next to Cross-Site Collection Publishing, click Activate.
  1. Verify that the user account that performs this procedure is a member of the Owners SharePoint group on the authoring site that contains the catalog.
  2. On the authoring site, on the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Site Administration section, click Term store management.
  4. In the TAXONOMY TERM STORE section, click the term set that you want to make available for tagging.
  5. Click the INTEDED USE tab, and then select Available for Tagging.
  6. Click Save.

When you create catalog content by using SharePoint lists, we recommend that you create site columns for the lists in which you want to maintain your catalog content. This is because managed properties are automatically created for site columns, and you can use these managed properties when defining queries for you catalog content on a publishing site. If you have several lists, we recommend that you create a site content type for each list, and then associate the appropriate site columns to this site content type. If you want to use managed navigation to display catalog content on a publishing site, you also have to create at least one term set as described in Create and manage term sets for tagging content on authoring sites. The tagging term set must be tied to a site column that is a Managed Metadata data type.

For information about how to create site content types and site columns, see the following articles:

If you have large amounts of data in external business systems — for example, an ERP system — consider importing this data into one or more SharePoint lists. SharePoint Server 2013 does not have a solution for importing list content. However, you can develop custom import tools — for example, by using Windows PowerShell. For a set of example Windows PowerShell scripts that you can use to import list content for cross-site publishing, see Import list content to Products list for SharePoint 2013 Preview. The example scripts import content only to a site collection that was created by using the Product Catalog Site Collection template.

Before you share a library or list as a catalog, verify that the Cross-Site Collection Publishing feature is activated for the site collection. If you used the Product Catalog Site Collection template to create the site collection, the Cross-Site Collection Publishing feature is already active. For all other types of site collections, you must activate the Cross-Site Collection Publishing feature before you can continue with the following steps. For more information, see Activate the Cross-Site Collection Publishing feature earlier in this article.

By default, anonymous access is enabled when you share a library or list as a catalog. If you have connected a publishing site to the catalog, and you don’t want anonymous users to be able to view and search content that was added to the search index from this catalog, you should disable anonymous access.

    Important:

In addition to enabling anonymous access for a catalog, you must enable anonymous access for the web application and publishing site so that anonymous users can search and view the content. For more information, see Create claims-based web applications in SharePoint 2013.

To share a library or list as a catalog

  1. Verify that the user account that performs this procedure is a member of the Owners group on the site that contains the library or list that you want to share.
  2. Browse to the library or list that you want to share, and then do one of the following:
  • To share a library, click the LIBRARY tab, and then, on the ribbon, in the Settings group, click Library Settings.
  • To share a list, click the LIST tab, and then, on the ribbon, in the Settings group, click List Settings.
  1. On the Settings page, in the General Settings section, click Catalog Settings.
  2. On the Catalog Settings page, in the Catalog Sharing section, select the Enable this library as a catalog check box.
  3. In the Anonymous Access section, if you want don’t want anonymous users to view and search this content, click Disable anonymous access.
  4. In the Catalog Item URL Fields section, in the Available fields box, select up to five fields that uniquely identify an item in the library or list, and then click Add.

    After you connect a publishing site to this catalog, the fields that you specified as catalog item URL fields appear as part of the friendly URL. (See the example that follows this procedure.)

  5. In the Navigation Hierarchy section, select the column that is associated with the term set that you want to use as a navigation term set for catalog pages. After you connect a publishing site to this library or list to show catalog content, the value of the column that you selected appears as part of the friendly URL (see the example that follows this procedure).

    Note:

You only have to make a selection in this section if you want to use managed navigation to display catalog content on a publishing site.

  1. Click OK.

    Note:

After you share a library or list as a catalog, the content source that contains the catalog must be crawled. You don’t have to start a full crawl. This is because an incremental crawl or a continuous crawl also adds the content to the search index. For more information, see Start, pause, resume, or stop crawls in SharePoint 2013 Preview.

In this example, let’s say that you have a list that contains data for different electronic products. The following items were specified when the list was shared as catalog:

  • Electronic products
    • Audio
    • Car audio
    • MP3
    • Computers
    • Laptops
    • Desktops

Each item in the shared list is associated with a value from this term set in the Item Category Managed Metadata site column. For more information about Managed Metadata columns, see Create a Managed Metadata column.

The following table describes how site columns and their corresponding values in the previous list are combined to create friendly URLs for catalog content when you connect a publishing site collection to this list.

 

Product title

Item Category

Item Number

Friendly URL to an item when the catalog is connected to a publishing site

Proseware 50W Car Radio

Car audio

1010101

<site>/audio/car-audio/1010101

Contoso 4GB Portable MP3 Player M450

MP3

4020102

<site>/audio/mp3/4020102

AdventureWorks Laptop8.9 E0890

Laptops

7030906

<site>/computers/laptops/7030906

WWI Desktop PC2.33 X2330

Desktops

7030906

<site>/computers/desktops/3030802

 

After you create a term set on the authoring site collection, you have to make it available to publishing site collections. You can make a term set available to all site collections or to specific site collections.

To make a term set available to all site collections

  1. Verify that the user account that performs this procedure is a member of the Owners SharePoint group on the authoring site that contains the catalog.
  2. On the authoring site, on the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Site Administration section, click Term store management. If the user that performs this procedure is already a member of the Term Store Administrators group, you can skip to step 7.
  4. In the Term Store Management Tool, verify that Managed Metadata Service is selected.
  5. In the Term Store Administrator section, type one or more user names.
  6. Click Save.
  7. Right-click Managed Metadata Service, and then select New Group.
  8. Type the name of the global term set that you want to create, and then press Enter.
  9. Refresh the page.
  10. Right-click the term set that you want to make available to all site collections, and then click Move Term Set.
  11. In the Term Set Move dialog box, click the global term set that you want to move the term set to, and then click OK.
  12. Refresh the page.

To make a term set available to specific site collections

  1. Verify that the user account that performs this procedure is a member of the Owners SharePoint group on the authoring site that contains the catalog.
  2. On the authoring site, on the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Site Administration section, click Term store management.
  4. In the Term Store Management Tool, click the group that contains all term sets within the site collection.
  5. In the Site Collection Access section, type the URLs of the site collections to which you want to make the term set available — for example, http://<site>/sites/products.
  6. Click Save.
  1. Verify that the user account that performs this procedure is a member of the Site collection administrators group on the site that contains the catalog.
  2. Browse to the catalog, and then do one of the following:
  • If you want to perform a full crawl of a catalog in a library, click the LIBRARY tab, and then, on the ribbon, in the Settings group, click Library Settings.
  • If you want to perform a full crawl of a catalog in a list, click the LIST tab, and then, on the ribbon, in the Settings group, click List Settings.
  1. On the Settings page, in the General Settings section, click Advanced settings.
  2. On the Advanced Settings page, in the Reindex List section, click Reindex List, and then click Reindex List to confirm that you want the catalog to be reindexed during the next scheduled crawl.
  3. Click OK.

    Note:

The full reindex of the catalog will be performed during the next scheduled crawl.

 

 
  1. Verify that the user account that completes this procedure is a member of the Owners SharePoint group on the publishing site collection.
  2. On the publishing site collection, on the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Site Administration section, click Manage catalog connections.
  4. On the Manage catalog connections page, click Connect to a catalog. A list of available catalogs appears. Note that only catalogs that have been crawled will appear.
  5. On the line that contains the catalog that you want to connect to, click Connect. You can also search for a specific catalog by typing the catalog name in the search field.
  6. On the Catalog Source Settings page, in the Connection Integration section, do one of the following:
  • To make catalog content available to the publishing site and integrate the catalog tagging term set into the publishing site navigation term set, select Integrate the catalog into my site. When you select this option, use the following steps to specify at which level the term sets should be integrated, specify the URL for the catalog item details page, and select category pages and catalog item pages.
  • To make the catalog content available to the publishing site, select Connect, but do not integrate the catalog. You should select this option if you want to use content from the library to create individual catalog item pages.

    Either option creates a result source for the catalog.

  1. In the Navigation Hierarchy section, specify the term from which the catalog tagging term set should be integrated into the publishing site navigation term set. The catalog navigation column that you previously configured in Share a library or list as a catalog appears by default. The fields in this section are optional. Therefore, if you don’t change the fields in this section, the catalog tagging term set will be integrated from the root term. If you want to integrate the catalog tagging term set from a different term, do the following:
  • Next to the Root term of hierarchy box, click Browse for a valid choice.
  • In the Select: Add Terms dialog box, click the term that corresponds to the level from which you want to integrate the catalog tagging term set, click Select, and then click OK.
  • To integrate the root term that is the parent of the selected term in the publishing site navigation term set, select the Include root term in site navigation check box.

        Note:

All items in the catalog must be tagged with a term from the specified catalog tagging term set. If this is not done, site navigation will not work as intended for all items.

  1. In the Navigation Position section, specify the term in the publishing site navigation term set where the catalog tagging term set should be integrated. Do one of the following:
  • To integrate the catalog tagging term set to the root term of the publishing site navigation term set, click Add to navigation root.
  • To integrate the catalog tagging term set to a term below the root term of the publishing site navigation term set, click Select an alternate location in site navigation, and then do the following:
    • Click Browse for a valid choice to display the publishing site navigation term set.
    • In the Select: Add Terms dialog box, click the term that corresponds to the level from which you want to integrate the catalog tagging term set, click Select, and then click OK.
  1. If you want changes to the catalog tagging term set to be updated on the publishing site, in the Navigation Pinning section, select the Pin terms to site navigation check box. By default, this option is selected. If you clear this check box, changes made to the catalog tagging term set are not reflected on the publishing site navigation.
  2. In the Catalog Item URL Behavior section, specify what you want the URL of the catalog item to do by selecting one of the following options:
  • To point the URL of the catalog item to an item details page, select Make URLs relative to this site. When you select this option, you have to specify a catalog item URL format as described in the next step. This also means that the content that you can display on the item details page has to come from the search index.
  • To have the catalog item URL point to the item in the source catalog, select Make URLs point to source catalog. When you select this option, you do not have to specify a catalog item URL format. Note that when you select this option, anonymous users are not able to access and view the item in the source catalog.
  1. In the Catalog Item URL Format section, select which properties the URL of the item details page should contain by doing one of the following:
  • To use the field that you specified as Primary Key the when you shared the library or list as a catalog as described in Share a library or list as a catalog, select Use the default URL format provided by the catalog source. By default, this option is already selected.

        Note:

All items in the catalog must have values for the specified field. Site navigation will not work as intended for items with missing values.

  • To manually define a format for the URL, select Manually define a URL format, and then type in a URL. You should select this option only if you have created an item details page and the items in your catalog are not tagged with a term from a catalog tagging term set. Type the URL in the following format: /<Folder of item details page>/<Name of item details page>.aspx? <Managed property name>=[Managed property value] — for example, /Pages/itemdetails.aspx?TitleProperty=[Title].
  • To construct a custom URL based on catalog properties, select Construct a URL format from catalog properties, and then do the following:
    • In the Available Fields list, select up to five fields, and then click Add.

    Important:

Fields of site column type Number will not create a valid URL. All items in the catalog must have values for the specified fields. Site navigation will not work as intended for items with missing values.

  1. In the Category Page section, do one of the following:
  • To have SharePoint Server 2013 automatically create a new Category page for your catalog content, click Create a new page, and then select a master page. The page will be added to the Pages library with the name Category-<catalog tagging term set name>. The page will not be published automatically.
  • To use a Category page that was already created, select Use an existing page, and then specify the location of the page.
  1. In the Item Page section, do one of the following:
  • To have SharePoint Server 2013 automatically create a new Item page for your catalog content, click Create a new page, and then select a master page. The page will be added to the Pages library with the name CatalogItem-<catalog tagging term set name>. The page will not be published automatically.
  • To use an already created Item page, select Use an existing page, and specify the location of this page.
  1. Click OK.

 

 

  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page where you want to add the Web Part.
  3. Click the Settings menu, and then click Edit page.
  4. In the Web Part Zone where you want to add the Web Part, click Add a Web Part.
  5. In the Categories list, click Content Rollup.
  6. In the Parts list, click Content Search, and then click Add.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page that contains the Content Search Web Part that you want to configure.
  3. Click the Settings menu, and then click Edit Page.
  4. In the Web Part, click the Content Search Web Part Menu arrow, and then click Edit Web Part.
  5. In the Web Part tool pane, in the Properties section, in the Search Criteria section, click Change query.
  6. On the BASICS tab, do one of the following:
  • To define your query by using Quick Mode, select options as described in the following table:

  • Quick Mode (default)

Select a query

Select a result source to specify which content should be searched. If you have shared a document library or list as catalog, the catalog result source will be displayed in this drop-down list. By default, this is set to Recently changed items (System).

Restrict results by app

Select an option from the list to restrict results to a specific site, library, list, or URL. By default, this is set to Current site.

Restrict by tag

You can limit results to content that is tagged with a term from a term set.

Select one of the following options:

 

Don’t restrict by any tag

Search results will not be limited based on tags (default).

Restrict by navigation term of current page

Search results will be limited to content that is tagged with the term of the current page. The current tag is displayed as the last part of the friendly URL. This option is only meaningful for sites that use managed navigation.

Restrict by current and child navigation

Search results will be limited to content that is tagged with the term of the current page (displayed as the last part of the friendly URL), and content that is tagged with sub-terms of the current page. This option is only meaningful for sites that use managed navigation.

    Note:

In a cross-site publishing scenario, this selection will only work when the result source selected in the Select a query section is the catalog result source that is created when a publishing site is connected to a catalog.

Restrict on this tag

Search results will be limited to content that is tagged with the tag that you type inside the box.


 

Select a query

Select a result source to specify which content should be searched.

Default result source is Local SharePoint Results (System).

Keyword filter

You can use keyword filters to add query variables to your query. See Query variables in SharePoint Server 2013 for a list of available query variables.

You can select pre-defined query variables from the drop-down list, and then add them to the query by clicking Add keyword filter.

Property filter

You can use property filters to query the content of managed properties that are set to queryable in the search schema.

You can select managed properties from the Property filter drop-down list. Click Add property filter to add the filter to the query.

Query text

Type your query by using Keyword Query Language (KQL), or use the Keyword filter and Property filter lists to build the query.

The keyword query can consist of free-text keywords, property filters, or operators. Use braces to enclose query variables. The query variables will be replaced with an actual value when the query is run.

Keyword queries have a maximum length of 2,048 characters.
  1. The REFINERS tab lists the managed properties that are enabled as refiners in the search schema. You can specify that the search results returned in the Content Search Web Part should be limited to one or more values from the refiners. Click a refiner in the list, and then click Apply to add it to the query.

    Click Show more if you want to define grouping of results. Under Group results, you can specify that the results should be grouped based on one or more managed properties. This is useful when you are displaying several variants for a given item, and want to group them under a single result.

  2. On the SORTING tab, you can specify how search results should be sorted.

    This tab is available only if you use Advanced Mode. If you use Quick Mode, you can define sorting options in the result source.

    In the Sort by drop-down list, select a managed property from the list of managed properties that are set as sortable in the search schema, and then select Descending or Ascending. For example, to sort by relevance (that is, to use a ranking model) select Rank.

    To add more sorting levels, click Add sort level.

    If you selected Rank from the Sort by list, you can select which ranking model to use for sorting in the Ranking Model list.

    Under Dynamic ordering, you can specify additional ranking by adding rules that will change the order of results when certain conditions apply. Click Add dynamic ordering rule, and then specify conditional rules.

  3. On the SETTINGS tab, specify the settings that are listed in the following table.

Query Rules

Select whether to use Query Rules or not.

URL Rewriting

Select if the URL rewrite to the item details page should continue to be relative for each catalog item as defined when you set up the catalog connection. If you select Don’t rewrite URLs, the URLs for catalog items are pointed directly to the library item of the connected catalog.

Loading Behavior

Select when the search results returned by the Content Search Web Part appear on the web page. The default option is Sync option: Issue query from the server. By using this loading behavior, queries are issued from the server, and the search results are included in the page response that is sent back from SharePoint. If you select Async option: Issue query from the browser, the queries will be issued from the end-users browser after the complete page is received. This option may be considered for secondary content on a page — for example Recommendations or Popular Items.

Priority

Select the level that best describes the relative importance of content that is displayed by this Web Part in relation to other Search Web Parts. If SharePoint Server 2013 is running under heavy load, the queries will be run according to their priority.
  1. On the TEST tab, you can preview the query that is sent by the Content Search Web Part.

Query text

Shows the final query that will be run by the Content Search Web Part. It is based on the original query template where dynamic variables are substituted with current values. Other changes to the query may have to be made as part of query rules.

Click Show more to display additional information.

Query template

Shows the content of the query template that is applied to the query.

Refined by

Shows the refiners applied to the query as defined on the REFINERS tab.

Grouped by

Shows the managed property on which search results should be grouped as defined on the REFINERS tab.

Applied query rules

Shows which query rules are applied to the query.

The Query template variables section shows the query variables that will be applied to the query, and the values of the variables that apply to the current page. You can type other values to test the effect they will have on the query. Click the Test Query button to preview the search results.

You can also test how the query works for different user segment terms. Click Add user segment term to add terms to be added to the query. Click the Test query button to preview the search results.

  • Query text

Shows the final query that will be run by the Content Search Web Part. It is based on the original query template where dynamic variables are substituted with current values. Other changes to the query may have to be made as part of query rules.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page where you want to add the Web Part.
  3. Click the Settings menu, and then click Edit Page.
  4. In the Web Part Zone where you want to add the Web Part, click Add a Web Part.
  5. In the Categories list, select Search.
  6. In the Parts list, select Refinement, and then click Add.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page that contains the Refinement Web Part that you want to configure.
  3. Click the Settings menu, and then click Edit Page.
  4. In the Web Part, click the Refinement Web Part Menu arrow, and then click Edit Web Part.
  5. You can configure the Web Part for stand-alone refiners or for refiners for faceted navigation by using the following procedures,
  • To configure the Web Part for stand-alone refiners:
  1. In the Web Part tool pane, in the Properties for Search Refinement section, verify that the Choose Refiners in this Web Part is selected.
  2. Click Choose Refiners…
  3. On the Refinement configuration page, from the Available refiners section, use the buttons to select which refiners should be added to the term set, and also in which order that they should be displayed. If you have specified an alias for a refinable managed property, this alias is displayed in the Configuration for section.
  4. In the Configuration for section, set the configuration for how every refiner appears.

    Note:

If you have a single language site, you can change the refiner display name in the Display name section. For multilingual sites, you have to change the refiner display language as described in Change the refiner display name.

  • To configure the Web Part for refiners for faceted navigation:
  1. In the Web Part tool pane, in the Properties for Search Refinement section, select the option Use the refinement configuration defined in the Managed Navigation term set.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. On the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Web Designer Galleries section, click Master pages and page layouts.
  4. On the Master Page Gallery page, click Display Templates.
  5. On the Display Templates page, click Language Files.
  6. On the Language Files page, click the folder that contains the language that you want to change the refiner display name for.
  7. Open the CustomStrings.js file.
  8. Add one line to the file for each managed property that is enabled as a refiner for which you want to change the display name byusing the following syntax:

    “rf_RefinementTitle_ManagedPropertyName”: “Sample Refinement Title for ManagedPropertyName”

    For example, you can add the following line to change the display name for the managed property RefinableInt00 to Price:

    “rf_RefinementTitle_RefinableInt00”: “Price”.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. On the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Web Designer Galleries section, click Master pages and page layouts.
  4. On the Master Page Gallery page, click Display Templates.
  5. On the Display Templates page, click Filters.
  6. Open the Filter_Default.html file.
  7. Change the value for ShowCounts to true.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. On the Settings menu, click Site Settings.
  3. On the Site Settings page, in the Web Designer Galleries section, click Master pages and page layouts.
  4. On the Master Page Gallery page, click Display Templates.
  5. On the Display Templates page, click Filters.

You can change the display template that is used by each refiner by selecting a display template from a list in the Display template section on the Refinement configuration page. When you add a Filter display template to the master page gallery, it is added to the list.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page where you want to add the Web Part.
  3. Click the Settings menu, and then click Edit Page.
  4. In the Web Part Zone where you want to add the Web Part, click Add a Web Part.
  5. In the Categories list, select Search.
  6. In the Parts, select Taxonomy Refinement Panel, and then click Add.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page where you have the Taxonomy Refinement Panel Web Part that you want to configure.
  3. On the Settings menu, click Edit Page.
  4. In the Web Part, click the Taxonomy Refinement Panel Web Part Menu arrow, and then click Edit Web Part.
  5. In the Web Part tool pane, in the Properties section, in the Query section, on the Refinement Target menu, select the Web Part you want to associate with the Taxonomy Refinement Panel Web Part.
  6. In the Web Part tool pane, in the Properties section, in the Query section, on the Refiner menu, select the managed property that you have specified for Managed Navigation.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page where you want to add the Web Part.
  3. Click the Settings menu, and then click Edit Page.
  4. In the Web Part Zone where you want to add the Web Part, click Add a Web Part.
  5. In the Categories list, click Search-Driven Content.
  6. In the Parts list, click Recommended Items, and then click Add.
  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the publishing site collection.
  2. Browse to the page where you have the Recommended Items Web Part that you want to configure.
  3. On the Settings menu, click Edit Page.
  4. In the Web Part, click the Recommended Items Web Part Menu arrow, and then click Edit Web Part.
  5. In the Web Part tool pane, in the Properties section, in the Search Criteria section, click Change query.
  6. On the BASICS tab, define your query by selecting options described in the following table.
  • Get

    recommended items for

From the drop-down list, select from which value recommendations should be displayed. In a catalog scenario, this will often be A token from a URL. If you select this option, you will also have to select which URL token you want to obtain recommendations for.

For example, let’s say that you want to obtain recommendations for items in your catalog. You have a catalog item page where you display your catalog items, and the item number is part of your friendly URL — for example, www.contoso/audio/mp3/4010101. (4010101 represents the item number.) When you want to obtain recommendations for a token from the URL, you should select {URLToken.1} (4010101) from the second drop-down list.

Restrict results by app

Use this drop-down list to specify a scope for the search results.

Restrict results by content type

Use this drop-down list to limit the search results to a specific content type.

If there are too few recommended items

If you don‘t have much usage data — for example, if your site is fairly new, or if the items do not have recommendations to display — this Web Part will not display any search results. In order for the Web Part to display recommendations even though not enough user data has cumulated, you can select the option to Select a query to fill in with additional results.
  1. The REFINERS tab lists the managed properties that are set as refiner-enabled in the search schema. You can specify that the search results returned in the Recommended Items Search Web Part should be limited to one or more values from the refiners. Click a refiner in the list, and then click Apply to add it to the query.

    Click Show more if you want to define grouping of results. Under Group results, you can specify that the results should be grouped based on one or more managed properties.

  2. On the SETTINGS tab, specify the following:
  • Query Rules

Select whether to use Query Rules or not.

URL Rewriting

Select if the URL rewrite to the item details page should continue to be relative for each catalog item as defined when you set up the catalog connection. If you select Don’t rewrite URLs, the URLs for your catalog items are pointed directly to the library item of the connected catalog.

Loading Behavior

Select when the search results returned by the Recommended Items Web Part should be displayed on the web page. The default option is Display the page and web party simultaneously. By using this loading behavior, queries are issued from the server, and the search results are included in the page response that is sent back from SharePoint. If you select Display the page and web part independently, the queries will be issued from the end-users browser after the complete page is received. This option may be considered for secondary content on a page — for example, Recommendations or Popular Items

Priority

Select the level that best describes the relative importance of content that is displayed by this Web Part in relation to other Search Web Parts. If SharePoint Server 2013 is running under heavy load, the queries will be run according to their priority.
  1. On the TEST tab, you can preview the query that is sent by the Recommended Items Web Part.

  • Query text

Shows the content of the query template that is applied to the query.

Click Show more to display additional information the query is

  • Refined by

Shows the refiners applied to the query as defined in the REFINERS tab.

Grouped by

Shows the managed property on which search results should be grouped as defined in the REFINERS tab.

Applied query rules

Shows which query rules are applied to the query.

In the Query template variables section, the selections that you made on the BASIC tab are displayed. In addition, you can type additional values for testing as outlined in the following table. Click the Test query button to preview the search results.

  • {RecsURL}*

Shows the token you selected when specifying for which value recommendations should be displayed.

{Scope}*

Shows the scope that you selected for the search results.

{ContentTypeID}*

Shows the content type that you selected for the search results.

You can also test how the query works for different user segment terms. Click Add user segment term for testing to add terms to be added to the query. Click the Test query button to preview the search results.

  • Query text

Shows the final query that will be run by the Recommended Items Web Part. It is based on the original query template where dynamic variables are substituted with current values. Other changes to the query may have be made as part of query rules.
  1. Verify that the user account that performs this procedure has the following credentials:
  • The user account that performs this procedure is a site collection administrator on the publishing site collection.
  1. On the publishing site collection, on the Settings menu, click Site settings.
  2. On the Site Settings page, in the Site Collection Administration section, click Search Schema.
  3. On the Managed Properties page, in the Managed property filter box, type the name of a refinable managed property — for example, RefinableString00 — and then click the arrow.
  4. In the Property Name column, click the refinable managed property that you want to edit.
  5. To specify an alias of the refinable managed property to use when you configure refiners for faceted navigation, on the Edit Managed Property page, type a user-friendly name in the Alias box.
  6. In the Mappings to crawled properties section, click Add a Mapping.
  7. In the Crawled property selection dialog box, find the crawled property that you want to map to the refinable managed property in the list, or search for it by typing the name of the crawled property in the box, and then clicking Find.

    Important:

When you search for a crawled property, you may find two crawled properties that represent the same content. For example, a site column of type text named Color will during crawl discover two crawled properties: ows_Color and ows_q_TEXT_Color. Crawled properties that begin with either ows_r<four letter code>, ows_q<four letter code> or ows_taxId are automatically created crawled properties. When you select a crawled property to map to a refinable managed property, make sure that you don’t map the automatically created crawled property. You should always map the crawled property that begins with ows_.

For information about automatically created crawled properties, see About automatically created managed properties (SharePoint 2013 Preview).

  1. Click OK.
  2. On the Edit Managed Property page, click OK.

    Note:

To configure refiners in Web Parts or in Term Store Management, you must start a full crawl of the content source that contains the refinable managed properties. For more information, see Start, pause, resume, or stop crawls in SharePoint 2013 Preview.

    Important:

All automatically created managed properties use the text data type. Therefore, you should only enable an automatically created managed property as a refiner if the site column used to create the managed property also uses the text data type. For example, if the site column uses an integer or date data type, you must create a new managed property, map the crawled property value to this new managed property, and then enable it as a refiner.

When you select a crawled property to map to a managed property, make sure that you don‘t map the automatically created crawled property. The name of the automatically created crawled property starts with either ows_r<four letter code>_, ows_q<four letter code>_, or ows_taxId_. The name of the crawled property that you should use in the mapping starts with ows_.

For information about how to create a new managed property, see To add a managed property. For more information about automatically created crawled properties, see About automatically created managed properties (SharePoint 2013 Preview).

To enable a managed property as a refiner

  1. Verify that the user account that performs this procedure is an administrator of the Search service application.
  2. In Central Administration, in the Application Management section, click Manage service applications.
  3. On the Manage Service Applications page, click Search Service Application.
  4. Click the Search service application.
  5. On the Managed Properties page, in the Managed property filter box, type the name of the managed property that you want to enable as refiner, and then click the arrow.
  6. In the Property Name column, click the managed property that you want to edit.
  7. On the Edit Managed Property page, in the Refinable section, select either Yes – active or Yes – latent. If you select Yes – latent, you can switch the refiner to active later without having to do a full crawl.
  8. Click OK.

    Note:

To configure refiners in Web Parts or in Term Store Management, a full crawl of the content source that contains the refinable managed properties must be completed. Administrators of the Search service application can complete a full crawl as described in Start, pause, resume, or stop crawls in SharePoint 2013 Preview. Site collection administrators can initiate a full crawl by specifying that the catalog that contains the refinable managed properties should be reindexed during the next scheduled crawl.

  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the authoring site collection.
  2. On the authoring site collection, on the Settings menu, click Site settings.
  3. On the Site Settings page, in the Site Administration section, click Term store management.
  4. In the TAXONOMY TERM STORE section, click to select the term set that you want to enable for faceted navigation.
  5. Click the INTENDED USE tab, and then select Use this Term Set for Faceted Navigation.
  6. Click Save.

When configuring refiners for faceted navigation, you can add refiners to all terms in a term set or to specific terms in a term set. This procedure is performed on the authoring site collection.

To add refiners to all terms in a term set

  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the authoring site collection.
  2. On the authoring site collection, on the Settings menu, click Site settings.
  3. On the Site Settings page, in the Site Administration section, click Term store management.
  4. In the TAXONOMY TERM STORE section, click the term set that you have enabled for faceted navigation.
  5. Click the FACETED NAVIGATION tab, and then click Customize refiners….
  6. On the Refinement Configuration page, in the Available refiners section, use the buttons to select which refiners should be added to the term set, and also to specify the order in which you want the refiners to appear. If you have specified an alias for a refinable managed property, this alias is displayed in the Configuration section.
  7. In the Configuration for section, specify how you want each refiner to appear.
  8. Click OK to close the Refinement Configuration page, and then click Save.

To add refiners to specific terms in a term set

  1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group on the authoring site collection.
  2. On the authoring site collection, on the Settings menu, click Site settings.
  3. On the Site Settings page, in the Site Administration section, click Term store management.
  4. In the TAXONOMY TERM STORE section, click the term set that you have enabled for faceted navigation, and then click the term to which you want to add term-specific refiners.
  5. Click the FACETED NAVIGATION tab, and then click Stop inheriting….
  6. Click FACETED NAVIGATION tab, and then click Customize refiners….
  7. On the Refinement Configuration page, in the Available refiners section, use the buttons to select which refiners should be added to the term set, and also to specify the order in which you want the refiners to appear. If you have specified an alias for a refinable managed property, this alias is displayed in the Configuration section.
  8. In the Configuration for section, specify how you want each refiner to appear.
  9. Click OK to close the Refinement Configuration page, and then click Save.

For refiners that contain numeric values, you can present the numeric values within different intervals. For example, if you want end-users to be able to refine based on price, it would be useful to specify different price intervals instead of showing all available prices as separate refiners. This procedure is performed in your authoring site collection.

To set intervals for refiner values

  1. Add refiners to a term set as described in Add refiners to a term set in this topic.
  2. On the Refinement Configuration page, in the Selected refiners section, click the refiner that you want to set intervals for.
  3. In the Configuration for section, for Intervals, select Custom, and then type the intervals in the Thresholds box.
  4. Click OK to close the Refinement Configuration page, and then click Save.

  • Additional steps

To show refiners on a page, you must add a Refinement Panel Web Part to the page where you want the refiners to appear. For more information, see Configure Search Web Parts in SharePoint Server 2013.

 

 

  1. Depending on the level at which you want to create the result source, do one of the following:
  • To create a result source for a Search service application:
  • Verify that the user account that performs this procedure is an administrator on the Search service application.
  • In Central Administration, in the Application Management section, click Manage service application.
  • Click the Search service application for which you want to create a result source.
  • On the Search Administration page for the Search service application, on the Quick Launch, in the Queries and Results section, click Result Sources.
  • To create a result source for a site collection:
  • Verify that the user account that performs this procedure is a site collection administrator on the publishing site collection.
  • On the publishing site collection, on the Settings menu, click Site Settings.
  • On the Site Settings page, in the Site Collection Administration section, click Search Result Sources.
  • To create a result source for a site:
  • Verify that the user account that performs this procedure is a member of the Owners group on the publishing site.
  • On the publishing site, on the Settings menu, click Site Settings.
  • On the Site Settings page, in the Search section, click Result Sources.
  1. On the Manage Result Sources page, click New Result Source.
  2. On the Add Result Source page, in the General Information section, do the following:
    1. In the Name box, type a name for the result source.
    2. In the Description box, type a description of the result source.
  3. In the Protocol section, select one of the following protocols for retrieving search results:
  • Local SharePoint, the default protocol, provides results from the search index for this Search service application.
  • Remote SharePoint provides results from the index of a search service in another farm.
  • OpenSearch provides results from a search engine that uses the OpenSearch 1.0/1.1 protocol.
  • Exchange provides results from Microsoft Exchange Server. Click Use AutoDiscover to have the search system find an Exchange Server endpoint automatically, or type the URL of the Exchange web service to retrieve results from — for example, https://contoso.com/ews/exchange.asmx.

        Note:

Note: The Exchange Web Services Managed API must be installed on the computer on which the search service is running. For more information, see Optional software in Hardware and software requirements for SharePoint 2013.

  1. In the Type section, select SharePoint Search Results to search the whole index, or People Search Results to enable query processing that is specific to people search.
  2. In the Query Transform field, do one of the following:
  • Leave the default query transform (searchTerms) as is. In this case, the query will be unchanged since the previous transform.
  • Type a different query transform in the text box.
  • Use the Query Builder to configure a query transform by doing the following:
  • Click Launch Query Builder.
  • In the Build Your Query dialog box, optionally build the query by specifying filters, sorting, and testing on the tabs as shown in the following tables.

  • On the BASICS tab

Keyword filter

You can use keyword filters to add pre-defined query variables to the query transform. You can select pre-defined query variables from the drop-down list, and then add them to the query by clicking Add keyword filter.

For an overview of query variables, see Query variables in SharePoint Server 2013.

Property filter

You can use property filters to query the content of managed properties that are set to queryable in the search schema.

You can select managed properties from the Property filter drop-down list. Click Add property filter to add the filter to the query.

  • On the SORTING tab

Sort results

In the Sort by menu, you can select a managed property from the list of managed properties that are set as sortable in the search schema, and then select Descending or Ascending. To sort by relevance, that is, to use a ranking model, select Rank. You can click Add sort level to specify a property for a secondary level of sorting for search results.

Ranking Model

If you selected Rank from the Sort by list, you can select the ranking model to use for sorting.

Dynamic ordering

You can click Add dynamic ordering rule to specify additional ranking by adding rules that change the order of results within the result block when certain conditions are satisfied.

  • On the TEST tab

Query text

You can view the final query text, which is based on the original query template, the applicable query rules, and the variable values.

Click Show more to display the options in the following rows of this table.

  

Query template

You can view the query as it is defined in the BASICS tab or in the text box in the Query transform section on the Add Result Source page.

Query template variables

You can test the query template by specifying values for the query variables.
  1. On the Add Result Source page, in the Credentials Information section, select the authentication type that you want for users to connect to the result source.

  • Set a result source as default

    You can set any result source as the default result source. Specifying a result source as default can make it easier to edit the query in Search Web Parts. For example, when you add a Content Search Web Part to a page, the Web Part automatically uses the default result source. For more information, see Configure Search Web Parts in SharePoint Server 2013.

    To set a result source as default

  1. Perform the appropriate procedures in the following list depending on the level at which the result source was configured.
  • If the result source was created at the Search service application level, do the following:
  • Verify that the user account that performs this procedure is an administrator for the Search service application.
  • In Central Administration, in the Application Management section, click Manage service applications.
  • Click the Search service application for which you want to set the result source as default.
  • On the Search Administration page, in the Queries and Results section, click Result Sources.
  • If the result source is at the site collection level, do the following:
  • Verify that the user account that performs this procedure is a site collection administrator on the publishing site collection.
  • On the publishing site collection, on the Settings menu, click Site Settings.
  • On the Site Settings page, in the Site Collection Administration section, click Search Result Sources.
  • If the result source is at the site level, do the following:
  • Verify that the user account that performs this procedure is a member of the Owners group on the publishing site.
  • On the publishing site, on the Settings menu, click Site Settings.
  • On the Site Settings page, in the Search section, click Result Sources.
  1. On the Manage Result Sources page, point to the result source that you want to set as default, click the arrow that appears, and then click Set as Default.

 

 

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:


    # To get a site at the root site collection level:
    $Site = Get-SPSite “http://localhost&#8221;

    # To get a site below the root site collection level:
    $Site = Get-SPSite “http://localhost/sites/<SiteName>&#8221;

    # To create a custom usage event type:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $EventGuid = [Guid]::NewGuid()
    $EventName = “<EventTypeName>”
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $newEventType = $tenantConfig.RegisterEventType($EventGuid, $EventName, “”)
    $tenantConfig.Update($SSP)

    Where:

  • <SiteName> is the name of the site for which you want to create a custom usage event.
  • <EventTypeName> is the name of the new custom usage event type that you want to create — for example, BuyEventType.

    This procedure creates a random GUID for the usage event type. Use this GUID when you add code to record the custom usage event, as described in Record a custom usage event.

        Important:

It can take up to three hours for a custom usage event type to become available in the system. However, to speed up the process, you can alternatively restart the SharePoint Timer Service.

    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.

  • Record a custom usage event

    After you have created a custom usage event type, as described in Create a custom usage event type, you have to add code to the place where the event occurs — for example, when a page loads, or when a user clicks a link or a button. This data is then sent to the analytics processing component, where it is recorded and processed.

    If you are using cross-site publishing, where you show catalog content on a publishing site, you must record the usage event on the URL of the indexed item, and override some site settings. For example, if you have a catalog in an authoring site that you have published on a publishing site, when a user interacts with a catalog item on the publishing site, this usage event must be recorded on the item in the authoring site. Furthermore, the code that you add to record the usage event must override the SiteId and the WebId of the publishing site, and be replaced with the SiteId and the WebId of the authoring site.

    To add code to record a custom usage event

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view GUIDs for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

  2. In an HTML editor, open the file where the custom usage event should be logged — for example, a display template for a Content Search Web Part, and add the following code:


    window.Log<CustomUsageEventType>ToEventStore = function(url)
    {
    ExecuteOrDelayUntilScriptLoaded(function()
    {
    var spClientContext = SP.ClientContext.get_current();
    var eventGuid = new SP.Guid(“<GUID>”);
    SP.Analytics.AnalyticsUsageEntry.logAnalyticsAppEvent(spClientContext, eventGuid, url);
    spClientContext.executeQueryAsync(null, Function.createDelegate(this, function(sender, e){ alert(“Failed to log event for item: ” + document.URL + ” due to: ” + e.get_message()) }));
    }, “SP.js”);
    }Where:

  • <CustomUsageEventType> is the name of the custom event — for example, BuyEventType.
  • <GUID> is the numeric ID of the usage event type — for example, 4e605543-63cf-4b5f-aab6-99a10b8fb257.
  1. In an HTML editor, open the file that refers to the custom usage event, and add the following code:

    # The example below shows how a custom usage event type is referred to when a button is clicked:
    <button onclick=”Log<CustomUsageEventType>ToEventStore(‘<URL>’)”></button>

    Where:

  • <CustomUsageEventType> is the name of the custom event type.
  • <URL> is the full URL of the item to which the usage event should be logged — for example, http://contoso.com/faq.

To add code to record a custom usage event and override site settings

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view GUIDs for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

  2. In an HTML editor, open the file where the custom usage event should be logged — for example, a display template for a Content Search Web Part. The following example shows how to override the current SiteId, WebId and UserId.


    window.Log<CustomUsageEventType>ToEventStore = function(url, siteIdGuid, webIdGuid, spUser)
    {
    ExecuteOrDelayUntilScriptLoaded(function()
    {
    var spClientContext = SP.ClientContext.get_current();
    var eventGuid = new SP.Guid(“<GUID>”);
    SP.Analytics.AnalyticsUsageEntry.logAnalyticsAppEvent2(spClientContext, eventGuid, url, webIdGuid, siteIdGuid, spUser);
    spClientContext.executeQueryAsync(null, Function.createDelegate(this, function(sender, e){ alert(“Failed to log event for item: ” + document.URL + ” due to: ” + e.get_message()) }));
    }, “SP.js”);
    }

    Where:

  • <CustomUsageEventType> is the name of the custom event type — for example, BuyEventType.
  • <GUID> is the numeric ID of the usage event type — for example, 4e605543-63cf-4b5f-aab6-99a10b8fb257.
  1. In an HTML editor, open the file that refers to the custom usage event type, and add the following code:

    # The example below shows how a custom usage event type is referred to when the “Buy!” button is clicked:
    <button onclick=”Log<CustomUsageEventType>ToEventStore(‘<URL>’, new SP.Guid(‘{<SiteId GUID>}’), new SP.Guid(‘{<WebId guid}>’), ‘<UserName>’)”>Buy!</button>

    Where:

  • <CustomUsageEventType> is the name of the custom event type — for example, BuyEventType.
  • <URL> is the URL found in the managed property OriginalPath.
  • <SiteId GUID> is the GUID in the managed property SiteID.
  • <WebId GUID> is the GUID in the managed property WebId.
  • <UserName> can — for example, be a cookie ID that is used to identify users on a site that has anonymous users.

    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.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view EventTypeId for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

  2. In an HTML editor, open the file where the custom usage event should be logged — for example, a display template for a Content Search Web Part, and add the following code:


    window.Log<DefaultUsageEventType>ToEventStore = function(url)
    {
    ExecuteOrDelayUntilScriptLoaded(function()
    {
    var spClientContext = SP.ClientContext.get_current();
    SP.Analytics.AnalyticsUsageEntry.logAnalyticsEvent(spClientContext, <EventTypeId>, url);
    spClientContext.executeQueryAsync(null, Function.createDelegate(this, function(sender, e){ alert(“Failed to log event for item: ” + document.URL + ” due to: ” + e.get_message()) }));
    }, “SP.js”);
    }

    Where:

  • <DefaultUsageEventType> is the name of the default usage event type — for example, Views.
  • <EventTypeId> is the numeric ID of the usage event type — for example, 1.
  1. In an HTML editor, open the file that refers to the default usage event, and add the following code:

    # The example below shows how a default usage event type is referred to on a page load:
    <body onload=    “Log<DefaultUsageEventType>ToEventStore(‘<URL>’)“>

    Where:

  • <DefaultUsageEventType> is the name of the default usage event type — for example, Views.
  • <URL> is the full URL of the item to which the usage event should be logged, — for example, http://contoso.com/careers
  1. Save the file.

To add code to record a default usage event and override site settings

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view EventTypeId for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

  2. In an HTML editor, open the file where the custom usage event should be logged — for example, a display template for a Content Search Web Part. The example below shows how to override the current SiteId, the WebId and the UserId.


    window.Log<DefaultUsageEventType>ToEventStore = function(url, siteIdGuid, webIdGuid, spUser)
    {
    ExecuteOrDelayUntilScriptLoaded(function()
    {
    var spClientContext = SP.ClientContext.get_current();
    SP.Analytics.AnalyticsUsageEntry.logAnalyticsEvent(spClientContext, <EventTypeId>, url, webIdGuid, siteIdGuid, spUser);
    spClientContext.executeQueryAsync(null, Function.createDelegate(this, function(sender, e){ alert(“Failed to log event for item: ” + document.URL + ” due to: ” + e.get_message()) }));
    }, “SP.js”);
    }

    Where:

  • <DefaultUsageEventType> is the name of the default event type — for example, Views.
  • <EventTypeId> is the numeric ID of the usage event type — for example, 1.
  1. In an HTML editor, open the file that refers to the default usage event type, and add the following code:

    # The example below shows how a default usage event type is referred to on a page load:
    <body onload=    “Log<DefaultUsageEventType>ToEventStore(‘<URL>’, new SP.Guid(‘{<SiteId GUID>}’), new SP.Guid(‘{<WebId GUID>}’), ‘<UserName>’)“>

    Where:

  • <DefaultUsageEventType> is the name of the default event type — for example, Views.
  • <URL> is the URL in the managed property OriginalPath.
  • <SiteId GUID> is the GUID in the managed property SiteID.
  • <WebId GUID> is the GUID in the managed property WebId.
  • <UserName><UserName> can — for example, be a cookie ID that is used to identify users on a site that has anonymous users

    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.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view EventTypeId for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

    # To get a usage event type:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }

    # To change the importance level of a usage event type:
    $event.RecommendationWeight = <RecommendationWeightNumber>
    $tenantConfig.Update($SSP)

    # To verify the changed importance level for the usage event type:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
    $event

    Where:

  • <EventTypeId> is the numeric ID of the usage event type for which you want to change the weight — for example, 256.
  • <RecommendationWeightNumber> is the level of importance that you want to apply to the user event type — for example, 4.

    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.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view EventTypeId for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

    # To get a usage event type:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }

    # To change the Recent time span for a usage event type:
    $event.RecentPopularityTimeFrame = <TimeFrame>
    $tenantConfig.Update($SSP)

    # To verify the changed Recent time frame for the usage event type:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
    $event

    Where:

  • <EventTypeId> is the numeric ID of the usage event type for which you want to change the Recent time frame — for example, 256.
  • <TimeFrame> is the new Recent time frame that you want to apply to the user event type — for example, 7.

        Note:

The system updates any changes to the Recent time period only after the Usage Analytics Timer Job has run.

    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.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view EventTypeId for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

    # To get a usage event type:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }

    # To enable the logging of anonymous users:
    $event.Options = [Microsoft.Office.Server.Search.Analytics.EventOptions]::AllowAnonymousWrite
    $tenantConfig.Update($SSP)

    # To verify that the logging of anonymous users has been enabled, i.e. that the Options property is set to AllowAnonymousWrite:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
    $event

    Where:

  • <EventTypeId> is the numeric ID of the usage event type that you want to enable for the logging of anonymous users — for example, 256.

To disable the logging of usage events of anonymous users

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    # To view EventTypeId for all usage event types:
    $SSP = Get-SPEnterpriseSearchServiceApplicationProxy
    $SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft

    # To get a usage event type:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)
    $event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }

    # To disable the logging of anonymous users:
    $event.Options = [Microsoft.Office.Server.Search.Analytics.EventOptions]::None
    $tenantConfig.Update($SSP)

    # To verify that logging of anonymous users has been disabled, i.e. that the Options property is set to None:
    $tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Gui

    Where:

  • <EventTypeId> is the numeric ID of the usage event type that you want to disable for the logging of anonymous users — for example, 256.

        Note:

For the default usage event type Views, you cannot disable the logging of anonymous users.

    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.

 

 

  1. Log on to the computer in the SharePoint Server 2013 farm where Workflow Manager was installed.
  2. Open the SharePoint Management Shell as an administrator. This is accomplished by right-clicking the SharePoint 2013 Management Shell and choosing Run as administrator.
  3. Run the Register-SPWorkflowService cmdlet.

    Example:

Register-SPWorkflowService –SPSite “http://myserver/mysitecollection&#8221; –WorkflowHostUri “http://workflow.example.com:12291&#8221; –AllowOAuthHttp

To configure Workflow Manager on a server that is part of the SharePoint 2013 farm and on which communication takes place by using HTTPS

  1. Determine if you need to install Workflow Manager certificates in SharePoint.

    Under some circumstances, you have to obtain and install Workflow Manager certificates. If your installation requires that you obtain and install these certificates, you must complete that step before continuing. To learn whether you need to install certificates, and for instructions, see Installing Workflow Manager certificates in SharePoint Server 2013.

  2. Log into the computer in the SharePoint Server 2013 farm where Workflow Manager was installed.
  3. Open the SharePoint Management Shell as an administrator. This is accomplished by right-clicking the SharePoint 2013 Management Shell and choosing Run as administrator.
  4. Run the Register-SPWorkflowService cmdlet.

    Example:

Register-SPWorkflowService –SPSite “https://myserver/mysitecollection&#8221; –WorkflowHostUri “https://workflow.example.com:12290&#8221;

To configure Workflow Manager on a server that is NOT part of the SharePoint 2013 farm and on which communication takes place by using HTTP

  1. Log on to each Web Front End (WFE) server in the SharePoint Server 2013 farm.
  2. Install the Workflow Manager Client on each WFE server in the SharePoint farm.

    Before you can run the workflow pairing cmdlet, you must install Workflow Manager Client on each of the WFE servers in the SharePoint farm.

    You can download and install the Workflow Manager Client here: http://go.microsoft.com/fwlink/p/?LinkID=268376

  3. Open the SharePoint Management Shell as an administrator. This is accomplished by right-clicking the SharePoint 2013 Management Shell command and choosing Run as administrator.
  4. Run the Register-SPWorkflowService cmdlet. The cmdlet should be run only once and can be run from any of the WFE servers in the SharePoint farm. Example:

    Register-SPWorkflowService –SPSite “http://myserver/mysitecollection&#8221; –WorkflowHostUri “http://workflow.example.com:12291&#8221; –AllowOAuthHttp

    Important:

You must install the Workflow Manager Client on each Web Front End (WFE) server in the SharePoint farm before you run the pairing cmdlet.

To configure Workflow Manager on a server that is NOT part of the SharePoint 2013 farm and on which communication takes place by using HTTPS

  1. Determine whether you need to install Workflow Manager certificates in SharePoint 2013.

    Under some circumstances, you have to obtain and install Workflow Manager certificates. If your installation requires that you obtain and install these certificates, you must complete that step before continuing. To learn whether you need to install certificates, and for instructions, see Installing Workflow Manager certificates in SharePoint Server 2013.

  2. Log on to each Web Front End (WFE) server in the SharePoint Server 2013 farm.
  3. Install the Workflow Manager Client on each WFE server in the SharePoint farm.

    Before you can run the workflow pairing cmdlet, you must install Workflow Manager Client on each of the WFE servers in the SharePoint farm.

    You can download and install the Workflow Manager Client here: http://go.microsoft.com/fwlink/p/?LinkID=268376

  4. Open the SharePoint Management Shell as an administrator. This is accomplished by right-clicking the SharePoint 2013 Management Shell command and choosing Run as administrator.
  5. Run the Register-SPWorkflowService cmdlet. Example:

    Register-SPWorkflowService –SPSite “https://myserver/mysitecollection&#8221; –WorkflowHostUri “https://workflow.example.com:12290&#8221;

    Important:

You must install the Workflow Manager Client on each Web Front End (WFE) server in the SharePoint farm before you run the pairing cmdlet.

  • Validate the installation

    Use these steps to validate that you have successfully installed and configured the required components.

    To validate the installation

  1. Add a user to your SharePoint site, and grant the user Site Designer permissions.
  2. Install SharePoint Designer 2013 and create a workflow based on the SharePoint 2013 Workflow platform. For more information, see Creating a workflow by using SharePoint Designer 2013 and the SharePoint 2013 Workflow platform.
  3. Run this workflow from the SharePoint user interface.
  1. If SSL is enabled either on SharePoint Server 2013 (which is not the default) or on Workflow Manager (which is the default), AND
  2. If SharePoint Server 2013 and Workflow Manager do not share a Certificate Authority, AND
  3. If Workflow Manager is configured to generate self-signed certificates (which is the default).

    Note:

Product trial, workflow development, and troubleshooting are easier if SSL is not enabled. However, communication between SharePoint Server 2013 and Workflow Manager is not encrypted if SSL is not enabled. For this reason, SSL should be enabled for production configurations.

To obtain and export certificates from the Workflow Manager server

  1. On a computer that has Workflow Manager installed, choose IIS Manager, Sites. Right-click Workflow Management Site, and then choose Edit Bindings.
  2. Choose the https port, and then choose Edit. Choose the View button in the SSL Certificate section.
  3. To export the issuer certificate, do the following:
    1. In the Certificate window, choose the Certification path tab.
    2. Select root certification path and choose View.
    3. On the Details tab, choose Export Certificate, and take the default options in the export wizard.
    4. Give the exported certificate file a friendly name.

To install certificates on SharePoint Server 2013

  1. Copy the issuer certificate to your SharePoint Server 2013 computer.
  2. Add the certificates to the Windows Certificate store.
  3. For each certificate, do the following:
    1. Double-click the file to open and view the certificate.
    2. On the certificate, choose the Install Certificate button to start the installation wizard.
    3. In the wizard, choose Place all certificates in the following store, and then choose Trusted Root Certification Authorities.
  4. Add the certificates to SharePoint Server by going to the SharePoint Management shell and running the New-SPTrustedRootAuthority cmdlet. Do this for each certificate file.

 

 
  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>

    Where:

  • <Name> is the name of the new web application.
  • <ApplicationPool> is the name of the application pool.
  • < WindowsAuthType > is either “NTLM“ or “Kerberos“. Kerberos is recommended.
  • <ApplicationPoolAccount> is the user account that this application pool will run as.
  • <Port> is the port on which the web application will be created in IIS.
  • <URL> is the public URL for the web application.
  • Example

    New-SPWebApplication -Name “Contoso Internet Site” -ApplicationPool “ContosoAppPool” -AuthenticationMethod “Kerberos” -ApplicationPoolAccount (Get-SPManagedAccount “CONTOSO\jdoe”) -Port 80 -URL “https://www.contoso.com&#8221;

For more information, see New-SPWebApplication.

    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.

After this procedure is complete, you can create one or more site collections for this web application. For more information, see Create a site collection.

After you successfully create the web application, when you open the Central Administration page, you see a health rule warning that indicates that one or more web applications is enabled with classic authentication mode. This is a reflection of our recommendation to use claims-based authentication instead of classic mode authentication.

 

 

  1. Verify that you have the following administrative credentials:
  • To create a web application, you must be a member of the Farm Administrators SharePoint group.
  1. Start SharePoint 2013 Central Administration.
  • For Windows Server 2008 R2:
    • Click Start, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Central Administration.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Central Administration.

      If SharePoint 2013 Central Administration is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Central Administration.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. On the Central Administration Home page, click Application Management.
  2. On the Application Management page, in the Web Applications section, click Manage web applications.
  3. In the Contribute group of the ribbon, click New.
  4. On the Create New Web Application page, in the IIS Web Site section, you can configure the settings for your new web application by selecting one of the following two options:
  • Click Use an existing IIS web site, and then select the web site on which to install your new web application.
  • Click Create a new IIS web site, and then type the name of the web site in the Name box.
  • In the Port box, type the port number you want to use to access the web application. If you are using an existing web site, this field contains the current port number.

        Note:

The default port number for HTTP access is 80, and the default port number for HTTPS access is 443.

  • Optional: In the IIS Web Site section, in the Host Header box, type the host name (for example, http://www.contoso.com) that you want to use to access the web application.

        Note:

You do not need to populate this field unless you want to configure two or more IIS web sites that share the same port number on the same server, and DNS has been configured to route requests to the same server.

  • In the Path box, type the path to the IIS web site home directory on the server. If you are creating a new web site, this field contains a suggested path. If you are using an existing web site, this field contains the current path of that web site.
  1. In the Security Configuration section, choose whether or not to Allow Anonymous access and whether or not to Use Secure Sockets Layer (SSL).

    Important:

Secure Sockets Layer (SSL) is a requirement for web applications that are deployed in scenarios that support server-to-server authentication and app authentication. In general, we strongly recommend using SSL for web applications.

  • In the Security Configuration section, click Yes or No for the Allow Anonymous options. If you choose to Yes, visitors can use the computer-specific anonymous access account (that is, IIS_IUSRS) to access the web site.

        Note:

If you want users to be able to access any site content anonymously, you must enable anonymous access for the entire web application zone before you enable anonymous access at the SharePoint site level. Later, site owners can configure anonymous access for their sites. If you do not enable anonymous access at the web application level, site owners cannot enable anonymous access at the site level.

  • In the Security Configuration section, click Yes or No for the Use Secure Sockets Layer (SSL) options. If you choose Yes, you must request and install an SSL certificate to configure SSL. For more information about how to set up SSL, see How to Setup SSL on IIS 7.0.
  1. In the Claims Authentication Types section, select the authentication method that you want to use for the web application.
  • To enable Windows authentication, select Enable Windows Authentication and, in the drop-down menu, select NTLM or Negotiate (Kerberos). We recommend using Negotiate (Kerberos).

    If you do not want to use Integrated Windows authentication, clear Integrated Windows authentication.

        Note:

If you do not select Windows Authentication for at least one zone of this web application, crawling for this web application will be disabled.

  • If you want users’ credentials to be sent over a network in a nonencrypted form, select Basic authentication (credentials are sent in clear text).

        Note:

You can select basic authentication or integrated Windows authentication, or both. If you select both, SharePoint 2013 offers both authentication types to the client web browser. The client web browser then determines which type of authentication to use. If you only select Basic authentication, ensure that SSL is enabled. Otherwise, a malicious user can intercept credentials.

  • To enable forms-based authentication, select Enable Forms Based Authentication (FBA), and then enter the ASP.NET Membership provider name and the ASP.NET Role manager name.

        Note:

If you select this option, ensure that SSL is enabled. Otherwise, a malicious user can intercept credentials.

  • If you have set up Trusted Identity Provider authentication by using Windows PowerShell, the Trusted Identity provider check box is selected.
  1. In the Sign In Page URL section, choose one of the following options to sign into SharePoint 2013:
  • Select Default Sign In Page URL to redirect users to a default sign-in web site for claims-based authentication.
  • Select Custom Sign In page URL and then type the sign-in URL to redirect users to a customized sign-in web site for claims-based authentication.
  1. In the Public URL section, type the URL for the domain name for all sites that users will access in this web application. This URL will be used as the base URL in links that are shown on pages within the web application. The default URL is the current server name and port, and it is automatically updated to reflect the current SSL, host header, and port number settings on the page. If you deploy SharePoint 2013 behind a load balancer or proxy server, then this URL may need to be different than the SSL, host header, and port settings on this page.

    The Zone value is automatically set to Default for a new web application. You can change the zone when you extend a web application.

  2. In the Application Pool section, do one of the following:
  • Click Use existing application pool, and then select the application pool that you want to use from the drop-down menu.
  • Click Create a new application pool, and then type the name of the new application pool, or keep the default name.
  • Click Predefined to use a predefined security account for this application pool, and then select the security account from the drop-down menu.
  • Click Configurable to specify a new security account to be used for an existing application pool.

        Note:

To create a new account, click the Register new managed account link.

  1. In the Database Name and Authentication section, choose the database server, database name, and authentication method for your new web application, as described in the following table.
  • Item

Action

Database Server

Type the name of the database server and SQL Server instance you want to use in the format <SERVERNAME\instance>. You can also use the default entry.

Database Name

Type the name of the database, or use the default entry.

Database Authentication

Select the database authentication to use by doing one of the following:

  • To use Windows authentication, leave this option selected. We recommend this option because Windows authentication automatically encrypts the password when it connects to SQL Server.
  • To use SQL authentication, click SQL authentication. In the Account box, type the name of the account that you want the web application to use to authenticate to the SQL Server database, and then type the password in the Password box.

    Note:

SQL authentication sends the SQL authentication password to SQL Server in an unencrypted format. We recommend that you only use SQL authentication if you force protocol encryption to SQL Server to encrypt your network traffic by using IPsec.

  1. If you use database mirroring, in the Failover Server section, in the Failover Database Server box, type the name of a specific failover database server that you want to associate with a content database
  2. In the Service Application Connections section, select the service application connections that will be available to the web application. In the drop-down menu, click default or [custom]. You use the [custom] option to choose the service application connections that you want to use for the web application.
  3. In the Customer Experience Improvement Program section, click Yes or No.
  4. Click OK to create the new web application.

  • Create a claims-based web application by using Windows PowerShell

    Use the procedure in this section to create a new claims-based SharePoint 2013 web application using Windows PowerShell.

    To create a claims-based web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • You must read about_Execution_Policies.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.

  1. To create a claims-based authentication provider, from the Windows PowerShell command prompt, type the following:

    $ap = New-SPAuthenticationProvider

  2. To create a claims-based web application, from the Windows PowerShell command prompt, type the following:

    New-SPWebApplication -Name <Name>
    -ApplicationPool <ApplicationPool>
    -ApplicationPoolAccount <ApplicationPoolAccount>
    -URL <URL> -Port <Port> -AuthenticationProvider $ap

    Where:

  • <Name> is the name of the new web application that uses claims-based authentication.
  • <ApplicationPool> is the name of the application pool.
  • <ApplicationPoolAccount> is the user account that this application pool will run as.
  • <URL> is the public URL for this web application.
  • <Port> is the port on which the web application will be created in IIS.

        Note:

For more information, see New-SPWebApplication.

The following example creates an https claims-based web application, using the current user credentials and the current machine name:

$waUrl = “https://&#8221; + $env:ComputerName
$siteAdmin = $env:userdomain + “\” + $env:username;
CreateWindowsWebApp -url $waUrl -title “WinClaimsInbound” -site_admin $siteAdmin -app_pool_name “WebAppPool1” -app_pool_account $siteAdmin -use_claims –use_ssl;

    Note:

After you have created the web site, you must configure SSL in IIS for this newly created web site. For more information about how to set up SSL, see How to Setup SSL on IIS 7.0.

If you want your web application to use HTTP, do not use the –use_ssl parameter, and use the http scheme for the –url parameter.

  • Create a classic-mode web application by using Windows PowerShell

    Use the procedure in this section to create a new classic-mode SharePoint 2013 web application using Windows PowerShell.

    To create a classic-mode web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • You must read about_Execution_Policies.
  1. From the Windows PowerShell command prompt, type the following:

    New-SPWebApplication –Name <Name>
    –ApplicationPool <ApplicationPool>
    -AuthenticationMethod <WindowsAuthType>
    –ApplicationPoolAccount <ApplicationPoolAccount>
    -Port <Port> -URL <URL>

    Where:

  • <Name> is the name of the new web application that uses classic-mode authentication.
  • <ApplicationPool> is the name of the application pool.
  • <WindowsAuthType> is either “NTLM“ or “Kerberos“. Kerberos is recommended.
  • <ApplicationPoolAccount> is the user account that this application pool will run as.
  • <Port> is the port on which the web application will be created in IIS.
  • <URL> is the public URL for the web application.

        Note:

For more information, see New-SPWebApplication.

    Note:

After you successfully create the web application, when you open the Central Administration page, you see a health rule warning that indicates that one or more web applications is enabled with classic authentication mode. This is a reflection of our recommendation to use claims-based authentication instead of classic mode authentication.

 

 

  1. Verify that you a member of the Administrators group on the server on which you are configuring IIS.
  2. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager to start IIS Manager console.
  3. Expand Sites in the console tree, and then click the IIS web site that corresponds to the web application zone on which you want to configure basic authentication.
  4. In Features View, in IIS, double-click Authentication.
  5. In Features View, in Authentication, right-click Basic Authentication, and then click Enable.
  6. Right-click Basic Authentication, and then click Edit.
  7. In the Edit Basic Authentication Settings dialog box, in the Default domain text box, type the appropriate default domain.

    The default domain is the name of a domain against which you want users to be authenticated when they do not provide a domain name.

  8. In the Realm text box, type the appropriate realm, and then click OK.

    The realm is a DNS domain name or an IP address that will use the credentials that are authenticated against your internal Windows domain. Configuring a realm name for basic authentication is optional.

The web site is now configured to use basic authentication.

You can also configure basic authentication when you create a web application in SharePoint Central Administration by selecting Basic authentication (password is sent in clear text) in the Claims Authentication Types section of the Create New Web Application dialog box. For more information, see Create claims-based web applications in SharePoint 2013.

    Security

In the Claims Authentication Types section of the Create New Web Application dialog box, you can select Integrated Windows authentication, Basic authentication (password is sent in clear text), or both. If you select both, SharePoint 2013 will offer both authentication types to the client web browser. The client web browser then determines the type of authentication to use. If you only select Basic authentication (password is sent in clear text), make sure that you enable SSL for this web application.

 

 

  1. Verify that you are a member of the Administrators group on the server on which you are configuring IIS.
  2. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager to start IIS Manager console.
  3. Expand Sites in the console tree, and then click the IIS web site that corresponds to the web application zone on which you want to configure digest authentication.
  4. In Features View, in IIS, double-click Authentication.
  5. In Features View, in Authentication, right-click Digest Authentication, and then click Enable.
  6. Right-click Digest Authentication, and then click Edit.
  7. In the Edit Digest Authentication Settings dialog box, in the Realm text box, type the appropriate realm, and then click OK.

    The realm is a DNS domain name or an IP address that will use the credentials that have been authenticated against your internal Windows domain. You must configure a realm name for digest authentication.

The web site is now configured to use digest authentication.

 

  1. Verify that the user account that performs this procedure is a local administrator on the domain controller.
  2. Click Start, point to Administrative Tools, and then click DNS.
  3. In DNS Manager, right-click Forward Lookup Zones, and then click New Zone….
  4. In the New Zone Wizard, click Next.
  5. In the Zone Type page, accept the default of Primary zone, and then click Next.
  6. In the Active Directory Zone Replication Scope page, select the appropriate replication method for your environment (the default is To all DNS servers in this domain), and then click Next.
  7. In the Zone Name page, in the Zone name box type the name for your new app domain name (for example, ContosoApps.com), and then click Next.

    The New Zone Wizard shows the new domain name for apps.



  8. On the Dynamic Update page, select the appropriate type of dynamic updates for your environment (the default is Do not allow dynamic updates), and then click Next.
  9. On the Completing the New Zone Wizard page, review the settings, and then click Finish.

For more information about how to create a forward lookup zone, see Add a Forward Lookup Zone.

You have now created a forward lookup zone (and a domain name) to use for apps in your environment.

To create a wildcard Alias (CNAME) record for the new domain name

  1. Verify that the user account that performs this procedure is a local administrator on the domain controller.
  2. In DNS Manager, under Forward Lookup Zones, right-click the new app domain name, and then click New Alias (CNAME).
  3. In the New Resource Record dialog box, in the Alias name (uses parent domain if left blank) box, type *.

    The Fully qualified domain name (FQDN) box displays *. followed by the domain name that you created for apps. For example, *.ContosoApps.com or *.Contoso-Apps.com.

  4. Next to the Fully qualified domain name (FQDN) for target host box, type the FQDN of the server that hosts the SharePoint sites.

    For example, SharePoint.Contoso.com.

    Or:

    1. Next to the Fully qualified domain name (FQDN) for target host box, click Browse and navigate to the Forward Lookup Zone for the domain that hosts the SharePoint sites.

    For example, Contoso.com.

    1. And then navigate to the record that points to the server that hosts the SharePoint site.

    For example, SharePoint.

    New Resource Record dialog box shows the wildcard alias for the app domain and the FQDN of the server that hosts the SharePoint sites.



  5. Click OK.

For more information about how to create a wildcard alias record in DNS Manager, see Add an Alias (CNAME) Resource Record to a Zone.

You can verify the new domain name and alias by pinging them.

To verify the new domain name

  1. Verify that the user account that is performing this procedure is a local administrator on the domain controller.
  2. Click Start, and then click Command Prompt.
  3. At the command prompt, type ping followed by a subdomain of the domain that you created, and then press ENTER.

    For example, ping Apps-12345678ABCDEF.contosoapps.com

    If the ping command returns the correct IP address, then your wildcard for the domain name was configured successfully.

  1. Verify that you are a member of the farm administrators group in Central Administration.
  2. In SharePoint 2013 Central Administration, click System Settings.
  3. On the System Settings page, under Servers, click Manage services on server.
  4. On the Services on Server page, next to App Management Service, click Start.
  5. On the Services on Server page, next to Microsoft SharePoint Foundation Subscription Settings Service, click Start.
  6. Verify that the App Management and Microsoft SharePoint Foundation Subscription Settings services are running. The following illustration shows the Services on Server page where you can verify that the App Management and Subscription Settings services are running.

    Services on Server showing the App Management and Subscription Settings services running.



To configure the Subscription Settings service application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. First you must establish the application pool, run as account, and database settings for the services. Use a farm account for the SPManagedAccount (which will be used for the application pool runas account).

    At the Windows PowerShell command prompt, type the following commands, and press ENTER after each one to create the application pool:

    $account = Get-SPManagedAccount “<farm account>”
    # Gets the name of the Farm administrators account and sets it to the variable $account for later use.

    Where:

  • <farm account> is the name of the Farm administrators account in the SharePoint farm.

    $appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account
    # Creates an application pool for the Subscription Settings service application.
    # Uses the Farm administrators account as the security account for the application pool.
    # Stores the application pool as a variable for later use.

  1. At the Windows PowerShell command prompt, type the following commands, and press ENTER after each one to create the new service application and proxy:

    $appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName <SettingsServiceDB>
    # Creates the Subscription Settings service application, using the variable to associate it with the application pool that was created earlier.
    # Stores the new service application as a variable for later use.

    Where:

  • <SettingsServiceDB> is the name of the Subscription Settings service database.

    $proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc
    # Creates a proxy for the Subscription Settings service application.

For more information, see Get-SPManagedAccount, New-SPServiceApplicationPool, New-SPSubscriptionSettingsServiceApplication, New-SPSubscriptionSettingsServiceApplicationProxy.

You can use either Windows PowerShell or Central Administration to create and configure the App Management service application. The following procedures provide the steps for each method.

To configure the App Management service application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. First you must establish the application pool, run as account, and database settings for the services. Use a farm account for the SPManagedAccount (which will be used for the application pool runas account).

    At the Windows PowerShell command prompt, type the following commands, and press ENTER after each one to create the application pool:

    $account = Get-SPManagedAccount “<farm account>”
    # Gets the name of the Farm administrators account and sets it to the variable $account for later use.

    Where:

  • <farm account> is the name of the Farm administrators account in the SharePoint farm.

    $appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
    # Creates an application pool for the Application Management service application.
    # Uses the Farm administrators account as the security account for the application pool.
    # Stores the application pool as a variable for later use.

  1. At the Windows PowerShell command prompt, type the following commands, and press ENTER after each one to create the new service application and proxy:

    $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName <AppServiceDB>
    # Creates the Application Management service application, using the variable to associate it with the application pool that was created earlier.
    # Stores the new service application as a variable for later use.

    Where:

  • <AppServiceDB> is the name of the App Management service database.

    $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc
    # Creates a proxy for the Application Management service application.

For more information, see Get-SPManagedAccount, New-SPServiceApplicationPool, New-SPAppManagementServiceApplication and New-SPAppManagementServiceApplicationProxy.

To create the App Management service application in Central Administration

  1. In SharePoint 2013 Central Administration, on the Application Management page, click Manage service applications.
  2. On the ribbon, click New, and then click App Management Service.
  3. In the New App Management Service Application page, in the Service Application Name box, type the name for the service application.
  4. In the Database section, in the Database Server box, type the instance of SQL Server where you want to store the database, or use the default server.
  5. In the Database Name box, type a database name, or use the default name.

    The database name must be unique.

  6. Under Database authentication, select the authentication that you want to use by doing one of the following:
  • If you want to use Windows authentication, leave this option selected. We recommend this option because Windows authentication automatically encrypts the password when it connects to SQL Server.
  • If you want to use SQL authentication, click SQL authentication. In the Account box, type the name of the account that you want the service application to use to authenticate to the SQL Server database, and then type the password in the Password box.

        Note:

In SQL authentication, an unencrypted password is sent to SQL Server. We recommend that you use SQL authentication only if you force protocol encryption to SQL Server or encrypt network traffic by using IPsec.

  1. In the Failover Database Server section, if you want to use a failover database server, specify the server name.
  2. In the Application Pool section, do one of the following:
  • Click Use existing application pool, and then select the application pool that you want to use from the drop-down list.
  • Click Create a new application pool, type the name of the new application pool, and then under Select a security account for this application pool do one of the following:
    • Click Predefined to use a predefined security account, and then select the security account from the drop-down list.
    • Click Configurable to specify a new security account to be used for an existing application pool. You can create a new account by clicking the Register new managed account link.
  1. In the Create App Management Service Application Proxy section, leave the Create App Management Service Application Proxy and add it to the default proxy group check box selected.
  2. Click OK.

    The following illustration shows the App Management service application and proxy that were created.

    Manage Service Applications page showing the App Management service application and proxy.

    Now you must start the service on the server.

  3. In SharePoint 2013 Central Administration, click System Settings.
  4. On the System Settings page, under Servers, click Manage services on server.
  5. On the Services on Server page, next to App Management Service, click Start.
  1. In Central Administration, click Apps.
  2. On the Apps page, click Configure App URLs.
  3. In the App domain box, type the isolated domain that you created for hosting apps.

    For example, ContosoApps.com or Contoso-Apps.com.

  4. In the App prefix box, type a name to use for the URL prefix for apps.

    For example, you could use “apps“ as the prefix so that you would see a URL for each app such as “apps-12345678ABCDEF.ContosoApps.com“. The following illustration shows the Configure App URLs page after you have filled in the App domain and prefix.

    The Configure App URLs page in Central Administration shows the App domain and App prefix.



  5. Click OK.

Use the following procedure to configure app URLs for multi-tenant hosting environments.

To configure app URLs by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following commands and press ENTER after each one:

    Set-SPAppDomain <appDomain>

    Set-SPAppSiteSubscriptionName -Name “app” -Confirm:$false

    Where:

  • <appDomain> is the domain name that you created.

For more information, see Set-SPAppSiteSubscriptionName and Set-SPAppDomain.

  • Configure the Internet-facing endpoints feature (Optional)

    The SharePoint Store contains apps for SharePoint intended for use with sites that require Internet-facing endpoints. By default, these apps are not available (greyed out and cannot be purchased) because they are incompatible with most sites. However, if you have a site that uses Internet-facing endpoints, and want to be able to use these apps, you can turn on the Internet-facing endpoints feature to show these apps in the SharePoint Store. You turn this feature on at the web application level in Central Administration.

    To configure Internet-facing endpoints for apps

  1. In Central Administration, click Application Management.
  2. On the Application Management page, click Manage Web applications.
  3. On the Manage Web Applications page, select the web application that you want to change.
  4. On the Ribbon, click Manage Features.
  5. In the feature list, next to Apps that require accessible internet facing endpoints, click Activate.
  6. Click OK.

 

 

  1. Verify that the user account that is performing this procedure is a member of the Farm administrators group.
  2. In Central Administration, on the Apps page, in the App Management section, click Manage App Catalog.

    If no App Catalog exists for the farm, the Web Application page opens, so you can select a web application.

  3. On the Web Application page, select the web application for which you want to create a catalog.
  4. In the App Catalog Site section, select Create a new app catalog site, and then click OK.
  5. On the Create App Catalog page, in the Title box, type a title for the App Catalog site.
  6. In the Description box, type the description for the site.
  7. In the URL box, fill in the URL to use for the site.
  8. In the Primary Site Collection Administrator section, in the User Name box, type the user who will manage the catalog.

    Only one user name can be entered. Security groups are not allowed.

  9. In the End Users section, in the Users/Groups box, type the names of the users or groups that you want to be able to browse the catalog.

    Added users or groups have read access to the App Catalog site. You can add multiple user names and security groups. Users must be added as End Users to be able to browse the App Catalog from their site collections.

  10. In the Select a quota template list box, select the quota template to use for the site.
  11. Click OK.

To use an existing App Catalog site collection for a different web application

  1. Verify that the user account that is performing this procedure is a member of the Farm administrators group.
  2. In Central Administration, on the Apps page, in the App Management section, click Manage App Catalog.
  3. On the Manage App Catalog page, next to Web Application, click the down arrow and click Change Web Application.
  4. In the Select Web Application box, select the web application for which you want to create a catalog.
  5. In the App Catalog section, select Enter a URL for an existing app catalog site.
  6. In the URL box, type the URL to the App Catalog site, and then click OK.

To view an App Catalog site collection from Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm administrators group and has Read permission to the App Catalog site.
  2. In Central Administration, on the Apps page, in the App Management section, click Manage App Catalog.
  3. On the Manage App Catalog page, verify that the web application that is selected is the web application you want to manage.

    If you want to switch to a different web application, click the down arrow next to the Web application URL to change to a different web application.

  4. Under Site URL click the link to open the App Catalog for that web application.
  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
  2. In Central Administration, on the Apps page, in the SharePoint and Office Store section, click Configure Store Settings.
  3. On the SharePoint Store Settings page, verify that the selected web application is the web application that you want to configure.

    If you want to switch to a different web application, click the down arrow next to the web application URL to change to a different web application.

  4. To allow or prevent purchases, select an option for Should end users be able to get apps from the SharePoint Store?
  • Select Yes to allow users to purchase apps.
  • Select No to prevent purchases but allow users to request apps.
  1. To allow or prevent apps for Office from the Office Store to be started when a user opens a document in the browser, select an option for Should apps for Office from the store be able to start when documents are opened in the browser?
  • Select Yes to allow apps for Office from the Office Store to start.
  • Select No to prevent apps for Office from the Office Store from starting.
  1. Click OK.

When users request an app for SharePoint from the SharePoint Store, users can request a specific number of licenses and provide a justification for the purchase of the app for SharePoint. Submitted requests are added to the App Requests list in the App Catalog of the web application that contains a user‘s site collection. The app request includes the following fields:

  • Requested by The user name of the person requesting the app for SharePoint.
  • Title The title of the app for SharePoint.
  • Seats and Site License The number of licenses the user requested for that app for SharePoint.
  • Justification The reason why the app for SharePoint would be useful for the organization.
  • Status By default, the status is set to New for new requests. The person who reviews the request can change the status to Pending, Approved, Declined, Withdrawn, Closed as Approved, or Closed as Declined.
  • View App Details A link to the app details page in the SharePoint Store.
  • Approver Comments The person who reviews the request can add comments for the requestor.

To view and manage app requests from the SharePoint Store Settings page

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group and is a member of the site Owners or Designers group for the App Catalog.
  2. In Central Administration, on the Apps page, in the SharePoint and Office Store section, click Configure Store Settings.
  3. On the SharePoint Store Settings page, verify that the selected web application is the web application that you want to configure.

    If you want to switch to a different web application, click the down arrow next to the web application URL to change to a different web application.

  4. In the App Requests section, click Click here to view app requests.

    The App Requests list in the App Catalog site opens.

  5. Select a request in the list, and then click the Edit button.
  6. Review the details of the request.

    Note:

At this time, the View app details link in the request details opens the SharePoint Store home page, instead of the details page for the app. Search for the app in the SharePoint Store to find more information about the app.

  1. Change the Status to the appropriate value – Approved if you want to user to be able to purchase the app, or Declined if you do not want to allow the purchase.
  2. Add comments in the Approver Comments box, and then click Save.

    To view a request, requestors can go to the Add an App page in their site collection, and then click Your Requests.

To view and manage app requests from the App Catalog site

  1. Verify that the user account that is performing this procedure is a member of the site Owners or Designers group for the App Catalog.
  2. On the App Catalog site, click the App Requests list.
  3. Select a request in the list, and then click the Edit button.
  4. Review the details of the request.

    Note:

At this time, the View app details link in the request details opens the SharePoint Store home page, instead of the details page for the app. Search for the app in the SharePoint Store to find more information about the app.

  1. Change the Status to the appropriate value – Approved if you want to user to be able to purchase the app, or Declined if you do not want to allow the app to be purchased.
  2. Add any comments in the Approver Comments box, and then click Save.

    To view a request, requestors can go to the Add an App page in their site collection, and then click Your Requests.
  1. Verify that the user account that is performing this procedure is a member of the site Owners or Designers group for the App Catalog.
  2. On the App Catalog site, click the Apps for SharePoint list.

    On the Apps for SharePoint page, click new item.

  3. In the Choose a file box, click Browse, and then locate the folder that contains the app that you want to upload.

    Tip:

You can also click Upload files using Windows Explorer instead to drag and drop an app for SharePoint into the App Catalog.

  1. Select the app, and then click Open.
  2. Click OK to upload the app.
  3. In the Item details box, verify the Name, Title, Short Description, Icon URL, and other settings for the app.

    Be sure that the Enabled check box is selected so that users can see the app in their sites.

    You can select the Featured check box to list the app in the Featured content view of the App Catalog.

  4. Click Save.

You can also categorize apps in the App Catalog. To add categories, edit the Category field for the App Catalog list and add the category names you want to use.

You can preview how the app will appear to users.
  1. Verify that the user account that is performing this procedure is a member of the site Owners or Designers group for the App Catalog.
  2. On the App Catalog site, click the Apps for SharePoint list.
  3. On the Apps for SharePoint page, select the app that you want to remove.
  4. In the ribbon, on the Files tab, click Delete Document to remove the app.
  5. In the dialog box, click OK to confirm that you want to send the item to the site Recycle Bin.

    The app is removed.

 

 
  1. Verify that the user account that is performing this procedure is a member of the site Owners group.
  2. On the home page, under Get started with your site, click Add lists, libraries, and other apps.

    If the Get started with your site control does not appear on the home page, click the Settings icon, and click View Site Contents, and then on the Site Contents page, click Add an App.

  3. In the Your Apps list, click the app you want to add.
  4. Follow the instructions to Trust the app (if it is a custom component) or Name the app (if it is a SharePoint component).

    The app for SharePoint is added and appears in the Apps section of your Site Contents list.

To add an app from an App Catalog

  1. Verify that the user account that is performing this procedure is a member of the site Owners group.
  2. On the home page, under Get started with your site, click Add lists, libraries, and other apps.

    If the Get started with your site control does not appear on the home page, click the Settings icon, and click View Site Contents, and then on the Site Contents page, click Add an App.

  3. Click FromName.

    Where Name is the name of your organization’s App Catalog. For example, “From Contoso”.

    Tip:

Apps marked as Featured in the App Catalog will also appear in the main list of Apps.

  1. Click the app you want to add.
  2. In the Grant Permission to an App dialog box, if you trust the app, click Allow Access.

    The app for SharePoint is added and appears in Apps section of your Site Contents list.

To add an app from the SharePoint Store

  1. Verify that the user account that is performing this procedure is a member of the site Owners group.
  2. On the home page, under Get started with your site, click Add lists, libraries, and other apps.

    If the Get started with your site control does not appear on the home page, click the Settings icon, and click View Site Contents, and then on the Site Contents page, click Add an App.

  3. Click SharePoint Store.
  4. Browse the SharePoint Store to find an app that you want.
  5. Click the app you want to add.
  6. Click Details, and then click Buy It.
  7. Follow the steps to log in and purchase the app, if required.
  8. In the Grant Permission to an App dialog box, if you trust the app, click Allow Access.

    The app for SharePoint is added and appears in the Apps section of your Site Contents list.

You can also install an app by using Windows PowerShell. First, you import the app package from the file system, and then install it to the site collection. The following procedure contains a script to perform these steps.

To install an app by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Site Owners group on the site collection to which you want to install the app.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command to import the app and then press ENTER:

    $spapp = Import-SPAppPackage -Path Path to app -Site URL -Source Source
    # Imports the app and sets a variable that you can use to identify the app when you install it in the next step.

    Where:

  • Path to app is the path to the app you want to import on the file system.
  • URL is URL for the site collection to which you want to import the app.
  • Source is one of the following: Marketplace, CorporateCatalog, DeveloperSite, ObjectModel, RemoteObjectModel, or InvalidSource.
  1. At the question Are you sure you want to perform this action?, type Y to import the app.

    The app is imported and information about the app, including the Asset ID, version string, and Product ID is displayed.

  2. At the Windows PowerShell command prompt, type the following command to add the app to a site and then press ENTER:

    Install-SPApp -Web URL -Identity $spapp
    # Installs the app to the subweb you specify.
    # Uses the $spapp variable you set previously to identify that app you want to install.

    Where:

  • URL is URL for the site or subweb to which you want to install the app.

For more information, see Import-SPAppPackage and Install-SPApp.

 

 

  1. Verify that the user account that is performing this procedure is a member of the Site owners group.
  2. On the site, on the Settings menu, click View Site Contents.
  3. In the Apps section, point to the app that you want to remove, click …, and then click Remove.
  4. Click OK to confirm that you want to remove the app.

Before you use the following procedure, be sure to get the title for the app that you want to remove.

To remove an app by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Site Owners group on the site collection to which you want to install the app.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following commands, and press ENTER after each one:

    $instances = Get-SPAppInstance -Web <URL>
    # Gets all apps installed to the subsite you specify.

    $instance = $instances | where {$_.Title -eq ‘<App_Title>‘}
    # Sets the $instance variable to the app with the title you supply.

    Uninstall-SPAppInstance -Identity $instance
    # Uninstalls the app from the subsite.

    Where:

  • <URL> is the path site collection or subsite that contains the app.
  • <App_Title> is the title of the app you want to remove.
  1. At the question Are you sure you want to perform this action?, type Y to uninstall the app.

For more information, see Get-SPAppInstance, Uninstall-SPAppInstance.

 

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. In Central Administration, click General Application Settings.
  3. On the General Application Settings page, in the Apps section, click Monitor Apps.
  4. On the Monitored Apps page, in the Action group of the ribbon, click Add App.

    Note:

If the App Catalog is not already created, or if the App Management Service application and app domain settings are not configured correctly the Add App dialog may create an error.

  1. Select the checkbox for the app that you want to monitor, or type a name in the Search for app name box, and then click the Search icon.
  2. On the search results page, select the app that you want to monitor.

    Note:

Apps that you add to the Monitored Apps list previously are not displayed in the search results.

  1. Click Add App.

    The app now appears in the list of monitored apps.

To remove an app from the monitor apps list

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Monitored Apps page, select the checkbox next to the app that you want to remove.
  3. In the Manage group of the ribbon, click Remove App.
  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Monitored Apps page, click the app that you want to view.

    A new page opens and displays detailed information about the app, such as the following: licensing, errors, installations, and usage.

    Note:

The administrator can also select an app in the monitored apps list and in the App Details group of the ribbon, click View Details.

  1. In the Usage section, click Days, Months, or Years to change the chart to those time frames.

To view the app error details in Monitored Apps

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Monitored Apps page, click the number in the Runtime Errors column for the app you want to view.

    Note:

The administrator can also select an app in the monitored apps list and in the App Details group of the ribbon, click View Errors.

  1. The App Monitoring Details dialog appears with information about each error for that app. You can use the Correlation ID to find the errors in the error log.
  2. Click the URL in the Location column to view more error details for this app.
  3. On the App Monitoring Details page, click the number next to Runtime Errors.
  4. The App Monitoring Details dialog appears and includes a list of all Runtime Errors for this app, the time each error occurred, and the Correlation ID.

    Note:

The app error list can help you determine if you want to remove the app because there are too many errors or if the app is working as it should.

  1. Verify that the user account that is performing this procedure is a member of the site Owners group.
  2. On the Site Contents page, in the quick launch pane, click Apps.

    A new page opens and displays all of the apps that are installed on this site.

  3. On the Apps page click the icon next to the app you want to monitor and then click Details in the callout.

    The App Details page appears for the selected app and the site owner can see the details for licenses, errors Installs and usage.

  4. In the Errors section, click the number next to Install Errors, Runtime Errors, or Upgrade Errors to see the error details.

    For example, click the number next to Runtime Errors and the Runtime Errors dialog appears. This includes a list of all Runtime Errors for this app, the time each error occurred, and the Correlation ID.

    This app error list can help you determine if you want to remove the app because there are too many errors or if the app is working as it should.

    Note:

The app errors that appear in this list have occurred within the previous four days.

  1. In the Usage section, click Days, Months, or Years to change the chart to those time frames.

    The chart displays two bars for each time period that represents the number of times the app has been launched and the number of specific users that use this app each day.

    Note:

If the app uses connections to external data sources through Business Connectivity Services, a graph that shows the number of calls made to the external data sources is also shown. Dates that appear in the Usage and BCS Calls graphs are in Coordinated Universal Time (UTC).

 

 
  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group or a license manager.
  2. In Central Administration, click Apps.
  3. On the Apps page, in the Store section, click Manage App Licenses.
  4. On the Manage App Licenses page, click an app for SharePoint in the list to view the license details.

    The Manage App License page shows detailed licensing information. This includes the name of the app, the developer, and current license details.

  5. In the top section, click the drop-down arrow in the dialog box to see purchase details for the selected app for SharePoint.

    The app details include the following information:

  • Number of licenses available for users
  • License type
  • App purchaser name
  1. At the end of the dialog box, a farm administrator can view the app details.
  • Click View in Store to see the app details.
    • In the People with a License (number of licenses available)section, the number of available licenses and a list of the people who currently have licenses for this App are shown.
    • In the License Managers section, all app managers are listed.

To add users to the app license

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Manage App Licenses page, click an app for SharePoint for which you want to add users.
  3. In the People with a License section, click assign people.
  4. In the dialog box that appears below, enter the user name that you want to add and then, click Add User.

    The user name is added to the list at the bottom of this section and the number of available licenses for this app is refreshed for the selected app for SharePoint.

To purchase more app licenses

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Manage App Licenses page, click an app for SharePoint for which you want to purchase more licenses.
  3. In the People with a License section, click buy more licenses.
  4. The SharePoint Store opens with the specific app showing the details with links to purchase additional licenses. Choose the number of Apps you want to purchase and then click OK.

To remove app licenses

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Manage App Licenses page, click an app for SharePoint for which you want to remove licenses.
  3. In the top section, under the app for SharePoint name, at the end of the dialog box, click Remove this License.
  4. Verification: Optionally, include steps that users should perform to verify that the operation was successful.

To recover app licenses

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Manage App Licenses page, click an app for SharePoint for which you want to recover licenses.
  3. In the top section, under the app name, at the end of the dialog box, click Recover License.

    The app for SharePoint details show any changes the administrator has made.

To add a license manager

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
  2. On the Manage App License page, in the License Managers section, click add manager.

    Below the License Managers section, the new App manager appears in the list.

 

 

  1. Create and configure a new farm that is separate from the old farm
  2. Copy the content and services databases to the new farm
  3. Upgrade the data and sites

You can upgrade the content databases in any order and upgrade several databases at the same time to speed up the overall process.

For more information, see Overview of the upgrade process to SharePoint 2013.

  1. A server farm administrator installs SharePoint 2013 to a new farm. The administrator configures farm settings and tests the environment.
  2. A server farm administrator sets the SharePoint 2010 Products farm to read-only so that users can continue to access the old farm while upgrade is in progress on the new farm.

    Figure: Create new farm, set old farm to read-only
  1. With the farm and databases in read-only mode, a server farm administrator backs up the content and service application databases from the SQL Server instance on the SharePoint 2010 Products farm.
  2. The server farm administrator restores a copy of the databases to the SQL Server instance on the SharePoint 2013 farm and sets the databases to read-write on the new farm.

    Figure: Use SQL Server tools to copy databases
  1. A server farm administrator configures the service applications for the new farm. The following service applications have databases that you can upgrade during this process:
  • SharePoint Server 2010 and SharePoint Foundation 2010
    • Business Data Connectivity service application
  • SharePoint Server 2010 only
    • Managed Metadata service application
    • PerformancePoint Services service application
    • Search service application
    • Secure Store Service application
    • User Profile service application
  1. A server farm administrator creates a web application on the SharePoint 2013 farm for each web application on the SharePoint 2010 Products farm.

    Figure: Create web applications for upgrade



  2. A server farm administrator installs all server-side customizations.

    Figure: Copy customizations to the new farm



  3. A server farm administrator then attaches the content databases to the new farm and upgrades the content databases for those web applications.

    Figure: Upgrade the databases by using Windows PowerShell



  4. A server farm administrator confirms that the upgrade is successful.
  1. The My Site host has not been upgraded. My Sites cannot be upgraded yet.
  2. A server farm administrator has upgraded the My Site host. No My Sites have been upgraded.
  3. Some users have upgraded their My Sites.
  4. All My Sites have been upgraded.

    Note:

A server farm administrator can choose to force an upgrade of My Sites without waiting for users to upgrade them. For details and steps, read Upgrade site collections to SharePoint 2013.

Owners of all other site collections can start to upgrade their sites as soon as they see a notification on their site’s home page that the new version is available. The following illustration shows four stages for a site collection during the upgrade process.

Stages in upgrading site collections



  1. The site owner runs the site collection health checks to determine readiness for upgrade. The site owner addresses issues before they continue with the next step.
  2. Optionally, the site owner requests an upgrade evaluation site collection. A timer job runs to create the site collection and the site owner receives an email message when the evaluation site collection is ready. The site owner previews the new user interface. After several days or weeks, the evaluation site collection expires and is deleted by a timer job.

    A server farm administrator can determine the length of time before expiration.

  3. When the site owner is ready, the site owner starts the upgrade process. The site collection health checks are run again automatically. The site owner must address issues before upgrading. If health checks return no issues, the upgrade starts.
  4. When upgrade is complete, the site owner sees the Upgrade Status page that contains the status and a link to the upgrade logs. The site owner reviews the site to make sure that everything works correctly.

    Note:

A server farm administrator can also force specific site collections to be upgraded without waiting for the site owners to upgrade them. For details and steps, read Upgrade site collections to SharePoint 2013.

 

 

  1. Know what is in your environment. Do a full survey first.

    Document the hardware and software in your environment, where server-side customizations are installed and used, and the settings that you need. This helps you plan the trial environment and also helps you recover if upgrade fails. A worksheet is available to record information about your environment. Download the worksheet at SharePoint 2013 Products Preview Upgrade Worksheet.

  2. Make your test environment as similar as possible to your real environment.

    If possible, use the same kind of hardware and use the same settings, the same URLs, and so on to configure it. Minimize the differences between your test environment and your real environment. As you introduce more differences, you are likely to spend time resolving unrelated issues to make sure that they will not occur during the actual upgrade.

  3. Use real data.

    Use copies of your actual databases to run the tests. When you use real data, you can identify trouble areas and also determine upgrade performance. You can also measure how long different upgrade sequences and actions take on different kinds of data. If you cannot test all the data, test a representative subset of the data. Make sure that you find issues with the different kinds and sizes of sites, lists, libraries, and customizations that are present in your environment. If you cannot test all data because of storage concerns, try going over the data in several passes, removing the old trial copies before going on to the next batch.

  4. Run multiple tests.

    A single test can tell you whether you will encounter big problems. Multiple tests will help you find all the issues that you might face and help you estimate a more accurate timeline for the process. By running multiple tests, you can determine the following:

  • The upgrade approaches that will work best for your environment
  • The downtime mitigation techniques that you should plan to use
  • How the process or performance may change after you address the issues that you uncovered in your first tests

    Your final test pass can help you validate whether you have addressed the errors and are ready to upgrade your production environment.

  1. Do not ignore errors or warnings.

    Even though a warning is not an error, a warning could lead to problems in the upgrade process. Resolve errors, but also investigate warnings to make sure that you know the results that a warning might produce.

  2. Test the upgraded environment, not just the upgrade process.

    Check your service applications and run a search crawl and review the log files.

For more information about how to test upgrade, see Use a trial upgrade to SharePoint 2013 to find potential issues and the SharePoint 2013 Products Preview – Test Your Upgrade Process model.

  • Best practices for upgrading to SharePoint 2013

    To guarantee a smooth upgrade from SharePoint 2010 Products to SharePoint 2013, follow these best practices:

  1. Ensure that the environment is fully functioning before you begin to upgrade.

    An upgrade does not solve problems that already exist in your environment. Therefore, make sure that the environment is fully functioning before you start to upgrade. For example, if you are not using web applications, unextend them before you upgrade. If you want to delete a web application in Internet Information Services (IIS), unextend the web application before you delete it. Otherwise, SharePoint 2013 will try to upgrade the web application even though it does not exist, and the upgrade will fail. If you find and solve problems beforehand, you are more likely to meet the estimated upgrade schedule.

  2. Perform a trial upgrade on a test farm first.

    Copy your databases to a test environment and perform a trial upgrade. Examine the results to determine the following:

  1. Plan for capacity.

    Ensure that you have enough disk, processor, and memory capacity to handle upgrade requirements. For more information about system requirements, see System requirements (SharePoint 2013 Preview). For more information about how to plan the disk space that is required for upgrade, see Plan for performance during upgrade to SharePoint 2013.

  2. Clean up before you upgrade

    Issues in your environment can affect the success of upgrade, and unnecessary or very large amounts of data can affect upgrade performance for both databases and site collections. If you don’t need something in your environment, consider removing it before upgrade. If there are issues detected, try to resolve them before you start to upgrade. For more information, see Clean up an environment before an upgrade to SharePoint 2013.

  3. Back up your databases.

    Perform a full backup of your databases before you upgrade. That way, you can try upgrade again if it fails.

  4. Optimize your environment before upgrade.

    Be sure to optimize your SharePoint 2010 Products environment to meet any limits or restrictions, either from your business or governance needs or from the SharePoint 2013 boundaries and limits before upgrade. This will help reduce errors during the upgrade process and prevent broken lists or sites after upgrade. For more information about limits in the product, see SharePoint Server 2010 Capacity Management: Software Boundaries and Limits. For more information about large lists and how to address the lower limit on site collections, see Clean up an environment before an upgrade to SharePoint 2013.

  5. (Optional) Set the original databases to read-only if you want to keep your original environment available while you upgrade.

    If you expect a long outage period while you upgrade, you can set the databases in the original environment to read-only. Users can continue to access the data but cannot change it. For more information, see Attach databases and upgrade to SharePoint 2013.

  6. After upgrade, review the Upgrade Status page and upgrade logs to determine whether you must address issues. Then review the upgraded sites.

    The Upgrade Status page reports on the upgrade progress, and the upgrade logs list any errors or warnings that occurred during the upgrade process. Verify all the sites and test them before you consider the upgrade finished. For more information, see Verify database upgrades in SharePoint 2013 and Review site collections upgraded to SharePoint 2013.

  7. Defer upgrade for site collections until you can get updated customizations to support 2013 mode.

    If you wait until the customizations are available, you can complete the initial upgrade of database and services without significantly affecting use of the existing sites in 2010 mode.

 

  1. Keep the customizations, don’t upgrade the sites   You can continue to run the site in 2010 mode in the upgraded environment. Although you can use this approach to keep the same functionality, you will be unable to take advantage of the features and capabilities that are available in the new version. Use this approach only temporarily – eventually you must address the issue (such as before an upgrade to the next version of the product).
  2. Replace or redo the customizations   If you want to use new functionality, plan to redesign your sites, or are significantly changing the information architecture, the upgrade is your opportunity to start over with new features, a new look, or a new organization. When you replace or redo customizations, you can take advantage of the new capabilities, change your design slightly if you want, or move to a more manageable design.
  3. Discard the customizations   Replace the customizations by using default functionality. You can reset pages to the default site definitions and remove any Web Parts or features that you no longer want to support. In fact, the site collection health-checker checks for unghosted pages and can reset the pages to the default versions. If you decide to discard any customizations, you must fix any issues that result from removing the customizations in the sites that used them. You can use your customizations inventory to determine which sites require this kind of attention before or after upgrade.
  1. If you have an Enterprise version of SQL Server, the Create Upgrade Evaluation Site Collections job timer takes a snapshot of the database and reads the data from the snapshot to a destination database (with the source database being the default target). This doesn‘t affect the read-only status of the source site throughout the whole process.
  2. For other versions of SQL Server that do not have snapshot capabilities, the Create Upgrade Evaluation Site Collections job timer backs up a site collection and restores it to a new URL. This makes the source site read-only for the whole duration of the process.

The Upgrade Site Collections job collects the list of site collections that were queued for upgrade and then upgrades the queued sites from oldest to newest. The recently added evaluation site is then upgraded (or at least upgrade is tried).

  1. Because of the web application throttle limit, only five sites can start to upgrade for web application 1 – instance 1 on Web server 1.
  2. An additional five sites start to upgrade on web application 1 – instance 2 on Web server 2.
  3. Because of the content database throttle, five sites are sent to the upgrade queue to wait their turn.

You can use the default throttling settings, or you can specify your own values for how many site collections can be upgraded at the same time. Farm administrators can also override throttle settings when they upgrade a site by using Windows PowerShell. Exercise caution when you change these values and make sure that you verify the settings that you want to use in a test environment before you implement them in production. If you increase throttling too much, you could create performance problems in your environment. For example, too many parallel upgrades could affect site rendering. For information about how to change these settings, see Manage site collection upgrades to SharePoint 2013.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2010 Products.
  3. Click SharePoint 2010 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command to return all site collections that are in or have subwebs in the old experience:

    Get-SPSite | ForEach-Object{$_.GetVisualReport()}

  5. At the Windows PowerShell command prompt, type the following command to upgrade those sites to the new experience:

    Get-SPSite | ForEach-Object{$_.VisualUpgradeWebs()}

For more information, see Get-SPSite and Manage visual upgrade (SharePoint Server 2010).

  • Repair data issues

Make sure that you repair all issues in your databases or site content before you upgrade. In particular, check the following items:

  • Check databases for corrupted data

    Clean up your databases to remove any orphaned sites or other corrupted data, such as a corrupted list. Consider defragmenting if you have removed sites or subsites from the database. For more information, see:

  • Check databases for duplicate or orphaned site collections

    Make sure that site collections exist in only one content database. Occasionally, site collections can leave behind duplicate or orphaned references in old content databases if they are moved to new databases, or if a copy of a database was attached to the farm, or if there was an error when a site collection was provisioned. If a site collection is referenced in more than one content database or there is more than one instance of the site collection in a content database, it can cause issues when you upgrade by using the database attach upgrade method. If you upgrade a duplicate version of the site collection first, the site map in your configuration database might end up pointing to that version of the site instead of the current version.

    Before you upgrade, use the Enumallwebs operation in stsadm command-line tool to discover which sites are in which content databases and compare the results. Also, examine each site collection in the results and check whether it is listed as missing in the site map. Being listed as missing indicates that it is an orphaned site. For more information, see Enumallwebs: Stsadm operation. If you find duplicate or orphaned sites, you can use the Remove-SPSite cmdlet in Windows PowerShell to remove the duplicate or orphaned sites from the database.

    For more information, see Remove-SPSite.

  • Check variations

    In publishing environments, check for any variations that must be fixed. For more information, see Variationsfixuptool: Stsadm operation.

  1. Review the Upgrade Status page in the SharePoint Central Administration website.

    For more information about how to check upgrade status, see Verify database upgrades in SharePoint 2013.

  2. Review the following log files:
  • The upgrade error log file and the upgrade log file (which contains more detailed information than the upgrade error log file).
  • ULS or trace log files.

    These files are stored in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS folder and are named Servername_YYYYMMDD–MMSS.log.

  • The application event log file.

    This file can be viewed by using the Event Viewer.

    For more information about the upgrade log files, see Verify database upgrades in SharePoint 2013. For more information about the trace log file, see Trace Logs on MSDN.

  • Then, address issues in order

Some issues have more effect than others. For example, a missing server-side file can cause many seemingly unrelated errors at the site level.

Address issues in the following order:

  1. Missing server-side files or customizations, such as features or Web Parts.

    Be sure to install all server-side customizations, such as features, Web Parts, and so on. Be sure to install customizations to the correct location in your new farm. For example, additional style sheets that you must have for SharePoint 2010 Products should be installed in the /14 path, not the new /15 path so that site collections that you have not upgraded can use them. Also, make sure that that you transfer all unique settings from the Web.config files for each web application to the new servers.

  2. Configuration issues in the server farm, web application, or service applications, such as managed paths or service applications that are not started.
  3. Additional issues that you discover on a site-by-site basis, starting with high-profile or very important sites.

As you identify and fix the top-level issues, you can try to run upgrade again to see whether any issues that occurred later in the upgrade process have also been fixed.

  1. Review the upgrade status page for your site collection.

    On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade. On the Site Collection Upgrade page, click Review Site Collection Upgrade Status.

  2. Review the site collection upgrade log files. You can review the site collection upgrade logs from the following locations:
  • For site collection administrators: There are also log files for site collection upgrade stored inside the site collection itself, in the Maintenance Logs catalog at (http://<SiteName>/_catalogs/MaintenanceLogs/YYYYMMDD-HHMMSS-SSS.txt , where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).
  • For farm administrators: The site collection upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. The logs are named in the following format: SiteUpgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). These file system logs have more information if you want details about issues.
  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt (PS C:\>), type the following command:

    upgrade-spcontentdatabase <Name>

    Where:

  • Name is the database name that you want to upgrade.

    You can also use the -id parameter and provide the database GUID instead of a database name. You can run the following cmdlet to find the GUID for a content database:

    Get-SPContentDatabase -Identity <content_database_name>

    For more information, see Upgrade-SPContentDatabase and Get-SPContentDatabase.

  • Restart upgrade for a site collection

    If upgrade ran into issues during a site collection upgrade, you can restart the upgrade process for the site collection after you have addressed the issue. You can use either the Site Settings page or a Windows PowerShell cmdlet to restart upgrade for a site collection.

    To restart upgrade for a site collection

  1. Verify that the user account that performs this procedure is a site collection administrator.
  2. On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade.
  3. On the Site Collection Upgrade page, click Upgrade this Site Collection.

    This option starts to upgrade your site collection. A box opens to verify that you want to start the process.

  4. Click I’m ready to start the actual upgrade.

    Note:

The site collection health checks are run automatically in repair mode before the upgrade starts. The results from the health checks are included in the upgrade log for the site collection. If there is an error, you must address it before you can continue to upgrade.

The upgrade starts, and the Upgrade status page for the site collection is displayed. This page automatically updates while the upgrade is in progress and displays information about the process, such as the following:

  • Errors or warnings
  • When the upgrade started
  • Where you can find the upgrade log file

    After the upgrade is complete, the Upgrade status page is displayed in the new user interface with the message, Upgrade Completed Successfully.

  1. Click Let’s see the new site to go to the home page.

Farm administrators can restart upgrade by using Windows PowerShell.

To restart upgrade for a site collection by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Upgrade-SPSite <http://site&gt; -VersionUpgrade [-Unthrottled]

    Where:

  • <http://site&gt; is the URL for the site collection.
  • Add the option -Unthrottled option to skip the site collection upgrade queue and start the upgrade immediately.

For more information, see Upgrade-SPSite.

 

 

  1. Run the Microsoft SharePoint Products Preparation Tool to install all required software.
  2. Run Setup to install the product.
  3. Install all language packs that you want in your environment.

    Note:

For more information about how to install available language packs, see Install or uninstall language packs for SharePoint 2013.

  1. Run the SharePoint Products Configuration Wizard to configure your server or servers.

    Important:

Some service applications can be upgraded by using a service application database upgrade. If you want to upgrade these service applications by upgrading the service application databases, do not use the Farm Configuration Wizard to configure these service applications when you set up your new farm.

For step-by-step instructions for these tasks, see Install SharePoint 2013.

Back to top

  1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role for the databases.
  2. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.
  3. Find the database that you want to configure to be read-only, right-click the database, and then click Properties.
  4. In the Database Properties dialog box, in the Select a page section, click Options.
  5. In the details pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select True.

You can use Transact-SQL to configure the READ_ONLY database availability option. For more information about how to use the SET clause of the ALTER DATABASE statement, see Setting Database Options.

Back to top

  1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role for the databases.
  2. In Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.
  3. Right-click the database that you want to back up, point to Tasks, and then click Back Up.

    The Back Up Database dialog box appears.

  4. In the Source area, in the Database box, verify the database name.
  5. In the Backup type box, select Full.
  6. Under Backup component, select Database.
  7. In the Backup set area, in the Name box, either accept the backup set name that is suggested or type a different name for the backup set.
  8. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.
  9. Click OK to start the backup process.

Repeat the previous procedure to back up all the content and appropriate service application databases that SharePoint 2010 Products uses in your environment.

    Important:

Before you can back up the Search service application Administration database, you must stop the Search service on your SharePoint Server 2010 farm. To stop the Search service, on the original farm, on the Start menu, click Administrative Tools, and then click Services. Right-click SharePoint Server Search 14, and then click Stop. Be sure to start the service again after you back up the database.

Back to top

  1. Verify that you have the following memberships:
  • Administrators group on the server on which you are running the command.
  1. Open the Command Prompt window, and then change to the following folder:

    %Program Files%\Microsoft Office Servers\14.0\Synchronization Service\Bin\

  2. To export the key, type the following at the command prompt, and then press ENTER:

    miiskmu.exe

  3. In the Microsoft Identity Integration Server Key Management Utility wizard, verify that Export key set is selected, and then click Next.
  4. In the Account Name box, type the account name for the farm administrator.
  5. In the Password box, type the password for the farm administrator.
  6. In the Domain box, type the domain that contains the farm administrator account, and then click Next.
  7. In the Specify export file name and location box, type or click browse to select the path and file name to use for the exported key, and then click Next.

    The key is exported as a file that has a .BIN file name extension.

  8. Verify the information, and then click Finish.

    A message appears indicating that the key was successfully exported.

  9. Click Close to close the Microsoft Identity Integration Server Key Management Utility.

For more information, see Back up a User Profile Service application (SharePoint Server 2010).

Back to top

  1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role for the databases.
  2. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.
  3. Right-click Databases, and then click Restore Database.

    The Restore Database dialog box appears.

  4. In the Restore Database dialog box, on the General page, type the name of the database to be restored in the To database list.

    Tip:

When you type the name for the restored database, you do not have to use the original name. If you want to change the database name from a name with a long GUID to a shorter, more friendly name, this is an opportunity to make that change. Be sure to also change the database and log file names in the file system (the MDF and LDF files) so that they match.

  1. In the To a point in time text box, keep the default (Most recent possible).
  2. To specify the source and location of the backup sets to restore, click From device, and then use the browse button to select the backup file.
  3. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.
  4. In the Backup location area, click Add.
  5. In the Locate Backup File dialog box, select the file that you want to restore, click OK, and then, in the Specify Backup dialog box, click OK.
  6. In the Restore Database dialog box, under Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.
  7. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.
  8. Click OK to start the restore process.

Back to top

  1. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.
  2. Select the database that you want to configure to be read-write, right-click the database, and then click Properties.
  3. In the Database Properties dialog box, in the Select a page section, click Options.
  4. In the details pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select False.

Back to top

  1. Start the service instances

    The first step is to start service instances for the five service applications that you can upgrade: the Business Data Connectivity service, Managed Metadata Web Service, PerformancePoint Services service, Secure Store service, User Profile service, and Search service. Most of these service instances can be started from Central Administration. However the SharePoint Server Search service instance must be started by using Windows PowerShell.

  2. Create the service applications and upgrade the databases

    After you have started the service instances, the next step is to create the service applications and upgrade the databases. You must use Windows PowerShell to restore the service application databases.

  3. Create proxies for the service applications

    After you have upgraded the service application databases, you create the proxies for the service applications and add them to the default proxy group. You must create proxies for the following service applications:

  • Managed Metadata service application
  • Search service application
  • Secure Store service application
  • PerformancePoint Services service application
  • User Profile service application

    The Business Data Connectivity service application automatically creates a proxy and assigns it to the default proxy group when you create the service application.

  1. Verify that the proxies are in the default group

The following sections provide procedures to complete these steps.

    Note:

The Business Data Connectivity service application is available in both SharePoint Foundation 2013 and SharePoint Server 2013. The other service applications are available only in SharePoint Server 2013. Although SharePoint Foundation 2013 includes search functionality, it is not the same Search service application that is in SharePoint Server 2013 and it cannot be upgraded.

Back to top

  1. Start SharePoint 2013 Central Administration.
  1. In SharePoint 2013 Central Administration, on the Application Management page, in the Service Applications section, click Manage Services on Server.
  2. Next to the Business Data Connectivity service, click Start.
  3. Next to the Managed Metadata Web Service, click Start.
  4. Next to the PerformancePoint Services service, click Start.
  5. Next to the Secure Store Service, click Start.
  6. Next to the User Profile Service, click Start.

The Search service instance must be started by using Windows PowerShell because you cannot start it from Central Administration unless a Search Service application already exists.

To start the Search service instance by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To start the Search service instance, at the Windows PowerShell command prompt, type the following commands and press ENTER after each one:

    $SearchInst = Get-SPEnterpriseSearchServiceInstance
    # Stores the identity for the Search service instance on this server as a variable
    Start-SPServiceInstance $SearchInst
    # Starts the service instance

For more information, see Get-SPEnterpriseSearchServiceInstance and Start-SPServiceInstance.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To store the application pool for a particular service application as a variable, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $applicationPool = Get-SPServiceApplicationPool -Identity ‘SharePoint Web Services default‘

    Where:

  • SharePoint Web Services default is the name of the service application pool that will contain the new service applications.

    This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you have multiple application pools and have to use a different application pool for a particular service application, you can repeat this step to get the appropriate application pool before you create the service application.

  1. To upgrade the Secure Store service application, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $sss = New-SPSecureStoreServiceApplication -Name ‘Secure Store‘ -ApplicationPool $applicationPool -DatabaseName ‘SecureStore_Upgrade_DB‘ -AuditingEnabled

    Where:

  • SecureStore is the name that you want to give the new Secure Store service application.
  • SecureStore_Upgrade_DB is the name of the service application database that you want to upgrade.

    This command sets a variable, $sss, that you use when you create the proxy later.

    For more information, see New-SPSecureStoreApplication.

    After you create the Secure Store service application and upgrade the database, you have to refresh the encryption key. For information about how to refresh the encryption key, see Refresh the encryption key.

  1. Type the following command to create a proxy for the Secure Store service application:

    Windows PowerShell 

    New-SPSecureStoreServiceApplicationProxy -Name ProxyName -ServiceApplication $sss -DefaultProxyGroup

    Where:

  • ProxyName is the proxy name that you want to use.
  • $sss is the variable that you set earlier to identify the new Secure Store service application.

        Tip:

If you do not use the variable $sss, then you must use an ID to identify the Secure Store service application instead of a name. If you have to find the ID, you can run the Get-SPServiceApplication cmdlet to return a list of all service application IDs.

  1. Type the following command to restore the passphrase for the Secure Store service application:

    Update-SPSecureStoreApplicationServerKey -Passphrase <Passphrase>

    Where:

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To store the application pool for a particular service application as a variable, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $applicationPool = Get-SPServiceApplicationPool -Identity ‘SharePoint Web Services default‘

    Where:

  • SharePoint Web Services default is the name of the service application pool that will contain the new service applications.

    This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you have multiple application pools and have to use a different application pool for a particular service application, you can repeat this step to get the appropriate application pool before you create the service application.

  1. To upgrade the Business Data Connectivity service application, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    New-SPBusinessDataCatalogServiceApplication -Name ‘BDC Service‘ -ApplicationPool $applicationPool -DatabaseName ‘BDC_Service_DB‘

    Where:

  • BDC Service is the name that you want to give the new Business Data Connectivity service application.
  • BDC_Service_DB is name of the service application database that you want to upgrade.

    For more information, see New-SPBusinessDataCatalogServiceApplication.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To store the application pool for a particular service application as a variable, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $applicationPool = Get-SPServiceApplicationPool -Identity ‘SharePoint Web Services default‘

    Where:

  • SharePoint Web Services default is the name of the service application pool that will contain the new service applications.

    This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you have multiple application pools and have to use a different application pool for a particular service application, you can repeat this step to get the appropriate application pool before you create the service application.

  1. To upgrade the Managed Metadata service application, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $mms = New-SPMetadataServiceApplication -Name ‘Managed Metadata Service Application‘ -ApplicationPool $applicationPool -DatabaseName ‘Managed Metadata Service_DB‘

    Where:

  • Managed Metadata Service Application is the name that you want to give the new Managed Metadata service application.
  • Managed Metadata Service_DB is name of the service application database that you want to upgrade.

    This command sets a variable, $mms, that you use when you create the proxy later.

    For more information, see New-SPMetadataServiceApplication.

  1. At the Windows PowerShell command prompt, type the following command to create a proxy for the Managed Metadata service application:

    Windows PowerShell 

    New-SPMetadataServiceApplicationProxy -Name ProxyName -ServiceApplication $mmd -DefaultProxyGroup

    Where:

  • ProxyName is the proxy name that you want to use.
  • $mmd is the variable that you set earlier to identify the new Managed Metadata service application.
  • DefaultProxyGroup adds the Managed Metadata service application proxy to the default proxy group for the local farm.

    For more information, see New-SPMetadataServiceApplicationProxy.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To store the application pool for a particular service application as a variable, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $applicationPool = Get-SPServiceApplicationPool -Identity ‘SharePoint Web Services default‘

    Where:

  • SharePoint Web Services default is the name of the service application pool that will contain the new service applications.

    This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you have multiple application pools and have to use a different application pool for a particular service application, you can repeat this step to get the appropriate application pool before you create the service application.

  1. To upgrade the User Profile service application, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $upa = New-SPProfileServiceApplication -Name ‘User Profile Service Application‘ -ApplicationPool $applicationPool -ProfileDBName ‘User Profile Service Application_ProfileDB‘ -SocialDBName ‘User Profile Service Application_SocialDB‘
    -ProfileSyncDBName ‘    User Profile Service Application_SyncDB‘

    Where:

  • User Profile Service Application is the name that you want to give the new User Profile service application.
  • User Profile Service Application_ProfileDB is name of the User Profile service application Profile database that you want to upgrade.
  • User Profile Service Application_SocialDB is name of the User Profile service application Social database that you want to upgrade.
  • User Profile Service Application_SyncDB is name of the User Profile service application Sync database that you want to upgrade.

    This command sets a variable, $upa, that you use when you create the proxy later.

    For more information, see New-SPProfileServiceApplication.

  1. Type the following command to create a proxy for the User Profile service application:

    Windows PowerShell 

    New-SPProfileServiceApplicationProxy -Name ProxyName -ServiceApplication ServiceApplicationID -DefaultProxyGroup

    Where:

  • ProxyName is the proxy name that you want to use.
  • $upa is the variable that you set earlier to identify the new User Profile service application.
  • ServiceApplicationID is ID of the User Profile service application that you created earlier.

        Tip:

If you do not use the variable $upa, then you must use an ID to identify the User Profile service application instead of a name. If you have to find the ID, you can run the Get-SPServiceApplication cmdlet to return a list of all service application IDs.

After you have created the User Profile Service service application, you must import the Microsoft Identity Integration Server Key (MIIS) encryption key. Import this key to the following directory: <root directory drive>\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin.

To import the encryption key for User Profile service application

  1. Verify that you have the following memberships:
  • Administrators group on the server on which you are running the command.
  1. Open the Command Prompt window, and then change to the following folder:

    %Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\

  2. To import the key, type the following at the command prompt, and then press ENTER:

    miiskmu.exe /i Path {0E19E162-827E-4077-82D4-E6ABD531636E}

    Where:

  • Path is the path and file name for the key that you want to import.

    You might also have to enter a user name and password. These are the credentials for the farm administrator.

For more information, see Install a software update (SharePoint Server 2010).

After you have imported the encryption key, you can start the User Profile Synchronization service.

  • Start the User Profile Synchronization service

  1. Start SharePoint 2013 Central Administration.
  • For Windows Server 2008 R2:
    • Click Start, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Central Administration.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Central Administration.

      If SharePoint 2013 Central Administration is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Central Administration.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. In Central Administration, on the System Settings page, under Servers click Manage services on Server.
  2. Next to the User Profile Synchronization Service, click Start.
  3. In the Select the User Profile Application section, select the User Profile service application that you upgraded.
  4. In the Service Account Name and Password section, type the account name and password to use for the User Profile Synchronization service.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To store the application pool for a particular service application as a variable, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $applicationPool = Get-SPServiceApplicationPool -Identity ‘SharePoint Web Services default‘

    Where:

  • SharePoint Web Services default is the name of the service application pool that will contain the new service applications.

    This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you have multiple application pools and have to use a different application pool for a particular service application, you can repeat this step to get the appropriate application pool before you create the service application.

  1. To upgrade the PerformancePoint Services service application, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $pps = New-SPPerformancePointServiceApplication -Name ‘PerformancePoint Service‘ -ApplicationPool $applicationPool -DatabaseName ‘PerformancePoint Service Application_DB‘

    Where:

  • PerformancePoint Service is the name that you want to give the new PerformancePoint Services service application.
  • PerformancePoint Service Application_DB is name of the PerformancePoint Services service application database that you want to upgrade.

    This command sets a variable, $pps, that you use when you create the proxy later.

    For more information, see New-SPProfileServiceApplication.

  1. Type the following command to create a proxy for the PerformancePoint Services service application:

    Windows PowerShell 

    New-SPPerformancePointServiceApplicationProxy -Name ProxyName -ServiceApplication ServiceAplicationNameorID -Default

    Where:

  • ProxyName is the proxy name that you want to use.
  • $pps is the variable that you set earlier to identify the new PerformancePoint Services service application.
  • Default adds the PerformancePoint Services service application proxy to the default proxy group for the local farm.

    For more information, see New-SPPerformancePointServiceApplicationProxy.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. To store the application pool for a particular service application as a variable, at the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    $applicationPool = Get-SPServiceApplicationPool -Identity ‘SharePoint Web Services default‘

    Where:

  • SharePoint Web Services default is the name of the service application pool that will contain the new service applications.

    This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you have multiple application pools and have to use a different application pool for a particular service application, you can repeat this step to get the appropriate application pool before you create the service application.

  1. To upgrade the Search service application, at the Windows PowerShell command prompt, type the following command:


    $searchInst = Get-SPEnterpriseSearchServiceInstance -local
    # Gets the Search service instance and sets a variable to use in the next command

    Restore-SPEnterpriseSearchServiceApplication -Name ‘<SearchServiceApplicationName>‘ -applicationpool $applicationPool -databasename ‘<SearchServiceApplicationDBName>‘ -databaseserver <ServerName> -AdminSearchServiceInstance $searchInst

    Where:

  • SearchServiceApplicationName is the name of the Search service application.
  • AppPoolName is the application pool name.
  • SearchServiceApplicationDBName is the name of the Search service application Administration database that you want to upgrade.
  • AdminSearchServiceInstanceID is the ID for the Search Service application instance.

        Note:

A Search service application upgrade might fail because of an issue that occurs during upgrade, such as network or SQL Server latency. If an error message appears during the Search service application upgrade, do the following:

  1. Delete the Search Administration database that you were trying to upgrade.
  2. Using the backup copy that you made of the Search Administration database, repeat the following procedures in this article for the Search service application only:
    1. Restore a backup copy of the database
    2. Set the databases to read-write
  3. Upgrade the Search service application by typing the command again at the Windows PowerShell command prompt.

For more information, see Restore-SPEnterpriseSearchServiceApplication.

You must follow several steps to create the Search service application proxy and add it to the default proxy group. You must complete separate actions to find the ID for the Search service application, create the new proxy, get the proxy ID, and then add the proxy to the default proxy group.

  1. Type the following command to get the ID for the Search service application and store it as a variable:

    Windows PowerShell 

    $ssa = Get-SPEnterpriseSearchServiceApplication

    For more information, see Get-SPEnterpriseSearchServiceApplication.

  2. Type the following command to create a proxy for the Search service application:

    Windows PowerShell 

    New-SPEnterpriseSearchServiceApplicationProxy -Name ProxyName -SearchApplication $ssa

    Where:

  1. Type the following command to get the Search service application proxy ID for the proxy you just created and set it as the variable $ssap:

    Windows PowerShell 

    $ssap = Get-SPEnterpriseSearchServiceApplicationProxy

    For more information, see Get-SPEnterpriseSearchServiceApplicationProxy.

  2. Type the following command to add the Search service application proxy to the default proxy group:

    Windows PowerShell 

    Add-SPServiceApplicationProxyGroupMember –member $ssap -identity “ “

    Where:

  • $ssap is the variable that you set earlier to identify the ID for the proxy you just created for the Search service application.
  • You use an empty identity parameter (“ “) to add it to the default group.

    For more information, see Add-SPServiceApplicationProxyGroupMember.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following commands:

    $pg = Get-SPServiceApplicationProxyGroup -Identity “ “
    $pg.Proxies

    Where:

  • $pg is a variable you set to represent the default proxy group.
  • You use an empty identity parameter (“ “) to specify the default proxy group.

    This returns a list of all proxies in the default proxy group, their display names, type names, and IDs.

For more information, see Get-SPServiceApplicationProxyGroup.

Now that the service applications are upgraded, you can start the process to upgrade the content databases. The first step in that process is to create the web applications that are needed for each content database.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Test-SPContentDatabase -Name DatabaseName -WebApplication URL

    Where:

  • DatabaseName is the name of the database that you want to test.
  • URL is the URL for the web application that will host the sites.

For more information, see Test-SPContentDatabase.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Mount-SPContentDatabase -Name DatabaseName -DatabaseServer ServerName -WebApplication URL

    Where:

  • DatabaseName is the name of the database that you want to upgrade.
  • ServerName is server on which the database is stored.
  • URL is the URL for the web application that will host the sites.

For more information, see Mount-SPContentDatabase.

    Tip:

To upgrade from SharePoint Foundation 2010 to SharePoint Server 2013, attach the SharePoint Foundation 2010 content databases directly to the SharePoint Server 2013 environment. Just follow the same steps in this article, only use the SharePoint Foundation 2010 databases and a SharePoint Server 2013 farm. The upgrade process will upgrade the version and the product at the same time.

Back to top

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. Start the SharePoint 2013 Management Shell.
  • For Windows Server 2008 R2:
    • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
  • For Windows Server 2012:
    • On the Start screen, click SharePoint 2013 Management Shell.

      If SharePoint 2013 Management Shell is not on the Start screen:

    • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  1. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Get-SPContentDatabase | ft Name, NeedsUpgradeIncludeChildren

This cmdlet returns a table-style list of databases in your farm and indicates whether the database needs an upgrade to SharePoint 2013.

Back to top

  1. Verify that you have the following administrative credentials:
  • To use SharePoint Central Administration, you must be a member of the Farm Administrators group.
  1. On the Central Administration home page, in the Upgrade and Migration section, click Check upgrade status.
  1. Verify that you have the following memberships:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.

  1. From the Windows PowerShell command prompt, type the following to set the specified user account as an administrator for the site:

    $WebAppName = “http://<yourWebAppUrl>“
    $wa = get-SPWebApplication $WebAppName
    $wa.UseClaimsAuthentication = $true
    $wa.Update()

    Where:

  • <yourWebAppUrl> is the URL of the web application.
  1. From the Windows PowerShell command prompt, type the following to configure the policy to enable the user to have full access:

    Windows PowerShell 

    $account = “yourDomain\yourUser”
    $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
    $wa = get-SPWebApplication $WebAppName
    $zp = $wa.ZonePolicies(“Default”)
    $p = $zp.Add($account,”PSPolicy”)
    $fc=$wa.PolicyRoles.GetSpecialRole(“FullControl”)
    $p.PolicyRoleBindings.Add($fc)
    $wa.Update()

    For more information, see Get-SPWebApplication.

  2. From the Windows PowerShell command prompt, type the following to perform user migration:

    $wa.MigrateUsers($true)

  3. After user migration completes, type the following from the Windows PowerShell command prompt to perform provisioning:

    Windows PowerShell 

    $wa.ProvisionGlobally()

    For more information, see New-SPClaimsPrincipal.

    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.

After you complete the previous procedures, you might experience one or more of the following issues:

  • Users who submit valid credentials when accessing the migrated web application might be notified that they do not have permissions. If this occurs, the portalsuperuseraccount property and the portalsuperreaderaccount property of the web application were probably configured prior to migration. If this is the case, update the portalsuperuseraccount property and the portalsuperreaderaccount property to use the new claims-based account name. After migration, you can find the new claims-based account name in the web application policy for the migrated web application.
  • If existing alerts are not invoked after migration, you might have to delete and recreate the alerts.
  • If Search crawl does not function on the web application after migration, make sure that the Search crawl account lists the new converted account name. If the new converted account name is not listed, you must manually create a new policy for the crawl account.

To migrate a claims-based SharePoint 2010 Products web application to SharePoint 2013

  1. In SharePoint 2013, create a claims-based web application. For more information, see Create claims-based web applications in SharePoint 2013.
  2. Attach the two existing SharePoint 2010 Products content databases to the newly created SharePoint 2013 claims-based web application. For more information, see Attach or detach content databases in SharePoint 2013.

    Note:

When you attach the SharePoint 2010 Products content databases to the SharePoint 2013 claims-based web application, the databases will be upgraded to the SharePoint 2013 database format. You have to verify that the content databases work correctly after you attach them.

  • Convert SharePoint 2010 Products classic-mode web applications to SharePoint 2013 claims-based web applications

    In SharePoint 2013, complete the following procedure to convert an existing SharePoint 2010 Products classic-mode web application to a SharePoint 2013 web application that uses claims-based authentication.

    To convert a SharePoint 2010 Products classic-mode web application to a SharePoint 2013 claims-based authentication

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.

  1. In the SharePoint 2013 environment, on the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. Change to the directory where you saved the file.
  5. At the Windows PowerShell command prompt, type the following command:

    New-SPWebApplication –name “ClassicAuthApp” –Port 100 –ApplicationPool
    “ClassicAuthAppPool”     –ApplicationPoolAccount (Get-SPManagedAccount
    “    <domainname>\<user>“)

    Where:

  • <domainname>\<user> is the domain to which the server belongs and the name of the user account.
  1. Attach the two existing SharePoint 2010 Products content databases to the new SharePoint 2013 classic-mode web application. For more information, see Attach or detach content databases in SharePoint 2013.

    Note:

When you attach the SharePoint 2010 Products content databases to the SharePoint 2013 classic-mode web application, the databases are upgraded to the SharePoint 2013 database format. You have to verify that the content databases work correctly after you have attached them.

  1. From the Windows PowerShell command prompt, type the following:

    Convert-SPWebApplication –Identity <yourWebAppUrl>
    –To Claims
    -RetainPermissions [ -Force]

    Where:

  • <yourWebAppUrl> is the URL of the web application.

        Note:

Convert-SPWebApplication converts the web application to claims-based authentication. You have to verify that the users can access the web application after you have converted it.

  1. If necessary, attach a third SharePoint 2010 Products content database to the new SharePoint 2013 classic-mode web application, and verify that the content database working correctly after you have attached it.
  2. From the Windows PowerShell command prompt, type the following:

    Convert-SPWebApplication –Identity yourWebAppUrl
    –To Claims
    -RetainPermissions [ -Force]

Verify that users can access the web application after you have converted it to claims-based authentication.

For more information, see New-SPWebApplication, Get-SPManagedAccount, and Convert-SPWebApplication.

    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.

  • Convert SharePoint 2013 classic-mode web applications to claims-based web applications

    In SharePoint 2013, complete the following procedures to first create a classic-mode Web application, and then convert it to claims-based authentication.

    To create a classic-mode Web application in SharePoint 2013

    • Verify that you have the following memberships:
      • securityadmin fixed server role on the SQL Server instance.
      • db_owner fixed database role on all databases that are to be updated.
      • Administrators group on the server on which you are running Windows PowerShell cmdlets.
      • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
      • Add memberships that are required beyond the minimums above.

        An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

            Note:

      If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.

    • From the Windows PowerShell command prompt, type the following:

      New-SPWebApplication –Name <Name>
      –ApplicationPool <ApplicationPool>
      -AuthenticationMethod <WindowsAuthType>
      –ApplicationPoolAccount <ApplicationPoolAccount>
      -Port <Port> -URL <URL>

      Where:

      • <Name> is the name of the new web application that uses classic-mode authentication.
      • <ApplicationPool> is the name of the application pool.
      • <WindowsAuthType> is either “NTLM“ or “Kerberos“. Kerberos is recommended.
      • <ApplicationPoolAccount> is the user account that this application pool will run as.
      • <Port> is the port on which the web application will be created in IIS.
      • <URL> is the public URL for the web application.

            Note:

      For more information, see New-SPWebApplication.

          Note:

      After you successfully create the web application, when you open the Central Administration page, you see a health rule warning that indicates that one or more web applications is enabled with classic authentication mode. This is a reflection of our recommendation to use claims-based authentication instead of classic mode authentication.

    To convert a SharePoint 2013 classic-mode web application to claims-based authentication

    • From the Windows PowerShell command prompt, type the following:

      Convert-SPWebApplication -Identity “http:// <servername>:port” -To Claims
      –RetainPermissions [-Force]

      Where:

      • <servername> is the name of the server.

    Verify that users can access the web application after you have converted it to claims-based authentication.

    For more information, see New-SPWebApplication, Get-SPManagedAccount, and Convert-SPWebApplication.

        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.

  • Migrate SharePoint 2010 Products classic-mode web applications to SharePoint 2013 classic-mode web applications

    In SharePoint 2013, complete the following procedure to create a classic-mode web application, and then migrate an existing SharePoint 2010 Products classic-mode Web application to SharePoint 2013.

    To migrate a SharePoint 2010 Products classic-mode web application to SharePoint 2013

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running Windows PowerShell cmdlets.
  • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).
  • Add memberships that are required beyond the minimums above.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.

  1. From the Windows PowerShell command prompt, type the following:

    New-SPWebApplication –name “ClassicAuthApp” –Port 100 –ApplicationPool
    “ClassicAuthAppPool”     –ApplicationPoolAccount (Get-SPManagedAccount
    “    <domainname>\<user>“)

    Where:

  • <domainname>\<user> is the domain to which the server belongs and the name of the user account.
  1. Attach the two existing SharePoint 2010 Products content databases to the new SharePoint 2013 classic-mode web application. Verify that the content databases work correctly after you have attached them. For more information, see Attach or detach content databases in SharePoint 2013.

    Note:

After migration has successfully completed, you might find a user who has not been migrated listed in the ULS log. Determine if the user still exists in your Active Directory domain, and then:

  • If the user does not exist in your Active Directory domain, assign someone else as the site owner and designate the user as deleted in the UserInfo table. To designate a user as deleted, change the tp_deleted value in the UserInfo table for that user to 1.
  • If the user does exist in your Active Directory domain, run the migration procedure again.

For more information, see New-SPWebApplication and Get-SPManagedAccount.

    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.

 

 

  1. Verify that the user account that performs this procedure is a site collection administrator.
  2. On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection health checks.
  3. On the Run site collection health checks page, click Start checks.

    A report lists all checked issues and issues that you should resolve.

  4. Resolve all issues, and then click Try it again to verify that you fixed them.

  • Run the site collection pre-upgrade health checks by using Windows PowerShell

    Farm administrators can use the following Windows PowerShell cmdlets to run the site collection health checks and to repair issues: Test-SPSite Repair-SPSite.

    To run the site collection health checks in test mode by using Windows PowerShell

  1. Verify that you have the following memberships:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Test-SPSite -Identity <SiteURL> [-Rule <RuleID>]

    Where:

  • <SiteURL> is URL for the site collection you want to check.
  • <RuleID> is ID for a specific rule that you want to run.

To run the site collection health checks in repair mode by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
  • Either a site collection administrator or be granted full control (for repair mode) for the web application by policy. For more information about permission policies for web applications, see Manage permission policies for a web application (SharePoint Server 2010).

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Repair-SPSite -Identity <SiteURL> [-Rule <RuleID>]

    Where:

  • <SiteURL> is URL for the site collection you want to repair.
  • <RuleID> is ID for a specific rule that you want to run.
  1. Run the site collection health checks to verify the site is ready to upgrade. For more information, see Run site collection health checks in SharePoint 2013.
  2. Create an upgrade evaluation site to preview the differences between versions. (Optional)
  3. Upgrade the site collection.
  4. Verify that upgrade was successful and the site works as expected. For more information, see Review site collections upgraded to SharePoint 2013.

This article discusses the second and third steps, and includes procedures for performing these tasks from Site Settings. For information about using Windows PowerShell cmdlets to upgrade sites from the command line, see Manage site collection upgrades to SharePoint 2013.

Upgrade step 2: Request evaluation site collection and Step 3: Upgrade the site



For a visual overview of the upgrade process, including site collection upgrade, see Overview of the upgrade process to SharePoint 2013. For more information about how farm administrators can control site collection upgrades, see Manage site collection upgrades to SharePoint 2013. For more conceptual information about site upgrade, including how to plan for upgrade, see Plan for site collection upgrades in SharePoint 2013.

    Important:

If you upgrade from SharePoint Server 2010 to SharePoint Server 2013, there are special considerations for My Sites. (My Sites are not available in SharePoint Foundation 2013.) Make sure that you upgrade the My Site Host site collection before you allow users to access their individual My Sites in SharePoint Server 2013. This makes sure that the server software and database changes are complete so that users can upgrade their individual My Sites successfully.

A user can upgrade his or her My Site by following the steps to upgrade a site collection later in this article, or a farm administrator can upgrade My Sites by using Windows PowerShell.

    Note:

Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources:

  1. Verify that the user account that performs this procedure is a site collection administrator.
  2. On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade.
  3. On the Step up to SharePoint 2013 page, click Try a demo upgrade.

    This option starts the process of generating an upgrade evaluation site collection.

  4. In the Create Upgrade Evaluation Site Collection box, click Create Upgrade Evaluation Site Collection.

    A box opens and informs you that a demo site request was received.

  5. Click Close to close the box.

    You will receive an e-mail message when the upgrade evaluation is available. The e-mail message will contain a link to the site collection. Review the site and confirm that your site collection will look and behave as expected in the new user interface.

After you have reviewed the upgrade evaluation and made any necessary changes in your original site based on your evaluation, you can upgrade your site collection.

Farm administrators can use Windows PowerShell to request an upgrade evaluation site collection. For more information, see Manage site collection upgrades to SharePoint 2013.

  1. Verify that the user account that performs this procedure is a site collection administrator.
  2. On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade.
  3. On the Site Collection Upgrade page, click Upgrade this Site Collection.

    This option starts the process of upgrading your site collection. A box opens to verify that you want to start the process.

  4. Click I’m ready to start the actual upgrade.

    Note:

The site collection health checks are run automatically in repair mode before the upgrade starts. The results from the health checks are included in the upgrade log for the site collection. If there is an error, you must address it before you can continue to upgrade.

The upgrade starts, and the Upgrade status page for the site collection is displayed. This page automatically updates while the upgrade is in progress and displays information about the process, such as the following:

  • Errors or warnings
  • When the upgrade started
  • Where you can find the upgrade log file

    After the upgrade is complete, the Upgrade status page is displayed in the new user interface with the message, Upgrade Completed Successfully.

  1. Click Let’s see the new site to go to the home page.

Farm administrators can use Windows PowerShell to upgrade a site collection. For more information, see Manage site collection upgrades to SharePoint 2013.

  • Verification

    To verify that upgrade has succeeded, check the Upgrade status page for the site collection.

    • View upgrade status in Site Settings

    Site collection administrators can view the Upgrade Status page in Site Settings to verify that upgrade has succeeded for a site collection.

    To view upgrade status in Site Settings

  1. Verify that the user account that performs this procedure is a site collection administrator.
  2. On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade.
  3. On the Site Collection Upgrade page, click Review Site Collection Upgrade Status.

    The Upgrade Status page for the site collection is displayed.

Farm administrators can use Windows PowerShell to view site collection upgrade status. For more information, see Manage site collection upgrades to SharePoint 2013.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following commands to view the upgrade notification settings for a web application:

    $wa=Get-SPWebApplication <URL>
    $wa.UpgradeReminderDelay
    $wa.UpgradeMaintenanceLink

    Where:

  • <URL> is URL for the web application that you want to check.

    This command returns the Upgrade reminder delay setting for the specified web application.

  1. At the Windows PowerShell command prompt, type the following command to view the self-service upgrade setting for a site collection:

    $site=Get-SPSite <URL>
    $wa.AllowSelfServiceUpgrade

    Where:

  • <URL> is URL for the site collection that you want to affect.

For more information, see Get-SPWebApplication and Get-SPSite.

To change the upgrade notification and self-service upgrade settings for a web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command to change the upgrade notification settings for a web application:

    $wa=Get-SPWebApplication <URL>
    $wa.UpgradeReminderDelay=    <Value>
    $wa.UpgradeMaintenanceLink=’    <LinkURL>‘

    Where:

  • <URL> is URL for the web application that you want to affect.
  • <Value> is the numeric value that you want to set for the delay (for example, 10 for 10 days).
  • <LinkURL> is a link where the user can find more information.
  1. At the Windows PowerShell command prompt, type the following command to change the self-service upgrade setting for a site collection:

    $site=Get-SPSite <URL>
    $wa.AllowSelfServiceUpgrade=    <Value>

    Where:

  • <URL> is URL for the site collection that you want to affect.
  • <Value> is either ‘true’ to allow site collection administrators to upgrade the site, or ‘false’ to not show them the notification and not allow them to upgrade.

For more information, see Get-SPWebApplication and Get-SPSite.

  • Control the compatibility range for site creation modes

    You can control which mode (2010 or 2013, or both) can be used when a user creates a site collection. The CompatibilityRange property on a web application controls the site modes available for a web application. You can view or change the settings for CompatibilityRange by using Windows PowerShell.

    To view the compatibility range for site creation modes for a web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following commands to view the compatibility range settings for a web application:

    $wa=Get-SPWebApplication <URL>
    # Stores the web application at that URL as a variable
    $wa.CompatibilityRange
    # Returns the CompatibilityRange for the specified web application

    Where:

  • <URL> is URL for the web application that you want to check.

    This command returns the compatibility range for the specified web application. For example:

    MaxCompatibilityLevel MinCompatibilityLevel  DefaultCompatibilityLevel  Singular
    ———————      ———————  ————————-   ——–
            
           15                    14                   
          15   
      False

  1. At the Windows PowerShell command prompt, type the following commands to view the maximum, minimum, and default settings for a specific range:

    [Microsoft.SharePoint.SPCompatibilityRange]::<RangeName>

    Where:

  • RangeName is one of the following values: OldVersions, NewVersion, AllVersions.

    This command returns the compatibility range for the specified value. For example, for NewVersion:

    MaxCompatibilityLevel MinCompatibilityLevel  DefaultCompatibilityLevel  Singular
    ——————— ———————      ————————-   ——–
                   15    
                  15                   
          15   
      True

For more information, see Get-SPWebApplication.

To change compatibility range for site creation modes for a web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command to change the compatibility range settings to a specific range:

    $wa=Get-SPWebApplication <URL>
    # Stores the web application at that URL as a variable
    $wa.CompatibilityRange = [Microsoft.SharePoint.SPCompatibilityRange]::    <RangeName>
    # Specifies which range to use
    $wa.Update()
    # Updates the CompatibilityRange setting to use only the range you specified
    $wa.CompatibilityRange
    # Returns the new CompatibilityRange for the web application

    Where:

  • <URL> is URL for the web application that you want to change.
  • RangeName is one of the following values: OldVersions, NewVersion, AllVersions.
  1. At the Windows PowerShell command prompt, type the following command to change the values for the CompatibilityRange manually:

    $wa=Get-SPWebApplication <URL>
    # Stores the web application at that URL as a variable
    $range = New-Object Microsoft.SharePoint.SPCompatibilityRange(    <Integer>,<Integer>)
    # Creates a new compatibility range from     <Integer> to <Integer>
    $wa.CompatibilityRange = $range
    # Specifies which range to use
    $wa.Update()
    #Updates the CompatibilityRange setting to use only the range you specified with $range
    $wa.CompatibilityRange
    # Returns the new CompatibilityRange for the web application

    Where:

  • <URL> is URL for the web application that you want to change.
  • Integer is a number to use as the minimum or maximum value. For example, (14,15) would set the MinCompatibilityLevel to 14 (2010) and the MaxCompatibilityLevel to 15 (2013). The DefaultCompatibilityLevel is automatically set to the lower of the MaxCompatibilityLevel and the current major version (for example, 15).

    This command sets and then returns the range that you specified. For example:

    MaxCompatibilityLevel  MinCompatibilityLevel  DefaultCompatibilityLevel  Singular
    ———————       ———————  ————————-   ——–
                    15                     14                   
          15   
      False

For more information, see Get-SPWebApplication.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. To view all site collections in the queue for a content database, at the Windows PowerShell command prompt, type the following command:

    Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress -ShowCompleted -ShowFailed |ft

    Where:

  • <DatabaseName> is name of the database that you want to check. You can also use the GUID for the database instead of the name.

    For more information, see Get-SPSiteUpgradeSessionInfo.

  1. To see all sites that are currently being upgraded, at the Windows PowerShell command prompt, type the following command:

    Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress

    Where:

  • <DatabaseName> is name of the database that you want to check. You can also use the GUID for the database instead of the name.

    For more information, see Get-SPSiteUpgradeSessionInfo.

  1. To see whether a particular site is in the queue, at the Windows PowerShell command prompt, type the following command:

    Get-SPSiteUpgradeSessionInfo -Site <http://site&gt;

    Where:

  1. To add a site collection to the upgrade queue, at the Windows PowerShell command prompt, type the following command:

    Upgrade-SPSite <http://site&gt; -VersionUpgrade -QueueOnly

    Where:

  1. To remove a site collection from the upgrade queue, at the Windows PowerShell command prompt, type the following command:

    Remove-SPSiteUpgradeSessionInfo -Identity <URL>

    Where:

  • Control site throttle settings for upgrade to SharePoint 2013

    You can view and change the upgrade throttle settings for a content database and web application by viewing and setting the SPContentDatabase.ConcurrentSiteUpgradeSessionLimit and SPWebApplication.SiteUpgradeThrottleSettings properties. For descriptions of the properties that control throttle levels and the default values, see Plan for site collection upgrades in SharePoint 2013.

    For more information about web application properties, see SPWebApplication Properties. For more information about content database properties, see SPContentDatabase Properties.

    The following procedure provides steps to view upgrade throttling settings for a web application.

    To view the upgrade throttle settings for a web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    $wa = Get-SPWebApplication <URL>
    $wa.SiteUpgradeThrottleSettings

    Where:

  • <URL> is URL for the web application that you want to check.

    This command returns the set of throttling settings for the specified web application. For example:

    AppPoolConcurrentUpgradeSessionLimit : 5
    UsageStorageLimit : 10
    SubwebCountLimit : 10
    Name :
    TypeName : Microsoft.SharePoint.Administration.SPSiteUpgradeThrottleSettings
    DisplayName :
    Id : ca76dda0-7050-4c6b-a126-05917da39f8a
    Status : Online
    Parent : SPWebApplication Name=SharePoint – 80
    Version : 8222
    Properties : {}
    Farm : SPFarm Name=SharePoint_ConfigUpgradedPersistedProperties : {}

For more information, see Get-SPWebApplication.

You can change the upgrade throttle settings for a web application. The following procedure provides steps to change the upgrade throttling settings for a web application.

To change the upgrade throttle settings for a web application by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    $wa=Get-SPWebApplication <URL>
    $wa.SiteUpgradeThrottleSettings.AppPoolConcurrentUpgradeSessionLimit=    <Value>
    $wa.SiteUpgradeThrottleSettings.UsageStorageLimit=    <Value>
    $wa.SiteUpgradeThrottleSettings.SubwebCountLimit=    <Value>

    Where:

  • <URL> is URL for the web applications that you want to affect.
  • Value is the numeric value that you want to set for that limit (for example, 8).

    This command changes the throttling settings for a web application to the value that you supply.

For more information, see Set-SPWebApplication.

The following procedure provides steps to view upgrade throttling settings for a content database.

To view the throttle settings for a content database by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    $db = Get-SPContentDatabase <DatabaseName>

    # Stores the database name as a variable to use in the next command

    $db.ConcurrentSiteUpgradeSessionLimit
    # Returns the value for the limit for that database

    Where:

  • <DatabaseName> is name of the database that you want to check. You can also use the GUID for the database instead of the name.

    This command returns the set of throttling settings for the specified content database.

For more information, see Get-SPContentDatabase.

You can change the upgrade throttle settings for a content database. The following procedure provides steps to change the upgrade throttling settings for a content database.

To change the throttle settings for a content database by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following commands:

    $db = Set-SPContentDatabase <DatabaseName>
    # Stores the database name as a variable to use in the next command

    $db.ConcurrentSiteUpgradeSessionLimit=<value>
    # Changes the limit to the value you specify.

    Where:

  • <DatabaseName> is name of the database that you want to affect. You can also use the GUID for the database instead of the name.
  • <value> is a numeric value to set the property to, such as 9.

    This command changes the throttling settings for the specified content database to the value that you supply.

For more information, see Set-SPContentDatabase.

  1. Verify that you have the following memberships:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Request-SPUpgradeEvaluationSiteCollection -identity URL to site

    Where:

  • URL to site is the URL to a site collection in 2010 mode.

For more information, see Request-SPUpgradeEvaluationSite.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Upgrade-SPSite <http://site&gt; -VersionUpgrade [-Unthrottled]

    Where:

  • <http://site&gt; is the URL for the site collection.
  • Add the option -Unthrottled option to skip the site collection upgrade queue and start the upgrade immediately.

This cmdlet upgrades the specific site collection to 2013 mode. For more information, see Upgrade-SPSite.

To upgrade all site collections in a database, use Windows PowerShell. However, because sites can continue to run in 2010 mode in the SharePoint 2013 environment, this is not a necessary procedure for most environments. If you do choose to upgrade all site collections immediately, site collection owners do not have an opportunity to use an upgrade evaluation site to preview the new user interface or change their original site before upgrading. We do not recommend that you upgrade all site collections immediately as part of your initial upgrade. However, you might want to upgrade all site collections after some time has passed and all customizations were verified in 2013 mode.

To upgrade all site collections in a database by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Get-SPSite -ContentDatabase <DBName> -Limit All | Upgrade-SPSite -VersionUpgrade -QueueOnly

    Where:

  • <DBName> is the name of the content database for which you want to upgrade all site collections.

    The -QueueOnly parameter adds the site collections to the upgrade queue. This allows the timer job to perform parallel upgrades when it is possible and can save time. The sites are upgraded in the order in which they are added to the queue.

This cmdlet upgrades all site collections in the specific content database to 2013 mode.

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Get-SPSiteUpgradeSessionInfo -Site <http://site&gt;

    Where:

  • <http://site&gt; is the URL of the site collection.

    This cmdlet returns the upgrade status for the specified site collection together with information about the upgrade session and a link to the log files for more information. For more information, see Get-SPSiteUpgradeSessionInfo.

  1. Or, you can use the following command to view the information about a specific site collection upgrade:

    $sc = Get-SPSite <http://site&gt;
    # Sets a variable for the site collection
    $sc.CompatibilityLevel
    # Returns the compatibility level for the site collection (either 14 or 15 for 2010 or 2013 mode)
    $sc.UpgradeInfo
    # Returns the upgrade information for the site collection

    Where:

  • <http://site&gt; is the URL of the site collection.

    This command returns the compatibility level and upgrade information (such as a pointer to the log file) for the specified site collection. If the compatibility level is “15,” then it has been upgraded to 2013 mode. For more information, see Get-SPSite.

To view upgrade status for a single database by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Windows PowerShell 

    Get-SPSiteUpgradeSessionInfo –ContentDatabase <DatabaseName> -ShowInProgress -ShowCompleted -ShowFailed

    Where:

  • <DatabaseName> is the name of the database that you want to check.

    This cmdlet returns any site collections that have an upgrade in progress, completed, or failed and lists their status, plus a link to the log files for more information. You can use only one parameter to find only in progress, completed, or failed upgrades. For more information, see Get-SPSiteUpgradeSessionInfo.

To view upgrade status for all site collections by using Windows PowerShell

  1. Verify that you have the following memberships:
  • securityadmin fixed server role on the SQL Server instance.
  • db_owner fixed database role on all databases that are to be updated.
  • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

        Note:

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

  1. On the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell.
  4. At the Windows PowerShell command prompt, type the following command:

    Get-SPSite -Limit All

This cmdlet returns the URL for all site collections in the environment and the compatibility level (14 or 15) for each site collection.

Discover more from Escape Business Solutions

Subscribe to get the latest posts sent to your email.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.