安装 SharePoint Server 的软件更新
适用于:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365
开始之前
在开始软件更新过程之前,先阅读以下有关权限、硬件要求、软件要求和更新过程的信息。
注意
虽然本文中的步骤涉及 SharePoint Server 2016,但它们适用于 SharePoint Foundation 2013、SharePoint Server 2013、SharePoint Server 2019 和 SharePoint Server 订阅版本,除非另有说明。
要执行本文中的过程,您必须具有以下成员资格和角色:
SQL Server 实例上的 securityadmin 固定服务器角色
要更新的所有数据库上的 db_owner 固定数据库角色
您运行 Microsoft PowerShell cmdlet 的服务器上的本地管理员
在安装更新之前,请确认满足下面的条件:
所有前端 Web 服务器都负载平衡,而且与负载平衡器一起处于循环中。
服务器场中的所有服务器都正常运行。 对于“搜索”,可以使用 Microsoft PowerShell cmdlet Get-SPEnterpriseSearchStatus 或转到管理中心 > 管理服务应用程序 >Search_service_application_name查看服务器状态。
所有数据库都处于活动状态,而且正确运行。
如果不满足上述任何条件,请不要启动更新。 在继续操作之前先解决所有问题。
SharePoint Server 2016、2019 和 Subscription Edition 可以在修补阶段完成后处理某些升级失败。 但是,如果内部版本间升级失败,您可能必须从备份中还原。 因此,在开始更新过程之前,请确保执行完整备份。 还原完成后,您可以继续更新。 已完成的任务不会再次运行。 有关详细信息,请参阅以下资源:
确定更新策略
在开始部署软件更新之前,请验证计划使用的更新策略是否适合 SharePoint Server 2016、2019 或订阅版环境。 有多个因素可确定用于部署软件更新的策略,比如停机时间的减少、成本和复杂性。
有关数据库附加过程工作原理的详细信息,请参阅 从 SharePoint 2013 升级到 SharePoint Server 2016 的升级过程概述、到 SharePoint Server2019 的升级过程概述和 升级到 SharePoint Server 订阅版的概述中的关系图。
注意
本文中的某些链接转到关于版本间升级(而不是内部版本间升级)的内容。 但是,两种类型的升级的大致过程相似。 例如,数据库升级阶段与内部版本间升级和版本间升级基本上相同。
监视安装进度
监视部署更新的过程以验证更新是否按计划进行。 可能存在阻止更新的问题,或者导致具有无法按预期工作的元素的更新场。 请格外注意数据库同步和自定义。
We recommend that you use the Upgrade and Migration page in Central Administration as the primary tool to view product and patch installation status, data status, and update status in real time.
安装程序运行后,您也可以查看日志文件并使用 Microsoft PowerShell 检查安装进度。
初始状态
下图显示了用作本文中介绍的每个修补方案示例的服务器场拓扑。
准备好继续时,请仅执行本文中的以下过程之一来安装更新:
使用无向后兼容性的就地方法
使用有向后兼容性的就地方法
使用数据库附加方法以提高现有内容的可用性
使用无向后兼容的就地方法
在此方案中,将禁用对前端 Web 服务器的传入请求,从而有效地关闭整个场。 然后,在所有场服务器上安装更新。 此策略结合了从 SharePoint 2013 到 SharePoint Server 2016 的升级过程概述的 SharePoint Server 2016 软件更新概述 部分所述的更新和内部版本到内部版本 升级阶段。
下图演示了要在服务器场上安装更新所要求的步骤。 您可以使用该图作为指导,以完成下面过程中的步骤("安装无向后兼容的更新")。
安装不向后兼容的更新的具体步骤
通知用户在安装更新时服务器场不可用。
从负载平衡器的循环中删除所有 Web 服务器(WEB-1 到 WEB-4),或暂停负载平衡器以停止对服务器的传入请求。
运行更新可执行文件,以在托管管理中心的应用程序服务器 (APP-1) 上安装更新。
运行更新可执行文件以在托管搜索组件的所有其他应用程序服务器 (APP-2) 上安装更新。 为此,请执行本文稍后出现的 主机搜索组件 过程,然后返回到此过程的下一步。 目前不要在这些服务器上运行 SharePoint 产品配置向导。
检查升级日志文件,验证所有应用程序服务器均已成功更新。
升级日志文件和升级错误日志文件位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\16\LOGS 中。 升级日志文件按以下格式命名:Upgrade-YYYYMMDD-HHMMSS-SSS.log,其中 YYYYMMDD 是日期,HHMMSS-SSS 是时间(24 小时制的小时数,然后是分钟数、秒数和毫秒数)。 升级错误日志文件将所有错误和警告合并到一个更小的文件中,命名为 Upgrade-YYYYMMDD-HHMMSS-SSS-error.log。
登录到第一台 Web 服务器 (WEB-1)。
运行可执行文件以在 Web 服务器上安装更新。
运行可执行文件以在其余 Web 服务器(WEB-2、WEB-3 和 WEB-4)上安装更新。
检查升级日志文件,验证所有 Web 服务器均已成功更新。
在 管理中心 服务器 (APP-1) 上运行 SharePoint 产品配置向导。 这会升级配置数据库并升级每个内容数据库。
有关如何运行向导的信息,请参阅在 SharePoint Server 2016、2019 或订阅版 的多个服务器上安装 SharePoint Server。 有关 SharePoint 2013 的三层场,请参阅在多台服务器上安装 SharePoint 2013。
在其他应用程序服务器上运行 SharePoint 产品配置向导。
在第一台 Web 服务器 (WEB-1) 上运行 SharePoint 产品配置向导。
注意
运行配置向导以确保当对于特定服务器的更新失败时,该错误不会传播到其他 Web 服务器。 例如,对一台服务器的更新失败可能使对一个或多个网站集的更新失败。
为其余的每台 Web 服务器重复上一步。
验证更新是否成功完成。 有关详细信息,请参阅 在 SharePoint Server 2016 中验证数据库升级。
将 Web 服务器(WEB-1 至 WEB-4)添加到负载平衡器中的循环,或启动负载平衡器以启用对服务器的传入请求。
通知用户服务器场恢复可用状态。 你已完成安装更新并使用本文。
使用具有向后兼容的就地方法
此方案利用 SharePoint 的向后兼容性和延迟升级功能来减少部署软件更新所需的场停机时间。 但是,不会消除停机时间。 升级数据库内容时,站点和服务将不可用。
此更新方案使用两个阶段在服务器场中的服务器上安装更新。 这些阶段为:
在场服务器上安装更新。
执行内部版本间升级以完成修补过程。
重要
在更新阶段,服务器场可以继续处于生产状态,并具有最少的停机时间。 然而,在升级阶段,服务器场将不可用。 如果用户尝试在升级服务器场时访问内容,出于资源争用和锁定原因,将导致升级失败或在升级过程中速度过慢。 这样的尝试不受支持而且未经测试。
有关详细信息,请参阅:
- SharePoint Server 2016、2019 和订阅版的软件更新概述
- 从 SharePoint 2013 升级到 SharePoint Server 2016 的过程概述
- 在 SharePoint Server 2019 中验证数据库升级
- 在 SharePoint Server 订阅版中验证数据库升级
更新阶段
下图演示了要在服务器场上安装更新所要求的步骤。 您可以使用该图作为指导,以完成下面过程中的步骤("安装更新")。
安装更新的具体步骤
从负载平衡器中的循环中删除一半的 Web 服务器(WEB-1 和 WEB-2),或者暂停负载平衡器以停止对服务器的传入请求。
在负载平衡循环之外的每台 Web 服务器(WEB-1 和 WEB-2)上,运行可执行文件以安装更新。 不要在这些服务器上运行 SharePoint 产品配置向导。 查看升级日志文件,验证这两台 Web 服务器都已成功更新。
升级日志文件和升级错误日志文件位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\16\LOGS 中。 升级日志文件按以下格式命名:Upgrade-YYYYMMDD-HHMMSS-SSS.log,其中 YYYYMMDD 是日期,HHMMSS-SSS 是时间(24 小时制的小时数,然后是分钟数、秒数和毫秒数)。 升级错误日志文件将所有错误和警告合并到一个更小的文件中,命名为 Upgrade- YYYYMMDD-HHMMSS-SSS-error.log。
从负载平衡器的循环中删除其余的 Web 服务器(WEB-3 和 WEB-4),或暂停负载平衡器以停止对服务器的传入请求。
将更新的 Web 服务器(WEB-1 和 WEB-2)添加回负载平衡循环。
在负载平衡循环之外的每台 Web 服务器上,运行可执行文件以安装更新。 目前不要在这些服务器上运行 SharePoint 产品配置向导。 查看升级日志文件,验证这两台 Web 服务器都已成功更新。
将更新的 Web 服务器(WEB-3 和 WEB-4)添加回负载平衡循环。
在托管搜索组件的所有应用程序服务器(APP-1 和 APP-2)上安装更新。 为此,请执行本文后面部分出现的 安装 SharePoint Server 2016 软件更新 过程,然后返回到此过程中的下一步。 目前不要运行 SharePoint 产品配置向导。
如果场具有不托管搜索组件的其他应用程序服务器,请运行更新可执行文件以在这些服务器上安装更新。 目前不要在这些服务器上运行 SharePoint 产品配置向导。
检查升级日志文件,验证这些应用程序服务器均已成功更新。
在此过程中,数据库和其他组件(如设置、功能和站点级数据)仍必须升级,因为 SharePoint 产品配置向导未在任何服务器场服务器上运行。 然而,服务器场应能够在向后兼容模式下运行。
升级阶段
下图演示了升级服务器中的服务器以完成修补过程的步骤。 在此过程中,用户无法使用正在升级的网站。
使用上图作为指南,以在下面的过程中遵循这些步骤。
重要
在升级序列中的下一台服务器之前,监视每台服务器上的升级状态。 我们建议您在开始升级前,先创建服务器场的备份。
以下过程显示升级服务器场的所有步骤。 在同一中断时段,您可以升级所有组件,或者可以利用一些较短的中断时段并在不同时间升级单独的服务器场部分。 如果想要中断升级阶段,可以在单独的中断时段升级以下组件:
服务
如果软件更新包含对必须应用的服务的更新,则可以升级服务,然后在以下过程中继续运行服务器场 (步骤 8) ,直到可能需要更长的服务器场中断才能完成内容和服务器场升级。
内容数据库
您可以利用较短的服务器场中断每次仅升级一些内容数据库(下面过程中的步骤 3 和 4),然后恢复服务器场运行(下面过程中的步骤 8)。 您可以在后续中断时段重复该过程,直到升级所有内容,而且服务器场中的服务器已为升级做好准备。
您也可以同时为非常少量的内容数据库并行升级各个内容数据库。 但是,请勿尝试并行升级过多的内容数据库,因为这会减慢整体升级过程并延长中断时间。 建议一次不要在同一 SQL Server 卷上升级两个以上的内容数据库。 相隔几分钟启动将并行发生的每个内容数据库的升级,以防止在升级过程启动时的锁定争用。 此外,限制在单一 Web 服务器或应用程序服务器上升级的内容数据库的数量。 每个额外的升级过程都会消耗相对大量的资源。 可以在每个 Web 服务器或应用程序服务器上升级的内容数据库的数量通常为四个数据库。 然而,不管由哪个 Web 服务器或应用程序服务器发起升级,确保不要超过在每个 SQL Server 卷上升级的数据库的数量。
升级服务器场
从负载平衡器的循环中删除 Web 服务器(WEB-1 到 WEB-4),或暂停负载平衡器以停止对服务器的传入请求。
重要
在升级完成并且服务器返回到活动的负载平衡状态之前,网站和服务将不可用。
根据需要升级特定服务
某些更新可能还需要运行其他 PowerShell cmdlet 来升级特定的服务应用程序。 软件更新的注释可能指示您必须升级特定服务,以便该服务在修补后继续运行。 例如,这适用于无法在向后兼容模式下运行的服务。
您可以创建较短的脱机期间来升级服务而无需升级整个服务器场。 如果需要,用于升级特定服务应用程序的其他 PowerShell cmdlet 应包含在说明中。
(可选) 使用 PowerShell Upgrade-SPContentDatabase cmdlet 升级每个内容数据库。 有关详细信息,请参阅 Upgrade-SPContentDatabase。
这是一个可选步骤,但它有助于确保首先升级所有内容数据库。 它具有启用某些并行升级以缩短中断时间的优势。 如果未执行,则运行 SharePoint 产品配置向导来升级场服务器时,所有剩余的非升级内容数据库都将进行串行升级。
重要
为每个数据库运行 Upgrade-SPContentDatabase cmdlet。 您可以从任何已升级的 Web 服务器或应用程序服务器运行此 cmdlet。 请注意,当此过程在每个数据库上运行时,该数据库的内容将不可用。
在管理中心服务器 (APP-1) 上,执行以下操作之一:
运行 SharePoint 产品配置向导
在 PowerShell 命令提示符处运行以下命令:
cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
重要
SharePoint 产品配置向导 还启动配置数据库以及所有其他未升级数据库的即时升级。 因为内容数据库大多是已升级的唯一数据库,所以如上一步中所述,所有服务应用程序数据库也在此步骤中升级。 在此过程运行时,您的网站将不可用。
在其余的应用程序服务器 (APP-2) 上运行 SharePoint 产品配置向导 或 PSConfig(如此过程中的步骤 4)。
在 Web 服务器(WEB-1 至 WEB-4)上运行 SharePoint 产品配置向导 或 PSConfig(如此过程中的步骤 4)。
验证更新是否成功完成。
有关详细信息,请参阅 在 SharePoint 2013 中验证数据库升级、 在 SharePoint Server 2016 中验证数据库升级、 在 SharePoint Server 2019 中验证数据库升级和 在 SharePoint Server 订阅版中验证数据库升级 。
将升级的 Web 服务器(WEB-1 至 WEB-4)添加回负载平衡器中的循环。
你已完成安装更新并使用本文。
使用数据库附加方法以获取现有内容的高可用性
为了确保现有内容的高可用性,此方案在现有服务器场上使用只读数据库。 您在新服务器场上安装更新,并在更新完成后,将用户流量路由到新的服务器场。
下图演示了通过使用数据库附加方法,在新的服务器场上安装更新需要遵循的步骤顺序。
有关详细信息,请参阅 将内容数据库从 SharePoint 2013 升级到 SharePoint Server 2016、 将数据库从 SharePoint 2016 升级到 SharePoint Server 2019 和将 数据库从 SharePoint Server 2019 和 SharePoint Server 2016 升级到 SharePoint Server 订阅版本。
使用上图作为指南,以在下面的过程中遵循建议的步骤。
使用数据库附加方法安装更新的具体步骤
创建用于安装软件更新的新场。 此场不需要前端 Web 服务器。
有关详细信息,请参阅 为数据库附加升级创建 SharePoint 2016 场、 为数据库附加升级创建 SharePoint Server 2019 场和 为数据库附加升级创建 SharePoint Server 订阅版本场。
注意
如果原始服务器场使用数据库镜像,则在新的服务器场上部署软件更新后配置镜像。
在现有服务器场上配置数据库,以便它们处于只读状态。
注意
如果现有服务器场已镜像,则在将数据库设置为只读前,暂停镜像。
有关如何配置只读数据库的详细信息,请参阅将 内容数据库从 SharePoint 2013 升级到 SharePoint Server 2016,并在 SharePointServer 中运行使用只读数据库的场中的“将以前的版本) 数据库设置为 Read-Only (数据库附加 Read-Only 数据库”部分。
在现有服务器场上配置服务应用程序数据库,以使它们处于只读状态。 这可防止意外更改服务应用程序。
注意
步骤 4 到 13 不适用于 SharePoint Foundation 2013、SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 订阅版。
如果要修补 User Profile Service 应用程序数据库,则必须从旧数据库导出用户配置文件同步服务加密密钥,然后将密钥导入新数据库。 此密钥也称为 Microsoft Identity Integration Server (MIIS) 密钥、同步服务加密密钥以及 Forefront Identity Manager 2010 (FIM 2010) 密钥。 如果未正确导出然后导入密钥,同步服务将不会启动。 要导出加密密钥,请完成以下步骤:
使用场管理员凭据登录到包含旧 User Profile Service 服务应用程序数据库的计算机。
打开命令提示符窗口,然后转到以下文件夹:
%Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\
键入以下命令,然后按 Enter:
miiskmu.exe /e<路径>
其中 <,Path> 是要将密钥导出到的文件的完整路径。
在现有服务器场上备份内容数据库。 有关详细信息,请参阅在 SharePoint Server 中规划备份和恢复。
要导入加密密钥,请执行以下步骤:
使用场管理员凭据登录到包含新 User Profile Service 服务应用程序数据库的计算机。
尝试启动用户配置文件同步服务。 由于尚未导入加密密钥,因此服务不会启动。 通过使用 ULS 日志或确保服务的状态为“ 已停止”来确认服务未启动。
打开命令提示符窗口,然后转到以下文件夹:
%Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\
键入以下命令,然后按 Enter:
miiskmu.exe /i<Path>{0E19E162-827E-4077-82D4-E6ABD531636E}
其中 <,Path> 是将密钥导出到的文件的完整路径。
(可选)要检查加密密钥是否正确导入,在命令提示符下,键入以下命令,然后按 Enter:
miiskmu.exe /c {0E19E162-827E-4077-82D4-E6ABD531636E}
将内容数据库还原到新的数据库服务器。
在新的服务器场上为旧服务器场中的每个现有服务应用程序创建服务应用程序。
从现有服务器场复制所有设置。
使用数据库附加方法在新服务器场上创建数据库。 有关详细信息,请参阅 将数据库从 SharePoint 2013 升级到 SharePoint Server 2016 和 在 SharePoint Server 中附加和还原只读内容数据库。
验证新服务器场没有问题。
通过将 DNS 配置为指向新的服务器场或确保新服务器场负载平衡,启用新服务器场作为生产服务器场。 验证用户可以访问新服务器场。
给用户一些时间,使他们从缓存的 DNS 进行切换,然后弃用旧服务器场。
验证更新是否成功完成。 有关详细信息,请参阅 在 SharePoint 2016 中验证数据库升级。
你已完成安装更新并使用本文。
在托管搜索组件的服务器上安装软件更新
仅当本文中的其他过程指向这些过程时,才执行本节中的过程。 这包括本节中的以下过程:
在服务器场停机时更新托管搜索组件的服务器
以最短停机时间更新服托管搜索组件的服务器
以最短停机时间确定服务器可用性组是否可更新
在服务器场停机时更新托管搜索组件的服务器
在 PowerShell 命令提示符处键入下列命令,暂停 Search Service 应用程序:
$ssa=Get-SPEnterpriseSearchServiceApplication Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
在托管一个或多个搜索组件的每台服务器上,按以下顺序停止与搜索相关的 Windows 服务:
SPTimerV4
OSearch16
SPSearchHostController
重要
在停止下一项服务之前,确认每项服务均已停止。
在托管一个或多个搜索组件的每台服务器上,运行更新可执行文件以安装更新。
在托管一个或多个搜索组件的每台服务器上,按以下顺序启动与搜索相关的 Windows 服务:
SPSearchHostController
OSearch16
SPTimerV4
在 PowerShell 命令提示符处键入以下命令,确认所有搜索组件在更新后均已恢复活动状态:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -ne "Active"} | fl
重新运行命令,直至输出中不列出任何搜索组件。
在 PowerShell 命令提示符处键入以下命令,恢复 Search Service 应用程序:
Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
验证此服务器场正在爬网更新内容,并且能够对新的和修改过的文档编制索引。 为此,您可以添加或修改网站集的项、对本地 SharePoint 网站内容源执行爬网,然后对项目执行搜索并验证该项目出现在搜索结果中。
以最短停机时间更新服托管搜索组件的服务器
将托管搜索组件的服务器分为两个可用性组,以便在更新和内部版本间升级过程中尽量减少停机时间。 (只要其中一个组处于活动状态且运行正常,场就可以提供查询和爬网和索引内容。) 有关如何将服务器划分为两个可用性组的说明,请参阅本文后面的 确定服务器可用性组以最短停机时间进行更新 的过程。
在 PowerShell 命令提示符处键入以下命令,暂停 Search Service 应用程序:
Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
在服务器可用性组 1 中的每台服务器上,按以下顺序停止与搜索相关的 Windows 服务:
SPTimerV4
OSearch16
SPSearchHostController
重要
在停止下一项服务之前,确认每项服务均已停止。
在可用性组 1 中的每台服务器上,运行更新可执行文件以安装更新。
在可用性组 2 中的每台服务器上,按照与停止可用性组 1 中服务器的相同顺序,停止与搜索相关的 Windows 服务。 同样,在停止下一个服务之前,请务必验证每个服务是否已停止。
在可用性组 1 中的每台服务器上,按以下顺序启动与搜索相关的 Windows 服务:
SPSearchHostController
OSearch16
SPTimerV4
等到与可用性组 1 关联的所有搜索组件处于活动状态。 要确定哪些组件处于活动状态,请在 PowerShell 命令提示符处键入以下命令:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
重新运行该命令,直至与可用性组 1 关联的所有搜索组件均在输出中列出。
在可用性组 2 中的每台服务器上,运行更新可执行文件以安装更新。
在可用性组 2 中的每台服务器上,按照与启动可用性组 1 中服务器的相同顺序,启动与搜索相关的 Windows 服务。
等到与可用性组 2 关联的所有搜索组件处于活动状态。 要确定哪些组件处于活动状态,请在 PowerShell 命令提示符处键入以下命令:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
重新运行该命令,直至与可用性组 2 关联的所有搜索组件均在输出中列出。
在 PowerShell 命令提示符处键入以下命令,恢复 Search Service 应用程序:
Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
验证此服务器场正在爬网更新内容,并且能够对新的和修改过的文档编制索引。 为此,您可以添加或修改网站集的项、对本地 SharePoint 网站内容源执行爬网,然后对项目执行搜索并验证该项目出现在搜索结果中。
以最短停机时间确定服务器可用性组是否可更新
在场中的任何服务器上启动 SharePoint 命令行管理程序。
在 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) } }
确定可用性组 1 中的服务器集。 这些服务器必须满足以下三个要求:
服务器集必须包含下列类型的搜索组件中的一个或多个,但不是全部:
内容处理组件
查询处理组件
分析处理组件
爬网组件
索引组件
服务器集必须包含每个索引分区的索引组件中的一个或多个,但不是全部:
该集必须包含搜索管理组件,该组件不是在此过程中的步骤 2 中标识的主要组件。
确定可用性组 2 中的服务器集。 该服务器集必须包含托管搜索组件的所有剩余服务器,其中包括托管在本过程步骤 2 中识别的主搜索管理组件的服务器。
在托管分布式缓存的服务器上安装软件更新
在重新启动服务器运行软件更新或配置向导之前,必须停止分布式缓存以防止未分配的缓存分数。 按照 此处 概述的过程正常关闭分布式缓存。
重要
不要对 SharePoint Server 2013、SharePoint Server 2016 和 SharePoint Server 2019 使用 Stop-SPDistributedCacheServiceInstance -Graceful
,因为这样会在将缓存传输到场中的另一台服务器之前终止分布式缓存。 但 Stop-SPDistributedCacheServiceInstance -Graceful
可用于 SharePoint Server 订阅版。
排查托管搜索组件的服务器上的软件更新问题
问题: 更新后,可能不再具有适当的注册表项或文件系统权限。
解决方案: 运行以下命令:
Initialize-SPResourceSecurity