**上一次修改主题:**2017-06-29

**摘要:**安装软件更新,以在运行 SharePoint Server 2016 的服务器上执行内部版本间升级。

本文内容:

  • 开始之前

  • 确定更新策略

  • 监视安装进度

  • 初始状态

  • 使用具有向后兼容的就地方法

  • 在承载搜索组件的服务器上安装软件更新

开始之前

在开始软件更新过程之前,先阅读以下有关权限、硬件要求、软件要求和更新过程的信息。

若要执行本文中的 Microsoft PowerShell 过程,您必须具有以下成员资格和角色:

  • SQL Server 实例上的 securityadmin 固定服务器角色

  • 要更新的所有数据库上的 db_owner 固定数据库角色

  • 您运行 Microsoft PowerShell cmdlet 的服务器上的本地管理员

在安装更新之前,请确认满足下面的条件:

  • 所有前端 Web 服务器都负载平衡,而且与负载平衡器一起处于循环中。

  • 所有场服务器都正常运行。对于 Search,您可以使用 Microsoft PowerShell cmdlet Get-SPEnterpriseSearchStatus 或转到“管理中心”>“管理服务应用程序”>“Search_service_application_name”以查看服务器状态。

  • 所有数据库都处于活动状态,而且正确运行。

如果以上任何条件不满足,则不要开始更新。在继续操作之前先解决所有问题。

修复阶段完成后,SharePoint Server 2016 可以应对某些升级失败的问题。但是,如果内部版本间升级失败,您可能必须从备份中还原。因此,在开始更新过程之前,请确保执行完整备份。还原完成后,您可以继续更新。已完成的任务不会再次运行。有关详细信息,请参阅以下资源:

确定更新策略

开始部署软件更新之前,请验证您计划使用的更新策略是否最适合您的 SharePoint Server 2016 环境。有几个因素(如成本和复杂程度)可确定要用于部署软件更新的策略。

备注

本文中的某些链接转到关于版本间升级(而不是内部版本间升级)的内容。但是,两种类型的升级的大致过程相似。例如,数据库升级阶段与内部版本间升级和版本间升级基本上相同。

监视安装进度

监视部署更新的过程以验证更新是否按计划进行。可能存在一些阻止更新的问题,或者存在将导致更新的服务器场具有不能按预期工作的元素。请格外注意数据库同步和自定义。

我们建议您使用 管理中心 中的“升级和迁移”页作为主要工具,用来实时查看产品和补丁安装状态、数据状态和更新状态。

安装程序运行后,您也可以查看日志文件并使用 Microsoft PowerShell 检查安装进度。

初始状态

下图显示了用作本文中介绍的每个修补方案示例的服务器场拓扑。

Shows an example of a farm topology for a patching scenario

使用具有向后兼容的就地方法

此方案利用 SharePoint Server 2016 的向后兼容性和延迟升级功能,以避免部署软件更新需要的服务器场停机时间。

此更新方案使用两个阶段在服务器场中的服务器上安装更新。这些阶段为:

  1. 在场服务器上安装更新。

  2. 执行内部版本间升级以完成修补过程。

有关详细信息,请参阅SharePoint Server 2016 的软件更新概述软件更新过程部分。

更新阶段

下图演示了要在服务器场上安装更新所要求的步骤。您可以使用该图作为指导,以完成下面过程中的步骤(“安装更新”)。

Illustrates how in-place with backward compatibility method works by take half of web server offline, patch it, bring back online, then repeat same for the remaining web servers. Note, the SharePoint Products Configuration Wizard is not run in this step.

安装更新

  1. 运行 sts2016-kb3115088-fullfile-x64-glb.exe 文件(即 sts.msp)。

  2. 运行 wssloc2016-kb2920690-fullfile-x64-glb.exe 文件(即 wssmui.msp)。

    备注

    您可能需要在服务器场中为每种安装的语言提取 wssmui.msp 文件。

  3. 从负载平衡器的循环中删除第一台 Web 服务器 (WEB-1),或暂停负载平衡器以停止对服务器的传入请求。

  4. 修补 Web 服务器 (WEB-1)。

  5. 将 Web 服务器 (WEB-1) 添加回循环中。

  6. 对其余的 Web 服务器(WEB-2 到 WEB-4)重复步骤 3 和 4。

  7. 在负载均衡循环之外的每台 Web 服务器上,运行要安装的修补程序(即,sts.msp 和 wssmui.msp 文件)。此时不要在这些服务器上运行 SharePoint 产品配置向导。查看升级日志文件,验证这两台 Web 服务器都已成功更新。

  8. 在托管 SharePoint 管理中心网站的所有应用程序服务器上安装该修补程序。此时不要运行 SharePoint 产品配置向导。

  9. 如果您的服务器场具有不托管搜索组件的附加应用程序服务器,请运行更新执行文件,在这些服务器上安装更新。此时不要在这两台服务器上运行 SharePoint 产品配置向导。

  10. 检查升级日志文件,验证这些应用程序服务器均已成功更新。

