자동 업데이트 관리에서 Azure Update Manager로 전환

아티클
05/09/2024

적용 대상: ✔️ Windows VM ✔️ Linux VM ✔️ 온-프레미스 환경 ✔️ Azure Arc 지원 서버

이 문서에서는 Azure 업데이트 관리자의 가상 머신을 Automation 업데이트 관리자로 옮기는 지침을 제공합니다.

Azure 업데이트 관리자는 Azure, 온-프레미스 및 다중 클라우드 환경에서 Windows 및 Linux 머신에 대한 소프트웨어 업데이트를 관리하는 SaaS 솔루션을 제공합니다. 이 솔루션은 단일 컴퓨터에서 또는 여러 컴퓨터에서 대규모로 소프트웨어 업데이트를 평가 및 배포하는 새로운 기능을 제공하는, 더욱 발전한 Azure Automation 업데이트 관리 솔루션입니다.

Azure Update Manager의 경우 AMA와 MMA는 모두 Azure VM용 Microsoft Azure VM 에이전트 및 Arc 지원 서버용 Azure 연결된 컴퓨터 에이전트를 사용하므로 소프트웨어 업데이트 워크플로를 관리하기 위한 요구 사항이 아닙니다. 컴퓨터에서 처음으로 업데이트 작업을 수행하면 확장이 컴퓨터로 푸시되고 에이전트와 상호 작용하여 누락된 업데이트를 평가하고 업데이트를 설치합니다.

참고 항목

Azure Automation 업데이트 관리 솔루션을 사용하는 경우에는, 컴퓨터의 패치 관리 요구 사항에 맞게 Azure 업데이트 관리자로의 마이그레이션이 완료되지 않았다면 컴퓨터에서 MMA 에이전트를 제거하지 않는 것이 좋습니다. Azure 업데이트 관리자로 옮기지 않고 컴퓨터에서 MMA 에이전트를 제거하면 해당 컴퓨터에 대한 패치 워크플로가 중단됩니다.
Azure Automation 업데이트 관리의 모든 기능은 사용 중단 날짜 전까지는 Azure 업데이트 관리자에서 사용할 수 있습니다.

Azure Portal 환경

이 섹션에서는 포털 환경을 사용하여 자동화 업데이트 관리에서 Azure 업데이트 관리자로 일정과 컴퓨터를 이동하는 방법을 설명합니다. 자동화 업데이트 관리 솔루션을 기반으로 사용자 지정이 빌드되지 않은 경우 최소한의 클릭만으로 리소스를 이동하는 자동화된 방법을 사용하면 가장 쉽게 이동할 수 있습니다.

포털 마이그레이션 환경에 액세스하려면 여러 진입점을 사용할 수 있습니다.

다음 진입점에 있는 지금 마이그레이션 단추를 선택합니다. 선택 후에는 일정과 컴퓨터를 Azure 업데이트 관리자로 이동하는 과정이 안내됩니다. 이 프로세스는 최소한의 활동으로 마이그레이션을 완료할 수 있도록 사용자 친화적이고 간단하게 설계되었습니다.

다음 진입점 중 하나에서 마이그레이션할 수 있습니다.

지금 마이그레이션 단추를 선택하면 마이그레이션 블레이드가 열립니다. 여기에는 Automation 계정의 컴퓨터 및 일정을 포함한 모든 리소스에 대한 요약이 포함되어 있습니다. 기본적으로 이 경로를 사용하는 경우 이 블레이드에 액세스한 Automation 계정이 미리 선택되어 있습니다.

여기에서는 자동화 업데이트 관리에서 사용하도록 설정되어 있고 Azure 업데이트 관리자로 이동해야 하는 Azure, Arc 지원 서버, Azure 비 Arc 지원 서버 및 일정의 수를 확인할 수 있습니다. 또한 이러한 리소스의 세부 정보를 볼 수도 있습니다.

마이그레이션 블레이드는 이동될 리소스에 대해 간략하게 설명하므로 계속 진행하기 전에 마이그레이션을 검토하고 확인할 수 있습니다. 준비가 되면 마이그레이션 프로세스를 진행하여 일정과 컴퓨터를 Azure 업데이트 관리자로 이동할 수 있습니다.

