Перейдите с управления обновлениями в службе автоматизации на Диспетчер обновлений Azure

Статья
05/09/2024

Область применения: ✔️ виртуальные машины ✔️ ✔️ Linux под управлением Windows На локальных серверах с ✔️ поддержкой Azure Arc

В этой статье приводятся рекомендации по перемещению виртуальных машин из службы "Управление обновлениями службы автоматизации" в Диспетчер обновлений Azure.

Диспетчер обновлений Azure предоставляет решение SaaS для управления обновлениями программного обеспечения на компьютерах Windows и Linux в Azure, локальных и многооблачных средах. Это эволюция решения управления обновлениями служба автоматизации Azure с новыми функциями и функциями, для оценки и развертывания обновлений программного обеспечения на одном компьютере или на нескольких компьютерах в масштабе.

Для диспетчера обновлений Azure AMA и MMA не требуются для управления рабочими процессами обновления программного обеспечения, так как для виртуальных машин Azure он использует агент виртуальной машины Microsoft Azure, а для серверов с поддержкой Arc — агент Azure Connected Machine Agent. При первом выполнении операции обновления на компьютере расширение отправляется на компьютер и взаимодействует с агентами для определения того, какие из обновлений отсутствуют, а также для установки обновлений.

Примечание.

Если вы используете решение для управления обновлениями службы автоматизации Azure, рекомендуется не удалять агенты MMA с компьютеров без завершения миграции в Диспетчер обновлений Azure для нужд управления исправлениями компьютера. Если вы удалите агент MMA с компьютера без перехода в Диспетчер обновлений Azure, это приведет к разрыву рабочих процессов исправления для этого компьютера.
Все возможности управления обновлениями служба автоматизации Azure будут доступны в Диспетчере обновлений Azure до даты отмены.

Взаимодействие с порталом Azure

В этом разделе объясняется, как использовать интерфейс портала для перемещения расписаний и компьютеров из службы "Управление обновлениями службы автоматизации" в Диспетчер обновлений Azure. С минимальными щелчками и автоматическим способом перемещения ресурсов проще всего перемещаться, если у вас нет настроек, созданных на основе решения управления обновлениями автоматизации.

Для доступа к интерфейсу миграции портала можно использовать несколько точек входа.

Нажмите кнопку "Перейти сейчас" на следующих точках входа. После выбора вы узнаете, как переместить расписания и компьютеры в Диспетчер обновлений Azure. Этот процесс предназначен для того, чтобы быть понятным и прямым, чтобы позволить вам выполнить миграцию с минимальными усилиями.

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

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

Здесь вы можете узнать, сколько серверов с поддержкой Azure, Серверов с поддержкой Arc, не включенных в Azure Arc, а также расписания включены в службе "Управление обновлениями службы автоматизации" и должны быть перемещены в Диспетчер обновлений Azure. Вы также можете просмотреть сведения об этих ресурсах.

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

После просмотра ресурсов, которые необходимо переместить, можно продолжить процесс миграции, который является трехэтапным процессом:

Необходимые условия

Это включает два шага.

a. Подключение компьютеров, отличных от Azure, не поддерживающих Arc, к Arc . Это связано с тем, что подключение Arc является обязательным условием для Диспетчера обновлений Azure. Подключение компьютеров к Azure Arc бесплатно, и после этого вы можете воспользоваться всеми службами управления, как можно сделать для любого компьютера Azure. Дополнительные сведения см . в документации по Azure Arc о том, как подключить компьютеры.

b. Скачайте и запустите скрипт PowerShell локально . Это необходимо для создания удостоверения пользователя и соответствующих назначений ролей, чтобы выполнить миграцию. Этот сценарий предоставляет RBAC удостоверению пользователя в подписке, к которой принадлежит учетная запись автоматизации, компьютеры, подключенные к управлению обновлениями службы автоматизации, область, которые являются частью динамических запросов и т. д., чтобы конфигурация была назначена компьютерам, конфигурации MRP можно создать и удалить решение для обновления. Дополнительные сведения см . в документации по Диспетчеру обновлений Azure.
Перемещение ресурсов в учетную запись службы автоматизации в Диспетчер обновлений Azure

