| Service | Microsoft Docs article | Related commit history on GitHub | Change details |
|---|---|---|---|
| SharePoint | Back Up Databases To Snapshots | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/back-up-databases-to-snapshots.md | If you want to back up databases to snapshots, you must use SQL Server tools. Th [Database Snapshots (SQL Server)](/sql/relational-databases/databases/database-snapshots-sql-server?viewFallbackFrom=sql-server-2014) -[Database Snapshots with AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/database-snapshots-with-always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014) +[Database Snapshots with Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/database-snapshots-with-always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014) |
| SharePoint | Best Practices For Sql Server In A Sharepoint Server Farm | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/best-practices-for-sql-server-in-a-sharepoint-server-farm.md | For guidance about highly available databases that use mirroring, see [Database ### SQL Server Failover Clustering and Always On Availability Groups -SQL Server 2012 introduced the AlwaysOn Availability Groups feature. This feature is a high availability and disaster recovery solution that's an alternative to database mirroring and log shipping solutions. AlwaysOn Availability Groups now support up to nine availability replicas. +SQL Server 2012 introduced the Always On Availability Groups feature. This feature is a high availability and disaster recovery solution that's an alternative to database mirroring and log shipping solutions. Always On Availability Groups now support up to nine availability replicas. > [!NOTE] > Database mirroring will be deprecated in future versions of SQL Server. We recommend using Always On Availability Groups. -AlwaysOn Availability Groups require a Windows Server Failover Clustering (WSFC) cluster. A WSFC resource group is created for every availability group that is created. For more information, see the following resources: +Always On Availability Groups require a Windows Server Failover Clustering (WSFC) cluster. A WSFC resource group is created for every availability group that is created. For more information, see the following resources: -- [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014)+- [Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014) -- [Overview of AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server)+- [Overview of Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server) - [Failover Clustering and Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/failover-clustering-and-always-on-availability-groups-sql-server) -- [Configure SQL Server AlwaysOn Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md)+- [Configure SQL Server Always On Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md) ## Design storage for optimal throughput and manageability |
| SharePoint | Configure An Alwayson Availability Group | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/configure-an-alwayson-availability-group.md | Title: "Configure SQL Server AlwaysOn Availability Groups for SharePoint Server" + Title: "Configure SQL Server Always On Availability Groups for SharePoint Server" ms.assetid: 18fedf59-f293-4c15-953e-c42ec66fa13f description: "Learn how to create and configure a SQL Server Always On Availability Group for a SharePoint Server farm." -# Configure SQL Server AlwaysOn Availability Groups for SharePoint Server +# Configure SQL Server Always On Availability Groups for SharePoint Server [!INCLUDE[appliesto-2013-2016-2019-SUB-xxx-md](../includes/appliesto-2013-2016-2019-SUB-xxx-md.md)] For more information, see [Always On Availability Groups (SQL Server)](/sql/data The primary replica makes the availability databases available for read-write connections from clients and sends transaction log records for each primary database to every secondary replica. Each secondary replica applies transaction log records to its secondary databases. -All replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode. For more information about synchronous and asynchronous commit mode, see [Availability Modes (AlwaysOn Availability Groups)](/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups). +All replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode. For more information about synchronous and asynchronous commit mode, see [Availability Modes (Always On Availability Groups)](/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups). > [!NOTE] > Database issues, such as a database becoming suspect due to a loss of a data file, deletion of a database, or corruption of a transaction log do not cause failovers. Read the following articles to learn important concepts about SQL Server Always On technology: -- For details about the benefits of Always On Availability Groups and an overview of Always On Availability Groups terms, see [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server).+- For details about the benefits of Always On Availability Groups and an overview of Always On Availability Groups terms, see [Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server). - For detailed information about prerequisites, see [Prereqs, Restrictions, Recommendations - Always On Availability Groups](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability). Read the following articles to learn important concepts about SQL Server Always To create and use SQL Server Always On Availability Groups, you have to install both SQL Server versions on a Windows Server Failover Clustering (WSFC) cluster. For more information, see [Windows Server Failover Clustering (WSFC) with SQL Server](/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server) and for SQL Server 2016 and 2017, [Windows Server Failover Clustering (WSFC) with SQL Server](/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server). -To create and use SQL Server AlwaysOn Availability Groups, you have to install SQL Server on a Windows Server Failover Clustering (WSFC) cluster. +To create and use SQL Server Always On Availability Groups, you have to install SQL Server on a Windows Server Failover Clustering (WSFC) cluster. Although configuring a WSFC cluster is out of the scope for this article, you should be aware of the following requirements before you install and configure a cluster: To prepare the environment, complete the following tasks: 1. Install SQL Server 2012 prerequisites on each cluster node. - For more information, see [Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)](/previous-versions/sql/sql-server-2012/ff878487(v=sql.110)). + For more information, see [Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)](/previous-versions/sql/sql-server-2012/ff878487(v=sql.110)). 2. Install SQL Server on each cluster node. Use the following procedure to install SQL Server 2014 (SP1). 1. Install SQL Server 2014 (SP1) prerequisites on each cluster node. - For more information, see [Hardware and Software Requirements for Installing SQL Server 2014](/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server) and [Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability). + For more information, see [Hardware and Software Requirements for Installing SQL Server 2014](/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server) and [Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability). 2. Install SQL Server on each cluster node. You must enable Always On for each database server in the cluster. 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 Always On Availability Groups, and then click **Properties**. -4. Select the **AlwaysOn High Availability** tab. +4. Select the **Always On High Availability** tab. -5. Select the **Enable AlwaysOn Availability Groups** check box, and then click **OK**. +5. Select the **Enable Always On 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 Always On for SQL Server on the other cluster nodes. -For more information, see [Enable and Disable AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server). +For more information, see [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server). ### Create and configure the availability group <a name="proc3"> </a> Depending on the SQL Server 2014 (SP1), SQL Server 2016/2017, or SQL Server 2012 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]-> A database must be a user database in order to add it to an availability group. System databases can't 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)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability#PrerequisitesForAGs) and see [Creation and Configuration of Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/creation-and-configuration-of-availability-groups-sql-server). +> A database must be a user database in order to add it to an availability group. System databases can't belong to an availability group. For more information, see the "Availability Database Prerequisites and Restrictions" section of [Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability#PrerequisitesForAGs) and see [Creation and Configuration of Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/creation-and-configuration-of-availability-groups-sql-server). If there are no user databases 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. The following table shows the information that you have to provide for each repl > SharePoint Server does not leverage read-only replicas. It will only leverage the primary replica in the availability group. > [!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)](/sql/database-engine/availability-groups/windows/specify-endpoint-url-adding-or-modifying-availability-replica) and [Active Secondaries: Backup on Secondary Replicas (AlwaysOn Availability Groups)](/sql/database-engine/availability-groups/windows/active-secondaries-backup-on-secondary-replicas-always-on-availability-groups). +> 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)](/sql/database-engine/availability-groups/windows/specify-endpoint-url-adding-or-modifying-availability-replica) and [Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups)](/sql/database-engine/availability-groups/windows/active-secondaries-backup-on-secondary-replicas-always-on-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)](/sql/database-engine/availability-groups/windows/select-initial-data-synchronization-page-always-on-availability-group-wizards). +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 (Always On Availability Group Wizards)](/sql/database-engine/availability-groups/windows/select-initial-data-synchronization-page-always-on-availability-group-wizards). A network share must exist and must be accessed by all the nodes in the Always On configuration to do the initial data synchronization between all the cluster nodes that host a replica. For more information, see [Network Shares Extension](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc730672(v=ws.11)) and [Storage](/windows-server/storage/storage). Use the following procedure to create an availability group on the primary repli 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**. +3. To start the New Availability Group Wizard, right-click **Always On 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. The following new performance objects are available to monitor an Always On envi **Health and capacity** -For general health monitoring you can use the Availability Groups Dashboard to obtain the health of the availability groups in the system. For more information, see [AlwaysOn Policies for Operational Issues with AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-policies-for-operational-issues-always-on-availability) for SQL Server 2014 (SP1) and [Always On Policies for Operational Issues - Always On Availability](/sql/database-engine/availability-groups/windows/always-on-policies-for-operational-issues-always-on-availability) for SQL Server 2016 and SQL Server 2017. For more information about SQL Server 2012, see the following: +For general health monitoring you can use the Availability Groups Dashboard to obtain the health of the availability groups in the system. For more information, see [Always On Policies for Operational Issues with Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-policies-for-operational-issues-always-on-availability) for SQL Server 2014 (SP1) and [Always On Policies for Operational Issues - Always On Availability](/sql/database-engine/availability-groups/windows/always-on-policies-for-operational-issues-always-on-availability) for SQL Server 2016 and SQL Server 2017. For more information about SQL Server 2012, see the following: -- [The AlwaysOn Health Model Part 1 -- Health Model Architecture](https://go.microsoft.com/fwlink/p/?LinkId=245945)+- [The Always On Health Model Part 1 -- Health Model Architecture](https://go.microsoft.com/fwlink/p/?LinkId=245945) -- [The AlwaysOn Health Model Part 2 -- Extending the Health Model](https://go.microsoft.com/fwlink/p/?LinkId=245946)+- [The Always On Health Model Part 2 -- Extending the Health Model](https://go.microsoft.com/fwlink/p/?LinkId=245946) You can also use Transact-SQL to monitor availability groups by using the set of catalog and dynamic management views that are provided for Always On Availability Groups. For more information, see [Monitor Availability Groups (Transact-SQL)](/sql/database-engine/availability-groups/windows/monitor-availability-groups-transact-sql) for SQL Server 2014 (SP1) and [Monitor Availability Groups (Transact-SQL)](/sql/database-engine/availability-groups/windows/monitor-availability-groups-transact-sql) for SQL Server 2016 and SQL Server 2017. You can also use Transact-SQL to monitor availability groups by using the set of [Install SharePoint Server](../install/install.md) #### Other Resources -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) |
| SharePoint | Configure Log Shipping | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/configure-log-shipping.md | In the illustration: - DFSR copies files from the file share in the on-premises environment to the file share in the Azure environment. In a WAN scenario, DFSR is more efficient than shipping the logs directly to the secondary server in Azure. -- Log shipping replays the logs from the file share in the Azure environment to the primary replica in the SQL Server AlwaysOn availability group in the recovery environment.+- Log shipping replays the logs from the file share in the Azure environment to the primary replica in the SQL Server Always On availability group in the recovery environment. - Log-shipped databases are not attached to the SharePoint Server farm until a recovery exercise is performed. The following diagram shows the seven phases that the complete SharePoint Server ## Using log shipping for disaster recovery <a name="Use"> </a> -Log shipping enables you to automatically send transaction log files for databases from a primary database server instance to a secondary database server instance. In our on-premises test environment, we use AlwaysOn availability groups with two replicas for high availability. We configured log shipping on both replicas. Each replica must be able to ship transaction logs. Only the replica that is active and owns the database can ship logs. However, if a failover event occurred and the secondary replica became active, it would have to ship transaction logs instead of the failed replica. +Log shipping enables you to automatically send transaction log files for databases from a primary database server instance to a secondary database server instance. In our on-premises test environment, we use Always On availability groups with two replicas for high availability. We configured log shipping on both replicas. Each replica must be able to ship transaction logs. Only the replica that is active and owns the database can ship logs. However, if a failover event occurred and the secondary replica became active, it would have to ship transaction logs instead of the failed replica. After the transaction logs are received in the Azure environment, they are restored, one at a time, to each SharePoint database on the secondary database server. For more information about our test environment, see [Microsoft proof of concept environment](/office365/enterprise/sharepoint-server-2013-disaster-recovery-in-microsoft-azure#POC). The log-shipping infrastructure used for our disaster-recovery solution environm  -The previous diagram shows the log shipping infrastructure and data flow. The diagram shows the SQL Server database servers and the file servers in the production farm and the Azure recovery farm. These farms are nearly identical, and each contains a primary and secondary replica for each AlwaysOn availability group. The file servers, FIL1 and AZ-FIL1, are configured the same, including the number of hard disks and disk sizes. Additional servers in the farm are not shown. +The previous diagram shows the log shipping infrastructure and data flow. The diagram shows the SQL Server database servers and the file servers in the production farm and the Azure recovery farm. These farms are nearly identical, and each contains a primary and secondary replica for each Always On availability group. The file servers, FIL1 and AZ-FIL1, are configured the same, including the number of hard disks and disk sizes. Additional servers in the farm are not shown. To provide high availability, each replica in an availability group stores a backup (full, differential, and transaction logs) of the other replica. The required steps to configure, run, and validate log shipping are condensed an #### Concepts -[Configure SQL Server AlwaysOn Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md) +[Configure SQL Server Always On Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md) #### Other Resources [About Log Shipping (SQL Server)](/sql/database-engine/log-shipping/about-log-shipping-sql-server) |
| SharePoint | Corporate Portal And Extranet Sites Design Samples | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/corporate-portal-and-extranet-sites-design-samples.md | Each server farm in the design sample is composed of six servers with the follow - Two application servers -- Two database servers with SQL Server installed and configured to support SQL Server clustering, mirroring, or AlwaysOn. AlwaysOn requires SQL Server 2012.+- Two database servers with SQL Server installed and configured to support SQL Server clustering, mirroring, or Always On. Always On requires SQL Server 2012. The concept of front-end and application server is different in SharePoint Server 2016, see [Overview of MinRole Server Roles in SharePoint Server](../install/overview-of-minrole-server-roles-in-sharepoint-server.md) |
| SharePoint | Deploying Sharepoint Server With Sql Server Alwayson Availability Groups In | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md | Title: "Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure" + Title: "Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure" ms.assetid: af7cf3e7-94b1-4a5d-8cb9-80c5a0b397f2 description: "Get an overview of deploying SharePoint Server in Microsoft Azure with links to each phase of the deployment." -# Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure +# Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure [!INCLUDE[appliesto-xxx-2016-2019-SUB-xxx-md](../includes/appliesto-xxx-2016-2019-SUB-xxx-md.md)] You deploy this SharePoint Server farm with the following phases: - [SharePoint Intranet Farm in Azure Phase 5: Create the availability group and add the SharePoint databases](./sharepoint-intranet-farm-in-azure-phase-5-create-the-availability-group-and-add.md) - Prepare databases and create a SQL Server AlwaysOn availability group. + Prepare databases and create a SQL Server Always On availability group. This configuration is a prescriptive, phase-by-phase guide for a predefined architecture to create a highly available intranet SharePoint Server farm in Azure infrastructure services. Keep the following in mind: |
| SharePoint | Designing A Sharepoint Server Farm In Azure | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/designing-a-sharepoint-server-farm-in-azure.md | Microsoft supports the following SharePoint Server deployment scenarios on Azure - Non-production farms, such as those used for dev/test environments or for proof-of-concept -- As a disaster recovery target using log shipping, SQL Server AlwaysOn Availability Groups, or Azure Site Recovery+- As a disaster recovery target using log shipping, SQL Server Always On Availability Groups, or Azure Site Recovery - Production farms, using Azure premium storage for servers running the search role For the virtual machines of the SharePoint farm, do the following: - Use a minimum of two VMs for each server role. -- If you are using SQL Server AlwaysOn Availability Groups and plan to use only two SQL servers, you must also use minority node server for the cluster.+- If you are using SQL Server Always On Availability Groups and plan to use only two SQL servers, you must also use minority node server for the cluster. - Place the network interfaces and the VMs in the resource group for the server role. For the VMs, fill in the following table before creating them, using as many row If you are ready to create a proof-of-concept or dev/test configuration of an intranet SharePoint Server farm in Azure, see [Intranet SharePoint Server in Azure dev/test environment](intranet-sharepoint-server-in-azure-dev-test-environment.md). -If you are ready to deploy a production-ready, high availability SharePoint Server farm in Azure, see [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md). +If you are ready to deploy a production-ready, high availability SharePoint Server farm in Azure, see [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md). ## See also |
| SharePoint | Intranet Sharepoint Server In Azure Dev Test Environment | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/intranet-sharepoint-server-in-azure-dev-test-environment.md | Your emulated intranet SharePoint Server farm running in Azure is now ready for When you are ready to design a production SharePoint Server farm in Azure, see [Designing a SharePoint Server farm in Azure](designing-a-sharepoint-server-farm-in-azure.md). -When you are ready to deploy a production-ready, high availability SharePoint Server farm in Azure, see [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md). +When you are ready to deploy a production-ready, high availability SharePoint Server farm in Azure, see [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md). ## See also |
| SharePoint | Move All Databases | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/move-all-databases.md | Before you begin this operation, review the steps in this process: If you do not want to use SQL Server connection aliases use one of the following procedures to update the database connections for your SharePoint Server farm. - - [Scenario 1](#PS): Use this procedure to update the database connections if you use SharePoint Server and SQL Server AlwaysOn Availability Groups for high availability or disaster recovery. + - [Scenario 1](#PS): Use this procedure to update the database connections if you use SharePoint Server and SQL Server Always On Availability Groups for high availability or disaster recovery. - [Scenario 2](#MAN): Use this procedure if you must use manual steps or if you move the databases from a SharePoint Server Single-server farm role installation to a new Single-server farm role installation. The version of the existing SharePoint Server and Windows Server must also suppo The following procedures provide methods to connect to the new SQL Server instance or update the database connections. Use the procedure that works best for your SharePoint Server farm environment. > [!IMPORTANT]-> If you're using SharePoint Server and SQL Server AlwaysOn Availability Groups before moving the databases, you should point to the AG Listner. If you're moving from a single-server farm to an AlwayOn Availability Group then you should use the cliconfg.exe. +> If you're using SharePoint Server and SQL Server Always On Availability Groups before moving the databases, you should point to the AG Listner. If you're moving from a single-server farm to an AlwayOn Availability Group then you should use the cliconfg.exe. ### To point the web application to the new database server by setting up SQL Server connection aliases You can use these Microsoft PowerShell cmdlets to deploy, manage, and remove ava - **Get-AvailabilityGroupStatus** -Use the following procedure to update the database connections if you use SharePoint Server and SQL Server AlwaysOn Availability Groups for high availability or disaster recovery. +Use the following procedure to update the database connections if you use SharePoint Server and SQL Server Always On Availability Groups for high availability or disaster recovery. <a name="PS"></a>**Scenario 1: To update the database connections by using PowerShell** Where \<GUID\> is the ID of the database that you move. $db.ChangeDatabaseInstance("<DBServerName>") ``` -Where \<DBServerName\> is the name or alias of the new SQL Server or is the AlwaysOn Availability Group listener DNS name. +Where \<DBServerName\> is the name or alias of the new SQL Server or is the Always On Availability Group listener DNS name. ``` $db.Update() |
| SharePoint | Overview Of Sql Server In A Sharepoint Server 2013 Environment | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/overview-of-sql-server-in-a-sharepoint-server-2013-environment.md | SQL Server 2012 with SP1 and SQL Server 2014 provide business intelligence solut ### High Availability Solutions <a name="HA"> </a> -We recommend AlwaysOn Availability Groups for high availability in SQL Server 2012 Reporting Services and SQL Server 2014 Reporting Services. Other high availability solutions are AlwaysOn Failover Cluster Instances, database mirroring, and log shipping. Both AlwaysOn Availability Groups and Failover Cluster Instances solutions require and use Windows Server Failover Clustering (WSFC). +We recommend Always On Availability Groups for high availability in SQL Server 2012 Reporting Services and SQL Server 2014 Reporting Services. Other high availability solutions are Always On Failover Cluster Instances, database mirroring, and log shipping. Both Always On Availability Groups and Failover Cluster Instances solutions require and use Windows Server Failover Clustering (WSFC). > [!NOTE]-> We recommend that you use AlwaysOn Availability Groups instead of database mirroring for your high availability solution with SQL Server 2012 or SQL Server 2014 and SharePoint Server 2013. For more information, see [Overview of SQL Server High-Availability Solutions](/sql/database-engine/sql-server-business-continuity-dr). +> We recommend that you use Always On Availability Groups instead of database mirroring for your high availability solution with SQL Server 2012 or SQL Server 2014 and SharePoint Server 2013. For more information, see [Overview of SQL Server High-Availability Solutions](/sql/database-engine/sql-server-business-continuity-dr). -For more information, see [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server), and [Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability?view=sql-server-2017&preserve-view=true). +For more information, see [Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server), and [Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability?view=sql-server-2017&preserve-view=true). ### Reporting Services SharePoint mode <a name="RSsp"> </a> |
| SharePoint | Overview Of Sql Server In Sharepoint Server 2016 And 2019 Environments | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/overview-of-sql-server-in-sharepoint-server-2016-and-2019-environments.md | For more information, see [Features Supported by the Editions of SQL Server 2014 ### High Availability Solutions <a name="HA"> </a> -We recommend AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances for high availability in SQL Server 2014 Reporting Services (SP1). Other high availability solutions are database mirroring, and log shipping. Both AlwaysOn Availability Groups and Failover Cluster Instances solutions require and use Windows Server Failover Clustering (WSFC). +We recommend Always On Availability Groups and Always On Failover Cluster Instances for high availability in SQL Server 2014 Reporting Services (SP1). Other high availability solutions are database mirroring, and log shipping. Both Always On Availability Groups and Failover Cluster Instances solutions require and use Windows Server Failover Clustering (WSFC). > [!NOTE]-> We recommend that you use AlwaysOn Availability Groups instead of database mirroring for your high availability solution with SQL Server 2014 (SP1), SQL Server 2016, and SQL Server 2017 RTM for SharePoint Servers 2016 and 2019. For more information, see [Overview of SQL Server High-Availability Solutions](/sql/database-engine/sql-server-business-continuity-dr?viewFallbackFrom=sql-server-2014). +> We recommend that you use Always On Availability Groups instead of database mirroring for your high availability solution with SQL Server 2014 (SP1), SQL Server 2016, and SQL Server 2017 RTM for SharePoint Servers 2016 and 2019. For more information, see [Overview of SQL Server High-Availability Solutions](/sql/database-engine/sql-server-business-continuity-dr?viewFallbackFrom=sql-server-2014). -For more information, see [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014), and [Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability).For information about high availability for SQL Server Reporting Services, see [High Availability (Reporting Services)](https://go.microsoft.com/fwlink/?LinkID=808640&clcid=0x409). +For more information, see [Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014), and [Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability).For information about high availability for SQL Server Reporting Services, see [High Availability (Reporting Services)](https://go.microsoft.com/fwlink/?LinkID=808640&clcid=0x409). #### Log Shipping |
| SharePoint | Plan For Disaster Recovery | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/plan-for-disaster-recovery.md | In a warm standby disaster recovery scenario, you create a warm standby environm **Virtual warm standby environments** -Virtualization provides a workable and cost effective option for a warm standby recovery solution. You can use Hyper-V as an in-house solution or Azure as a hosted solution to provide necessary infrastructure for recovery. For more information, see [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +Virtualization provides a workable and cost effective option for a warm standby recovery solution. You can use Hyper-V as an in-house solution or Azure as a hosted solution to provide necessary infrastructure for recovery. For more information, see [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) ### Hot standby recovery In a hot standby disaster recovery scenario, you set up a failover farm in the s > [!NOTE] > SQL Server mirroring can only be used to copy databases to a single mirror server, but you can log-ship to multiple secondary servers. - The SQL Server database mirroring feature will be removed in future versions. We recommend that you avoid using this feature in new deployments. Plan to change applications that currently use this feature. Use AlwaysOn Availability Groups instead. + The SQL Server database mirroring feature will be removed in future versions. We recommend that you avoid using this feature in new deployments. Plan to change applications that currently use this feature. Use Always On Availability Groups instead. - Service applications vary in whether they can be log-shipped to a farm. For more information, see [Service application redundancy](#ServiceAppRedundancy) later in this article. |
| SharePoint | Plan For High Availability | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/plan-for-high-availability.md | Fault tolerance is readily available for almost every hardware component in the Because the SharePoint platform and its application workloads depend on the availability and reliability of all the SharePoint databases, highly available databases are an extremely important aspect of your high availability strategy. You can use the following features as fault-tolerant solutions for SharePoint database servers and databases: -- SQL Server failover clustering (AlwaysOn Failover Cluster Instances (FCI) in SQL Server 2014 with Service Pack 1 (SP1)) and SQL Server 2012+- SQL Server failover clustering (Always On Failover Cluster Instances (FCI) in SQL Server 2014 with Service Pack 1 (SP1)) and SQL Server 2012 -- AlwaysOn Availability Groups+- Always On Availability Groups - SQL Server high-availability database mirroring -**About AlwaysOn Failover Cluster Instances and AlwaysOn Availability Groups** +**About Always On Failover Cluster Instances and Always On Availability Groups** -A failover cluster requires shared disk storage between two computers. In a two node configuration, the computers are configured as active/passive which provides a fully redundant instance of the primary node. The passive node is only brought online when the primary node fails. The shared disk is only presented to one computer at a time. This configuration typically requires the most additional hardware. In SQL Server 2014 (SP1) and SQL Server 2012, this type of cluster configuration is an AlwaysOn Failover Cluster Instance, and it is a specific way to install SQL Server. Because of the configuration requirements, you cannot take a standard SQL Server installation and easily change it to a Failover Cluster Instance. +A failover cluster requires shared disk storage between two computers. In a two node configuration, the computers are configured as active/passive which provides a fully redundant instance of the primary node. The passive node is only brought online when the primary node fails. The shared disk is only presented to one computer at a time. This configuration typically requires the most additional hardware. In SQL Server 2014 (SP1) and SQL Server 2012, this type of cluster configuration is an Always On Failover Cluster Instance, and it is a specific way to install SQL Server. Because of the configuration requirements, you cannot take a standard SQL Server installation and easily change it to a Failover Cluster Instance. -An AlwaysOn Availability Group is a different technology in SQL Server 2014 (SP1) and SQL Server 2012 (think of it as a descendant of Database Mirroring) that uses some features exposed by Windows Clustering. However, it does not require shared disk storage, and the computers in an availability group do not have to have a specialized configuration of SQL Server installed on them. After a database server is added to a Windows Cluster, it is fairly easy to enable AlwaysOn Availability Groups and then configure the availability group that you want. +An Always On Availability Group is a different technology in SQL Server 2014 (SP1) and SQL Server 2012 (think of it as a descendant of Database Mirroring) that uses some features exposed by Windows Clustering. However, it does not require shared disk storage, and the computers in an availability group do not have to have a specialized configuration of SQL Server installed on them. After a database server is added to a Windows Cluster, it is fairly easy to enable Always On Availability Groups and then configure the availability group that you want. -In summary, any server that runs SQL Server 2014 (SP1) and SQL Server 2012 Enterprise Edition can use AlwaysOn Availability Groups by joining a cluster and configuring the availability group. AlwaysOn failover clusters require special hardware and configuration steps to set up Failover Cluster Instances. Each of these technologies has its use for specific environments, and both are complementary competitors. For more information about these features, see [High Availability Solutions (SQL Server)](/sql/sql-server/failover-clusters/high-availability-solutions-sql-server). For help deciding which SQL Server availability technology to use, see [Business continuity and database recovery - SQL Server](/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-ver15). +In summary, any server that runs SQL Server 2014 (SP1) and SQL Server 2012 Enterprise Edition can use Always On Availability Groups by joining a cluster and configuring the availability group. Always On failover clusters require special hardware and configuration steps to set up Failover Cluster Instances. Each of these technologies has its use for specific environments, and both are complementary competitors. For more information about these features, see [High Availability Solutions (SQL Server)](/sql/sql-server/failover-clusters/high-availability-solutions-sql-server). For help deciding which SQL Server availability technology to use, see [Business continuity and database recovery - SQL Server](/sql/database-engine/sql-server-business-continuity-dr). > [!IMPORTANT]-> Because each SQL Server high availability option has its own features, strengths, and weaknesses, one option is not necessarily better than another. For example, in a given scenario that uses AlwaysOn Availability Groups, minimizing data lose might be better than any performance gain that AlwaysOn Failover Cluster Instances achieves. You must choose a high-availability solution that is based on your business requirements and IT infrastructure requirements. +> Because each SQL Server high availability option has its own features, strengths, and weaknesses, one option is not necessarily better than another. For example, in a given scenario that uses Always On Availability Groups, minimizing data lose might be better than any performance gain that Always On Failover Cluster Instances achieves. You must choose a high-availability solution that is based on your business requirements and IT infrastructure requirements. A determining factor in selecting a SQL Server option to use is the SharePoint databases. You must understand the characteristics of the SharePoint Server databases. Each database may have specific requirements or constraints that will determine the SQL Server fault-tolerant solution that is appropriate and fully supported in your production environment. We recommend that you review the following articles: SharePoint Server references the cluster as a whole. Therefore, failover is auto > [!NOTE] > When either a planned or unplanned failover happens, connections are dropped and must be established again when transitioning from one cluster node to another cluster node. -For detailed information about SQL Server failover clustering, see [AlwaysOn Failover Cluster Instances (SQL Server)](/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?viewFallbackFrom=sql-server-2014). +For detailed information about SQL Server failover clustering, see [Always On Failover Cluster Instances (SQL Server)](/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?viewFallbackFrom=sql-server-2014). -#### SQL Server AlwaysOn Availability Groups and SQL Server Database Mirroring +#### SQL Server Always On Availability Groups and SQL Server Database Mirroring -The key benefit of SQL Server AlwaysOn Availability Groups and SQL Server Database Mirroring is that both provide complete or almost complete data redundancy depending on how you configure them for transaction processing. In addition to minimizing data loss, automatic failover minimizes downtime for production databases. +The key benefit of SQL Server Always On Availability Groups and SQL Server Database Mirroring is that both provide complete or almost complete data redundancy depending on how you configure them for transaction processing. In addition to minimizing data loss, automatic failover minimizes downtime for production databases. > [!IMPORTANT]-> Although SQL Server 2016, SQL Server 2014 (SP1), and SQL Server 2012 support database mirroring, this feature is planned to be deprecated. We recommend that you avoid using this feature in new development work. Plan to change applications that currently use this feature. Use AlwaysOn Availability Groups instead. +> Although SQL Server 2016, SQL Server 2014 (SP1), and SQL Server 2012 support database mirroring, this feature is planned to be deprecated. We recommend that you avoid using this feature in new development work. Plan to change applications that currently use this feature. Use Always On Availability Groups instead. - **AlwaysOn Availability Groups** + **Always On Availability Groups** -The SQL Server AlwaysOn Availability Groups feature is both a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring. AlwaysOn Availability Groups supports a failover environment for one or more user databases contained in a user-defined collection. This collection, an availability group, consists of the following components: +The SQL Server Always On Availability Groups feature is both a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring. Always On Availability Groups supports a failover environment for one or more user databases contained in a user-defined collection. This collection, an availability group, consists of the following components: - Replicas, which are a discrete set of user databases called availability databases that are handled as a single unit. An availability group supports one primary replica and up to four secondary replicas. - A specific instance of SQL Server to host each replica and to maintain a local copy of each database that belongs to the availability group. -When an availability group fails over to a target instance or target server, all databases in the group also fail over. Because SQL Server 2014 (SP1) and SQL Server 2012 can host multiple availability groups on a single server, you can configure AlwaysOn to fail over to SQL Server instances on different servers. This reduces the need for idle, high-performance standby servers to handle the full load of the primary server, which is one of the many benefits of availability groups. +When an availability group fails over to a target instance or target server, all databases in the group also fail over. Because SQL Server 2014 (SP1) and SQL Server 2012 can host multiple availability groups on a single server, you can configure Always On to fail over to SQL Server instances on different servers. This reduces the need for idle, high-performance standby servers to handle the full load of the primary server, which is one of the many benefits of availability groups. > [!NOTE] > Database issues, such as a database becoming suspect due to a loss of a data file, deletion of a database, or corruption of a transaction log do not cause a failover. -For more information about the benefits of AlwaysOn Availability Groups and an overview of AlwaysOn Availability Groups terminology, see [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014 +For more information about the benefits of Always On Availability Groups and an overview of Always On Availability Groups terminology, see [Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014 ). **Database mirroring** > [!NOTE]-> Although SQL Server 2016, SQL Server 2014 (SP1), and SQL Server 2012 support database mirroring, this feature is planned to be deprecated. We recommend that you avoid using this feature in new development work. Plan to change applications that currently use this feature. Use AlwaysOn Availability Groups instead. +> Although SQL Server 2016, SQL Server 2014 (SP1), and SQL Server 2012 support database mirroring, this feature is planned to be deprecated. We recommend that you avoid using this feature in new development work. Plan to change applications that currently use this feature. Use Always On Availability Groups instead. Database mirroring provides database redundancy by keeping a mirrored copy of databases on the primary database server. Mirroring is implemented on a per-database basis and only works with databases that use the full recovery model. The following table provides a general comparison of the RPO and RTO results tha |**SQL Server solution**|**Potential data loss (RPO)**|**Potential recovery time (RTO)**|**Automatic failover**|**Readable secondaries <br/> **Note:** SharePoint Server supports readable secondary replicas for runtime usage. For more information, see [Office 2013 cumulative update for April 2014](https://support.microsoft.com/kb/2953733) and [Run a farm that uses read-only databases in SharePoint Server](run-a-farm-that-uses-read-only-databases.md).**| |:--|:--|:--|:--|:--|-|AlwaysOn Availability Group (synchronous-commit) <br/> |Zero <br/> |Seconds <br/> |Yes <br/> |0 - 2 <br/> | -|AlwaysOn Availability Group (asynchronous-commit) <br/> |Seconds <br/> |Minutes <br/> |No <br/> |0 - 4 <br/> | -|AlwaysOn Failover Cluster Instance <br/> |Does not apply <br/> An FCI itself does not provide data protection. The amount of data loss depends on the storage system implementation. <br/> |Seconds to minutes <br/> |Yes <br/> |Does not apply <br/> | +|Always On Availability Group (synchronous-commit) <br/> |Zero <br/> |Seconds <br/> |Yes <br/> |0 - 2 <br/> | +|Always On Availability Group (asynchronous-commit) <br/> |Seconds <br/> |Minutes <br/> |No <br/> |0 - 4 <br/> | +|Always On Failover Cluster Instance <br/> |Does not apply <br/> An FCI itself does not provide data protection. The amount of data loss depends on the storage system implementation. <br/> |Seconds to minutes <br/> |Yes <br/> |Does not apply <br/> | |Database mirroring - High-safety (synchronous mode + witness server) <br/> |Zero <br/> |Seconds <br/> |Yes <br/> |Does not apply <br/> | |Database mirroring - High-performance (asynchronous mode) <br/> |Seconds <br/> |Minutes <br/> |No <br/> |Does not apply <br/> | |Backup, copy, restore <br/> |Hours or zero if the tail of the log can be accessed after the failure. <br/> |Hours to days <br/> |No <br/> |Not during a restore <br/> | -**Comparison of SQL Server Cluster, AlwaysOn Availability Group and Database mirror** +**Comparison of SQL Server Cluster, Always On Availability Group and Database mirror** -|**Process**|**SQL Server failover cluster**|**SQL Server 2014 (SP1) and SQL Server 2012 AlwaysOn Availability Group**|**SQL Server high-availability mirror**| +|**Process**|**SQL Server failover cluster**|**SQL Server 2014 (SP1) and SQL Server 2012 Always On Availability Group**|**SQL Server high-availability mirror**| |:--|:--|:--|:--| |Time to fail over <br/> |Cluster member takes over almost immediately after failure. A lag occurs while the cluster node spins up. <br/> |Replica takes over almost immediately after failure. A lag occurs while the secondary replica spins up. <br/> |Mirror takes over as soon as the redo queue is processed. <br/> | |Transactional consistency <br/> |Yes <br/> |Yes <br/> |Yes <br/> | The following table provides a general comparison of the RPO and RTO results tha |Storage types supported <br/> |Requires shared storage which is more expensive than dedicated storage. <br/> |Can use less expensive directly attached storage solutions. <br/> |Can use less expensive directly attached storage. <br/> | |Location requirements <br/> |Members of the cluster must be on the same subnet. <br/> **Note:** This is not the case with SQL Server 2014 (SP1) and SQL Server 2012. <br/> |Replicas can be on different subnets as long as latency does not cause performance issues. <br/> |Principal, mirror, and witness servers must be on the same LAN (up to 1 millisecond latency round-trip). <br/> | |Recovery model <br/> |SQL Server full recovery model recommended. You can use the SQL Server simple recovery model. However, the only available recovery point if the cluster is lost will be the last full backup. <br/> |Requires SQL Server 2014 (SP1) and SQL Server 2012 full recovery model. <br/> |Requires SQL Server full recovery model. <br/> |-|Performance overhead <br/> |Some decrease in performance may occur while a failover is occurring. The server will be unavailable during failover and connections are dropped and then established again on the new active node. <br/> |AlwaysOn Availability Groups introduce transactional latency because of synchronous commit on the secondary replicas. The amount of latency depends on the number of secondary replicas that have to be synchronized. <br/> Memory and processor overhead is greater than clustering, but less than mirroring. <br/> |High-availability mirroring introduces transactional latency because it is synchronous. It also requires additional memory and processor overhead. <br/> | -|Operations overhead <br/> |Set up and maintained at the server level. <br/> |The operational overhead is greater than clustering and mirroring. AlwaysOn requires overhead at the level of the SQL Server database server in addition to the Windows Server level. <br/> **Note:** Server-level objects such as logons and agent jobs must be maintained manually. <br/> If you add content databases, you have to add them to an availability group and then synchronize the primary replica to the secondary replicas. <br/> A SharePoint farm environment requires multiple configuration steps to make sure that the SharePoint Server connection string is correctly associated with the availability group listener name. <br/> | The operations overhead is more than clustering. Must be set up and maintained for all databases. Reconfiguring after failover is manual. <br/> **Note:** Server-level objects such as logons and agent jobs must be maintained manually. <br/> If you add content databases, you have to add them to the principal and then synchronize the principal to the mirror. <br/> | +|Performance overhead <br/> |Some decrease in performance may occur while a failover is occurring. The server will be unavailable during failover and connections are dropped and then established again on the new active node. <br/> |Always On Availability Groups introduce transactional latency because of synchronous commit on the secondary replicas. The amount of latency depends on the number of secondary replicas that have to be synchronized. <br/> Memory and processor overhead is greater than clustering, but less than mirroring. <br/> |High-availability mirroring introduces transactional latency because it is synchronous. It also requires additional memory and processor overhead. <br/> | +|Operations overhead <br/> |Set up and maintained at the server level. <br/> |The operational overhead is greater than clustering and mirroring. Always On requires overhead at the level of the SQL Server database server in addition to the Windows Server level. <br/> **Note:** Server-level objects such as logons and agent jobs must be maintained manually. <br/> If you add content databases, you have to add them to an availability group and then synchronize the primary replica to the secondary replicas. <br/> A SharePoint farm environment requires multiple configuration steps to make sure that the SharePoint Server connection string is correctly associated with the availability group listener name. <br/> | The operations overhead is more than clustering. Must be set up and maintained for all databases. Reconfiguring after failover is manual. <br/> **Note:** Server-level objects such as logons and agent jobs must be maintained manually. <br/> If you add content databases, you have to add them to the principal and then synchronize the principal to the mirror. <br/> | ## Configure two data centers as a single farm ("stretched" farm) to provide high availability <a name="CfgStretchedFarm"> </a> Your high availability strategy must include the appropriate backup and restore [High availability and disaster recovery concepts in SharePoint Server](high-availability-and-disaster-recovery-concepts.md) -[Choose a disaster recovery strategy for SharePoint Server](plan-for-disaster-recovery.md) +[Choose a disaster recovery strategy for SharePoint Server](plan-for-disaster-recovery.md) |
| SharePoint | Plan For Sql Server Always On And Microsoft Azure Disaster Recovery | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/plan-for-sql-server-always-on-and-microsoft-azure-disaster-recovery.md | Each SQL Server instance that is part of an Always On Availability Group must al For more information about prerequisites, restrictions, recommendations, and general usage for availability groups, see: -- [Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)]( /sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability?view=sql-server-2017&preserve-view=true)+- [Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)]( /sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability?view=sql-server-2017&preserve-view=true) -- [AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-2017&preserve-view=true)+- [Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-2017&preserve-view=true) The next figure (Figure 4) shows the Availability Group replica infrastructure that we used for the SharePoint databases. **Figure 4 Availability Group replica infrastructure** - + In the infrastructure shown in Figure 4, a common practice is to have the database servers in the recovery environment on a separate subnet, which must be taken into account when configuring WSFC and Availability Group listeners. Like SharePoint Server, it is easier to design the architecture up front, rather ### Availability group commit modes and failover types -It is important to understand how commit modes affect the different types of failover for each Availability Group configuration because this will affect farm recovery. The following table is from the SQL Server documentation. This table summarizes which forms of failover are supported under different availability and failover modes. For each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of the primary replica plus the modes of one or more secondary replicas. For more information, see [Failover and Failover Modes (AlwaysOn Availability Groups)](/sql/database-engine/availability-groups/windows/failover-and-failover-modes-always-on-availability-groups?view=sql-server-2017&preserve-view=true). +It is important to understand how commit modes affect the different types of failover for each Availability Group configuration because this will affect farm recovery. The following table is from the SQL Server documentation. This table summarizes which forms of failover are supported under different availability and failover modes. For each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of the primary replica plus the modes of one or more secondary replicas. For more information, see [Failover and Failover Modes (Always On Availability Groups)](/sql/database-engine/availability-groups/windows/failover-and-failover-modes-always-on-availability-groups?view=sql-server-2017&preserve-view=true). |**Failover type**|**Synchronous-commit mode with automatic-failover mode**|**Synchronous-commit mode with manual-failover mode**|**Asynchronous-commit mode**| |:--|:--|:--|:--| The [Appendix](#App) data sheet in the appendix will help you plan, deploy, and ### Build phase 1 <a name="Bp1"> </a> - + The next table provides more information about the steps in Build phase 1. The next table provides more information about the steps in Build phase 1. |1. Configure a two-node WSFC cluster <br/> |Use the Windows Server article, [Create a Failover Cluster](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn505754(v=ws.11)) to create a two-node cluster. For Windows Server 2016 information, see [Failover Clustering in Windows Server 2016](/windows-server/failover-clustering/failover-clustering-overview). <br/> | |2. Configure a file share witness <br/> |The preferred configuration for WSFC in a SharePoint environment is to use a file share witness and a node majority. Both cluster nodes in the on-premises farm have a quorum vote. The cluster node in the recovery farm doesn't have a vote. <br/> For more information, see [Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj612870(v=ws.11)). For Windows Server 2016, see [Deploy a Cloud Witness for a Failover Cluster](/windows-server/failover-clustering/failover-clustering-overview). <br/> Use the following Microsoft PowerShell cmdlet to configure a file share and node majority Quorum: <br/> `Set-ClusterQuorum -NodeAndFileShareMajority "\\fileserver\share"` <br/> Use the following PowerShell cmdlet to assign votes: <br/> `(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=1` <br/> Use the following PowerShell syntax to configure a Cloud Witness: <br/> `Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>` <br/> | |3. Install SQL Server on each Windows cluster node <br/> |Install SQL Server on both Windows Server cluster nodes. Note the following: <br/> **Do not** run the SQL Server setup program for a failover cluster. These nodes are not part of a SQL Failover Cluster Instance (FCI) Cluster. <br/> Make sure that the SQL Server data paths are exactly the same for each instance. <br/> For more information, see [Install SQL Server 2014 from the Installation Wizard (Setup)](/sql/database-engine/install-windows/install-sql-server-from-the-installation-wizard-setup?viewFallbackFrom=sql-server-2014&preserve-view=true) or [Install SQL Server 2014 from the Command Prompt](/sql/database-engine/install-windows/install-sql-server-from-the-command-prompt?viewFallbackFrom=sql-server-2014). Also, see [Install SQL Server from the Installation Wizard (Setup)](/sql/database-engine/install-windows/install-sql-server-from-the-installation-wizard-setup?view=sql-server-2017&preserve-view=true). <br/> |-|4. Enable SQL Server Always On <br/> |Use the guidance in [Enable and Disable AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014&preserve-view=true) to enable Always On. Use theSQL Server2016 guidance in [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?view=sql-server-2017&preserve-view=true). <br/> The database grouping section after this table shows how you can logically group SharePoint databases and map them to different availability groups to meet your disaster recovery requirements as well as your high availability requirements. <br/> | +|4. Enable SQL Server Always On <br/> |Use the guidance in [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014&preserve-view=true) to enable Always On. Use theSQL Server2016 guidance in [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?view=sql-server-2017&preserve-view=true). <br/> The database grouping section after this table shows how you can logically group SharePoint databases and map them to different availability groups to meet your disaster recovery requirements as well as your high availability requirements. <br/> | |5. Configure farm account security <br/> |Configure the appropriate permissions in each SQL Server instance for the SharePoint setup user administrator account. This account must be a member of the **db_owner** role and assigned to the **securityadmin** and **dbcreator** SQL Server security roles during setup and configuration. <br/> For more information, see [Configure SQL Server security for SharePoint Server](../security-for-sharepoint-server/configure-sql-server-security-for-sharepoint-environments.md) and [Account permissions and security settings in SharePoint Server 2016](../install/account-permissions-and-security-settings-in-sharepoint-server-2016.md). <br/> |-|6. Create availability groups, Always On Endpoints, and Availability Group Listeners <br/> |Create the availability groups for synchronous-commit mode for high availability. (It is common practice to configure the availability groups logically for the logical failover of databases). After you create the Always On Endpoints, create Availability Group listeners to enable client connectivity to each availability group. <br/> **Note:** You can create the availability groups with temporary database names so SharePoint can use the listeners when the farm is configured. This is so the database connection strings point to the appropriate DNS entries created by the listeners. This saves you having to reconfigure the listeners later. <br/> For more information, see [Configure SQL Server AlwaysOn Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md). <br/> For information, see [Create a Database Mirroring Endpoint for AlwaysOn Availability Groups (SQL Server PowerShell)](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?viewFallbackFrom=sql-server-2014). For SQL Server 2016 information, see [Database Mirroring - Always On Availability Groups- PowerShell](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?view=sql-server-2017&preserve-view=true). <br/> For SQL Server 2016 information, see [Listeners, Client Connectivity, Application Failover](/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover?view=sql-server-2017&preserve-view=true). <br/> **Note:** If you create the Availability Group Listeners using SQL Server Management Studio, you have to add an IP address for the disaster recovery subnet for each listener. This is not required if you provision Availability Group Listeners using the SQL Server `New-SqlAvailabilityGroupListener` PowerShell cmdlet. The recovery farm will reference the SQL instances through DNS host (A) entries and not the Availability Group listeners. For more information, see [New-SqlAvailabilityGroupListener](/powershell/module/sqlps/New-SqlAvailabilityGroupListener?view=sqlserver-ps&preserve-view=true). <br/> | +|6. Create availability groups, Always On Endpoints, and Availability Group Listeners <br/> |Create the availability groups for synchronous-commit mode for high availability. (It is common practice to configure the availability groups logically for the logical failover of databases). After you create the Always On Endpoints, create Availability Group listeners to enable client connectivity to each availability group. <br/> **Note:** You can create the availability groups with temporary database names so SharePoint can use the listeners when the farm is configured. This is so the database connection strings point to the appropriate DNS entries created by the listeners. This saves you having to reconfigure the listeners later. <br/> For more information, see [Configure SQL Server Always On Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md). <br/> For information, see [Create a Database Mirroring Endpoint for Always On Availability Groups (SQL Server PowerShell)](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?viewFallbackFrom=sql-server-2014). For SQL Server 2016 information, see [Database Mirroring - Always On Availability Groups- PowerShell](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?view=sql-server-2017&preserve-view=true). <br/> For SQL Server 2016 information, see [Listeners, Client Connectivity, Application Failover](/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover?view=sql-server-2017&preserve-view=true). <br/> **Note:** If you create the Availability Group Listeners using SQL Server Management Studio, you have to add an IP address for the disaster recovery subnet for each listener. This is not required if you provision Availability Group Listeners using the SQL Server `New-SqlAvailabilityGroupListener` PowerShell cmdlet. The recovery farm will reference the SQL instances through DNS host (A) entries and not the Availability Group listeners. For more information, see [New-SqlAvailabilityGroupListener](/powershell/module/sqlps/New-SqlAvailabilityGroupListener?view=sqlserver-ps&preserve-view=true). <br/> | #### Database grouping for disaster recovery The next table provides more information about the steps in Build phase 2. |2. Install prerequisites and binaries <br/> |For more information, see [Install prerequisites for SharePoint Server from a network share](../install/install-prerequisites-from-network-share.md). <br/> | |3. Configure Farm SMTP Settings, Web Apps, and Site Collections <br/> |Use the `New-SPWebApplication` cmdlet to create Web Applications and use the `New-SPSite` cmdlet to create Site Collections. <br/> | |4. Configure Service Applications <br/> |Use the Service Application cmdlets in [Index of Windows PowerShell cmdlets for SharePoint Server 2016](/powershell/module/sharepoint-server/?view=sharepoint-ps&preserve-view=true) to configure service applications. <br/> |-|5. Add the on-premises production farm databases to availability groups and synchronize the replicas <br/> |When you finish configuring the farm, add the farm databases to the appropriate availability groups. Use these PowerShell cmdlets to add the databases and verify that they've been added to the availability group you specify, `Add-DatabasetoAvailabilityGroup` and `Get-AvailabilityGroupStatus` <br/> **Important:** Make sure that you enable the full recovery model on all databases that are to be added to an availability group before you add them. <br/> After you add the farm configuration database to an availability group you must restart all the servers in the farm to ensure farm stability. <br/> Synchronize the availability group replicas. For more information, see [Select Initial Data Synchronization Page (AlwaysOn Availability Group Wizards)](/sql/database-engine/availability-groups/windows/select-initial-data-synchronization-page-always-on-availability-group-wizards?view=sql-server-2017&preserve-view=true). <br/> | +|5. Add the on-premises production farm databases to availability groups and synchronize the replicas <br/> |When you finish configuring the farm, add the farm databases to the appropriate availability groups. Use these PowerShell cmdlets to add the databases and verify that they've been added to the availability group you specify, `Add-DatabasetoAvailabilityGroup` and `Get-AvailabilityGroupStatus` <br/> **Important:** Make sure that you enable the full recovery model on all databases that are to be added to an availability group before you add them. <br/> After you add the farm configuration database to an availability group you must restart all the servers in the farm to ensure farm stability. <br/> Synchronize the availability group replicas. For more information, see [Select Initial Data Synchronization Page (Always On Availability Group Wizards)](/sql/database-engine/availability-groups/windows/select-initial-data-synchronization-page-always-on-availability-group-wizards?view=sql-server-2017&preserve-view=true). <br/> | ### Build phase 3 <a name="Bp3"> </a> The next table provides more information about the steps in Build phase 3. |:--|:--| |1. Add two nodes to the Azure disaster recovery datacenter which will stretch the on-premises WSFC cluster <br/> |Configure these settings on the server that will be the new cluster node; Install the Windows Failover clustering feature, test the cluster, and then remove the quorum vote from the new node. <br/> Open the Windows PowerShell command line as an Administrator and run the following cmdlet to install the Windows Failover clustering feature and management tools: `Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools` <br/> Test the cluster with the following cmdlet: `Test-Cluster` <br/> Remove the Quorum vote from the server with the following commands: `(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=0` <br/> For more information, see [Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj612870(v=ws.11)). For Windows Server 2016 information, see [Deploy a Cloud Witness for a Failover Cluster](/windows-server/failover-clustering/deploy-cloud-witness). <br/> **Note:** If you use the same architecture as our test environment, you'll have to perform these configuration steps on both the SQL Server instances in the recovery environment. <br/> | |2. Install the SQL Server instances <br/> |Install SQL Server on both nodes. Ensure that the data paths are exactly the same for each SQL instance and that the configurations are identical, for example, port configurations, database collation, and so on. For more information, see [Install SQL Server 2012 from the Installation Wizard (Setup)](/sql/database-engine/install-windows/install-sql-server-from-the-installation-wizard-setup?viewFallbackFrom=sql-server-2014). Also, see [Install SQL Server from the Installation Wizard (Setup)](/sql/database-engine/install-windows/install-sql-server-from-the-installation-wizard-setup?view=sql-server-2017&preserve-view=true). <br/> |-|3. Enable SQL Server Always On Availability Groups <br/> |Use SQL Server Configuration Manager to enable SQL Server Always On Availability Groups. For more information, see [Enable and Disable AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014). For SQL Server 2016 guidance, see [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?view=sql-server-2017&preserve-view=true). <br/> Refer to the table in [Build phase 1](#Bp1) for examples of the logical grouping of SharePoint Server 2016 databases to availability groups. <br/> | +|3. Enable SQL Server Always On Availability Groups <br/> |Use SQL Server Configuration Manager to enable SQL Server Always On Availability Groups. For more information, see [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?viewFallbackFrom=sql-server-2014). For SQL Server 2016 guidance, see [Enable and Disable Always On Availability Groups (SQL Server)](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?view=sql-server-2017&preserve-view=true). <br/> Refer to the table in [Build phase 1](#Bp1) for examples of the logical grouping of SharePoint Server 2016 databases to availability groups. <br/> | |4. Configure farm account security <br/> |Configure the appropriate permissions in each SQL Server instance for the SharePoint setup user administrator account. This account must be a member of the **db_owner** role and assigned to the **securityadmin** and **dbcreator** SQL Server security roles during setup and configuration. <br/> For more information, see [Configure SQL Server security for SharePoint Server](../security-for-sharepoint-server/configure-sql-server-security-for-sharepoint-environments.md), [Account permissions and security settings in SharePoint Server 2016](../install/account-permissions-and-security-settings-in-sharepoint-server-2016.md), and [Account permissions and security settings in SharePoint 2013](../install/account-permissions-and-security-settings-in-sharepoint-2013.md) <br/> | ### Build phase 4 The next table provides more information about the steps in Build phase 5. |**Step**|**Notes and guidance**| |:--|:--| |1. Verify that the SQL instance can access the database and backup shares. <br/> |Each node in an availability group must have access to a common backup location. This is required for the initial database seeding during the process of adding replicas to the availability group. <br/> The SQL Server account must have access to the common backup location. <br/> |-|2. Create a SQL Server endpoint and grant connect permissions to the endpoint. <br/> |You must create a logon on the disaster recovery SQL Server instance in order to create a secondary replica and join the databases to the Availability Groups. For more information, see [Set Up Login Accounts for Database Mirroring or AlwaysOn Availability Groups (SQL Server)](/sql/database-engine/database-mirroring/set-up-login-accounts-database-mirroring-always-on-availability?viewFallbackFrom=sql-server-2014) and [Set Up Login Accounts - Database Mirroring Always On Availability](/sql/database-engine/database-mirroring/set-up-login-accounts-database-mirroring-always-on-availability?view=sql-server-2017&preserve-view=true). <br/> A SQL Server endpoint is required on the primary replica so the SQL instance can send log buffers to the secondary replicas. Use the process in [Create a Database Mirroring Endpoint for AlwaysOn Availability Groups (SQL Server PowerShell)](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?viewFallbackFrom=sql-server-2014) and [Database Mirroring - Always On Availability Groups- PowerShell](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?view=sql-server-2017&preserve-view=true) to create the endpoint. <br/> You must give the service account on the primary SQL Server instance access to the endpoint in order to transfer log buffers to the disaster recovery instances. Connect permission is required. <br/> For more information, see [GRANT Endpoint Permissions (Transact-SQL)](/sql/t-sql/statements/grant-endpoint-permissions-transact-sql). <br/> | +|2. Create a SQL Server endpoint and grant connect permissions to the endpoint. <br/> |You must create a logon on the disaster recovery SQL Server instance in order to create a secondary replica and join the databases to the Availability Groups. For more information, see [Set Up Login Accounts for Database Mirroring or Always On Availability Groups (SQL Server)](/sql/database-engine/database-mirroring/set-up-login-accounts-database-mirroring-always-on-availability?viewFallbackFrom=sql-server-2014) and [Set Up Login Accounts - Database Mirroring Always On Availability](/sql/database-engine/database-mirroring/set-up-login-accounts-database-mirroring-always-on-availability?view=sql-server-2017&preserve-view=true). <br/> A SQL Server endpoint is required on the primary replica so the SQL instance can send log buffers to the secondary replicas. Use the process in [Create a Database Mirroring Endpoint for Always On Availability Groups (SQL Server PowerShell)](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?viewFallbackFrom=sql-server-2014) and [Database Mirroring - Always On Availability Groups- PowerShell](/sql/database-engine/availability-groups/windows/database-mirroring-always-on-availability-groups-powershell?view=sql-server-2017&preserve-view=true) to create the endpoint. <br/> You must give the service account on the primary SQL Server instance access to the endpoint in order to transfer log buffers to the disaster recovery instances. Connect permission is required. <br/> For more information, see [GRANT Endpoint Permissions (Transact-SQL)](/sql/t-sql/statements/grant-endpoint-permissions-transact-sql). <br/> | |3. Create secondary replicas of the user content and service application databases in the recovery farm instance. <br/> |Each Availability Group requires a secondary replica in the disaster recovery farm. You must be connected to the SQL instance that is hosting the primary replica before you can create the secondary replica. <br/> For more information, see [Add a Secondary Replica to an Availability Group (SQL Server)](/sql/database-engine/availability-groups/windows/add-a-secondary-replica-to-an-availability-group-sql-server?view=sql-server-2017&preserve-view=true). <br/> | |4. Ensure that the replicas in the recovery farm are configured for Read-Only access. <br/> |The availability replicas in the DR SL Server instances are configured as readable secondary replicas. The disaster recovery farm will access the service application and content databases in read-only mode. This is because the recovery farm is already referencing the service application database names. This reduces the Recovery Time Objective (RTO) when we failover to the DR environment. <br/> **Note:** If this is not configured correctly, you may experience errors in the recovery environment. <br/> For more information, see [Configure Read-Only Routing for an Availability Group (SQL Server)](/sql/database-engine/availability-groups/windows/configure-read-only-routing-for-an-availability-group-sql-server?view=sql-server-2017&preserve-view=true) and [Configure Read-Only Access on an Availability Replica (SQL Server)](/sql/database-engine/availability-groups/windows/configure-read-only-access-on-an-availability-replica-sql-server?view=sql-server-2017&preserve-view=true). <br/> | |5. Copy logons from the primary SQL Server instance to the secondary SQL Server instances. <br/> |You have to copy SQL logons and passwords from the primary instance to the secondary instances. SQL Server copies only the content of an availability group database. Logons and passwords are not copied from one instance to another. <br/> For more information, see [How to transfer logins and passwords between instances of SQL Server](/troubleshoot/sql/security/transfer-logins-passwords-between-instances) and [Troubleshoot Orphaned Users (SQL Server)](/sql/sql-server/failover-clusters/troubleshoot-orphaned-users-sql-server). <br/> | |
| SharePoint | Server Management | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/server-management.md | Use the following articles to manage your SharePoint Server environment. |[SQL Server and storage (SharePoint Server)](sql-server-and-storage.md) <br/> |Learn how to plan for SQL Server and storage configuration for SharePoint Server 2016 and SharePoint Server 2013. <br/> | |[Overview of backup and recovery in SharePoint Server](backup-and-recovery-overview.md) <br/> |Learn about how to prepare to back up and restore and complete specific operations for SharePoint Server 2016 and SharePoint 2013. <br/> | |[High availability and disaster recovery concepts in SharePoint Server](high-availability-and-disaster-recovery-concepts.md) <br/> |Create a well-designed high availability plan and a disaster recovery plan that meets business goals and objectives for SharePoint Server 2016 and SharePoint 2013. <br/> |-|[Configure SQL Server AlwaysOn Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md) <br/> |Learn how to create and configure a SQL Server Always On Availability Group for a SharePoint Server 2016 and SharePoint 2013 farm. <br/> | +|[Configure SQL Server Always On Availability Groups for SharePoint Server](configure-an-alwayson-availability-group.md) <br/> |Learn how to create and configure a SQL Server Always On Availability Group for a SharePoint Server 2016 and SharePoint 2013 farm. <br/> | |[Performance planning in SharePoint Server 2013](performance-planning-in-sharepoint-server-2013.md) <br/> |Learn about the concepts and planning considerations for managing the capacity of a SharePoint Server environment. <br/> | |[Managing a MinRole Server Farm in SharePoint Server 2016](managing-a-minrole-server-farm-in-sharepoint-server-2016.md) <br/> |Learn how to manage your MinRole farm deployment in SharePoint Server 2016. <br/> | |[Remove a server from a farm in SharePoint Server 2016](remove-a-server-from-a-farm-in-sharepoint-server-2016.md) <br/> |Learn how to remove a web server, application server, or database server from a SharePoint 2013 farm. <br/> | |
| SharePoint | Sharepoint 2013 Dev Test Environments In Azure | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-2013-dev-test-environments-in-azure.md | The high-availability SharePoint farm consists of nine virtual machines hosted i  -You can use the high-availability farm configuration to test higher client loads, high availability of the external SharePoint site, and SQL Server AlwaysOn Availability Groups for a SharePoint farm. You can also use this configuration for SharePoint app development in a high-availability environment. +You can use the high-availability farm configuration to test higher client loads, high availability of the external SharePoint site, and SQL Server Always On Availability Groups for a SharePoint farm. You can also use this configuration for SharePoint app development in a high-availability environment. > [!NOTE] > You cannot create the SharePoint 2013 non-HA Farm or SharePoint 2013 HA Farm with an Azure Free Trial. |
| SharePoint | Sharepoint Intranet Farm In Azure Phase 1 Configure Azure | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-intranet-farm-in-azure-phase-1-configure-azure.md | description: "Configure the Microsoft Azure infrastructure to host a high-availa [!INCLUDE[appliesto-xxx-2016-xxx-xxx-xxx-md](../includes/appliesto-xxx-2016-xxx-xxx-xxx-md.md)] -In this phase of deploying an intranet-only SharePoint Server 2016 farm in Azure, you build out the Azure infrastructure. You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 2: Configure domain controllers](sharepoint-intranet-farm-in-azure-phase-2-configure-domain-controllers.md). See [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. +In this phase of deploying an intranet-only SharePoint Server 2016 farm in Azure, you build out the Azure infrastructure. You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 2: Configure domain controllers](sharepoint-intranet-farm-in-azure-phase-2-configure-domain-controllers.md). See [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. Azure must be provisioned with these basic components for networking and storage: Use [SharePoint Intranet Farm in Azure Phase 2: Configure domain controllers](sh #### Other Resources -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) [SharePoint Server in Microsoft Azure](./sharepoint-server-in-microsoft-azure.md) |
| SharePoint | Sharepoint Intranet Farm In Azure Phase 2 Configure Domain Controllers | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-intranet-farm-in-azure-phase-2-configure-domain-controllers.md | In this phase of deploying an intranet-only SharePoint Server 2016 farm in Azure > [!NOTE] > SharePoint Server 2016 also supports the use of [Azure Active Directory (AD) Domain Services](/azure/active-directory-domain-services/active-directory-ds-overview) as a substitute for virtual machines running as domain replicas. However, at this time, this deployment guide only describes the use of virtual machine-based replica domain controllers. -You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 3: Configure SQL Server Infrastructure](sharepoint-intranet-farm-in-azure-phase-3-configure-sql-server-infrastructure.md). See [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. +You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 3: Configure SQL Server Infrastructure](sharepoint-intranet-farm-in-azure-phase-3-configure-sql-server-infrastructure.md). See [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. ## Create the domain controller virtual machines in Azure Use [SharePoint Intranet Farm in Azure Phase 3: Configure SQL Server Infrastruct #### Other Resources -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) [SharePoint Server in Microsoft Azure](./sharepoint-server-in-microsoft-azure.md) |
| SharePoint | Sharepoint Intranet Farm In Azure Phase 3 Configure Sql Server Infrastructure | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-intranet-farm-in-azure-phase-3-configure-sql-server-infrastructure.md | description: "Configure the SQL Server infrastructure to host a high-availabilit In this phase of deploying an intranet-only SharePoint Server 2016 farm in Azure infrastructure services, you create and configure the two SQL Server virtual machines and the cluster majority node, and then combine them into a Windows Server cluster. -You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 4: Configure SharePoint servers](sharepoint-intranet-farm-in-azure-phase-4-configure-sharepoint-servers.md). See [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. +You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 4: Configure SharePoint servers](sharepoint-intranet-farm-in-azure-phase-4-configure-sharepoint-servers.md). See [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. > [!NOTE] > These instructions use a SQL Server image in the Azure image gallery and you are charged ongoing costs for the use of the SQL Server license. It is also possible to create virtual machines in Azure and install your own SQL Server licenses, but you must have Software Assurance and License Mobility to use your SQL Server license on a virtual machine, including an Azure virtual machine. Note that you must supply domain account credentials after running the **Add-Com ## Create the Windows server cluster -SQL Server AlwaysOn Availability Groups rely on the Windows Server Failover Clustering (WSFC) feature of Windows Server. The feature allows several machines to participate as a group in a cluster. When one machine fails, a second machine is ready to take its place. Therefore the first task is to enable the Failover Clustering feature on all of the participating machines, which include: +SQL Server Always On Availability Groups rely on the Windows Server Failover Clustering (WSFC) feature of Windows Server. The feature allows several machines to participate as a group in a cluster. When one machine fails, a second machine is ready to take its place. Therefore the first task is to enable the Failover Clustering feature on all of the participating machines, which include: - The primary SQL server Due to current non-RFC-compliant behavior by DHCP in Azure, creation of a WSFC c If you are using a cloud witness, see [Deploy a Cloud Witness for a Failover Cluster](/windows-server/failover-clustering/deploy-cloud-witness). -## Enable AlwaysOn Availability Groups +## Enable Always On Availability Groups -The next step is to enable AlwaysOn Availability Groups using the SQL Server Configuration Manager. Note that an availability group in SQL Server differs from an Azure availability set. An availability group contains databases that are highly-available and recoverable. An Azure availability set allocates virtual machines to different fault domains. For more information about fault domains, see [Manage the Availability of Virtual Machines](/azure/virtual-machines/windows/manage-availability). +The next step is to enable Always On Availability Groups using the SQL Server Configuration Manager. Note that an availability group in SQL Server differs from an Azure availability set. An availability group contains databases that are highly-available and recoverable. An Azure availability set allocates virtual machines to different fault domains. For more information about fault domains, see [Manage the Availability of Virtual Machines](/azure/virtual-machines/windows/manage-availability). -Use these steps to enable AlwaysOn Availability Groups on SQL Server: +Use these steps to enable Always On Availability Groups on SQL Server: 1. Connect to the primary SQL server using the sp_install account, or some other account that has sysadmin server role on the SQL server. Use these steps to enable AlwaysOn Availability Groups on SQL Server: 4. In the contents pane, double-click **SQL Server (MSSQLSERVER)**. -5. In **SQL Server (MSSQLSERVER) Properties**, click the **AlwaysOn High Availability** tab, select **Enable AlwaysOn Availability Groups**, click **Apply**, and then click **OK** when prompted. Do not close the properties window yet. +5. In **SQL Server (MSSQLSERVER) Properties**, click the **Always On High Availability** tab, select **Enable Always On Availability Groups**, click **Apply**, and then click **OK** when prompted. Do not close the properties window yet. 6. Click **Log On** tab, ensure the **This Account** radio button is selected, then type \<your domain>**\sqlservice** in **Account Name**. Type the sqlservice account password in **Password** and **Confirm password**, and then click **OK**. Use [SharePoint Intranet Farm in Azure Phase 4: Configure SharePoint servers](sh #### Other Resources -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) [SharePoint Server in Microsoft Azure](./sharepoint-server-in-microsoft-azure.md) |
| SharePoint | Sharepoint Intranet Farm In Azure Phase 4 Configure Sharepoint Servers | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-intranet-farm-in-azure-phase-4-configure-sharepoint-servers.md | description: "Configure the SharePoint servers to host a high-availability Share In this phase of deploying an intranet-only SharePoint Server 2016 farm in Azure infrastructure services, you create the SharePoint Server 2016 servers and configure their roles with the SharePoint Configuration Wizard. -You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 5: Create the availability group and add the SharePoint databases](sharepoint-intranet-farm-in-azure-phase-5-create-the-availability-group-and-add.md). See [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. +You must complete this phase before moving on to [SharePoint Intranet Farm in Azure Phase 5: Create the availability group and add the SharePoint databases](sharepoint-intranet-farm-in-azure-phase-5-create-the-availability-group-and-add.md). See [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. ## Create the SharePoint server virtual machines in Azure Use [SharePoint Intranet Farm in Azure Phase 5: Create the availability group an #### Other Resources -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) [SharePoint Server in Microsoft Azure](./sharepoint-server-in-microsoft-azure.md) |
| SharePoint | Sharepoint Intranet Farm In Azure Phase 5 Create The Availability Group And Add | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-intranet-farm-in-azure-phase-5-create-the-availability-group-and-add.md | description: "Configure the SQL Server availability group for your high-availabi [!INCLUDE[appliesto-xxx-2016-xxx-xxx-xxx-md](../includes/appliesto-xxx-2016-xxx-xxx-xxx-md.md)] -In this final phase of deploying an intranet-only SharePoint Server 2016 farm in Azure infrastructure services, you create a new SQL Server AlwaysOn Availability Group with the databases of the SharePoint farm, create the availability group listener, and then complete the SharePoint farm configuration. +In this final phase of deploying an intranet-only SharePoint Server 2016 farm in Azure infrastructure services, you create a new SQL Server Always On Availability Group with the databases of the SharePoint farm, create the availability group listener, and then complete the SharePoint farm configuration. -See [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. +See [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for all of the phases. ## Configure the availability group Perform the following steps for every database that you are adding to the availa 5. Select the **Options** item from the left navigation. -6. Ensure that **Recovery Model** is set to **FULL**. If it is not, change it to support AlwaysOn Functionality. +6. Ensure that **Recovery Model** is set to **FULL**. If it is not, change it to support Always On Functionality. -The following procedures must be repeated for every database that needs to be added to the availability group. Some SharePoint Server 2016 databases do not support SQL Server AlwaysOn Availability Groups. For more information, see [Supported high availability and disaster recovery options for SharePoint databases](./supported-high-availability-and-disaster-recovery-options-for-sharepoint-databas.md). +The following procedures must be repeated for every database that needs to be added to the availability group. Some SharePoint Server 2016 databases do not support SQL Server Always On Availability Groups. For more information, see [Supported high availability and disaster recovery options for SharePoint databases](./supported-high-availability-and-disaster-recovery-options-for-sharepoint-databas.md). **To back up a database** After at least one database is prepared (using the backup and restore method), y 1. Return to the Remote Desktop session for the first SQL Server virtual machine. -2. In **SQL Server Management Studio**, in the left pane, right-click **AlwaysOn High Availability**, and then click **New Availability Group Wizard**. +2. In **SQL Server Management Studio**, in the left pane, right-click **Always On High Availability**, and then click **New Availability Group Wizard**. 3. On the **Introduction** page, click **Next**. Use these steps to configure the listener port: 1. Connect to the first SQL Server virtual machine, launch SQL Server Management Studio, and connect to the local computer. -2. Navigate to **AlwaysOn High Availability \> Availability Groups \> Availability Group Listeners**. +2. Navigate to **Always On High Availability \> Availability Groups \> Availability Group Listeners**. You should now see the listener name that you created in Failover Cluster Manager. Use these steps to test the connection to the listener: The sqlcmd connection automatically connects to whichever instance of SQL Server hosts the primary replica. -You use the health dashboard to check the AlwaysOn Availability Group for successful operation with these steps: +You use the health dashboard to check the Always On Availability Group for successful operation with these steps: -1. On the first SQL Server virtual machines, in the left pane of SQL Server Management Studio, expand **AlwaysOn High Availability \> Availability Groups**. +1. On the first SQL Server virtual machines, in the left pane of SQL Server Management Studio, expand **Always On High Availability \> Availability Groups**. 2. Right-click your Availability Group, and then click **Show Dashboard**. You use the health dashboard to check the AlwaysOn Availability Group for succes Now that the SharePoint configuration and admin content databases have been added to the Availability Group and are synchronizing correctly, the next step is to ensure they are accessible in the event of a SQL Server node failure. To do this, the SQL Server database connection string for the SharePoint farm needs to be updated to match the DNS name of the SQL cluster internal load balancer. > [!NOTE]-> With an on-premises SQL Server AlwaysOn deployment, the Availability Groups would use Listeners to present a connection point to the SharePoint Servers. In Azure IaaS there are network limitations which prevent this and so the internal load balancer DNS name must be used instead. Because of this situation, the SharePoint PowerShell cmdlets for managing availability group membership cannot be used. You must use database object method calls instead. +> With an on-premises SQL Server Always On deployment, the Availability Groups would use Listeners to present a connection point to the SharePoint Servers. In Azure IaaS there are network limitations which prevent this and so the internal load balancer DNS name must be used instead. Because of this situation, the SharePoint PowerShell cmdlets for managing availability group membership cannot be used. You must use database object method calls instead. Use these steps to update the SharePoint database connection strings: Your high availability SharePoint Server 2016 farm in Azure is complete. #### Other Resources -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](./deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) [SharePoint Server in Microsoft Azure](./sharepoint-server-in-microsoft-azure.md) |
| SharePoint | Sharepoint Server Dev Test Environment In Azure | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-server-dev-test-environment-in-azure.md | From a browser on your local computer, access **http://**\<DNS name of the spVM When you are ready to design a production SharePoint Server farm in Azure, see [Designing a SharePoint Server farm in Azure](designing-a-sharepoint-server-farm-in-azure.md). -When you are ready to deploy a production-ready, high availability SharePoint Server 2016 farm in Azure, see [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md). +When you are ready to deploy a production-ready, high availability SharePoint Server 2016 farm in Azure, see [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md). To start developing Low or High Trust Addins, you must first configure an App Domain. See [Configure an environment for apps for SharePoint Server](configure-an-environment-for-apps-for-sharepoint.md). Start-AzVM -Name spVM -ResourceGroupName $rgName [Designing a SharePoint Server farm in Azure](designing-a-sharepoint-server-farm-in-azure.md) -[Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) +[Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) [Cloud adoption Test Lab Guides (TLGs)](/office365/enterprise/cloud-adoption-test-lab-guides-tlgs) |
| SharePoint | Sharepoint Server In Microsoft Azure | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/sharepoint-server-in-microsoft-azure.md | To get your hands on SharePoint Server farm in Azure infrastructure services, se ## Deployment -See [Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for step-by-step instructions on how to build out this high-availability intranet production farm in Azure. +See [Deploying SharePoint Server with SQL Server Always On Availability Groups in Azure](deploying-sharepoint-server-with-sql-server-alwayson-availability-groups-in.md) for step-by-step instructions on how to build out this high-availability intranet production farm in Azure.  |
| SharePoint | Storage And Sql Server Capacity Planning And Configuration | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/storage-and-sql-server-capacity-planning-and-configuration.md | To estimate the storage requirements for the service applications in the system, Availability is how much a SharePoint Server environment is perceived by users to be available. An available system is a system that is resilient ΓÇö that is, incidents that affect service occur infrequently, and timely and effective action is taken when they do occur. -Availability requirements can significantly increase your storage needs. For detailed information, see [Create a high availability architecture and strategy for SharePoint Server](plan-for-high-availability.md). Also, see the SQL Server 2012 white paper [AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solutions by Using AlwaysOn Availability Groups](/previous-versions/sql/sql-server-2012/jj191711(v=msdn.10)). +Availability requirements can significantly increase your storage needs. For detailed information, see [Create a high availability architecture and strategy for SharePoint Server](plan-for-high-availability.md). Also, see the SQL Server 2012 white paper [Always On Architecture Guide: Building a High Availability and Disaster Recovery Solutions by Using Always On Availability Groups](/previous-versions/sql/sql-server-2012/jj191711(v=msdn.10)). <a name="Section2"> </a> ## Choose SQL Server version and edition The following list provides some best practices and recommendations: - We do not recommend a wide area network (WAN) topology in which a server that is running SQL Server is deployed remotely from other components of the farm over a network that has latency greater than 1 ms., because this topology has not been tested. -- Plan for an adequate WAN network if you plan to use SQL Server the AlwaysOn implementation suite, mirroring, log shipping, or Failover Clustering to keep a remote site up to date.+- Plan for an adequate WAN network if you plan to use SQL Server the Always On implementation suite, mirroring, log shipping, or Failover Clustering to keep a remote site up to date. - We recommend that web servers and application servers have two network adapters: one network adapter to handle user traffic and the other to handle communication with the servers that are running SQL Server. |
| SharePoint | Supported High Availability And Disaster Recovery Options For Sharepoint Databas | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/administration/supported-high-availability-and-disaster-recovery-options-for-sharepoint-databas.md | For supported versions of SQL Server, see: |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |SharePoint_Config <br/> | |Purpose <br/> |The configuration database contains data about SharePoint databases, Internet Information Services (IIS) web sites, web applications, Trusted solutions, Web Part packages, and Site templates. <br/> The configuration database also contains specific data for SharePoint Server farm settings, such as default quota settings and blocked file types. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |No. This is a farm specific database. <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No. This is a farm specific database. <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No. This is a farm specific database. <br/> | **Central Administration content database** For supported versions of SQL Server, see: |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |SharePoint_AdminContent_\<GUID\> <br/> | |Purpose <br/> |This database stores all configuration data for the Central Administration site collection. If SQL Server 2016 RTM, Power Pivot for SharePoint Server 2016 or SQL Server 2012 Power Pivot for SharePoint 2013 is installed the Central Administration content database also stores the Excel Online and Excel worksheets and Power Pivot data files that are used in the Power Pivot Management Dashboard. <br/> **Note:** Power Pivot for SharePoint Server 2016 is only available with SQL Server 2016 RTM. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |No. This is a farm specific database. <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No. This is a farm specific database. <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No. This is a farm specific database. <br/> | **Content database** For supported versions of SQL Server, see: |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |WSS_Content <br/> | |Purpose <br/> |Content databases store all content for a site collection. This includes site documents or files in document libraries, list data, Web Part properties, audit logs, and some **apps for SharePoint data** if the apps are installed, in addition to user names and rights. <br/> Content databases also store user data for SQL Server 2016 CTP 3.1 or later, Power Pivot for SharePoint Server 2016 and SQL Server 2012 Power Pivot for SharePoint 2013, if you installed it in your SharePoint Server environment. Additionally Content databases also store the Project Server 2016 extensions in SharePoint Server 2016. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ## SharePoint Servers 2016 and 2019 service application databases <a name="SAppDBsSPALL"> </a> The following table provides the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2016/2019:** AppMng_Service_DB_\<GUID\> <br/> **2013:** AppManagement <br/> | |Purpose <br/> |Stores app licenses and permissions that are downloaded from the SharePoint Store or App Catalog. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### Business Data Connectivity service database The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |Bdc_Service_DB_\<GUID\> <br/> | |Purpose <br/> |Stores external content types and related objects. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### Managed Metadata Service database The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2016/2019:** Managed Metadata Service_\<GUID\> <br/> **2013:** Managed Metadata Service Application_Metadata_\<GUID\> <br/> | |Purpose <br/> |Stores managed metadata and syndicated content types. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | > [!NOTE] > The Managed Metadata Service is the Taxonomy service. This database cannot be attached to a Managed Metadata Service Application in read only mode. The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2016/2019:** PerformancePoint Service Application_\<GUID\> <br/> **2013:** PerformancePoint Service_\<GUID\> <br/> | |Purpose <br/> |Stores temporary objects and saved user comments and settings. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### Power Pivot Service database The following table describes the supported high availability and disaster recov |:--|:--| |Default database name when it is installed with the Power Pivot for SharePoint Configuration Tool <br/> |DefaultPowerPivotServiceApplicationDB_\<GUID\> <br/> | |Purpose <br/> |Stores data refresh schedules, and workbook usage data for internal use by Power Pivot service applications. <br/> |-|Supports SQL Server synchronous mirroring in a farm for availability |Yes, but not recommended. Use AlwaysOn in Synchronous-Commit Mode instead. <br/> | -|Supports SQL Server AlwaysOn Availability Group in Synchronous-Commit Mode for availability <br/> |Yes, recommended. <br/> | +|Supports SQL Server synchronous mirroring in a farm for availability |Yes, but not recommended. Use Always On in Synchronous-Commit Mode instead. <br/> | +|Supports SQL Server Always On Availability Group in Synchronous-Commit Mode for availability <br/> |Yes, recommended. <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### Project Server database The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |ProjectWebApp <br/> | |Purpose <br/> | Each Project Web App database contains the following data: <br/> All Project and Portfolio Management (PPM) data <br/> Time tracking and Timesheet data <br/> Aggregated SharePoint project site data <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### SharePoint Search service databases The following tables provide the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |Search_Service_Application_DB_\<GUID\> <br/> | |Purpose <br/> | Stores the Search application configuration and system access control list (SACL) for the crawl component. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |No. Taking a copy of the Search Administration database and using it to re-create the Search service application is supported. <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No. Taking a copy of the Search Administration database and using it to re-create the Search service application is supported. <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No. Taking a copy of the Search Administration database and using it to re-create the Search service application is supported. <br/> | **Analytics Reporting database** The following tables provide the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |Search_Service_Application_AnalyticsReportingStoreDB_\<GUID\> <br/> | |Purpose <br/> |Stores the results for usage analysis reports and extracts information from the Link database when it is needed. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | **Crawl database** The following tables provide the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |Search_Service_Application_CrawlStoreDB_\<GUID\> <br/> | |Purpose <br/> |Stores the state of the crawled data and the crawl history. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |No <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | **Link database** The following tables provide the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |Search_Service_Application_LinkStoreDB_\<GUID\> <br/> | |Purpose <br/> |Stores the information that is extracted by the content processing component and click through information. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |No <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | ### Secure Store database The following table provides the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |Secure_Store_Service_DB_\<GUID\> <br/> | |Purpose <br/> |Stores and maps credentials, such as account names and passwords. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### SharePoint Translation Services database The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2016/2019:** TranslationService_\<GUID\> <br/> **2013:** SharePoint Translation Services_\<GUID\> <br/> | |Purpose <br/> |Stores information about pending and completed batch document translations with enabled file name extensions. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### State Service database The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2016/2019:** StateService_\<GUID\> <br/> **2013:** SessionStateService_\<GUID\> <br/> | |Purpose <br/> |Stores temporary state information for InfoPath Forms Services, Exchange Server, the chart Web Part, and Visio Services. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |No <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No <br/> | ### Subscription Settings service application The following table provides the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2019:** Subscription <br/> **2013/2016:** SettingsServiceDB <br/> | |Purpose <br/> |Stores features and settings for hosted customers. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### Usage and Health Data Collection database The following table provides the supported high availability and disaster recove |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |**2016/2019:** WSS_Logging <br/> **2013:** SharePoint_Logging <br/> | |Purpose <br/> |Stores health monitoring and usage data temporarily, and can be used for reporting and diagnostics. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes, but not recommended <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> **Note:** It is not possible to run PSConfig, (SharePoint Products Configuration Wizard or Microsoft PowerShell) to apply SharePoint CUs when this database is a member of an Always On Availability Group. <br/> |Yes, but not recommended <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> **Note:** It is not possible to run PSConfig, (SharePoint Products Configuration Wizard or Microsoft PowerShell) to apply SharePoint CUs when this database is a member of an Always On Availability Group. <br/> |Yes, but not recommended <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes, but not recommended <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |No. This database is farm specific. However, you can copy it to a disaster recovery environment for data mining. <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |No. This database is farm specific. However, you can copy it to a disaster recovery environment for data mining. <br/> | ### User Profile Service databases The following tables describe the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |User Profile Service Application_ProfileDB_\<GUID\> <br/> | |Purpose <br/> |Stores and manages users and their associated information. It also stores information about a user's social network in addition to memberships in distribution lists and sites. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | **Synchronization database** The following tables describe the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |User Profile Service Application_SyncDB_\<GUID\> <br/> | |Purpose <br/> |Stores configuration and staging data for use when profile data is synchronized with directory services such as Active Directory. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | **Social Tagging database** The following tables describe the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |User Profile Service Application_SocialDB_\<GUID\> <br/> | |Purpose <br/> |Stores social tags and notes created by users, alongside their respective URLs. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ### Word Automation Services database The following table describes the supported high availability and disaster recov |Default database name when it is installed with the SharePoint Products Configuration Wizard <br/> |WordAutomationServices_\<GUID\> <br/> | |Purpose <br/> |Stores information about pending and completed document conversions. <br/> | |Supports SQL Server synchronous mirroring in a farm for availability <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with synchronous-commit for availability <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with synchronous-commit for availability <br/> |Yes <br/> | |Supports SQL Server asynchronous mirroring or log-shipping to another farm for disaster recovery <br/> |Yes <br/> |-|Supports SQL Server AlwaysOn Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | +|Supports SQL Server Always On Availability Group with asynchronous-commit for disaster recovery <br/> |Yes <br/> | ## SQL Server System databases <a name="SQLSysDbs"> </a> SharePoint Server is built on SQL Server and uses the following SQL Server system databases: master, msdb, model, Resource, and tempdb. SQL Server provides a complete set of administrative tools that let users fully administer their system and manage all users and objects in a database. For more information about the SQL Server system databases, see [System Databases](/sql/relational-databases/databases/system-databases?viewFallbackFrom=sql-server-2014). -You can only mirror user databases, put them in a SQL Server AlwaysOn availability group or log ship them. You can't use these approaches to provide high availability or disaster recovery for the system databases. +You can only mirror user databases, put them in a SQL Server Always On availability group or log ship them. You can't use these approaches to provide high availability or disaster recovery for the system databases. ## SQL Server Reporting Services databases <a name="SQLRSDbs"> </a> A Reporting Services report server is a stateless server that stores application - Use the high availability features of the SQL Server Database Engine to maximize the uptime of the report server databases. If you configure a Database Engine instance to run in a failover cluster, you can select that instance when you create a report server database. -- Use SQL Server AlwaysOn Availability Groups with the Reporting Services databases and for data sources where applicable.+- Use SQL Server Always On Availability Groups with the Reporting Services databases and for data sources where applicable. - Configure multiple report servers to run in a scale-out deployment, where all the servers share a single report server database. Deploying multiple report server instances on different servers can help increase the level of uninterrupted service. A Reporting Services report server is a stateless server that stores application [Database types and descriptions in SharePoint Server](../technical-reference/database-types-and-descriptions.md) #### Other Resources -[AlwaysOn Availability Groups (SQL Server): Interoperability and Coexistence with Other Database Engine Features](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server) +[Always On Availability Groups (SQL Server): Interoperability and Coexistence with Other Database Engine Features](/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server) [Database Mirroring: Interoperability and Coexistence](/sql/database-engine/database-mirroring/database-mirroring-interoperability-and-coexistence-sql-server?viewFallbackFrom=sql-server-2014) |
| SharePoint | System Center Operations Manager Knowledge Articles | https://github.com/MicrosoftDocs/OfficeDocs-SharePoint/commits/public/SharePoint/SharePointServer/technical-reference/system-center-operations-manager-knowledge-articles.md | description: "Navigate to SharePoint Server articles about resolving alerts from [!INCLUDE[appliesto-2013-2016-2019-SUB-xxx-md](../includes/appliesto-2013-2016-2019-SUB-xxx-md.md)] -Navigate to SharePoint Server 2019. 2016, and 2013 articles about resolving alerts from the Systems Center Operations Manager (SCOM) management pack. +Navigate to SharePoint Server Subscription Edition, 2019, 2016, or 2013 articles for information about resolving alerts from the Systems Center Operations Manager (SCOM) management pack. The articles in this section are knowledge articles for the SharePoint Server 2016 Monitoring Pack for System Center Operations Manager 2016. These articles are also knowledge articles for the SharePoint Server 2013 and SharePoint Foundation 2013 Monitoring Pack for System Center Operations Manager 2012. > [!NOTE] > The Project Server 2013 knowledge articles for Systems Center Operations Manager only appear in the SharePoint Server 2013 and SharePoint Foundation 2013 Monitoring Pack for System Center Operations Manager 2012. -Typically, you would see these articles after you click a link in an alert in the Operations Manager console. You can use these articles to help you troubleshoot problems in SharePoint Server. +Typically, you would see these articles after you select a link in an alert in the Operations Manager console. You can use these articles for help with troubleshooting problems in SharePoint Server. Download and install: +- [System Center Management Pack for SharePoint Server Subscription Edition](https://www.microsoft.com/download/details.aspx?id=104089) + - [System Center Management Pack for SharePoint Server 2019](https://www.microsoft.com/download/details.aspx?id=57776) - [System Center Monitoring Pack for SharePoint Server 2016](https://go.microsoft.com/fwlink/?LinkID=746863&clcid=0x409) |