이동해야 하는 리소스를 검토한 후 3단계 프로세스인 마이그레이션 프로세스를 진행할 수 있습니다.

필수 조건

여기에는 두 단계가 포함됩니다.

a. 비 Azure Arc 지원 컴퓨터를 Arc에 온보딩 - 이는 Arc 연결이 Azure 업데이트 관리자의 필수 조건이기 때문입니다. Azure Arc에 컴퓨터를 온보딩하는 데 비용이 들지 않으며, 온보딩하고 나면 다른 Azure 컴퓨터에서와 마찬가지로 모든 관리 서비스를 이용할 수 있습니다. 컴퓨터 온보딩 방법에 대한 자세한 내용은 Azure Arc 설명서를 참조하세요.

b. PowerShell 스크립트를 로컬에서 다운로드하고 실행합니다. - 마이그레이션이 수행될 수 있도록 사용자 ID를 만들고 적절한 역할을 할당하는 데 필요합니다. 이 스크립트는 자동화 계정이 속한 구독, 자동화 업데이트 관리에 온보딩된 컴퓨터, 동적 쿼리의 일부인 범위 등에 대한 사용자 ID에 적절한 RBAC를 제공하므로, 구성을 컴퓨터에 할당하고, MRP 구성을 만들고, 업데이트 솔루션을 제거할 수 있습니다. 자세한 내용은 Azure 업데이트 관리자 설명서를 참조하세요.
Automation 계정의 리소스를 Azure 업데이트 관리자로 이동

마이그레이션 프로세스의 다음 단계는 이동할 컴퓨터에서 Azure 업데이트 관리자를 사용하도록 설정하고 마이그레이션할 일정에 대해 동등한 유지 관리 구성을 만드는 것입니다. 지금 마이그레이션 단추를 선택하면 MigrateToAzureUpdateManager Runbook을 Automation 계정으로 가져오고 자세한 로깅이 True로 설정됩니다.

Runbook에 전달해야 하는 매개 변수를 제공하는 시작 Runbook을 선택합니다.

가져올 매개 변수와 매개 변수를 가져와야 하는 위치에 대한 자세한 내용은 컴퓨터 및 일정 마이그레이션을 참조하세요. 모든 매개 변수를 전달한 후 Runbook을 시작하면 Azure 업데이트 관리자가 컴퓨터에서 사용하도록 설정되기 시작하고 Azure 업데이트 관리자의 유지 관리 구성이 만들어지기 시작합니다. 일정 실행 및 마이그레이션 상태에 대해 Azure Runbook 로그를 모니터링할 수 있습니다.
자동화 업데이트 관리에서 리소스 디보딩

정리 스크립트를 실행하여 자동화 업데이트 관리 솔루션에서 컴퓨터를 디보딩하고 자동화 업데이트 관리 일정을 사용하지 않도록 설정합니다.

정리 스크립트 실행 단추를 선택하면 Runbook DeboardFromAutomationUpdateManagement를 Automation 계정으로 가져오고 자세한 로깅이 True로 설정됩니다.

Runbook 시작을 선택하면 Runbook에 전달할 매개 변수를 요청합니다. 자세한 내용은 자동화 업데이트 관리 솔루션에서 디보딩을 참조하여 Runbook에 전달할 매개 변수를 가져옵니다.

마이그레이션 스크립트

마이그레이션 Runbook을 사용하면 모든 워크로드(머신 및 일정)를 Automation 업데이트 관리에서 Azure 업데이트 관리자로 자동으로 마이그레이션할 수 있습니다. 이 섹션에서는 스크립트를 실행하는 방법, 백 엔드에서 스크립트가 수행하는 일, 예상되는 동작 및 (해당하는 경우) 제한 사항에 대해 자세히 설명합니다. 스크립트를 사용하면 한 번에 하나의 자동화 계정에서 모든 머신과 일정을 마이그레이션할 수 있습니다. 자동화 계정이 여러 개라면 모든 자동화 계정에 대해 Runbook을 실행해야 합니다.

큰 틀에서 보면, 사용자는 다음 단계에 따라 머신과 일정을 Automation 업데이트 관리에서 Azure 업데이트 관리자로 마이그레이션해야 합니다.

필수 구성 요소 요약

