Pindah dari Manajemen Pembaruan Automation ke Azure Update Manager

Berlaku untuk: ✔️ VM Windows VM ✔️ ✔️ Linux Lingkungan ✔️ lokal server yang didukung Azure Arc

Artikel ini menyediakan panduan untuk memindahkan komputer virtual dari Manajemen Pembaruan Automation ke Azure Update Manager.

Azure Update Manager menyediakan solusi SaaS untuk mengelola dan mengatur pembaruan perangkat lunak ke komputer Windows dan Linux di seluruh lingkungan Azure, lokal, dan multicloud. Ini adalah evolusi solusi manajemen Pembaruan Azure Automation dengan fitur dan fungsionalitas baru, untuk penilaian dan penyebaran pembaruan perangkat lunak pada satu komputer atau pada beberapa komputer dalam skala besar.

Untuk Manajer Pembaharuan Azure, baik AMA dan MMA bukan persyaratan untuk mengelola alur kerja pembaruan perangkat lunak karena bergantung pada Agen VM Microsoft Azure untuk Azure VM dan agen mesin yang terhubung Azure untuk server yang didukung Arc. Ketika Anda melakukan operasi pembaruan untuk pertama kalinya pada komputer, ekstensi didorong ke komputer dan berinteraksi dengan agen untuk menilai pembaruan yang hilang dan menginstal pembaruan.

Catatan

  • Jika Anda menggunakan Solusi Manajemen Pembaruan Azure Automation, kami sarankan Anda tidak menghapus agen MMA dari komputer tanpa menyelesaikan migrasi ke Azure Update Manager untuk kebutuhan manajemen patch komputer. Jika Anda menghapus agen MMA dari mesin tanpa pindah ke Azure Update Manager, itu akan merusak alur kerja patching untuk komputer tersebut.

  • Semua kemampuan Manajemen Pembaruan Azure Automation akan tersedia di Azure Update Manager sebelum tanggal penghentian.

pengalaman portal Azure (pratinjau)

Bagian ini menjelaskan cara menggunakan pengalaman portal (pratinjau) untuk memindahkan jadwal dan komputer dari Manajemen Pembaruan Automation ke Azure Update Manager. Dengan klik minimal dan cara otomatis untuk memindahkan sumber daya Anda, ini adalah cara term mudah untuk berpindah jika Anda tidak memiliki penyesuaian yang dibangun di atas solusi Manajemen Pembaruan Automation Anda.

Untuk mengakses pengalaman migrasi portal, Anda dapat menggunakan beberapa titik masuk.

Pilih tombol Migrasi Sekarang yang ada di titik masuk berikut. Setelah pemilihan, Anda dipandu melalui proses pemindahan jadwal dan komputer Anda ke Azure Update Manager. Proses ini dirancang untuk ramah pengguna dan langsung ke depan untuk memungkinkan Anda menyelesaikan migrasi dengan upaya minimal.

Anda dapat bermigrasi dari salah satu titik masuk berikut:

Pilih tombol Migrasi Sekarang dan bilah migrasi terbuka. Ini berisi ringkasan semua sumber daya termasuk mesin, dan jadwal di akun Automation. Secara default, akun Automation tempat Anda mengakses bilah ini telah dipilih sebelumnya jika Anda melewati rute ini.

Cuplikan layar yang memperlihatkan cara bermigrasi dari titik entri Manajemen Pembaruan Automation.

Di sini, Anda dapat melihat berapa banyak server yang didukung Azure, Arc, server non-Azure non-Arc yang diaktifkan, dan jadwal diaktifkan di Manajemen Pembaruan Automation dan perlu dipindahkan ke Azure Update Manager. Anda juga dapat melihat detail sumber daya ini.

Bilah migrasi memberikan gambaran umum tentang sumber daya yang akan dipindahkan, memungkinkan Anda meninjau dan mengonfirmasi migrasi sebelum melanjutkan. Setelah siap, Anda dapat melanjutkan proses migrasi untuk memindahkan jadwal dan komputer Anda ke Azure Update Manager.

Cuplikan layar yang memperlihatkan cara memigrasikan semua sumber daya dari akun Automation.