Следующим шагом в процессе миграции является включение диспетчера обновлений Azure на компьютерах, которые необходимо переместить и создать эквивалентные конфигурации обслуживания для переноса расписаний. При нажатии кнопки "Миграция теперь " она импортирует модуль Runbook MigrateToAzureUpdateManager в учетную запись службы автоматизации и задает подробное ведение журнала true.

Выберите "Пуск runbook", который представляет параметры, которые необходимо передать в модуль Runbook.

Дополнительные сведения о параметрах для получения и расположения, откуда он должен быть получен, см. в разделе миграции компьютеров и расписаний. После запуска модуля Runbook после передачи всех параметров Диспетчер обновлений Azure начнет включаться на компьютерах и конфигурациях обслуживания в Azure Update Manager начнет создаваться. Журналы runbook Azure можно отслеживать для состояния выполнения и миграции расписаний.
Отключение ресурсов из управления обновлениями службы автоматизации

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

После нажатия кнопки "Запустить сценарий очистки" модуль Runbook DeboardFromAutomationUpdateManagement будет импортирован в учетную запись службы автоматизации, а его подробное ведение журнала имеет значение True.

При нажатии кнопки "Запуск модуля Runbook" запрашивает передать параметры в модуль Runbook. Дополнительные сведения см. в разделе "Отмена подключения из решения управления обновлениями службы автоматизации" для получения параметров, передаваемых в модуль Runbook.

Скрипты миграции

С помощью модулей Runbook миграции можно автоматически перенести все рабочие нагрузки (компьютеры и расписания) из службы "Управление обновлениями службы автоматизации" в Диспетчер обновлений Azure. В этом разделе описано, как запустить скрипт, что делает скрипт на серверной части, ожидаемое поведение и какие-либо ограничения, если это применимо. Скрипт может перенести все компьютеры и расписания в одной учетной записи службы автоматизации в один раз. Если у вас несколько учетных записей службы автоматизации, необходимо запустить модуль Runbook для всех учетных записей службы автоматизации.

На высоком уровне необходимо выполнить следующие действия, чтобы перенести компьютеры и расписания из службы "Управление обновлениями службы автоматизации" в Диспетчер обновлений Azure.

Сводка по предварительным требованиям

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

Сводка по шагам

Запустите модуль Runbook службы автоматизации миграции для переноса компьютеров и расписаний из службы "Управление обновлениями службы автоматизации" в Диспетчер обновлений Azure. Подробные инструкции см. в пошаговом руководстве.
Запустите скрипты очистки, чтобы отклопиться от управления обновлениями службы автоматизации. Подробные инструкции см. в пошаговом руководстве.

Неподдерживаемые сценарии

Не будут перенесены сохраненные поисковые запросы, не относящиеся к Azure; их необходимо перенести вручную.

Полный список ограничений и вещей, которые следует отметить, см. в последнем разделе этой статьи.

Пошаговое руководство

Сведения, упоминание описанные выше действия, подробно описаны ниже.

Предварительные требования 1. Подключение компьютеров, отличных от Azure, к Arc

Что делать

Модуль Runbook службы автоматизации миграции игнорирует ресурсы, которые не подключены к Arc. Поэтому перед запуском модуля Runbook миграции необходимо подключить все компьютеры, отличные от Azure Arc. Выполните действия, чтобы подключить компьютеры к Azure Arc.

Предварительные требования 2. Создание удостоверений пользователей и назначений ролей с помощью скрипта PowerShell

А. Предварительные требования для запуска скрипта

Выполните команду Install-Module -Name Az -Repository PSGallery -Force в PowerShell. Скрипт предварительных требований зависит от Az.Modules. Этот шаг требуется, если Az.Modules не присутствуют или не обновляются.
Чтобы запустить этот скрипт предварительных требований, необходимо иметь разрешения Microsoft.Authorization/roleAssignments/write для всех подписок, содержащих ресурсы управления обновлениями службы автоматизации, такие как компьютеры, расписания, рабочая область log analytics и учетная запись службы автоматизации. Узнайте , как назначить роль Azure.
У вас должны быть разрешения управления обновлениями.

B. Выполнение скрипта