비 Azure 머신을 Azure Arc에 온보딩합니다.
시스템에서 로컬로 사용자 ID 및 역할 할당을 만드는 PowerShell 스크립트를 다운로드하고 실행합니다. 단계별 가이드에서 자세한 지침을 참조하세요. 특정 필수 구성 요소를 확인할 수 있습니다.

단계 요약

마이그레이션 자동화 Runbook을 실행해 머신과 일정을 Automation 업데이트 관리에서 Azure 업데이트 관리자로 마이그레이션합니다. 자세한 지침은 단계별 가이드를 참조하세요.
정리 스크립트를 실행하여 Automation 업데이트 관리에서 디보딩합니다. 자세한 지침은 단계별 가이드를 참조하세요.

지원되지 않는 시나리오

비 Azure 저장된 검색 쿼리는 마이그레이션되지 않습니다. 수동으로 마이그레이션해야 합니다.

제한 사항 및 주의할 사항의 전체 목록은 이 문서의 마지막 섹션을 참조하세요.

단계별 가이드

위의 각 단계에서 언급하는 정보는 아래에서 자세히 설명합니다.

필수 구성 요소 1: 비 Azure 머신을 Arc에 온보딩

수행할 작업

마이그레이션 자동화 Runbook은 Arc에 온보딩되지 않은 리소스는 무시합니다. 따라서 마이그레이션 Runbook을 실행하기 전에 모든 비 Azure 머신을 Azure Arc에 온보딩하는 것이 필수 구성 요소입니다. 단계에 따라 머신을 Azure Arc에 온보딩합니다.

필수 구성 요소 2: PowerShell 스크립트를 실행하여 사용자 ID 및 역할 할당 만들기

A. 스크립트 실행을 위한 필수 구성 요소

PowerShell에서 Install-Module -Name Az -Repository PSGallery -Force 명령을 실행합니다. 필수 구성 요소 스크립트는 Az.Modules에 따라 달라집니다. 이 단계는 Az.Modules가 없거나 업데이트되지 않을 때 필요합니다.
이 필수 구성 요소 스크립트를 실행하려면 머신, 일정, 로그 분석 작업 영역 및 자동화 계정 같은 Automation 업데이트 관리 리소스를 포함하는 모든 구독에 대해 Microsoft.Authorization/roleAssignments/write 권한이 있어야 합니다. Azure 역할을 할당하는 방법을 참조하세요.
업데이트 관리 권한이 있어야 합니다.

B. 스크립트 실행

PowerShell 스크립트 MigrationPrerequisiteScript를 다운로드하여 실행합니다. 이 스크립트는 입력으로 마이그레이션할 Automation 계정의 AutomationAccountResourceId와 AutomationAccountAzureEnvironment를 사용합니다. AutomationAccountAzureEnvironment에 허용되는 값은 자동화 계정이 속한 클라우드를 나타내는 AzureCloud, AzureUSGovernment 및 AzureChina입니다.

자동화 계정>속성으로 이동하면 AutomationAccountResourceId를 가져올 수 있습니다.

C. 확인

스크립트를 실행한 후 자동화 계정에서 사용자 관리 ID가 생성되었는지 확인합니다. Automation 계정>ID>할당된 사용자.

D. 스크립트에 의한 백 엔드 작업

마이그레이션을 실행하고 스크립트를 디보딩하는 데 필요한 Automation 계정의 Az.Modules 업데이트.
자동화 계정이 속한 Azure 클라우드 환경을 저장할 AutomationAccountAzureEnvironment라는 이름의 자동화 변수를 만듭니다.
Automation 계정과 동일한 구독 및 리소스 그룹에서 사용자 ID를 만듭니다. 사용자 ID의 이름은 AutomationAccount_aummig_umsi 형식이 됩니다.
Automation 계정에 사용자 ID 연결.
스크립트는 사용자 관리 ID에 업데이트 관리 권한 필요 권한을 할당합니다.
1. 이를 위해 스크립트는 이 자동화 계정으로 Automation 업데이트 관리에 온보딩된 모든 머신을 가져오고, 해당 구독 ID를 구문 분석하여 필요한 RBAC를 사용자 ID에 부여합니다.
2. 이 스크립트는 여기서 MRP 구성을 만들 수 있도록, 자동화 계정이 속한 구독의 사용자 ID에 적절한 RBAC를 제공합니다.
3. 스크립트는 Log Analytics 작업 영역 및 솔루션에 필요한 역할을 할당합니다.
Microsoft.Maintenance 및 Microsoft.EventGrid 리소스 공급자에 대한 필수 구독 등록입니다.