至此,在此过程中仍然必须升级数据库和其他组件,例如设置、功能和网站级别的数据,因为 SharePoint 产品配置向导 未在任何服务器场中的服务器上运行。然而,服务器场应能够在向后兼容模式下运行。

升级阶段

下图显示了升级场服务器以完成修补过程的步骤。

Steps to use during the upgrade phase of an in-place software update

使用上图作为指南,以在下面的过程中遵循这些步骤。

重要

在升级序列中的下一台服务器之前,监视每台服务器上的升级状态。我们建议您在开始升级前,先创建服务器场的备份。

以下过程显示了升级服务器场的所有步骤。

  • Services

    如果软件更新包含对必须应用的服务的更新,则可以升级服务,然后恢复运行服务器场(下面过程中的步骤),直到可以有更长的服务器场中断来完成内容和服务器场的升级。

  • Content databases

    也可以同时为非常少量的内容数据库并行升级各个内容数据库。然而,不要尝试并行升级太多内容数据库,因为它将使整体升级过程变慢。我们建议,不要在相同的 SQL Server 卷上一次升级两个以上的内容数据库。相隔几分钟启动将并行发生的每个内容数据库的升级,以防止在升级过程启动时的锁定争用。此外,限制在单一 Web 服务器或应用程序服务器上升级的内容数据库的数量。每个附加升级过程将占用相对大量的资源。可以在每个 Web 服务器或应用程序服务器上升级的内容数据库的数量通常为四个数据库。然而,不管由哪个 Web 服务器或应用程序服务器发起升级,确保不要超过在每个 SQL Server 卷上升级的数据库的数量。

升级服务器场

  1. 使用 Windows PowerShell Upgrade-SPContentDatabase cmdlet 升级每个内容数据库。有关详细信息,请参阅 Upgrade-SPContentDatabase。这是可选步骤,但将帮助确保所有内容数据库首先升级。它具有启用某些并行升级以避免中断时间的优势。如果未执行,则在运行 SharePoint 2016 产品配置向导以升级场服务器时,所有剩余的未升级的内容数据库将按序列升级。

    备注

    针对每个数据库运行 Upgrade-SPContentDatabase cmdlet。您可以从任何升级的 Web 服务器或应用程序服务器中运行此 cmdlet。

  2. 在管理中心服务器 (APP-1) 上,执行以下操作之一:

    • 运行 SharePoint 2016 产品配置向导。

    • 在 Microsoft PowerShell 命令提示符处运行以下命令。

      cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin
      .\psconfig.exe -cmd secureresources -cmd installfeatures -cmd upgrade -inplace b2b -force -wait -cmd applicationcontent -install 
      

    备注

    如果更新过程因任何原因失败,您可以运行 Copy-SPSideBySideFiles cmdlet 来恢复更新的状态。有关并排文件的更多信息,请参阅 Copy-SPSideBySideFiles

    重要

    SharePoint 产品配置向导 还启动配置数据库以及所有其他未升级数据库的即时升级。因为内容数据库大多是已升级的唯一数据库,所以如上一步中所述,所有服务应用程序数据库也在此步骤中升级。

  3. 从负载平衡器的循环中删除 Web 服务器 (WEB-1),或暂停负载平衡器以停止对服务器的传入请求

    在从循环中删除的 Web 服务器 (WEB-1) 上,在 PowerShell 命令提示符处运行以下命令。

    cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin
    .\psconfig.exe -cmd secureresources -cmd installfeatures -cmd upgrade -inplace b2b -force -wait -cmd applicationcontent -install 
    
  4. 将 Web 服务器 (WEB-1) 添加回循环中。

  5. 针对其他 Web 服务器 (WEB 2、WEB-3 和 WEB-4)重复步骤 3 到 4。

  6. 根据需要,Upgrade specific services某些更新可能还需要您运行其他 PowerShell cmdlet 来升级特定的服务应用程序。软件更新的注释可能指示您必须升级特定服务,以便该服务在修补后继续运行。用于升级特定服务应用程序的其他 PowerShell cmdlet(如果必需)应包含在注释中。

  7. 在其余的应用程序服务器 (APP-2) 上运行 SharePoint 2016 产品配置向导 或 PSConfig(如此过程中的步骤 3)。

  8. 对 APP-3 和 APP-4 服务器重复步骤 3 和 4。

  9. 确认更新完成并且成功。

在托管搜索组件的服务器上安装软件更新

仅当本文中的其他过程指示您执行本部分中的过程时才执行此过程。这包括本部分中的下列过程:

  • 在服务器场停机时更新托管搜索组件的服务器

  • 以最短停机时间更新服托管搜索组件的服务器

  • 以最短停机时间确定服务器可用性组是否可更新

