Использование приложения оркестрации исправлений

Приложение оркестрации исправлений (POA) представляет собой оболочку над службой Azure Service Fabric Repair Manager, позволяющую настроить расписание исправлений операционной системы для кластеров, не размещенных в Azure. POA не требуется для кластеров, не размещенных в Azure, но планирование установки исправлений по домену обновления требуется для исправления узлов кластера Service Fabric без простоя.

POA — это приложение Service Fabric, которое автоматизирует исправление операционной системы в кластере Service Fabric без простоя.

POA предоставляет следующие функции:

• Автоматическая установка обновления операционной системы. Обновления операционной системы автоматически загружаются и устанавливаются. Узлы кластера перезагружаются по мере необходимости без простоя кластера.

• Кластерное исправление и интеграция мониторинга работоспособности. Хотя POA применяет обновления, он отслеживает работоспособность узлов кластера. Узлы кластера обновляются по одному узлу в один раз или один домен обновления одновременно. Если работоспособность кластера исчезает из-за процесса исправления, исправление останавливается, чтобы предотвратить усугубление проблемы.

Внутренние сведения о POA

POA состоит из следующих подкомпонентов:

• Служба координаторов: эта служба с отслеживанием состояния отвечает за:

  • Координация задания Windows Update на всем кластере.
  • Сохранение результатов завершенных операций обновления Windows.

• Служба агента узла: эта бесстатусная служба выполняется на всех узлах кластера Service Fabric. Служба отвечает за:

  • Начальная загрузка агента узла NTService.
  • Мониторинг агента узла службы NTService.

• Агент узла NTService: эта служба Windows NT выполняется на более высоком уровне привилегий (SYSTEM). Напротив, служба агента узла и служба координатора выполняются на более низком уровне привилегий (NETWORK SERVICE). Служба отвечает за выполнение следующих заданий Центра обновления Windows на всех узлах кластера:

  • Отключение автоматических обновлений Windows на узле.
  • Скачивание и установка обновлений Windows в соответствии с политикой, предоставленной пользователем.
  • Перезапуск компьютера после установки обновлений Windows.
  • Отправка результатов обновлений Windows в службу координаторов.
  • Сообщение о состоянии здоровья в случае, если операция завершилась сбоем после исчерпания всех попыток повторного выполнения.

Предпосылки

Включите службу Repair Manager (если она еще не запущена)

Для POA требуется, чтобы служба Repair Manager была включена в кластере.

Кластеры Azure

Кластеры Azure на уровне устойчивости silver имеют службу Repair Manager, включенную по умолчанию. Кластеры Azure на уровне устойчивости золота могут или не могут включать службу Диспетчера восстановления в зависимости от того, когда эти кластеры были созданы. Кластеры Azure в бронзовом уровне устойчивости по умолчанию не включены в службу Repair Manager. Если служба уже включена, ее можно увидеть в разделе системных служб в Service Fabric Explorer.

Портал Azure

Диспетчер восстановления можно включить на портале Azure при настройке кластера. При настройке кластера выберите параметр "Включить диспетчер восстановления " в разделе "Компоненты надстройки".

Модель развертывания Azure Resource Manager

Кроме того, можно использовать модель развертывания Azure Resource Manager для включения службы Repair Manager в новых и существующих кластерах Service Fabric. Получите шаблон для кластера, который требуется развернуть. Вы можете использовать примеры шаблонов или создать пользовательский шаблон модели развертывания Azure Resource Manager.

Чтобы включить службу Repair Manager с помощью шаблона модели развертывания Azure Resource Manager, сделайте следующее:

1. Убедитесь, что apiVersion для ресурса Microsoft.ServiceFabric/clusters задано значение 2017-07-01-preview. Если есть различия, необходимо обновить apiVersion до версии 2017-07-01-preview или более поздней.

   {
       "apiVersion": "2017-07-01-preview",
       "type": "Microsoft.ServiceFabric/clusters",
       "name": "[parameters('clusterName')]",
       "location": "[parameters('clusterLocation')]",
       ...
   }
   

2. Включите службу Repair Manager, добавив следующий addonFeatures раздел после fabricSettings раздела:

   "fabricSettings": [
       ...      
   ],
   "addonFeatures": [
       "RepairManager"
   ],
   