1단계: 머신 및 일정 마이그레이션

이 단계에서는 자동화 Runbook을 사용하여 자동화 계정에서 Azure Update Manager로 모든 머신과 일정을 마이그레이션합니다.

다음 단계를 따르세요.:

Runbook 갤러리에서 마이그레이션 Runbook을 가져오고 게시합니다. 찾아보기 갤러리에서 Azure Automation 업데이트를 검색하고, Azure Automation 업데이트 관리에서 Azure 업데이트 관리자로 마이그레이션이라는 마이그레이션 Runbook을 가져온 다음 Runbook을 게시합니다.

Runbook은 PowerShell 5.1을 지원합니다.
Runbook에 대한 자세한 정보 로깅을 True로 설정합니다.
Runbook을 실행하고 AutomationAccountResourceId, UserManagedServiceIdentityClientId 같은 필수 매개 변수를 전달합니다.
1. 자동화 계정>속성에서 AutomationAccountResourceId를 가져올 수 있습니다.
2. 자동화 계정>ID>할당된 사용자>ID>속성>클라이언트 ID에서 UserManagedServiceIdentityClientId를 가져올 수 있습니다.
3. EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement를 TRUE로 설정하면 Automation 업데이트 관리에 온보딩된 모든 컴퓨터에서 주기적 평가 속성이 사용하도록 설정됩니다.
4. MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines를 TRUE로 설정하면 Automation 업데이트 관리에 있는 모든 업데이트 일정이 Azure 업데이트 관리자로 마이그레이션되고, 이러한 일정에 연결된 모든 컴퓨터에서 주기적 평가 속성이 True로 켜집니다.
5. Azure 업데이트 관리자에서 모든 유지 관리 속성이 생성될 ResourceGroupForMaintenanceConfigurations를 지정해야 합니다. 새 이름을 입력하면, 모든 유지 관리 구성이 생성될 리소스 그룹이 생성됩니다. 그러나 리소스 그룹이 이미 있는 이름을 입력하면, 모든 유지 관리 구성이 기존 리소스 그룹에 생성됩니다.
Azure Runbook 로그에서 SUC의 실행 상태와 마이그레이션 상태를 확인합니다.

백 엔드에서의 Runbook 작업

Runbook 마이그레이션은 다음 작업을 수행합니다.

모든 컴퓨터에서 주기적 평가를 사용하도록 설정합니다.
자동화 계정에 있는 모든 일정은 Azure 업데이트 관리자로 마이그레이션되고, 각 일정에 대한 (동일한 속성을 갖는) 유지 관리 구성이 생성됩니다.

스크립트 정보

다음은 마이그레이션 스크립트가 수행하는 동작입니다.

입력으로 가져온 이름의 리소스 그룹이 자동화 계정의 구독에 이미 존재하는지 확인합니다. 존재하지 않는다면 고객이 지정한 이름을 사용하여 리소스 그룹을 만듭니다. 이 리소스 그룹은 V2용 MRP 구성을 만드는 데 사용됩니다.
RebootOnly 설정은 Azure 업데이트 관리자에서 사용할 수 없습니다. RebootOnly 설정이 있는 일정은 마이그레이션되지 않습니다.
errored/expired/provisioningFailed/disabled 상태인 SUC를 필터링하고 마이그레이션되지 않음으로 표시한 다음, 이러한 SUC가 마이그레이션되지 않음을 나타내는 적절한 로그를 인쇄합니다.
구성 할당 이름은 AUMMig_AAName_SUCName 형식인 문자열입니다.
Azure Resource Graph를 확인하여, 이 동적 범위가 유지 관리 구성에 이미 할당되었는지 확인합니다. 할당되지 않았다면 AUMMig_ AAName_SUCName_SomeGUID 형식의 할당 이름으로 할당해야 합니다.
사전/사후 작업이 구성된 일정의 경우 스크립트는 사전/사후 작업의 Runbook과 사전/사후 유지 관리 이벤트에 대한 Event Grid 구독에 대한 자동화 웹후크를 만듭니다. 자세한 내용은 Azure 업데이트 관리자에서 사전/사후 작동 방식을 참조하세요.
요약된 로그 집합이 출력 스트림에 인쇄되어, 컴퓨터와 SUC의 전반적인 상태를 확인할 수 있습니다.
자세한 로그는 자세한 정보 표시 스트림으로 인쇄됩니다.
마이그레이션 후 작업인 소프트웨어 업데이트 구성은 다음 네 가지 마이그레이션 상태 중 하나일 수 있습니다.
- MigrationFailed
- PartiallyMigrated
- NotMigrated
- Migrated