Скачайте и запустите скрипт MigrationPrerequisiteScript PowerShell локально. Этот скрипт принимает AutomationAccountResourceId учетной записи службы автоматизации для переноса и автоматизацииAccountAzureEnvironment в качестве входных данных. Допустимые значения для AutomationAccountAzureEnvironment : AzureCloud, AzureUSGovernment и AzureChina, указывающие облако, к которому принадлежит учетная запись службы автоматизации.

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

C. Проверка

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

D. Внутренние операции с помощью скрипта

Обновление Az.Modules для учетной записи службы автоматизации, которая потребуется для выполнения сценариев миграции и переноса.
Создает переменную автоматизации с именем AutomationAccountAzureEnvironment, которая будет хранить облачную среду Azure, к которой принадлежит учетная запись службы автоматизации.
Создание удостоверения пользователя в той же подписке и группе ресурсов, что и учетная запись службы автоматизации. Имя удостоверения пользователя будет таким же , как AutomationAccount_aummig_umsi.
Присоединение удостоверения пользователя к учетной записи службы автоматизации.
Скрипт назначает следующие разрешения управляемому удостоверению пользователя: обязательные разрешения для управления обновлениями.
1. Для этого скрипт извлекает все компьютеры, подключенные к управлению обновлениями службы автоматизации, в рамках этой учетной записи службы автоматизации, и анализирует идентификаторы подписок, которые необходимо предоставить RBAC идентификатору пользователя.
2. Скрипт предоставляет RBAC правильному идентификатору пользователя в подписке, к которой принадлежит учетная запись службы автоматизации, чтобы можно было создать здесь конфигурации MRP.
3. Скрипт назначает необходимые роли для рабочей области и решения Log Analytics.
Регистрация необходимых подписок для поставщиков ресурсов Microsoft.Maintenance и Microsoft.EventGrid.

Шаг 1. Миграция компьютеров и расписаний

Этот шаг включает использование модуля Runbook службы автоматизации для переноса всех компьютеров и расписаний из учетной записи службы автоматизации в Диспетчер обновлений Azure.

Выполните следующие действия:

Импорт модуля Runbook миграции из коллекции runbook и публикация. Выполните поиск обновления службы автоматизации Azure из коллекции и импортируйте модуль Runbook миграции с именем "Миграция из служба автоматизации Azure управление обновлениями в Диспетчер обновлений Azure" и опубликуйте модуль Runbook.

Runbook поддерживает PowerShell 5.1.
Задайте для модуля Runbook значение True для подробного ведения журнала.
Запустите модуль Runbook и передайте необходимые параметры, такие как AutomationAccountResourceId, UserManagedServiceIdentityClientId и т. д.
1. Вы можете получить automationAccountResourceId из свойств учетной записи>службы автоматизации.
2. Вы можете получить идентификатор клиента userManagedServiceIdentityClientId из идентификатора пользователя,>назначенного>пользователем удостоверения>>службы автоматизации.>
3. Параметр EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement для TRUE включает периодическое свойство оценки на всех компьютерах, подключенных к управлению обновлениями службы автоматизации.
4. Установка параметра MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines на TRUE перенесите все расписания обновлений в Диспетчер обновлений службы автоматизации в Диспетчер обновлений Azure, а также включить периодическое свойство оценки в True на всех компьютерах, связанных с этими расписаниями.
5. Необходимо указать ResourceGroupForMaintenanceConfigurations , где будут созданы все конфигурации обслуживания в Диспетчере обновлений Azure. Если указать новое имя, будет создана группа ресурсов, в которой будут созданы все конфигурации обслуживания. Однако если указать имя, с которым уже существует группа ресурсов, все конфигурации обслуживания будут созданы в существующей группе ресурсов.
Проверьте журналы Runbook Azure, чтобы узнать о состоянии выполнения и миграции для SCS.

Операции Runbook в серверной части

Миграция модуля Runbook выполняет следующие задачи:

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

Сведения о скрипте

Ниже приведено поведение скрипта миграции.