3. После обновления шаблона кластера с этими изменениями примените их и дождитесь завершения обновления. Теперь вы увидите службу Диспетчера восстановления, запущенную в кластере. Она называется fabric:/System/RepairManagerService в разделе системных служб в Service Fabric Explorer.

Автономные локальные кластеры

Чтобы включить службу Repair Manager в новом или существующем кластере Service Fabric, можно использовать параметры конфигурации для автономного кластера Windows.

Чтобы включить службу Диспетчера восстановления, выполните следующие действия.

1. Убедитесь, что apiVersion в конфигурациях общего кластера задано значение 04–2017 или более поздней версии, как показано ниже:

   {
       "name": "SampleCluster",
       "clusterConfigurationVersion": "1.0.0",
       "apiVersion": "04-2017",
       ...
   }
   

2. Включите службу Repair Manager, добавив следующий addonFeatures раздел после fabricSettings раздела, как показано ниже:

   "fabricSettings": [
       ...      
   ],
   "addonFeatures": [
       "RepairManager"
   ],
   

3. Обновите манифест кластера с помощью обновленного манифеста кластера , создайте новый кластер или обновите конфигурацию кластера.

   После запуска кластера с обновленным манифестом кластера вы увидите службу Repair Manager, запущенную в кластере. Она называется fabric:/System/RepairManagerService, и она находится в разделе системных служб в Service Fabric Explorer.

Настройка обновлений Windows для всех узлов

Автоматическое обновление Windows может привести к потере доступности, так как одновременно несколько узлов кластера могут перезапуститься. PoA по умолчанию пытается отключить автоматические обновления Windows на каждом узле кластера. Однако если параметры управляются администратором или групповой политикой, рекомендуется явно задать политику центра обновления Windows для уведомления перед загрузкой.

Скачивание пакета приложения

Чтобы скачать пакет приложения, перейдите на страницу релиза Patch Orchestration Application на сайте GitHub.

Настройка поведения POA

Вы можете настроить поведение POA в соответствии с вашими потребностями. Переопределите значения по умолчанию, передавая параметр приложения при создании или обновлении приложения. Параметры приложения можно предоставить, указав ApplicationParameter для командлетов Start-ServiceFabricApplicationUpgrade или New-ServiceFabricApplication.

Развертывание POA

1. Завершите все необходимые действия для подготовки кластера.

2. Разверните POA, как и любое другое приложение Service Fabric. Сведения о развертывании с помощью PowerShell см. в статье "Развертывание и удаление приложений с помощью PowerShell".

3. Чтобы настроить приложение во время развертывания, передайте параметр ApplicationParameter в командлет New-ServiceFabricApplication. Для удобства мы предоставили скрипт Deploy.ps1 вместе с приложением. Чтобы использовать скрипт:

   • Подключитесь к кластеру Service Fabric с помощью Connect-ServiceFabricCluster.
   • Выполните скрипт PowerShell Deploy.ps1 с указанным значением ApplicationParameter.

Обновление POA

Чтобы обновить версию POA с помощью PowerShell, следуйте инструкциям в обновлении приложения Service Fabric с помощью PowerShell.

Удаление POA

Чтобы удалить приложение, следуйте инструкциям в статье "Развертывание и удаление приложений с помощью PowerShell".

Для удобства мы предоставили скрипт Undeploy.ps1 вместе с приложением. Чтобы использовать скрипт:

• Подключитесь к кластеру Service Fabric с помощью Connect-ServiceFabricCluster.
• Выполните скрипт PowerShell Undeploy.ps1.

Просмотр результатов обновления Windows

POA предоставляет REST API для показа пользователям исторических результатов. Ниже приведен пример результата JSON:

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

Поля JSON описаны в следующей таблице:

Если обновление еще не запланировано, результат JSON пуст.

Войдите в кластер, чтобы запросить результаты Центра обновления Windows. Найдите IP-адрес реплики для основного адреса службы координатора и откройте следующий URL-адрес в браузере: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

Конечная точка REST для службы координатора имеет динамический порт. Чтобы проверить точный URL-адрес, обратитесь к Service Fabric Explorer. Например, результаты доступны по http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResultsадресу.