아래 표에서는 각 마이그레이션 상태와 관련된 시나리오를 확인할 수 있습니다.

MigrationFailed	PartiallyMigrated	NotMigrated	Migrated
소프트웨어 업데이트 구성에 대한 유지 관리 구성을 만들지 못했습니다.	패치 설정을 적용하지 못한 컴퓨터 수가 0이 아닙니다.	내부 서비스 오류 같은 일부 클라이언트/서버 오류 때문에 API에서 소프트웨어 업데이트 구성을 얻지 못했습니다.
	구성 할당이 실패한 컴퓨터의 수가 0이 아닙니다.	소프트웨어 업데이트 구성의 재부팅 설정이 재부팅 전용입니다. 이 기능은 현재 Azure 업데이트 관리자에서 지원되지 않습니다.
	0이 아닌 동적 쿼리 수를 확인하지 못하여 Azure Resource Graph에 대한 쿼리를 실행하지 못했습니다.
	동적 범위 구성 할당 실패 수가 0이 아닙니다.	소프트웨어 업데이트 구성의 DB에 성공 프로비전 상태가 없습니다.
	소프트웨어 업데이트 구성에 저장된 검색 쿼리가 있습니다.	소프트웨어 업데이트 구성이 DB에서 errored 상태입니다.
	소프트웨어 업데이트 구성에 성공적으로 마이그레이션되지 않은 사전/사후 작업이 있습니다.	소프트웨어 업데이트 구성과 연결된 일정이 마이그레이션 시점에 이미 만료되었습니다.
		소프트웨어 업데이트 구성과 관련된 일정이 사용 안 함으로 설정되었습니다.
		소프트웨어 업데이트 구성을 마이그레이션하는 동안 처리되지 않은 예외입니다.	패치 설정을 적용하지 못한 컴퓨터 수가 0입니다. And 구성 할당이 실패한 컴퓨터의 수가 0입니다. And 0인 동적 쿼리 수를 확인하지 못하여 Azure Resource Graph에 대한 쿼리를 실행하지 못했습니다. And 동적 범위 구성 할당 실패 수가 0입니다. And 소프트웨어 업데이트 구성에 저장된 검색 쿼리가 없습니다.

위의 표에서 소프트웨어 업데이트 구성에 특정 상태가 있는 이유에 해당하는 (하나 또는 그 이상의) 시나리오를 파악하려면 자세한 정보 표시/실패/경고 로그를 확인하여 오류 코드와 오류 메시지를 확인합니다.

또한 업데이트 일정의 이름으로 검색하여 관련된 로그를 가져와 디버깅할 수도 있습니다.

2단계: Automation 업데이트 관리 솔루션에서 디보딩

다음 단계를 따르세요.:

Runbook 갤러리에서 마이그레이션 Runbook을 가져옵니다. 찾아보기 갤러리에서 Azure Automation 업데이트를 검색하고, Azure Automation 업데이트 관리 디보딩이라는 마이그레이션 Runbook을 가져온 다음 Runbook을 게시합니다.

Runbook은 PowerShell 5.1을 지원합니다.
Runbook에 대한 자세한 정보 로깅을 True로 설정합니다.
Runbook을 시작하고 Automation AccountResourceId, UserManagedServiceIdentityClientId 등의 매개 변수를 전달합니다.

자동화 계정>속성에서 AutomationAccountResourceId를 가져올 수 있습니다.

자동화 계정>ID>할당된 사용자>ID>속성>클라이언트 ID에서 UserManagedServiceIdentityClientId를 가져올 수 있습니다.
Azure Runbook 로그에서 머신 및 일정의 디보딩 상태를 확인합니다.