Setelah meninjau sumber daya yang harus dipindahkan, Anda dapat melanjutkan proses migrasi yang merupakan proses tiga langkah:

  1. Prasyarat

    Ini termasuk dua langkah:

    a. Onboarding komputer non-Azure non-Arc yang diaktifkan ke Arc - Ini karena konektivitas Arc adalah prasyarat untuk Azure Update Manager. Onboarding komputer Anda ke Azure Arc gratis, dan setelah Melakukannya, Anda dapat memanfaatkan semua layanan manajemen seperti yang dapat Anda lakukan untuk komputer Azure apa pun. Untuk informasi selengkapnya, lihat Dokumentasi Azure Arc tentang cara onboarding komputer Anda.

    b. Unduh dan jalankan skrip PowerShell secara lokal - Ini diperlukan untuk pembuatan identitas pengguna dan penetapan peran yang sesuai sehingga migrasi dapat berlangsung. Skrip ini memberikan RBAC yang tepat ke Identitas Pengguna pada langganan tempat akun otomatisasi berada, komputer yang di-onboard ke Manajemen Pembaruan Automation, cakupan yang merupakan bagian dari kueri dinamis dll. sehingga konfigurasi dapat ditetapkan ke mesin, konfigurasi MRP dapat dibuat dan solusi pembaruan dapat dihapus. Untuk informasi selengkapnya, lihat Dokumentasi Azure Update Manager.

    Cuplikan layar yang memperlihatkan prasyarat untuk migrasi.

  2. Memindahkan sumber daya di akun Automation ke Azure Update Manager

    Langkah selanjutnya dalam proses migrasi adalah mengaktifkan Azure Update Manager pada komputer untuk dipindahkan dan membuat konfigurasi pemeliharaan yang setara agar jadwal dimigrasikan. Saat Anda memilih tombol Migrasi Sekarang , tombol ini mengimpor runbook MigrateToAzureUpdateManager ke akun Automation Anda dan mengatur pengelogan verbose ke True.

    Cuplikan layar yang memperlihatkan cara memigrasikan beban kerja di akun Automation Anda.

    Pilih Mulai runbook, yang menyajikan parameter yang harus diteruskan ke runbook.

    Cuplikan layar yang menunjukkan cara memulai runbook untuk memungkinkan parameter diteruskan ke runbook.

    Untuk informasi selengkapnya tentang parameter yang akan diambil dan lokasi tempat parameter harus diambil, lihat migrasi komputer dan jadwal. Setelah Anda memulai runbook setelah meneruskan semua parameter, Azure Update Manager akan mulai diaktifkan pada mesin dan konfigurasi pemeliharaan di Azure Update Manager akan mulai dibuat. Anda dapat memantau log runbook Azure untuk status eksekusi dan migrasi jadwal.

  3. Deboard sumber daya dari manajemen Pembaruan Automation

    Jalankan skrip pembersihan untuk mendeboardasi komputer dari solusi Manajemen Pembaruan Automation dan nonaktifkan jadwal Manajemen Pembaruan Automation.

    Setelah Anda memilih tombol Jalankan skrip pembersihan, runbook DeboardFromAutomationUpdateManagement akan diimpor ke akun Automation Anda, dan pengelogan verbosenya diatur ke True.

    Cuplikan layar yang memperlihatkan cara melakukan pascamigrasi.

    Saat Anda memilih Mulai runbook, meminta parameter untuk diteruskan ke runbook. Untuk informasi selengkapnya, lihat Deboarding dari solusi Manajemen Pembaruan Automation untuk mengambil parameter yang akan diteruskan ke runbook.

    Cuplikan layar yang memperlihatkan cara mendeboardasi dari Manajemen Pembaruan Automation dan memulai runbook.

Skrip migrasi (pratinjau)

Dengan menggunakan runbook migrasi, Anda dapat secara otomatis memigrasikan semua beban kerja (mesin dan jadwal) dari Manajemen Pembaruan Automation ke Azure Update Manager. Bagian ini merinci tentang cara menjalankan skrip, apa yang dilakukan skrip di backend, perilaku yang diharapkan, dan batasan apa pun, jika berlaku. Skrip dapat memigrasikan semua komputer dan jadwal dalam satu akun otomatisasi sekaligus. Jika Anda memiliki beberapa akun otomatisasi, Anda harus menjalankan runbook untuk semua akun otomatisasi.

