Перейдите с управления обновлениями в службе автоматизации на Диспетчер обновлений Azure
Область применения: ✔️ виртуальные машины ✔️ ✔️ 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.
Присоединение удостоверения пользователя к учетной записи службы автоматизации.
Скрипт назначает следующие разрешения управляемому удостоверению пользователя: обязательные разрешения для управления обновлениями.
- Для этого скрипт извлекает все компьютеры, подключенные к управлению обновлениями службы автоматизации, в рамках этой учетной записи службы автоматизации, и анализирует идентификаторы подписок, которые необходимо предоставить RBAC идентификатору пользователя.
- Скрипт предоставляет RBAC правильному идентификатору пользователя в подписке, к которой принадлежит учетная запись службы автоматизации, чтобы можно было создать здесь конфигурации MRP.
- Скрипт назначает необходимые роли для рабочей области и решения 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 и т. д.
Вы можете получить automationAccountResourceId из свойств учетной записи>службы автоматизации.
Вы можете получить идентификатор клиента userManagedServiceIdentityClientId из идентификатора пользователя,>назначенного>пользователем удостоверения>>службы автоматизации.>
Параметр EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement для TRUE включает периодическое свойство оценки на всех компьютерах, подключенных к управлению обновлениями службы автоматизации.
Установка параметра MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines на TRUE перенесите все расписания обновлений в Диспетчер обновлений службы автоматизации в Диспетчер обновлений Azure, а также включить периодическое свойство оценки в True на всех компьютерах, связанных с этими расписаниями.
Необходимо указать 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 | Создание оповещений на основе данных об обновлениях для вашей среды | Оповещения можно настроить для обновлений, хранящихся в Анализе журналов. | Рекомендуется попробовать общедоступную предварительную версию оповещений на компьютерах, отличных от рабочей среды, и использовать эту функцию для рабочих нагрузок после того, как эта функция войдет в общую доступность. | Создание оповещений (предварительная версия) |