SharePoint Server 零停机时间修补步骤
适用范围：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 订阅版中提供了零停机时间修补 (ZDP) 。 让用户在修补 SharePoint Server 场时继续处理、保存和搜索文档。
零停机时间修补是在 sharePoint Microsoft 365 中开发的修补和升级方法。 其开发意图是在允许管理员修补服务的同时，让用户继续使用其订阅。 换句话说，这种经过测试的方法旨在允许在相关人员积极使用其文件、搜搜爬网和显示器结果时在 SharePoint Server 场中进行修补。 这就是“零故障时间”的含义。
讨论 ZDP 时要注意的几个事项（我们将在本文的后续部分中讨论这些元素）。
通过在 SharePoint Server 中使用 MinRole 可以增强 ZDP 体验，但 MinRole 不 是必需的。
你的场必须具备高可用性 (HA) 才能从 ZDP 中获益。 高可用性 SharePoint Server 场 是 ZDP 的要求。
切记 ZDP 的目标是用户的运行时间，因此在本文中，涉及修补和重新启动场的所有决策都将以此为前提。
重要
即使 SharePoint Server 场中的所有服务器都配置为使用“自定义”角色，您仍然可以手动配置高度可用的场。 有 一些文章 可帮助你构建高度可用的场，容错原则 (具有冗余硬件) 和高可用性 (具有系统和软件来支持故障转移和继续运行时间) 是相同的。 注意在更为复杂的高度可用或自定义场中，应额外注意以支持 HA 的方法修补搜索服务器，例如一次修补一个索引副本，绝不同时修补或升级同一个分区中的索引副本。
ZDP 进程
此示例使用 MinRole 对 SharePoint Server 场设置使用 ZDP。 环境示例如下所示：
要将此结构分解，请将两个 Web 前端 (WFE)（SPWeb01 和 02）连接到一个负载平衡器，此时两者都在处理请求。 有两个应用程序服务器（SPApp01 和 02）、两个分布式缓存服务器（SPDCH01 和 02）和两个搜索服务器（SPSRCH01 和 02）。 在此结构之后但却未直接包含在 ZDP 进程中的是 SQL Server 群集（例如，SQL Server Always-On）。
可以假想在该图表的场中间从上到下画一条线。 行的一侧是以“01”结尾的所有服务器 (列 1) ，“02”中的冗余服务器位于第 2 列) 的另一 (。 我们将利用这种双重构造，在修补时为用户保留服务器场。
在大多数情况下，你在行的一侧执行的所有操作 (到 01 服务器，) 你将完全重复 02。 在这个相对简单的两个阶段的 ZDP 进程中涉及的所有步骤中，WFE（SPWeb01 和 02）使用的步骤最为复杂。 我们将从那里开始。
注意
可 在此处找到有关 SharePoint Server 软件更新的一般信息。 请注意，本文链接到有关 SharePoint Server 权限设置 的文档。 请根据需要查看这些文章，并请注意修补部分涉及数据库更新。 例如，如果在安装后更改了 SharePoint 帐户的 SQL Server 权限，则需要查看这些文章。
在从负载均衡器中取出其中一个之前，请确保已重新启动并测试了 WFE，以避免先修补的 WFE 退出轮换，而其他 WFE 不处理生成的负载的情况。 场中的所有服务器都应通过重启刷新并且运行状况良好，然后才能进行修补。 此外，在升级或修补窗口时，注意停止搜索爬网和配置文件导入。
重要
即使正在升级或移除位于指定 WFE 的静态文件，并行运行也可以保证场中的所有 Web 前端在升级时处理相同的静态内容。 并行内置于 PSCONFIG 中，但必须启用。 即使在更改和更新文件系统文件时，此功能也可确保用户在浏览 SharePoint 和使用其文件时具有相同的网站体验。
若要启用并行功能，请使用其中一个内容 Web 应用程序的 URL 执行一次以下 PowerShell 脚本：
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
自 KB3178672 (2017 年 3 月 SharePoint Server 2016 及更高版本更新) 起，PSCONFIG 将自动将文件夹中16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER>的所有 .js、.css和 .htm 文件16-HIVE\TEMPLATE\LAYOUTS复制到文件夹中，需要能够切换到新的用户界面文件并完成本主题稍后阶段 2 - PSCONFIG 升级 (4) 中所述的并行过程。
阶段 1 - 修补程序安装
第一个阶段是在服务器上获取修补程序二进制文件，并将其安装在服务器上。
将第一个 WFE (SPWeb01) 从负载均衡器中取出，并使用“STS”和“WSS”包对其进行修补。
完成修补后重新启动服务器。
在负载均衡器中返回要轮换的服务器。
从负载均衡器中取出第二个 WFE (SPWeb02) ，并使用“STS”和“WSS”包对其进行修补。
完成修补后重新启动服务器。
在整个升级完成之前，请将此服务器排除在负载均衡器外。注意
如果未在维护窗口中运行升级，且该场具有大量负载，则可以直至准备好运行 PSCONFIG 时再将此 WFE 返回网络负载平衡器。
对于第 1 列中的每个 SPApp、SPDCH 和 SPSRCH，请使用“STS”和“WSS”包进行修补。
完成后重新启动它们。 ）
现在，对第 2 列重复“修补并重新启动”。 对于第 2 列中每个 SPApp02、SPDCH02和SPSRCH02，请使用“STS”和“WSS”包进行修补。
完成后重新启动它们。 ）
阶段 2 - PSCONFIG 升级
SharePoint Server 场中的每个节点都安装了修补程序，并且所有修补程序都已重新启动。 是时候执行内部版本到内部版本升级了。
注意
在 ZDP 过程中，可以运行 Upgrade-SPContentdatabase ，以减少完成运行 PSCONFIG 所花费的总时间。 在具有大量数据库或选择了大型数据库时考虑使用此操作。
返回到负载均衡旋转 (SPWeb02) 的 WFE，打开 SharePoint 命令行管理程序，并运行以下 PSCONFIG 命令：
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install命令完成后，将该 WFE (SPWeb02) 返回负载平衡器。 该服务器已完全完成修补和升级。
提示
PSCONFIG 进程中的最后一步保证了将对用户界面 (UI) 的更新从 /layouts 文件夹复制到指定版本的文件夹。 这是并行 UI 更新的一部分，可允许浏览你的场的用户在升级完成和你准备好切换到新界面前享有一种 UI 体验。
若要确保并行复制成功，请检查关联的日志文件。 默认情况下，它位于以下位置：
C：\program files\common files\Microsoft shared\web server extensions\16\logs。 (根驱动器号可能会有所不同！)
如果由于某种原因，PSCONFIG 未成功复制 UI 文件，请运行此命令以手动复制它们 Copy-SidebySideFiles！
从负载均衡器中删除 SPWeb01。 > 打开 SharePoint 命令行管理程序并运行相同的 PSCONFIG 命令：
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install将此 WEF (SPWeb01) 返回到负载平衡器。 它现在也已完全修补和升级。
两个 WFE 都已进行修补和升级。 转到场的其余部分，但请确保所需的 Microsoft PowerShell 命令一次运行一台服务器，而不是并行运行。 这意味着，对于所有第 1 列，一次运行一个服务器命令。 然后，对于第 2 列的服务器，一次运行一个服务器，且不重叠。 最终目标是维护运行时间。 以串行方式运行 PSCONFIG 命令是完成 ZDP 过程的最安全、最可预测的方法，因此我们将这样做。
对于第 1 列 (SPApp01 中的所有剩余服务器，SPDCH01 SPSRCH01) 在 SharePoint 命令行管理程序中运行相同的 PSCONFIG 命令。 在每个服务器上执行此操作，一次只在一个服务器上进行，直至列 1 中的所有服务器都已升级。
重要
注意运行 PSCONFIG 前先正确地 remove the Distributed Cache（移除分布式缓存）并在完成后重新 add the Distributed Cache to the server（将分布式缓存添加至服务器）。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
对于第 2 列 (SPApp02 中的所有剩余服务器，SPDCH02、SPSRCH02) 在 SharePoint 命令行管理程序中运行相同的 PSCONFIG 命令。 在每个服务器上执行此操作，一次只在一个服务器上进行，直至列 2 中的所有服务器都已升级。
重要
注意运行 PSCONFIG 前先正确地 remove the Distributed Cache（移除分布式缓存）并在完成后重新 add the Distributed Cache to the server（将分布式缓存添加至服务器）。
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install重要
所有服务器都成功通过 PSCONFIG 后，请记住运行下面的 SharePoint 命令行管理程序命令，切换到新的用户界面文件并完成并行过程：
$webapp = Get-SPWebApplication <webappURL>$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
$webapp.WebService.update()
现在你已大功告成，该场已在使用过程中完全完成升级，且无任何故障时间。
为什么 MinRole 可以发挥作用？
谈论 ZDP 时，还应阐释 MinRole 的概念。 MinRole 是安装 SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 订阅版的选项。 它将场的配置划分为前端 (WFE)、应用程序服务器 (App)、分布式缓存 (DCache)、搜索或自定义（用于自定义代码或第三方产品）等角色。 此配置将平均提供四个服务器 - 两个 WFE、两个应用服务器、两个 DCache 服务器和两个搜索服务器。
默认情况下，调整 WFE 以实现低延迟，调整应用程序服务器以实现高吞吐量。 同样，捆绑搜索组件，以便调用不必离开它们所发起的框，这会使搜索服务器更高效地工作。 MinRole 的最大优势之一是它内置默认容错功能。
为什么需要具备高可用性？
HA 在 SharePoint 中是一个广泛的主题。 联机提供了完整的白皮书和文章，例如 本文档。 为了简化此概念，至少在本文中，应认识到 ZDP (以及 MinRole) 源自 Microsoft 365 中的 SharePoint。 在 Microsoft 365 的 SharePoint 中，虚拟化服务器内置了冗余，因此同一 SharePoint 场中的两个相同角色的服务器不会位于同一主机或机架上。 这使 SharePoint 更具容错能力。 可以让两个具有每种 SharePoint 服务器角色的服务器位于自己的服务中心不同机架上的独立主机上，机架间存在共享的路由器或缆线来使通信更快，以此来模拟相同的情形。 还可以只在测试环境中设置每种 SharePoint 服务器角色的两个物理服务器（为场的每一半选择独立的电源插排，并确保服务器集之间的路由快速，并且如果可以，绕过较宽广的网络通信以实现低延迟）。
此处的目标是高可用性和容错功能。 这意味着最优先执行的操作是将机架或服务器上的角色分开，确保配备具有每种角色的两个服务器，加快这两层之间的网络流量，并确保设置已使系统准备就绪可以监测数据库服务器并自动进行故障转移。 对于在 SharePoint 中手动安装服务（选择“自定义”角色时），服务在场中具有冗余很重要。 例如，分布式缓存聚集，你的场具有多个 WFE，将应用程序和搜索服务器成对设置。 这样，在一个服务器存在严重问题时，另一个可以处理用户负载。
在此处使用的示例中，我绘制了物理服务器以使概念更易理解。 在规划 ZDP 时，应绘制出自己的环境，无论它位于何处， (完整的机架名称/数字，以及可在其中找到每个 SharePoint Server 角色的服务器名称) 。 无论安装程序的大小如何，这是隔离可能已潜入安装程序的任何角色冗余和容错目标冲突的最快捷方法之一。