Pada tingkat tinggi, Anda perlu mengikuti langkah-langkah di bawah ini untuk memigrasikan komputer dan jadwal Anda dari Manajemen Pembaruan Automation ke Azure Update Manager.

Ringkasan prasyarat

  1. Onboarding komputer non-Azure ke Azure Arc.
  2. Unduh dan jalankan skrip PowerShell untuk pembuatan Identitas Pengguna dan Penetapan Peran secara lokal di sistem Anda. Lihat instruksi terperinci dalam panduan langkah demi langkah karena juga memiliki prasyarat tertentu.

Ringkasan langkah-langkah

  1. Jalankan runbook otomatisasi migrasi untuk memigrasikan komputer dan jadwal dari Manajemen Pembaruan Automation ke Azure Update Manager. Lihat instruksi terperinci dalam panduan langkah demi langkah.
  2. Jalankan skrip pembersihan untuk melakukan deboarding dari Manajemen Pembaruan Automation. Lihat instruksi terperinci dalam panduan langkah demi langkah.

Skenario yang tidak didukung

  • Jadwal pembaruan yang memiliki tugas Pra/Posting tidak akan dimigrasikan untuk saat ini.
  • Kueri Pencarian Tersimpan Non-Azure tidak akan dimigrasikan; ini harus dimigrasikan secara manual.

Untuk daftar lengkap batasan dan hal-hal yang perlu diperhatikan, lihat bagian terakhir dari artikel ini.

Panduan langkah demi langkah

Informasi yang disebutkan dalam setiap langkah di atas dijelaskan secara rinci di bawah ini.

Prasyarat 1: OnboardIng Non-Azure Machines ke Arc

Apa yang harus dilakukan

Runbook otomatisasi migrasi mengabaikan sumber daya yang tidak di-onboard ke Arc. Oleh karena itu, ini adalah prasyarat untuk onboarding semua komputer non-Azure ke Azure Arc sebelum menjalankan runbook migrasi. Ikuti langkah-langkah untuk onboarding komputer ke Azure Arc.

Prasyarat 2: Membuat Identitas Pengguna dan Penetapan Peran dengan menjalankan skrip PowerShell

J. Prasyarat untuk menjalankan skrip

  • Jalankan perintah Install-Module -Name Az -Repository PSGallery -Force di PowerShell. Skrip prasyarat tergantung pada Az.Modules. Langkah ini diperlukan jika Az.Modules tidak ada atau diperbarui.
  • Untuk menjalankan skrip prasyarat ini, Anda harus memiliki izin Microsoft.Authorization/roleAssignments/write pada semua langganan yang berisi sumber daya Manajemen Pembaruan Automation seperti komputer, jadwal, ruang kerja analitik log, dan akun otomatisasi. Lihat cara menetapkan peran Azure.
  • Anda harus memiliki Izin Manajemen Pembaruan.

Cuplikan layar yang menunjukkan bagaimana perintah untuk menginstal modul.

B. Jalankan skrip

Unduh dan jalankan skrip MigrationPrerequisiteScript PowerShell secara lokal. Skrip ini mengambil AutomationAccountResourceId dari akun Automation untuk dimigrasikan sebagai input.

Cuplikan layar yang memperlihatkan cara mengunduh dan menjalankan skrip.

Anda dapat mengambil AutomationAccountResourceId dengan masuk ke Properti Akun>Automation.

Cuplikan layar yang memperlihatkan cara mengambil ID sumber daya.

C. Verifikasi

Setelah Anda menjalankan skrip, verifikasi bahwa identitas terkelola pengguna dibuat di akun automasi. Pengguna Identitas>akun>Automation Ditetapkan.

Cuplikan layar yang memperlihatkan cara memverifikasi bahwa identitas terkelola pengguna dibuat.