在服务器场停机时更新托管搜索组件的服务器

  1. 在 PowerShell 命令提示符处键入下列命令,暂停 Search Service 应用程序:

    $ssa=Get-SPEnterpriseSearchServiceApplication 
    Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  2. 在托管一个或多个搜索组件的每台服务器上,按以下顺序停止与搜索相关的 Windows 服务:

    1. SPTimerV4

    2. Osearch16

    3. SPSearchHostController

    重要

    在停止下一项服务之前,确认每项服务均已停止。

  3. 在托管一个或多个搜索组件的每台服务器上,运行更新可执行文件以安装更新。

  4. 在托管一个或多个搜索组件的每台服务器上,按以下顺序启动与搜索相关的 Windows 服务:

    1. SPSearchHostController

    2. Osearch16

    3. SPTimerV4

  5. 在 PowerShell 命令提示符处键入以下命令,确认所有搜索组件在更新后均已恢复活动状态:

    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -ne "Active"} | fl
    

    重新运行命令,直至输出中不列出任何搜索组件。

  6. 在 PowerShell 命令提示符处键入以下命令,恢复 Search Service 应用程序:

    Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  7. 验证此服务器场正在爬网更新内容,并且能够对新的和修改过的文档编制索引。为此,您可以添加或修改网站集的项、对本地 SharePoint 网站内容源执行爬网,然后对项目执行搜索并验证该项目出现在搜索结果中。

以最短停机时间更新服托管搜索组件的服务器

  1. 将托管搜索组件的服务器分为两个可用性组,以便在更新和内部版本间升级过程中尽量减少停机时间。(只要其中一个组处于活动状态且运行状况良好,服务器场就可提供查询,并对内容进行爬网和索引。)有关如何将服务器分成两个可用性组的说明,请参阅本文后面的过程以最短停机时间确定服务器可用性组是否可更新。

  2. 在 PowerShell 命令提示符处键入以下命令,暂停 Search Service 应用程序:

    Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  3. 在服务器可用性组 1 中的每台服务器上,按以下顺序停止与搜索相关的 Windows 服务:

    1. SPTimerV4

    2. Osearch16

    3. SPSearchHostController

    重要

    在停止下一项服务之前,确认每项服务均已停止。

  4. 在可用性组 1 中的每台服务器上,运行更新可执行文件以安装更新。

  5. 在可用性组 2 中的每台服务器上,按照与停止可用性组 1 中服务器的相同顺序,停止与搜索相关的 Windows 服务。同样,在停止下一项服务之前,务必确认每项服务均已停止。

  6. 在可用性组 1 中的每台服务器上,按以下顺序启动与搜索相关的 Windows 服务:

    1. SPSearchHostController

    2. Osearch16

    3. SPTimerV4

  7. 等到与可用性组 1 关联的所有搜索组件处于活动状态。要确定哪些组件处于活动状态,请在 PowerShell 命令提示符处键入以下命令:

    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
    

    重新运行该命令,直至与可用性组 1 关联的所有搜索组件均在输出中列出。

  8. 在可用性组 2 中的每台服务器上,运行更新可执行文件以安装更新。

  9. 在可用性组 2 中的每台服务器上,按照与启动可用性组 1 中服务器的相同顺序,启动与搜索相关的 Windows 服务。

  10. 等到与可用性组 2 关联的所有搜索组件处于活动状态。要确定哪些组件处于活动状态,请在 PowerShell 命令提示符处键入以下命令:

    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
    

    重新运行该命令,直至与可用性组 2 关联的所有搜索组件均在输出中列出。

  11. 在 PowerShell 命令提示符处键入以下命令,恢复 Search Service 应用程序:

    Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
    
  12. 验证此服务器场正在爬网更新内容,并且能够对新的和修改过的文档编制索引。为此,您可以添加或修改网站集的项、对本地 SharePoint 网站内容源执行爬网,然后对项目执行搜索并验证该项目出现在搜索结果中。

以最短停机时间确定服务器可用性组是否可更新

  1. 在场中的任一服务器上启用 SharePoint Server 2016 命令行管理程序。

  2. 在 PowerShell 命令提示符处键入下列命令,确定主搜索管理组件以及托管该组件的服务器:

    $ssa=Get-SPEnterpriseSearchServiceApplication
    Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where { (($_.State -ne "Unknown") -and ($_.Name -match "Admin")) } | ForEach {if (Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Component $_.Name -Primary) { Get-SPEnterpriseSearchTopology -SearchApplication $ssa -active | Get-SPEnterpriseSearchComponent -identity $($_.Name) } }
    
  3. 确定可用性组 1 中的服务器集。这些服务器必须满足以下三个要求:

    • 服务器集必须包含下列类型的搜索组件中的一个或多个,但不是全部:

      • 内容处理组件

      • 查询处理组件

      • 分析处理组件

      • 爬网组件

      • 索引组件

    • 服务器集必须包含每个索引分区的索引组件中的一个或多个,但不是全部:

    • 服务器集必须包含一个除本过程步骤 2 中识别的主组件以外的搜索管理组件。

  4. 确定可用性组 2 中的服务器集。该服务器集必须包含托管搜索组件的所有剩余服务器,其中包括托管在本过程步骤 2 中识别的主搜索管理组件的服务器。