Проверьте, присутствует ли группа ресурсов с именем, принятым в качестве входных данных, в подписке учетной записи службы автоматизации или нет. Если нет, создайте группу ресурсов с именем, указанным клиентом. Эта группа ресурсов используется для создания конфигураций MRP для версии 2.
Параметр RebootOnly недоступен в Диспетчере обновлений Azure. Расписания с параметром RebootOnly не переносятся.
Отфильтруйте suCs, которые находятся в состоянии ошибки, истечения срока действия или подготовкиFailed/disabled, и помечайте их как не перенесенные, и напечатать соответствующие журналы, указывающие, что такие suCs не переносятся.
Имя назначения конфигурации — это строка, которая будет находиться в формате AUMMig_AAName_SUCName
Узнайте, назначена ли эта динамическая область конфигурации обслуживания или не проверка для Azure Resource Graph. Если это не назначено, назначьте только имя назначения в формате AUMMig_ AAName_SUCName_SomeGUID.
Для расписаний с настроенными задачами предварительной и последующей отправки скрипт создаст веб-перехватчик автоматизации для модулей Runbook в задачах предварительной записи и подписках сетки событий для событий предварительного или последующего обслуживания. Дополнительные сведения см. в статье о работе предварительной и публикации в Диспетчере обновлений Azure
Резюмируемый набор журналов выводится в поток вывода, чтобы обеспечить общее состояние компьютеров и SCS.
Подробные журналы печатаются в подробном потоке.
После миграции конфигурация обновления программного обеспечения может иметь одно из следующих четырех состояний миграции:
- MigrationFailed
- ЧастичноMigrated
- NotMigrated
- Перенесены

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

MigrationFailed	ЧастичноMigrated	NotMigrated	Перенесены
Не удалось создать конфигурацию обслуживания для конфигурации обновления программного обеспечения.	Ненулевое число компьютеров, в которых не удалось применить исправление Параметры.	Не удалось получить конфигурацию обновления программного обеспечения из API из-за некоторых ошибок клиента или сервера, например внутренней ошибки службы.
	Ненулевое число компьютеров с неисправными назначениями конфигурации.	Конфигурация обновления программного обеспечения имеет параметр перезагрузки только в качестве перезагрузки. Это не поддерживается сегодня в Диспетчере обновлений Azure.
	Ненулевое число динамических запросов не удалось устранить, которое не удалось выполнить запрос к Azure Resource Graph.
	Ненулевое число сбоев назначения конфигурации динамической области.	Конфигурация обновления программного обеспечения не имеет состояния подготовки в базе данных.
	Конфигурация обновления программного обеспечения сохраняет поисковые запросы.	Конфигурация обновления программного обеспечения находится в состоянии ошибки в базе данных.
	Конфигурация обновления программного обеспечения выполняет задачи предварительной или post, которые не были успешно перенесены.	Расписание, связанное с конфигурацией обновления программного обеспечения, уже истекло во время миграции.
		Расписание, связанное с конфигурацией обновления программного обеспечения, отключено.
		Необработанное исключение при переносе конфигурации обновления программного обеспечения.	Ноль компьютеров, где не удалось применить исправление Параметры. And Ноль компьютеров с неудачными назначениями конфигурации. And Не удалось разрешить не удалось выполнить запрос к Azure Resource Graph, но не удалось выполнить динамические запросы. And Сбои назначения динамической области. And Конфигурация обновления программного обеспечения содержит ноль сохраненных запросов поиска.

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

Вы также можете выполнить поиск по имени расписания обновления, чтобы получить журналы, относящиеся к нему для отладки.

Шаг 2. Отключение подключения из решения управления обновлениями службы автоматизации

Выполните следующие действия:

Импортируйте модуль Runbook миграции из коллекции runbook. Выполните поиск обновления службы автоматизации Azure из коллекции и импортируйте модуль Runbook миграции с именем Deboard из служба автоматизации Azure Update Management и опубликуйте модуль Runbook.

Runbook поддерживает PowerShell 5.1.
Задайте для модуля Runbook значение True для подробного ведения журнала.
Запустите модуль Runbook и передайте такие параметры, как AccountResourceId, UserManagedServiceIdentityClientId и т. д.

Вы можете получить automationAccountResourceId из свойств учетной записи>службы автоматизации.

Вы можете получить идентификатор клиента userManagedServiceIdentityClientId из идентификатора пользователя,>назначенного>пользователем удостоверения>>службы автоматизации.>
Проверьте журналы runbook Azure для состояния деboarding компьютеров и расписаний.