D. Operasi backend berdasarkan skrip

  1. Memperbarui Az.Modules untuk akun Automation, yang akan diperlukan untuk menjalankan skrip migrasi dan deboarding

  2. Pembuatan Identitas Pengguna dalam grup Langganan dan sumber daya yang sama dengan Akun Automation. Nama Identitas Pengguna akan seperti AutomationAccount_aummig_umsi.

  3. Melampirkan Identitas Pengguna ke Akun Automation.

  4. Skrip menetapkan izin berikut ke identitas terkelola pengguna: Izin Manajemen Pembaruan Diperlukan.

    1. Untuk ini, skrip mengambil semua mesin yang di-onboard ke Manajemen Pembaruan Automation di bawah akun otomatisasi ini dan mengurai ID langganan mereka untuk diberikan RBAC yang diperlukan ke Identitas Pengguna.
    2. Skrip memberikan RBAC yang tepat ke Identitas Pengguna pada langganan tempat akun otomatisasi berada sehingga konfigurasi MRP dapat dibuat di sini.
    3. Skrip menetapkan peran yang diperlukan untuk ruang kerja dan solusi Analitik Log.

Langkah 1: Migrasi komputer dan jadwal

Langkah ini melibatkan penggunaan runbook otomatisasi untuk memigrasikan semua mesin dan jadwal dari akun otomatisasi ke Azure Update Manager.

Ikuti langkah-langkah ini:

  1. Impor runbook migrasi dari galeri runbook dan terbitkan. Cari pembaruan otomatisasi azure dari telusuri galeri, dan impor runbook migrasi bernama Migrate dari Manajemen Pembaruan Azure Automation ke Azure Update Manager dan terbitkan runbook.

    Cuplikan layar yang memperlihatkan cara bermigrasi dari Manajemen Pembaruan Automation.

    Runbook mendukung PowerShell 5.1.

    Cuplikan layar yang memperlihatkan runbook mendukung PowerShell 5.1 saat mengimpor.

  2. Atur Pengelogan Verbose ke True untuk runbook.

    Cuplikan layar yang memperlihatkan cara mengatur catatan log verbose.

  3. Jalankan runbook dan berikan parameter yang diperlukan seperti AutomationAccountResourceId, UserManagedServiceIdentityClientId, dll.

    Cuplikan layar yang menunjukkan cara menjalankan runbook dan meneruskan parameter yang diperlukan.

    1. Anda dapat mengambil AutomationAccountResourceId dari Properti Akun>Automation.

      Cuplikan layar yang memperlihatkan cara mengambil ID sumber daya akun Automation.

    2. Anda dapat mengambil UserManagedServiceIdentityClientId dari ID Klien Properti>Identitas>yang Ditetapkan>Pengguna Akun>>Automation.

      Cuplikan layar yang memperlihatkan cara mengambil ID klien.

    3. Mengatur EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement ke TRUE akan mengaktifkan properti penilaian berkala pada semua komputer yang di-onboard ke Manajemen Pembaruan Automation.

    4. Mengatur MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines ke TRUE akan memigrasikan semua jadwal pembaruan dalam Manajemen Pembaruan Automation ke Azure Update Manager dan juga akan mengaktifkan properti penilaian berkala ke True pada semua komputer yang ditautkan ke jadwal ini.

    5. Anda perlu menentukan ResourceGroupForMaintenanceConfigurations tempat semua konfigurasi pemeliharaan di Azure Update Manager akan dibuat. Jika Anda memberikan nama baru, grup sumber daya akan dibuat di mana semua konfigurasi pemeliharaan akan dibuat. Namun, jika Anda memberikan nama tempat grup sumber daya sudah ada, semua konfigurasi pemeliharaan akan dibuat di grup sumber daya yang ada.

  4. Periksa Log Runbook Azure untuk status eksekusi dan status migrasi SUC.

    Cuplikan layar yang memperlihatkan log runbook.

Operasi runbook di backend

Migrasi runbook melakukan tugas-tugas berikut:

  • Mengaktifkan penilaian berkala pada semua komputer.
  • Semua jadwal di akun otomatisasi dimigrasikan ke Azure Update Manager dan konfigurasi pemeliharaan yang sesuai dibuat untuk masing-masing, memiliki properti yang sama.

