Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения: ✔️ виртуальные машины Windows ✔️ виртуальные машины Linux ✔️ локальная инфраструктура ✔️ серверы с поддержкой Azure Arc.
События предварительной и последующей публикации в Диспетчере обновлений Azure позволяют выполнять определенные задачи автоматически до и после запланированной конфигурации обслуживания. Дополнительные сведения о создании конфигураций обслуживания расписания см. в статье "Планирование повторяющихся обновлений для компьютеров" с помощью портала Azure и политики Azure. Например, используя события предварительного и последующего выполнения, можно выполнить следующие задачи на компьютерах, которые являются частью расписания. Следующий список не является исчерпывающим, и вы можете создавать события предварительной и публикации в соответствии с вашими потребности.
Примеры задач
Ниже приведены сценарии, в которых можно определить события предварительной и публикации.
| Scenario | Description |
|---|---|
| Включение компьютеров | Включите компьютер для применения обновлений. |
| Создать моментальный снимок | Оснастки дисков, используемые для восстановления данных. |
| Уведомление по электронной почте | Перед активацией исправления отправьте оповещение об уведомлении. |
| Остановка служб | Остановите службы, такие как службы шлюза, NPExServices, службы SQL и т. д. |
Планирование порядка выполнения с предварительными событиями и событиями публикации
Для заданного расписания можно включить предварительное событие, пост-событие или оба. Кроме того, можно использовать несколько предварительных и (или) после событий. Последовательность выполнения расписания с предварительными и последующими событиями выглядит следующим образом:
Предварительное событие — задачи, выполняемые до начала периода обслуживания расписания. Например, включите компьютеры перед исправлением.
Отмена . На этом шаге можно инициировать отмену запланированного выполнения. Некоторые сценарии, в которых можно отменить выполнение расписания, включают сбои предварительного события или предварительное выполнение не выполнено.
Note
Необходимо инициировать отмену в рамках предварительного события; Конфигурация Диспетчера обновлений Azure или обслуживания не будет автоматически отменять расписание. Если не удается отменить, расписание выполняется с установкой обновлений во время пользовательского периода обслуживания.
Установка обновлений. Обновления устанавливаются в рамках пользовательского периода обслуживания.
После события — после установки обновлений выполняется после выполнения события. Это происходит в течение периода обслуживания, если установка обновления завершена, и окно осталось или за пределами окна, если период обслуживания завершен. Например, отключите виртуальные машины после завершения исправления.
Note
В Диспетчере обновлений Azure события перед выполнением вне периода обслуживания и после выполнения событий могут выполняться вне периода обслуживания. Необходимо запланировать это дополнительное время, необходимое для завершения выполнения расписания на компьютерах.
Состояние расписания. Состояние успешного или неудачного выполнения расписания относится только к установке обновлений на компьютерах, входящих в расписание. Состояние выполнения расписания не включает состояние предварительного и последующего события. Если событие завершилось сбоем, и вы вызвали API отмены, состояние выполнения расписания отображается как отмененное.
Диспетчер обновлений Azure использует службу "Сетка событий " для создания и отправки событий перед и публикацией событий в конфигурациях запланированного обслуживания. В службе "Сетка событий" можно выбрать из обработчиков событий, таких как веб-перехватчики Azure, Функции Azure и т. д., чтобы активировать действие предварительного и последующего выполнения.
Note
Если вы используете модули Runbook в предварительной версии и публикации в управлении обновлениями службы автоматизации Azure и планируете повторно использовать их в Диспетчере обновлений Azure, рекомендуется использовать веб-перехватчики Azure, связанные с модулями Runbook службы автоматизации. Подробнее.
Временная шкала расписаний для предварительных и постовых событий
Мы рекомендуем ознакомиться со следующей таблицей, чтобы понять временную шкалу расписания для предварительного и последующего событий.
Например, если задано расписание обслуживания в 3:00, период обслуживания составляет 3 часа и 55 минут для области обслуживания гостей . Расписание содержит одно предварительное событие и одно событие после выполнения, и ниже приведены сведения:
| Time | Details |
|---|---|
| 2:19 вечера | Так как запуск расписания начинается в 3:00 вечера, вы можете изменить компьютеры или области 40 минут до времени начала (т. е. в 2:19 вечера).
Заметка Это применимо, если вы создаете новое расписание или редактируйте существующее расписание с предварительным событием. |
| 2:20 вечера - 2:30 вечера | Так как предварительное событие активируется по крайней мере 30 минут до начала, оно может активироваться в любое время от 2:20 до 2:30 вечера. |
| 2:30 – 2:50 вечера | Предварительное событие выполняется с 2:30 до 2:50 вечера. Предварительное событие должно завершить задачи до 2:50 вечера.
Заметка Если настроено более одного предварительного события, все события должны выполняться в течение 20 минут. В нескольких предварительных событиях все они выполняются независимо друг от друга. Вы можете настроить в соответствии с вашими потребностями, определив логику в предварительных событиях. Например, если вы хотите, чтобы два предварительных события выполнялись последовательно, можно включить отложенное время начала во вторую логику события. Если событие предварительного выполнения продолжает выполняться за 20 минут или завершается сбоем, можно отменить расписание выполнения, в противном случае установка исправлений продолжается независимо от состояния выполнения предварительного события. |
| 2:50 вечера | Последнее время, которое может вызвать API отмены, — 2:50 вечера.
Заметка Если API отмены не удалось вызвать или не было настроено, установка исправлений продолжает выполняться. |
| 3:00 вечера | Запуск расписания активируется в 3:00 вечера. |
| 6:55 вечера | В 6:55 расписание завершает установку обновлений в течение 3 часов 55 минут обслуживания.
После установки обновлений активируется событие после установки обновлений в 6:55. Заметка Если вы определили более короткий период обслуживания в течение 2 часов, событие после обслуживания будет запускаться через 2 часа, и если установка обновления завершена до указанного времени в 2 часа (т. е. 1 часа 50 минут), событие после отправки начнется немедленно. |
Рекомендуется следить за следующими параметрами:
- Если вы создаете новое расписание или редактируете существующее расписание с предварительным событием, вам потребуется по крайней мере 40 минут до начала периода обслуживания (3:00 в приведенном выше примере) для выполнения предварительного события в противном случае это приведет к автоматической отмене текущего запланированного запуска.
- Вызов API отмены из скрипта или кода отменяет выполнение расписания, а не весь график.
- Состояние предварительного и последующего выполнения события можно проверить в выбранном обработчике событий.
Дальнейшие шаги
- Сведения о создании событий предварительной и последующей отправки см. в разделе о событиях конфигурации предварительного и после обслуживания.
- Чтобы узнать, как настроить события предварительной и последующей отправки или отменить выполнение расписания, см. сведения о событиях конфигурации предварительного и последующего обслуживания.
- Чтобы узнать, как использовать предварительные и постовые события для включения и отключения виртуальных машин с помощью веб-перехватчиков, см. здесь.
- Чтобы узнать, как использовать предварительные и постовые события для включения и отключения виртуальных машин с помощью Функций Azure, см. здесь.