Отмена операций скрипта в серверной части

Отключите все базовые расписания для всех конфигураций обновлений программного обеспечения, присутствующих в этой учетной записи службы автоматизации. Это делается для обеспечения того, чтобы runbook patch-MicrosoftOMSComputers не активировался для SCS, которые были частично перенесены на версию 2.
Удалите решение Обновления из связанной рабочей области Log Analytics для учетной записи службы автоматизации, отложенной от управления обновлениями службы автоматизации в версии 1.
В выходной поток также выводится сводный журнал всех SCS, отключенных и состояние удаления решения обновлений из связанной рабочей области log analytics.
Подробные журналы печатаются в подробных потоках.

Выноски для процесса миграции:

Не будут перенесены сохраненные поисковые запросы, отличные от Azure.
Для работы модулей Runbook миграции и деboarding необходимо обновить Az.Modules.
Скрипт предварительных требований обновляет Az.Modules до последней версии 8.0.0.
Время начала расписания MRP будет равно следующемуRunTime конфигурации обновления программного обеспечения.
Данные из Log Analytics не будут перенесены.
Управляемые пользователем удостоверения не поддерживают сценарии между клиентами.
Параметр RebootOnly недоступен в Диспетчере обновлений Azure. Расписания с параметром RebootOnly не будут перенесены.
Для повторения служба автоматизации планирует поддержку значений между (от 1 до 100) для часовых и еженедельных и ежемесячных расписаний, в то время как конфигурация обслуживания Диспетчера обновлений Azure поддерживает от (от 6 до 35) для почасового и (1–35) для ежедневного или еженедельного или ежемесячного.
- Например, если расписание автоматизации имеет повторение каждые 100 часов, то для каждой конфигурации обслуживания каждые 100/24 = 4,16 (округление до ближайшего значения) —> четыре дня будет повторением конфигурации обслуживания.
- Например, если расписание автоматизации имеет повторение каждые 1 час, то эквивалентное расписание конфигурации обслуживания будет иметь его каждые 6 часов.
- Применить одно и то же соглашение для еженедельной и ежедневной.
  - Если расписание автоматизации имеет ежедневное повторение 100 дней, то 100/7 = 14,28 (округление до ближайшего значения) —> 14 недель будет повторение расписания конфигурации обслуживания.
  - Если расписание автоматизации имеет еженедельное повторение 100 недель, то 100/4.34 = 23.04 (округление до ближайшего значения) —> 23 месяца будет повторение расписания конфигурации обслуживания.
  - Если расписание автоматизации, которое должно повторяться каждые 100 недель и должно выполняться в пятницу. При переводе в конфигурацию обслуживания она будет каждые 23 месяца (100/4.34). Но в диспетчере обновлений Azure нет способа сказать, что выполнение каждые 23 месяца во всех пятницах этого месяца, поэтому расписание не будет перенесено.
  - Если расписание автоматизации имеет повторение более 35 месяцев, то в конфигурации обслуживания всегда будет повторяться 35 месяцев.
- SUC поддерживает от 30 минут до шести часов для периода обслуживания. MRP поддерживает от 1 часа до 30 минут до 4 часов.
  - Например, если SUC имеет период обслуживания 30 минут, то эквивалентное расписание MRP будет иметь его в течение 1 часа 30 минут.
  - Например, если SUC имеет период обслуживания 6 часов, то эквивалентное расписание MRP будет иметь его в течение 4 часов.
Когда модуль Runbook миграции выполняется несколько раз, предположим, что вы выполнили миграцию всех расписаний автоматизации, а затем еще раз попытались перенести все расписания, то runbook миграции будет выполнять ту же логику. Это снова обновит расписание MRP, если в SUC присутствует любое новое изменение. Он не будет делать повторяющиеся назначения конфигурации. Кроме того, операции выполняются только для расписаний автоматизации с включенными расписаниями. Если SUC был перенесен ранее, он будет пропущен в следующем повороте, так как его базовое расписание будет отключено.
В конце концов можно разрешить дополнительные компьютеры из Azure Resource Graph, как в Диспетчере обновлений Azure; Вы не можете проверка, если гибридная рабочая роль Runbook сообщает или нет, в отличие от управления обновлениями службы автоматизации, где это было пересечение динамических запросов и гибридной рабочей роли Runbook.