Tentang skrip

Berikut ini adalah perilaku skrip migrasi:

  • Periksa apakah grup sumber daya dengan nama yang diambil sebagai input sudah ada dalam langganan akun otomatisasi atau tidak. Jika tidak, buat grup sumber daya dengan nama yang ditentukan oleh Cx. Grup sumber daya ini digunakan untuk membuat konfigurasi MRP untuk V2.

  • Skrip mengabaikan jadwal pembaruan yang memiliki skrip pra dan posting yang terkait dengannya. Untuk jadwal pembaruan pra dan pasca skrip, migrasikan secara manual.

  • Pengaturan RebootOnly tidak tersedia di Azure Update Manager. Jadwal yang memiliki Pengaturan RebootOnly tidak dimigrasikan.

  • Filter SUC yang berada dalam status errored/expired/provisioningFailed/disabled dan tandai sebagai Tidak Dimigrasikan, dan cetak log yang sesuai yang menunjukkan bahwa SUC tersebut tidak dimigrasikan.

  • Nama penetapan konfigurasi adalah string yang akan dalam format AUMMig_AAName_SUCName

  • Cari tahu apakah Cakupan Dinamis ini sudah ditetapkan ke konfigurasi Pemeliharaan atau tidak dengan memeriksa azure Resource Graph. Jika tidak ditetapkan, maka hanya tetapkan dengan nama penugasan dalam format AUMMig_ AAName_SUCName_SomeGUID.

  • Sekumpulan log yang dirangkum dicetak ke aliran Output untuk memberikan status keseluruhan komputer dan SUC.

  • Log terperinci dicetak ke Verbose Stream.

  • Pascamigrasi, Konfigurasi Pembaruan Perangkat Lunak dapat memiliki salah satu dari empat status migrasi berikut:

    • MigrationFailed
    • SebagianMigrated
    • NotMigrated
    • Dimigrasi

Tabel di bawah ini memperlihatkan skenario yang terkait dengan setiap Status Migrasi.

MigrationFailed SebagianMigrated NotMigrated Dimigrasi
Gagal membuat Konfigurasi Pemeliharaan untuk Konfigurasi Pembaruan Perangkat Lunak. Bukan nol jumlah Mesin tempat Patch-Pengaturan gagal diterapkan. Gagal mendapatkan konfigurasi pembaruan perangkat lunak dari API karena beberapa kesalahan klien/server seperti mungkin Kesalahan Layanan internal.
Jumlah Non-Nol Komputer dengan Penugasan Konfigurasi yang gagal. Konfigurasi Pembaruan Perangkat Lunak memiliki pengaturan boot ulang sebagai reboot saja. Ini tidak didukung hari ini di Azure Update Manager.
Bukan nol jumlah Kueri Dinamis gagal diselesaikan yang gagal menjalankan kueri terhadap Azure Resource Graph. Konfigurasi Pembaruan Perangkat Lunak memiliki Tugas Pra/Posting. Saat ini, Pra/Posting dalam Pratinjau di Azure Update Manager dan jadwal tersebut tidak akan dimigrasikan.
Jumlah non-Nol kegagalan penetapan Konfigurasi Cakupan Dinamis. Konfigurasi Pembaruan Perangkat Lunak tidak memiliki status provisi yang berhasil di DB.
Konfigurasi Pembaruan Perangkat Lunak memiliki Kueri Pencarian Tersimpan. Konfigurasi Pembaruan Perangkat Lunak dalam status kesalahan di DB.
Jadwal yang terkait dengan Konfigurasi Pembaruan Perangkat Lunak sudah kedaluwarsa pada saat migrasi.
Jadwal yang terkait dengan Konfigurasi Pembaruan Perangkat Lunak dinonaktifkan.
Pengecualian tidak tertangani saat memigrasikan konfigurasi pembaruan perangkat lunak. Zero Machines tempat Patch-Pengaturan gagal diterapkan.

Dan

Zero Machines dengan Penugasan Konfigurasi yang gagal.

Dan

