В качестве исходной позиции имеется несколько серверов с Microsoft SharePoint Server 2019 с языковым пакетом Language Pack for SharePoint and Project Server 2019 версии 16.0.10417.20041 (это уровень обновления от Августа 2025 года). Необходимо провести процедуру актуализации версии SharePoint Server для закрытия таких известных уязвимостей, как, например, критическая уязвимость CVE-2026-20963. По опыту мы уже знаем, что обычно эта задача решается путём развёртывания последних кумулятивных обновлений Security Update для компонент SharePoint Server и не вызывает особых сложностей, но в этот раз мы столкнулись с проблемой, которая будет описана в данной заметке.
В нашем распоряжении имеется тестовое развёртывание, где компоненты SharePoint Workflow Manager и SharePoint Server 2019 установлены в рамках одного сервера и продуктивное развёртывание, где эти компоненты разнесены по разным серверам. В лучших традициях развёртывание обновлений SharePoint сначала проверяем на тестовом экземпляре.
Для поднятия версии SharePoint Server 2019 нам необходимо развернуть 2 обновления:
- Security update for SharePoint Server 2019: March 10, 2026 (KB5002845)
- Security update for SharePoint Server 2019 Language Pack: March 10, 2026 (KB5002847)
Однако, у последних кумулятивных обновлений SharePoint есть важное замечание:
Important:
* If you're currently running SharePoint Workflow Manager, you must install the SharePoint Workflow Manager (KB5002799) to your farm before you install this cumulative update.
* If you're currently running the Classic version of Workflow Manager, you have to enable the debug flag in order to continue using it.
$farm = Get-SPFarm
$farm.ServerDebugFlags.Add(53601)
$farm.update()
iisreset
Наш случай первый, то есть мы используем в своих развёртываниях SharePoint Workflow Manager. Поэтому прежде, чем разворачивать CU для SharePoint Server, нам потребуется сначала обновить WFM не ниже уровня KB5002799 (обновление Ноября 2025).
Перед запуском обновления WFM фиксируем его текущую версию. В нашем примере на сервере установлены пакеты SharePoint Workflow Manager и SharePoint Workflow Manager Client версии 16.0.15601.20418 (26.12.2022)
Ставить обновление KB5002799 от 11.11.2025 не будем, так как на текущий момент времени это не самая свежая версия (16.0.19127.20336). Будем устанавливать более свежую версию 16.0.19127.20506, которая представлена последним обновлением KB5002814 от 10.02.2026. Внимательно ознакомимся с описанием правильного процесса установки и скачаем файлы инсталляционных пакетов.
Обновление SharePoint Workflow Manager
Выполняем установку обновления KB5002814 для SharePoint Workflow Manager в следующем порядке (во избежание проблем важно соблюдать данный порядок):
1) Удаляем ранее установленную версию SharePoint Workflow Manager Client.
2) Устанавливаем новую версию SharePoint Workflow Manager Client (16.0.19127.20336):
msiexec /i "C:\Temp\KB5002814\sharepointworkflowmanagerclient_x64.msi" /l*v "C:\Temp\KB5002814\SPWFM_Client.log"
3) Устанавливаем новую версию (поверх старой) SharePoint Workflow Manager:
"C:\Temp\KB5002814\sharepointworkflowmanager-x64.exe" /log:"C:\Temp\KB5002814\SPWFM_Server.log"
4) После окончания установки появится запрос на перезагрузку. Перезагружаем сервер.
5) Запускаем мастер Workflow Manager Configuration Wizard, выбираем пункт обновления фермы "Upgrade Workflow Manager Farm" и соглашаемся с перезапуском служб в ходе обновления.
Мастер в автоматическом режиме выполнит все необходимые обновления фермы WFM.
После этого можно дополнительно перезагрузить сервер, чтобы убедиться в том, что в ходе загрузки системы все важные службы WFM стартуют успешно в автоматическом режиме.
Обновление SharePoint Server 2019
Выполняем установку обновлений для SharePoint Server в следующем порядке:
1) Устанавливаем обновление базовых компонент (KB5002845) - SharePoint Server 2019 Core
"C:\Temp\KB5002845\sts2019-kb5002845-fullfile-x64-glb.exe" /log:"C:\Temp\KB5002845\SP_Server.log"
2) После окончания установки появится запрос на перезагрузку. Перезагружаем сервер.
3) Устанавливаем обновление языковых компонент (KB5002847) - SharePoint Server 2019 Language Pack
"C:\Temp\KB5002847\wssloc2019-kb5002847-fullfile-x64-glb.exe" /log:"C:\Temp\KB5002847\SP_Server_LP.log"
4) Запускаем мастер SharePoint 2019 Products Configuration Wizard и соглашаемся с перезапуском служб в ходе обновления
Пару раз жмём "Next" и дожидаемся, когда мастер успешно закончит обновление.
5) Проверяем то, что версия SharePoint Server изменилась. На веб-сайте центра администрирования SharePoint "Central Administration" можно перейти в раздел "Upgrade and Migration" > "Check product and patch installation status".
Как видим, теперь к основной версии наложены обновления до актуальной версии 16.0.10417.20102.
Альтернативно проверить версию SharePoint Server 2019 после установки обновлений можно в SharePoint 2019 Management Shell:
(Get-SPFarm).BuildVersion.ToString()
16.0.10417.20102
6) Выполняем финальную перезагрузку сервера для того, чтобы убедиться в том, что при старте системы все службы SharePoint Server запускаются в автоматическом режиме без каких-либо проблем.
В идеальной ситуации на этом месте можно считать обновление законченным. Однако, когда мы провели первое подобное обновление на тестовом сервере, наш разработчик сообщил о том, что взаимодействие между SharePoint Workflow Manager и SharePoint Server сломалось.
Проблема с запуском службы Workflow Manager Backend
Было обнаружено, что после обновления служба Workflow Manager Backend (WorkflowServiceBackend) в цикличном режиме запускается и останавливается (падает процесс службы). При каждой такой аварийной остановке службы в Event-логах фиксируется две ошибки следующего вида:
Log Name: Application
Source: .NET Runtime
Date: 09.04.2026 16:08:22
Event ID: 1026
Level: Error
Computer: WEB01.ad.holding.com
Description:
Application: Microsoft.Workflow.ServiceHost.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.MissingMethodException at Microsoft.Activities.Dispatcher.DispatchLoopInstanceAsyncResult.IsPoison(Microsoft.Activities.Dispatcher.DispatcherMessage, Microsoft.Activities.Dispatcher.MessageSessionContext) at Microsoft.Activities.Dispatcher.DispatchLoopInstanceAsyncResult.PoisonCheckPeekCompleted(System.IAsyncResult) at Microsoft.Activities.Dispatcher.DispatchLoopInstanceAsyncResult.Isolate(AsyncCompletion, System.IAsyncResult) at Microsoft.Activities.Dispatcher.DispatchLoopInstanceAsyncResult.ExceptionHandlingFrame(System.IAsyncResult)
Exception Info: System.AggregateException
Exception Info: Microsoft.Workflow.Common.FatalException at Microsoft.Workflow.Common.Fx+<>c__DisplayClass18_0.b__0() at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at System.Threading.ThreadHelper.ThreadStart()
Log Name: Application
Source: Application Error
Date: 09.04.2026 16:08:22
Event ID: 1000
Level: Error
Computer: WEB01.ad.holding.com
Description:
Faulting application name: Microsoft.Workflow.ServiceHost.exe, version: 16.0.19127.20506, time stamp: 0xb253bee9
Faulting module name: KERNELBASE.dll, version: 10.0.20348.4294, time stamp: 0x73e9e45d
Exception code: 0xe0434352
Fault offset: 0x000000000003f33c
Faulting process id: 0x3254
Faulting application start time: 0x01dcc821e91a0f22
Faulting application path: C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts\Microsoft.Workflow.ServiceHost.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: f992cc01-b081-4687-988e-1019bee83ac8
Faulting package full name:
Faulting package-relative application ID:
По началу предполагали, что проблема связана с поломкой интеграции рабочих процессов SharePoint Workflow Manager в SharePoint Server. Проверили на SharePoint Server состояние Application Proxy для WFM:
Get-SPServiceApplicationProxy | Where-Object { $_.TypeName -like "*Workflow*" } | Format-List Name, TypeName, Status, Id, Uri
Name : Workflow Service Application Proxy
TypeName : Workflow Service Application Proxy
Status : Online
Id : f8013530-1670-47bd-a7d8-8434f3166828
Выглядит как живое, поэтому дергать процедуру перерегистрации Register-SPWorkflowService смысла особого нет.
Поиск информации на эту тему привёл к ветке обсуждения с похожей проблемой: "Sharepoint Workflow Manager : After September 2025 upgrade, workflow manager backend service stops every time a workflow is triggered", где в качестве решения предлагалось после развёртывания обновлений для WFM/SharePoint согласно рекомендации из это документа выполнять следующее:
$credential = [System.Net.CredentialCache]::DefaultNetworkCredentials
$site = Get-SPSite(<siteUri>)
$proxy = Get-SPWorkflowServiceApplicationProxy
$svcAddress = $proxy.GetWorkflowServiceAddress($site)
Copy-SPActivitiesToWorkflowService -WorkflowServiceAddress $svcAddress -Credential $credential -Force $true
Однако в нашем случае это решение не помогло.
После ряда безуспешных экспериментов в попытках исправить ситуацию возникла гипотеза о том, что когда удалялась старая версия клиента WFM и устанавливалась его новая версия из инсталлятора sharepointworkflowmanagerclient_x64.msi по какой-то причине не произошло обновление клиентских библиотек в системном хранилище Global Assembly Cache (GAC). В результате это привело к тому, что обновлённые компоненты серверной службы WorkflowServiceBackend при запуске выполняют какие-то клиентские вызовы, которых не понимают старые клиентские библиотеки WFM.
Решили попробовать старый костыльный трюк c GAC – распаковать инсталлятор клиента WFM, извлечь из него клиентские библиотеки и "в лоб" скопировать (с заменой) эти библиотеки в GAC.
Распаковываем инсталлятор клиента SharePoint Workflow Manager Client (16.0.19127.20336) sharepointworkflowmanagerclient_x64.msi, прямая ссылка на который есть в KB5002814:
msiexec /a "C:\Temp\KB5002814\sharepointworkflowmanagerclient_x64.msi" TARGETDIR="C:\Temp\KB5002814\SPWFM_Client_Extract" /qn
В распакованной структуре файлов находим подкаталог ..\Reference Assemblies\Microsoft\Workflow Manager\1.0\GacInstaller\ и в нём увидим ряд библиотек:
Характерным для этой последней версии клиентских библиотек WFM является не только дата изменения файла "сильно из прошлого", но и номер его версии "из прошлого" - 16.0.10001.10000. Это может здорово сбивать с толку и совсем не поддаётся нормальной человеческой логике, если проводить сравнение с клиентскими библиотеками WFM старой версии, где она маркирована как 16.0.15601.20416.
Из распакованного комплекта библиотек мы взяли 4 файла:
- Microsoft.Activities.dll
- Microsoft.Workflow.Client.dll
- Microsoft.Workflow.Common.dll
- Microsoft.Workflow.Tracing.dll
Это файлы скопировали (с заменой) в соответствующие им места в GAC:
- C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Activities\v4.0_1.0.0.0__31bf3856ad364e35\Microsoft.Activities.dll
- C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Workflow.Client\v4.0_1.0.0.0__31bf3856ad364e35\Microsoft.Workflow.Client.dll
- C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Workflow.Common\v4.0_1.0.0.0__31bf3856ad364e35\Microsoft.Workflow.Common.dll
- C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.Workflow.Tracing\v4.0_1.0.0.0__31bf3856ad364e35\Microsoft.Workflow.Tracing.dll
Дополнительно скопировали (с заменой) эти файлы также и по следующим путям:
- C:\Program Files\Reference Assemblies\Microsoft\Workflow Manager\1.0\Microsoft.Activities.dll
- C:\Program Files\Reference Assemblies\Microsoft\Workflow Manager\1.0\Microsoft.Workflow.Client.dll
При попытке переписать существующие файлы можно столкнуться с сообщением системы о том, что файл заблокирован другим процессом. В этом случае перед копированием можно остановить службы WFM и IIS:
Stop-Service WorkflowServiceBackend -Force
iisreset /stop
После копирования запускаем службы снова:
iisreset /start
Start-Service WorkflowServiceBackend
В результате этого служба WorkflowServiceBackend запустилась без ошибок и больше не падала.
Диагностика истинной причины, по которой клиентские библиотеки SharePoint Workflow Manager Client не смогли обновиться в GAC при переустановке sharepointworkflowmanagerclient_x64.msi на нашем тестовом сервере, оказалась затруднительна, так как эта самая установка выполнялась без подробного логирования в текстовый файл (как показано в примерах выше). При этом, как ни странно, последующая процедура установки обновлений WFM на продуктивном развёртывании прошла без описанных сюрпризов. Ещё раз убедились в том, что перед любым обновлением инфраструктуры SharePoint следует готовиться к любому развитию событий, иметь все возможные варианты бэкапов и использовать при запуске инсталляционных пакетов расширенные режимы логирования, если таковые поддерживаются.
RSS - Записи
Добавить комментарий