Если обратный прокси-сервер включен в кластере, вы также можете получить доступ к URL-адресу за пределами кластера.

Конечная точка, по которой вам нужно обращаться, — это http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

Чтобы включить обратный прокси-сервер в кластере, следуйте инструкциям в обратном прокси-сервере в Azure Service Fabric.

События диагностики и здоровья

В этом разделе рассматривается, как отлаживать или диагностировать проблемы с обновлениями патчей с помощью POA в кластерах Service Fabric.

Агент узлов NTService создает задачи восстановления для установки обновлений на узлах. Затем каждая задача подготавливается службой координатора в соответствии с политикой утверждения задач. Наконец, подготовленные задачи утверждены диспетчером восстановления, который не утверждает какую-либо задачу, если кластер находится в неработоспособном состоянии.

Чтобы помочь вам понять, как выполняются обновления на узле, рассмотрим этот процесс шаг за шагом:

1. NodeAgentNTService, работающий на каждом узле, ищет доступные обновления Windows в запланированное время. Если обновления доступны, он скачивает их на узле.

2. После скачивания обновлений служба NTService агента узла создает соответствующую задачу восстановления для узла с именем POS___<unique_id>. Эти задачи восстановления можно просмотреть с помощью командлета Get-ServiceFabricRepairTask или SFX в разделе сведений о узле. После создания задачи восстановления он быстро переходит в состояние "Утверждения".

3. Служба координатора периодически ищет задачи восстановления в состоянии заявленного, а затем обновляет их до состояния подготовки на основе политики утверждения задач. Если "TaskApprovalPolicy" настроена как "NodeWise", ремонтная задача, соответствующая узлу, подготавливается только в том случае, если в настоящее время нет другой задачи восстановления в состоянии подготовки, утверждения, выполнения или восстановления.

   Аналогичным образом, в случае UpdateWise TaskApprovalPolicy существуют задачи в предыдущих состояниях только для узлов, принадлежащих одному домену обновления. После перемещения задачи восстановления в состояние подготовки соответствующий узел Service Fabric отключен с намерением перезапуска.

   POA версии 1.4.0 и более поздних отправляют события со свойством ClusterPatchingStatus в службу CoordinatorService для отображения узлов, которые исправляются. Обновления устанавливаются на _poanode_0, как показано на следующем рисунке:

   

4. После отключения узла задача восстановления перемещается в состояние выполнения .

   Примечание.

   Узел, застрявший в отключенном состоянии, может блокировать новую задачу восстановления, которая останавливает операцию исправления в кластере.

5. Когда задача восстановления находится в состоянии выполнения , начинается установка исправлений на этом узле. После установки исправления узел может быть перезапущен или не перезапущен в зависимости от исправления. Затем задача ремонта перемещается в состояние Restoring, которое повторно активирует узел. Затем задача восстановления помечается как завершенная.

   Начиная с версии POA 1.4.0, вы можете найти состояние обновления, осмотрев события состояния в NodeAgentService, используя свойство WUOperationStatus-NodeName<>. Выделенные разделы в следующих изображениях показывают состояние обновлений Windows на узлах poanode_0 и poanode_2:

   

   

   Вы также можете получить сведения с помощью PowerShell. Для этого подключитесь к кластеру и получите состояние задачи восстановления с помощью Get-ServiceFabricRepairTask.

   В следующем примере задача "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" находится в состоянии DownloadComplete . Это означает, что обновления скачаны на узле poanode_2 , а установка будет предпринята при переходе задачи в состояние выполнения .

    D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k = Get-ServiceFabricRepairTask -TaskId "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15"
   
    D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k.ExecutorData
    {"ExecutorSubState":2,"ExecutorTimeoutInMinutes":90,"RestartRequestedTime":"0001-01-01T00:00:00"}
   

   Если не удается найти дополнительные проблемы, войдите на виртуальную машину или виртуальные машины и узнайте о них с помощью журналов событий Windows. Ранее упоминаемая задача восстановления может существовать только в следующих подстатах исполнителя:

   ИсполнителяSubState	Описание
   None=1	Подразумевает, что на узле не было текущей операции. Состояние может находиться в переходе.
   DownloadCompleted=2	Подразумевает, что операция скачивания была завершена успешно, частично сбоем или сбоем.
   УстановкаApproved=3	Подразумевает, что операция скачивания была завершена ранее и диспетчер восстановления одобрил установку.
   InstallationInProgress=4	Соответствует состоянию выполнения задачи восстановления.
   InstallationCompleted=5	Подразумевает, что установка была завершена успешно, частично успешно или неудачно.
   RestartRequested=6	Предполагает, что установка исправлений завершена и на узле выполняется ожидающееся действие перезапуска.
   RestartNotNeeded=7	Подразумевает, что перезагрузка не нужна после завершения установки исправлений.
   RestartCompleted=8	Подразумевает успешное завершение перезапуска.
   OperationCompleted=9	Операция Центра обновления Windows успешно завершена.
   OperationAborted=10	Подразумевает, что операция Центра обновления Windows была прервана.