Kueri Dinamis Nol gagal diselesaikan yang gagal menjalankan kueri terhadap Azure Resource Graph.

Dan

Kegagalan penetapan Konfigurasi Cakupan Dinamis Nol.

Dan

Konfigurasi Pembaruan Perangkat Lunak tidak memiliki Kueri Pencarian Tersimpan.

Untuk mengetahui dari tabel di atas skenario/skenario mana yang sesuai dengan mengapa konfigurasi pembaruan perangkat lunak memiliki status tertentu, lihat log verbose/failed/warning untuk mendapatkan kode kesalahan dan pesan kesalahan.

Anda juga dapat mencari dengan nama jadwal pembaruan untuk mendapatkan log khusus untuk penelusuran kesalahan.

Cuplikan layar yang memperlihatkan cara menampilkan log khusus untuk penelusuran kesalahan.

Langkah 2: Deboarding dari solusi Manajemen Pembaruan Automation

Ikuti langkah-langkah ini:

  1. Impor runbook migrasi dari galeri runbook. Cari pembaruan otomatisasi azure dari telusuri galeri, dan impor runbook migrasi bernama Deboard dari Manajemen Pembaruan Azure Automation dan terbitkan runbook.

    Cuplikan layar yang memperlihatkan cara mengimpor runbook migrasi deaboard.

    Runbook mendukung PowerShell 5.1.

    Cuplikan layar yang memperlihatkan runbook mendukung PowerShell 5.1 saat deboarding.

  2. Atur Pengelogan Verbose ke True untuk Runbook.

    Cuplikan layar yang memperlihatkan pengaturan rekaman verbose log saat deboarding.

  3. Mulai parameter runbook dan pass seperti Automation AccountResourceId, UserManagedServiceIdentityClientId, dll.

    Cuplikan layar yang menunjukkan cara memulai runbook dan meneruskan parameter saat deboarding.

    Anda dapat mengambil AutomationAccountResourceId dari Properti Akun>Automation.

    Cuplikan layar yang memperlihatkan cara mengambil ID sumber daya saat melakukan deboarding.

    Anda dapat mengambil UserManagedServiceIdentityClientId dari ID Klien Properti>Identitas>yang Ditetapkan>Pengguna Akun>>Automation.

    Cuplikan layar yang memperlihatkan cara mengambil ID klien saat melakukan deboarding.

  4. Periksa log runbook Azure untuk status deboarding komputer dan jadwal.

    Cuplikan layar yang memperlihatkan cara log runbook saat melakukan deboarding.

Operasi skrip deboarding di backend

  • Nonaktifkan semua jadwal yang mendasar untuk semua konfigurasi pembaruan perangkat lunak yang ada di akun Automation ini. Ini dilakukan untuk memastikan bahwa Runbook Patch-MicrosoftOMSComputers tidak dipicu untuk SUC yang sebagian dimigrasikan ke V2.
  • Hapus Solusi Pembaruan dari Ruang Kerja Analitik Log Tertaut untuk Akun Automation yang Dideboarding dari Manajemen Pembaruan Automation di V1.
  • Log ringkasan semua SUC yang dinonaktifkan dan status menghapus solusi pembaruan dari ruang kerja analitik log tertaut juga dicetak ke aliran output.
  • Log terperinci dicetak pada aliran verbose.