Руководство по миграции вручную

Рекомендации по перемещению различных возможностей приведены в таблице ниже:

S.No	Возможность	Управление обновлениями службы автоматизации	Диспетчер обновлений Azure	Шаги с помощью портал Azure	Действия с помощью API или скрипта
1	Управление исправлениями для компьютеров вне Azure.	Может работать как с подключением Arc, так и без него.	Azure Arc является обязательным условием для компьютеров, отличных от Azure.	1. Создание субъекта-службы 2. Создайте скрипт установки 3. Установка агента и подключение к Azure	1. Создание субъекта-службы 2. Создайте скрипт установки 3. Установка агента и подключение к Azure
2	Включите периодическую оценку, чтобы автоматически проверять наличие последних обновлений каждые несколько часов.	Компьютеры автоматически получают последние обновления каждые 12 часов для Windows и каждые 3 часа для Linux.	Периодическая оценка — это настройка обновления на вашем компьютере. Если он включен, Диспетчер обновлений получает обновления для компьютера каждые 24 часа и показывает статус последних обновлений.	1. Один компьютер 2. В масштабе 3. Масштабирование с помощью политики	1. Для виртуальной машины Azure 2.Для виртуальной машины с поддержкой Arc
3	Расписания развертывания статических обновлений (статический список компьютеров для развертывания обновлений).	Управление обновлениями службы автоматизации имеет собственные расписания.	Azure Update Manager создает объект конфигурации обслуживания для расписания. Таким образом, необходимо создать этот объект, скопировав все параметры расписания из службы Управление обновлениями службы автоматизации в расписание Диспетчера обновлений Azure.	1. Одна виртуальная машина 2. В масштабе 3. Масштабирование с помощью политики	Создание статической области
4	Расписания развертывания динамического обновления (определение области компьютеров с помощью группы ресурсов, тегов и т.д., которые оцениваются динамически во время выполнения).	То же, что и расписания статического обновления.	То же, что и расписания статического обновления.	Добавление динамической области	Создание динамической области
5	Отключить управление обновлениями в службе автоматизации Azure.	После выполнения шагов 1, 2 и 3 необходимо очистить объекты управления обновлениями Azure.		Удаление решения Управления обновлениями	Неприменимо
6	Отчетность	Пользовательские отчеты об обновлениях с использованием запросов Анализа журналов.	Данные об обновлении хранятся в Azure Resource Graph (ARG). Клиенты могут запрашивать данные ARG для создания пользовательских информационных панелей, книг и т.д.	Доступ к старым данным управления обновлениями службы автоматизации, хранящимся в Log Analytics, возможен, но возможность перемещения данных в ARG отсутствует. Вы можете писать запросы ARG для доступа к данным, которые будут храниться в ARG после установки исправлений на виртуальных машинах с помощью Диспетчера обновлений Azure. С помощью запросов ARG можно создавать панели мониторинга и книги, используя следующие инструкции: 1. Структура журнала графа ресурсов Azure обновляет данные 2. Пример запросов ARG 3. Создание книг	Неприменимо
7	Настройте рабочие процессы с помощью предварительных и постовых скриптов.	Доступно в виде Runbook службы автоматизации.	Рекомендуется попробовать использовать общедоступную предварительную версию для предварительных и постовых сценариев на компьютерах, отличных от рабочей среды, и использовать функцию для рабочих нагрузок после того, как эта функция войдет в общую доступность.	Управление событиями предварительной и публикации (предварительная версия)и руководство. Создание событий предварительной и публикации с помощью веб-перехватчика с помощью автоматизации
8	Создание оповещений на основе данных об обновлениях для вашей среды	Оповещения можно настроить для обновлений, хранящихся в Анализе журналов.	Рекомендуется попробовать общедоступную предварительную версию оповещений на компьютерах, отличных от рабочей среды, и использовать эту функцию для рабочих нагрузок после того, как эта функция войдет в общую доступность.	Создание оповещений (предварительная версия)

Следующие шаги

Руководство по переносу виртуальных машин Azure из Microsoft Configuration Manager в Azure Update Manager

Share via