6. В версиях POA 1.4.0 и более поздних, когда попытка обновления узла завершается, событие со свойством WUOperationStatus-[NodeName] публикуется в NodeAgentService, чтобы уведомить вас о времени начала следующей попытки загрузки и установки обновлений Windows. Это отображается на следующем рисунке:

   

Журналы диагностики

Журналы приложений управления обновлениями собираются как часть журналов выполнения Service Fabric.

Логи можно записывать с помощью средства диагностики или конвейера вашего выбора. POA использует следующие идентификаторы фиксированных поставщиков для регистрации событий с помощью источника событий:

• e39b723c-590c-4090-abb0-11e3e6616346
• fc0028ff-bfdc-499f-80dc-ed922c52c5e9
• 24afa313-0d3b-4c7c-b485-1047fd964b60
• 05dc046c-60e9-4ef7-965e-91660adffa68

Отчеты о здоровье

POA также публикует отчеты о состоянии службы агента узла или службы координатора в следующих сценариях:

• Служба NTService агента Node отключена.

  Если агент узла NTService на узле не работает, создается отчет о работоспособности на уровне предупреждения для службы агента узла.

• Служба Repair Manager не включена

  Если служба Repair Manager не найдена в кластере, для службы Coordinator создается предупреждающий отчет о работоспособности.

Часто задаваемые вопросы

Вопрос. Почему при запуске POA кластер отображается в состоянии ошибки?

Во время установки POA отключает или перезапускает узлы, что может временно привести к неработоспособному кластеру.

В зависимости от политики приложения один узел может выйти из строя во время операции исправления или весь домен обновления может выйти из строя сразу.

После завершения установки обновлений Windows узлы вновь активируются после перезапуска.

В следующем примере кластер временно пошел в состояние ошибки, так как два узла были отключены, а политика MaxPercentageUnhealthyNodes была нарушена. Ошибка является временной до начала операции исправления.

Если проблема сохраняется, обратитесь к разделу "Устранение неполадок".

Вопрос. Что делать, если POA находится в состоянии предупреждения?

Ответ. Проверьте, указывает ли отчет о работоспособности, опубликованный в приложении, первопричину. Обычно предупреждение содержит сведения о проблеме. Если проблема является временной, приложение, как ожидается, будет автоматически восстановлено.

Вопрос. Что делать, если кластер неработоспособен, и мне нужно выполнить срочное обновление операционной системы?

Ответ. POA не устанавливает обновления, пока кластер неработоспособен. Попробуйте перенести кластер в работоспособное состояние, чтобы разблокировать рабочий процесс POA.

Вопрос: Следует ли установить taskApprovalPolicy в значении NodeWise или UpgradeDomainWise для моего кластера?

Ответ. Параметр UpgradeDomainWise ускоряет общее восстановление кластера путем параллельного исправления всех узлов, принадлежащих домену обновления. Во время процесса узлы, принадлежащие всему домену обновления, недоступны (в отключенном состоянии).

В отличие от этого, настройка "NodeWise" проверяет или патчирует только один узел за раз, что может означать, что общее обновление кластера займет больше времени. Во время процесса исправления будет недоступен только один узел (в отключенном состоянии).