Callout untuk proses migrasi:

  • Jadwal yang memiliki tugas pra/posting tidak akan dimigrasikan untuk saat ini.
  • Kueri Pencarian Tersimpan Non-Azure tidak akan dimigrasikan.
  • Runbook Migrasi dan Deboarding harus memperbarui Az.Modules agar berfungsi.
  • Skrip prasyarat memperbarui Az.Modules ke versi terbaru 8.0.0.
  • StartTime Dari Jadwal MRP akan sama dengan NextRunTime dari Konfigurasi Pembaruan Perangkat Lunak.
  • Data dari Analitik Log tidak akan dimigrasikan.
  • Identitas Terkelola Pengguna tidak mendukung skenario lintas penyewa.
  • Pengaturan RebootOnly tidak tersedia di Azure Update Manager. Jadwal yang memiliki Pengaturan RebootOnly tidak akan dimigrasikan.
  • Untuk Pengulangan, Automation menjadwalkan nilai dukungan antara (1 hingga 100) untuk jadwal Per Jam/Harian/Mingguan/Bulanan, sedangkan konfigurasi pemeliharaan Azure Update Manager mendukung antara (6 hingga 35) untuk Per Jam dan (1 hingga 35) untuk Harian/Mingguan/Bulanan.
    • Misalnya, jika jadwal otomatisasi memiliki pengulangan setiap 100 Jam, maka jadwal konfigurasi pemeliharaan yang setara memilikinya untuk setiap 24/100 = 4,16 (Putaran ke Nilai Terdekat) -> Empat hari akan menjadi pengulangan untuk konfigurasi pemeliharaan.
    • Misalnya, jika jadwal otomatisasi memiliki pengulangan setiap 1 jam, maka jadwal konfigurasi pemeliharaan yang setara akan memilikinya setiap 6 jam.
    • Terapkan konvensi yang sama untuk Mingguan dan Harian.
      • Jika jadwal otomatisasi memiliki pengulangan harian katakanlah 100 hari, maka 100/7 = 14,28 (Putaran ke Nilai Terdekat) -> 14 minggu akan menjadi pengulangan untuk jadwal konfigurasi pemeliharaan.
      • Jika jadwal otomatisasi memiliki pengulangan mingguan katakanlah 100 minggu, maka 100/4,34 = 23,04 (Putaran ke Nilai Terdekat) -> 23 Bulan akan menjadi pengulangan untuk jadwal konfigurasi pemeliharaan.
      • Jika jadwal otomatisasi yang harus berulang Setiap 100 Minggu dan harus Dijalankan pada hari Jumat. Ketika diterjemahkan ke konfigurasi pemeliharaan, itu akan menjadi Setiap 23 Bulan (100/4.34). Tetapi tidak ada cara di Azure Update Manager untuk mengatakan bahwa jalankan setiap 23 Bulan pada semua Hari Jumat bulan itu, sehingga jadwal tidak akan dimigrasikan.
      • Jika jadwal otomatisasi memiliki pengulangan lebih dari 35 Bulan, maka dalam konfigurasi pemeliharaan akan selalu memiliki Pengulangan 35 Bulan.
    • SUC mendukung antara 30 Menit hingga enam Jam untuk Jendela Pemeliharaan. MRP mendukung antara 1 jam 30 menit hingga 4 jam.
      • Misalnya, jika SUC memiliki Jendela Pemeliharaan 30 Menit, maka jadwal MRP yang setara akan memilikinya selama 1 jam 30 menit.
      • Misalnya, jika SUC memiliki Jendela Pemeliharaan 6 jam, maka jadwal MRP yang setara akan memilikinya selama 4 jam.
  • Ketika runbook migrasi dijalankan beberapa kali, katakanlah Anda melakukan Migrasi Semua jadwal otomatisasi dan kemudian lagi mencoba memigrasikan semua jadwal, maka runbook migrasi akan menjalankan logika yang sama. Melakukannya lagi akan memperbarui jadwal MRP jika ada perubahan baru di SUC. Ini tidak akan membuat penugasan konfigurasi duplikat. Selain itu, operasi hanya dibawa untuk jadwal otomatisasi yang memiliki jadwal yang diaktifkan. Jika SUC Dimigrasikan sebelumnya, SUC akan dilewati pada giliran berikutnya karena jadwal yang mendasarnya akan Dinonaktifkan.
  • Pada akhirnya, Anda dapat mengatasi lebih banyak komputer dari Azure Resource Graph seperti di Azure Update Manager; Anda tidak dapat memeriksa apakah Hybrid Runbook Worker melaporkan atau tidak, tidak seperti dalam Manajemen Pembaruan Automation di mana itu adalah persimpangan Kueri Dinamis dan Hybrid Runbook Worker.

Panduan migrasi manual

Panduan untuk memindahkan berbagai kemampuan disediakan dalam tabel di bawah ini:

S.No Kemampuan Manajemen Pembaruan Automation Azure Update Manager Langkah-langkah menggunakan portal Azure Langkah-langkah menggunakan API/skrip
1 Manajemen patch untuk komputer Off-Azure. Dapat berjalan dengan atau tanpa konektivitas Arc. Azure Arc adalah prasyarat untuk komputer non-Azure. 1. Buat perwakilan
layanan 2. Hasilkan skrip
penginstalan 3. Menginstal agen dan menyambungkan ke Azure
1. Buat perwakilan layanan
2. Hasilkan skrip
penginstalan 3. Menginstal agen dan menyambungkan ke Azure
2 Aktifkan penilaian berkala untuk memeriksa pembaruan terbaru secara otomatis setiap beberapa jam. Komputer secara otomatis menerima pembaruan terbaru setiap 12 jam untuk Windows dan setiap 3 jam untuk Linux. Penilaian berkala adalah pengaturan pembaruan pada komputer Anda. Jika diaktifkan, Manajer Pembaruan mengambil pembaruan setiap 24 jam untuk mesin dan menunjukkan status pembaruan terbaru. 1. Mesin tunggal
2. Pada skala
3. Dalam skala besar menggunakan kebijakan
1. Untuk Azure VM
2.Untuk VM dengan dukungan Arc
3 Jadwal penyebaran Pembaruan Statis (Daftar statis komputer untuk penyebaran pembaruan). Manajemen Pembaruan Automation memiliki jadwalnya sendiri. Azure Update Manager membuat objek konfigurasi pemeliharaan untuk jadwal. Jadi, Anda perlu membuat objek ini, menyalin semua pengaturan jadwal dari Manajemen Pembaruan Automation ke jadwal Azure Update Manager. 1. VM
Tunggal 2. Pada skala
3. Dalam skala besar menggunakan kebijakan
Membuat cakupan statis
4 Jadwal penyebaran Pembaruan Dinamis (Menentukan cakupan komputer menggunakan grup sumber daya, tag, dll. yang dievaluasi secara dinamis saat runtime). Sama seperti jadwal pembaruan statis. Sama seperti jadwal pembaruan statis. Menambahkan cakupan dinamis Membuat cakupan dinamis
5 Deboard dari manajemen Pembaruan Azure Automation. Setelah Menyelesaikan langkah 1, 2, dan 3, Anda perlu membersihkan objek manajemen Pembaruan Azure. Hapus solusi Manajemen Pembaruan
NA
6 Pelaporan Laporan pembaruan kustom menggunakan kueri Analitik Log. Data pembaruan disimpan di Azure Resource Graph (ARG). Pelanggan dapat mengkueri data ARG untuk membangun dasbor kustom, buku kerja, dll. Data Manajemen Pembaruan Automation lama yang disimpan di Analitik log dapat diakses, tetapi tidak ada provisi untuk memindahkan data ke ARG. Anda dapat menulis kueri ARG untuk mengakses data yang akan disimpan ke ARG setelah komputer virtual di-patch melalui Azure Update Manager. Dengan kueri ARG, Anda bisa membuat dasbor dan buku kerja menggunakan instruksi berikut:
1. Struktur log azure Resource graph memperbarui data
2. Sampel kueri
ARG 3. Membuat buku kerja
NA
7 Kustomisasi alur kerja menggunakan skrip pra dan pasca. Tersedia sebagai runbook Automation. Kami menyarankan agar Anda mencoba Pratinjau Umum untuk pra dan pasca skrip pada mesin non-produksi Anda dan menggunakan fitur pada beban kerja produksi setelah fitur memasuki Ketersediaan Umum. Mengelola peristiwa pra dan pasca (pratinjau)
8 Membuat pemberitahuan berdasarkan data pembaruan untuk lingkungan Anda Pemberitahuan dapat disiapkan pada data pembaruan yang disimpan di Analitik Log. Kami menyarankan agar Anda mencoba Pratinjau Umum untuk pemberitahuan pada mesin non-produksi Anda dan menggunakan fitur pada beban kerja produksi setelah fitur memasuki Ketersediaan Umum. Membuat pemberitahuan (pratinjau)

Langkah berikutnya