백 엔드에서의 디보딩 스크립트 작업

이 Automation 계정에 존재하는 모든 소프트웨어 업데이트 구성에 대해 모든 기본 일정을 사용하지 않도록 설정합니다. 이 작업은 V2에 부분적으로 마이그레이션된 SUC에 Patch-MicrosoftOMSComputers Runbook이 트리거되지 않게 하기 위해 수행합니다.
V1의 Automation 업데이트 관리에서 디보딩되는 자동화 계정의 연결된 Log Analytics 작업 영역에서 업데이트 솔루션을 삭제합니다.
비활성화된 모든 SUC의 요약 로그와, 연결된 로그 분석 작업 영역에서 업데이트 솔루션을 제거한 상태도 출력 스트림에 인쇄됩니다.
자세한 로그는 자세한 정보 표시 스트림에 인쇄됩니다.

마이그레이션 프로세스 설명선:

비 Azure 저장된 검색 쿼리는 마이그레이션되지 않습니다.
마이그레이션 및 디보딩 Runbook이 작동하려면 Az.Modules가 업데이트되어야 합니다.
필수 구성 요소 스크립트는 Az.Modules를 최신 버전인 8.0.0으로 업데이트합니다.
MRP 일정의 StartTime은 소프트웨어 업데이트 구성의 nextRunTime과 동일합니다.
Log Analytics의 데이터는 마이그레이션되지 않습니다.
사용자 관리 ID는 테넌트 간 시나리오를 지원하지 않습니다.
RebootOnly 설정은 Azure 업데이트 관리자에서 사용할 수 없습니다. RebootOnly 설정이 있는 일정은 마이그레이션되지 않습니다.
되풀이의 경우 Automation 일정은 매시간/매일/매주/매월 일정의 값(1~100)을 지원하며, Azure 업데이트 관리자의 유지 관리 구성은 매시간(6~35) 및 매일/매주/매월(1~35) 사이의 값을 지원합니다.
- 예를 들어 자동화 일정이 100시간마다 되풀이되는 경우, 대응하는 유지 관리 구성 일정은 100/24 = 4.16(가장 가까운 값으로 반올림) -> 4일이 유지 관리 구성의 되풀이 시간이 됩니다.
- 예를 들어 자동화 일정이 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분~6시간의 유지 관리 기간을 지원합니다. MRP는 1시간 30분~4시간을 지원합니다.
  - 예를 들어 SUC의 유지 관리 기간이 30분인 경우, 대응하는 MRP 일정은 유지 관리 기간이 1시간 30분이 됩니다.
  - 예를 들어 SUC의 유지 관리 기간이 6시간인 경우, 대응하는 MRP 일정은 유지 관리 기간이 4시간이 됩니다.
마이그레이션 Runbook이 여러 번 실행되는 경우 모든 자동화 일정을 마이그레이션한 다음 다시 모든 일정을 마이그레이션하려고 하면, 마이그레이션 Runbook은 같은 논리를 실행합니다. 이 작업을 다시 수행하면 새 변경 사항이 SUC에 존재하는 경우 MRP 일정이 업데이트됩니다. 중복 구성 할당을 만들지는 않습니다. 또한 작업은 일정을 사용하도록 설정된 자동화 일정에 대해서만 수행됩니다. SUC가 이전에 마이그레이션된 경우, 기본 일정은 사용 안 함으로 설정되기 때문에 다음 턴에서 건너뜁니다.
결국 Azure 업데이트 관리자에서처럼 Azure Resource Graph에서도 더 많은 컴퓨터를 확인하게 됩니다. Dynamic Querys 및 Hybrid Runbook Worker의 교집합이었던 Automation 업데이트 관리와 달리, Hybrid Runbook Worker가 보고하는지 여부는 확인할 수 없습니다.

수동 마이그레이션 지침

아래 표에는 다양한 기능을 옮기는 지침이 나와 있습니다.