Если ваш кластер может выдержать работу на N-1 доменах обновления во время цикла исправления (где N — общее количество доменов обновления в вашем кластере), вы можете установить политику как «UpgradeDomainWise». В противном случае установите ее на «NodeWise».

Вопрос. Сколько времени требуется для исправления узла?

Обновление узла может занять от нескольких минут (например, обновления определений Windows Defender) до нескольких часов (например, накопительные обновления Windows). Время, необходимое для исправления узла, зависит главным образом от:

• Размер обновлений.
• Количество обновлений, которые должны применяться в окне исправления.
• Время установки обновлений, перезагрузка узла (при необходимости) и завершение действий по установке после перезагрузки.
• Производительность виртуальной машины или компьютера и сетевых условий.

Вопрос. Сколько времени требуется для исправления всего кластера?

Ответ. Время, необходимое для исправления всего кластера, зависит от:

• Время, необходимое для исправления узла.

• Политика службы координатора. Политика по умолчанию NodeWise приводит к исправлению только одного узла за раз, что происходит медленнее, чем с помощью UpgradeDomainWise.

  Например: если для исправления узла требуется около 1 часа, требуется исправление 20-узла (один и тот же тип узлов) с 5 доменами обновления, каждый из которых содержит 4 узла:

  • Для NodeWise: ~20 часов.
  • Для "UpgradeDomainWise": ~5 часов.

• Загрузка кластера. Для каждой операции исправления требуется переместить рабочую нагрузку клиента на другие доступные узлы в кластере. Узел, который обновляется, будет находиться в состоянии Отключение в течение этого времени. Если кластер работает вблизи пиковой нагрузки, процесс отключения займет больше времени. Таким образом, общий процесс исправления может оказаться медленным в таких условиях.

• Сбои в работе кластера во время обновления. Любое снижениеработоспособности кластера прерывает процесс исправления. Эта проблема увеличивает общее время, необходимое для исправления всего кластера.

Вопрос. Почему в результатах центра обновления Windows отображаются некоторые обновления, полученные с помощью REST API, но не в журнале обновления Windows на компьютере?

Ответ. Некоторые обновления продуктов отображаются только в собственном журнале обновлений или исправлений. Например, обновления Защитника Windows могут отображаться или не отображаться в истории обновлений Windows на Windows Server 2016.

Вопрос. Можно ли использовать POA для исправления кластера разработки (одноузлового кластера)?

Ответ. Нет, POA не может использоваться для исправления кластера с одним узлом. Это ограничение обусловлено тем, что системные службы Service Fabric или другие клиентские приложения могут повлечь простой. Таким образом, задания восстановления исправлений никогда не будут утверждены диспетчером восстановления.

Вопрос. Как исправить узлы кластера в Linux?

Ответ. Сведения об управлении обновлениями в Linux см. в статье об автоматических обновлениях образа ОС в масштабируемых наборах виртуальных машин Azure.

Вопрос. Почему цикл обновления занимает так много времени?

Ответ. Запрос к результату JSON, введите цикл обновления для всех узлов, а затем можно попытаться узнать время, затраченное на установку обновлений на каждом узле с помощью OperationStartTime и OperationTime (OperationCompletionTime).

Если существует большое время, в котором обновление не выполняется, кластер может находиться в состоянии ошибки и, следовательно, диспетчер восстановления не может утвердить какие-либо задачи восстановления POA. Если установка обновления занимает много времени на любом узле, этот узел, возможно, не был обновлен в течение некоторого времени. Многие обновления могут находиться в ожидании установки, что может привести к задержкам.

Возможно также, что установка патча для узла заблокирована, так как процесс застрял в состоянии Отключения. Обычно это происходит, так как отключение узла может привести к кворуму или потерям данных.

Вопрос. Почему узел должен быть отключен при внесении исправлений POA?

POA отключает узел с намерением перезапуска, что останавливает или перераспределяет все службы Service Fabric, работающие на этом узле. POA делает это, чтобы приложения не начали использовать сочетание новых и старых DLL, поэтому мы рекомендуем отключать узел перед установкой исправлений.

Вопрос. Что такое максимальное количество узлов, которые можно обновить с помощью POA?

Ответ. POA использует Service Fabric Repair Manager для создания задач ремонта узлов в рамках обновлений. Однако не более 250 задач восстановления могут присутствовать одновременно. В настоящее время POA создает задачи восстановления для каждого узла одновременно, поэтому POA может обновлять не более 250 узлов в кластере.

Заявления об отказе от ответственности

• POA принимает лицензионное соглашение End-User для Центра обновления Windows от имени пользователя. При необходимости параметр можно отключить в конфигурации приложения.

• POA собирает данные телеметрии для отслеживания использования и производительности. Данные телеметрии приложения соответствуют параметру телеметрии среды выполнения Service Fabric (который включен по умолчанию).

Устранение неполадок

В этом разделе приводятся возможные решения по устранению неполадок с узлами исправления.

Узел не возвращается в активное состояние.

• Узел может застрять в состоянии Отключение, так как:

  • Ожидается проверка безопасности. Чтобы исправить эту ситуацию, убедитесь, что достаточное количество узлов находится в исправном состоянии.

• Узел может застрять в отключенном состоянии, так как:

  • Он был отключен вручную.
  • Она была отключена из-за текущего задания инфраструктуры Azure.
  • Его временно отключили, чтобы исправить узел.

• Узел может застрять в нерабочем состоянии, так как:

  • Он был переведен в нерабочее состояние вручную.
  • Он проходит перезагрузку (которая может быть активирована POA).
  • У нее есть неисправная виртуальная машина или компьютер или возникают проблемы с сетевым подключением.

Обновления были пропущены на некоторых узлах

POA пытается установить обновление Windows в соответствии с политикой перепланирования. Служба пытается восстановить узел и пропустить обновление в соответствии с политикой приложения.

В таком случае в отношении Службы Агента Узла создается отчет о работоспособности на уровне предупреждения. Результат Центра обновления Windows также содержит возможные причины сбоя.

Состояние кластера переходит в ошибку во время установки обновления.

Неисправное обновление Windows может привести к сбою работоспособности приложения или кластера на определенном узле или домене обновления. POA прекращает любые последующие операции обновления Windows до тех пор, пока кластер не восстановит работоспособность.

Администратор должен вмешаться и определить, почему приложение или кластер стал неисправным из-за обновлений Windows.

Примечания к выпуску POA

Версия 1.1.0

• Общедоступный выпуск

Версия 1.1.1

• Исправлена ошибка в SetupEntryPoint NodeAgentService, которая мешала установке NodeAgentNTService.

Версия 1.2.0

• Исправление ошибок в рабочем процессе перезапуска системы.
• Исправлена ошибка при создании задач RM, из-за которых проверка работоспособности во время подготовки задач восстановления не выполнялось должным образом.
• Изменен режим запуска службы Windows POANodeSvc с автоматического на отложенный автоматический.

Версия 1.2.1

• Исправлена ошибка в рабочем процессе масштабирования кластера. Представлена логика сборки мусора для задач восстановления POA, относящихся к несуществующим узлам.

Версия 1.2.2

• Прочие исправления ошибок.
• Двоичные файлы теперь подписаны.
• Добавлена ссылка sfpkg для приложения.

Версия 1.3.0

• Установка параметра installWindowsOSOnlyUpdates в значение false теперь приводит к установке всех доступных обновлений.
• Изменена логика отключения автоматических обновлений. Это исправляет ошибку, из-за которой автоматические обновления не были отключены на Сервере 2016 и более поздних версиях.
• Параметризированное ограничение размещения для обеих микрослужб POA в расширенных сценариях использования.

Версия 1.3.1

• Исправление регрессии, в которой POA 1.3.0 не будет работать в Windows Server 2012 R2 или более ранней версии из-за сбоя при отключении автоматических обновлений.
• Исправлена ошибка, из-за которой конфигурация InstallWindowsOSOnlyUpdates всегда выбирается как True.
• Изменение значения по умолчанию InstallWindowsOSOnlyUpdates на False.

Версия 1.3.2

• Исправление проблемы, влияющей на процесс патчирования на узле, если существуют узлы с именем, являющимся подмножеством текущего имени узла. Для таких узлов возможно, что исправление было пропущено или перезагрузка ожидается.