S.No	기능	Automation 업데이트 관리	Azure 업데이트 관리자	Azure Portal 사용 단계	API/스크립트 사용 단계
1	Azure 해제 컴퓨터에 대한 패치 관리입니다.	Arc 연결을 사용하거나 사용하지 않고 실행할 수 있습니다.	Azure Arc는 비 Azure 컴퓨터의 필수 요소입니다.	1. 서비스 주체 만들기 2. 설치 스크립트 생성 3. 에이전트를 설치하고 Azure에 연결	1. 서비스 주체 만들기 2. 설치 스크립트 생성 3. 에이전트를 설치하고 Azure에 연결
2	주기적 평가를 사용하도록 설정하여 몇 시간마다 자동으로 최신 업데이트를 확인합니다.	컴퓨터는 Windows의 경우 12시간마다, Linux의 경우 3시간마다 최신 업데이트를 자동으로 받습니다.	주기적 평가는 컴퓨터의 업데이트 설정입니다. 주기적 평가를 켜면 업데이트 관리자는 24시간마다 컴퓨터에 업데이트를 가져오고 최신 업데이트 상태를 표시합니다.	1. 컴퓨터 한 대 2. 대규모 3. 정책을 사용하여 대규모	1. Azure VM 대상 2.Arc 지원 VM 대상
3	정적 업데이트 배포 일정(업데이트 배포용 컴퓨터의 정적 목록).	Automation 업데이트 관리에는 고유한 일정이 존재합니다.	Azure 업데이트 관리자는 일정에 대한 유지 관리 구성 개체를 만듭니다. 따라서 Automation 업데이트 관리의 모든 일정 설정을 Azure 업데이트 관리자 일정으로 복사하여 이 개체를 만들어야 합니다.	1. 단일 VM 2. 대규모 3. 정책을 사용하여 대규모	정적 범위 만들기
4	동적 업데이트 배포 일정입니다(런타임에 동적으로 평가되는 리소스 그룹이나 태그 등을 사용하여 컴퓨터 범위 정의).	정적 업데이트 일정과 동일합니다.	정적 업데이트 일정과 동일합니다.	동적 범위 추가	동적 범위 만들기
5	Azure Automation 업데이트 관리에서 디보드합니다.	1, 2, 3단계를 완료한 후에는 Azure 업데이트 관리 개체를 정리해야 합니다.		업데이트 관리 솔루션 제거	해당 없음
6	보고	Log Analytics 쿼리를 사용하여 보고서를 사용자 지정 업데이트합니다.	업데이트 데이터는 ARG(Azure Resource Graph)에 저장됩니다. 고객은 ARG 데이터를 쿼리하여 사용자 지정 대시보드나 통합 문서 등을 빌드할 수 있습니다.	Log Analytics에 저장된 이전 Automation 업데이트 관리 데이터에 액세스할 수 있지만, 데이터를 ARG로 옮기는 프로비저닝은 진행되지 않습니다. Azure 업데이트 관리자를 통해 가상 머신이 패치된 후에는, ARG 쿼리를 작성하여 ARG에 저장될 데이터에 액세스할 수 있습니다. 사용할 수 있는 ARG 쿼리를 이용해, 다음 지침을 사용하여 대시보드와 통합 문서를 빌드할 수 있습니다. 1. Azure Resource 그래프 업데이트 데이터의 로그 구조 2. 샘플 ARG 쿼리 3. 통합 문서 만들기	해당 없음
7	사전 및 사후 스크립트를 사용하여 워크플로를 사용자 지정합니다.	Automation Runbook으로 사용할 수 있습니다.	비 프로덕션 머신에서 사전 및 사후 스크립트의 공개 미리 보기를 사용해 본 다음, 기능이 일반 공급 상태가 되는 프로덕션 워크로드에서 기능을 사용하는 방법을 권장합니다.	사전 및 사후 이벤트 관리(미리 보기) 및 자습서: Automation과 함께 웹후크를 사용하여 사전 및 사후 이벤트 만들기
8	사용자 환경에 대한 업데이트 데이터를 기반으로 경고 만들기	Log Analytics에 저장된 업데이트 데이터에 대한 경고를 설정할 수 있습니다.	비 프로덕션 머신에서 경고의 공개 미리 보기를 사용해 본 다음, 기능이 일반 공급 상태가 되는 프로덕션 워크로드에서 기능을 사용하는 방법을 권장합니다.	경고 만들기(미리 보기)

다음 단계

Microsoft Configuration Manager에서 Azure Update Manager로 Azure VM을 마이그레이션하는 방법에 대한 지침

다음을 통해 공유