업데이트 관리 문제 해결

아티클
03/20/2024

주의

이 문서에서는 EOL(수명 종료) 상태에 가까워진 Linux 배포판인 CentOS를 참조하세요. 이에 따라 사용 및 계획을 고려하세요. 자세한 내용은 CentOS 수명 종료 지침을 참조 하세요.

이 문서에서는 머신에서 업데이트 관리 기능을 사용하여 업데이트를 평가하고 관리할 때 발생할 수 있는 문제에 대해 설명합니다. 기본 문제를 확인하기 위한 Hybrid Runbook Worker 에이전트용 에이전트 문제 해결사가 제공됩니다. 문제 해결사에 대해 자세히 알아보려면 Windows 업데이트 에이전트 문제 해결 및 Linux 업데이트 에이전트 문제 해결을 참조하세요. 다른 기능 배포 문제는 기능 배포 문제 해결을 참조하세요.

참고 항목

Windows 머신에 업데이트 관리를 배포할 때 문제가 발생하는 경우 로컬 머신에서 Windows 이벤트 뷰어를 열고 애플리케이션 및 서비스 로그에서 Operations Manager 이벤트 로그를 확인합니다. 이벤트 ID가 4502인 이벤트 및 Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent를 포함하는 이벤트 정보를 찾아봅니다.

시나리오: Windows Defender 업데이트가 항상 누락된 것으로 표시됨

문제

Windows Defender(KB2267602)에 대한 정의 업데이트가 설치 시 실행되는 평가에서 항상 누락된 것으로 표시되고 Windows 업데이트 기록을 확인하면 최신 상태로 표시됩니다.

원인

정의 업데이트는 하루에 여러 번 게시됩니다. 그 결과 하루에 게시되는 KB2267602 릴리스가 여러 개로 표시되지만 각각 업데이트 ID와 버전이 다릅니다.

업데이트 관리 평가는 11시간 후에 한 번 실행됩니다. 이 예제에서는 오전 10시에 평가가 실행되었고 당시 설치 가능한 버전으로 1.237.316.0이 있었습니다. Log Analytics 작업 영역에서 Update 테이블을 검색하면 정의 업데이트 1.237.316.0이 Needed라는 UpdateState와 함께 표시됩니다. 예약된 배포가 몇 시간 후에(예를 들어 오후 1시) 실행되고 이때 여전히 버전 1.237.316.0이 있거나 최신 버전이 있는 경우 최신 버전이 설치되고 이는 UpdateRunProgress 테이블에 기록되는 레코드에 반영됩니다. 그러나 Update 테이블에는 다음 평가가 실행될 때까지 버전 1.237.316.0이 계속 Needed로 표시됩니다. 평가가 다시 실행될 때 최신 정의 업데이트가 없을 수 있으므로 Update 테이블에 정의 업데이트 버전 1.237.316.0이 누락된 것으로 표시되거나 최신 버전이 필요한 것으로 표시되지 않습니다. 정의 업데이트의 빈도로 인해 로그 검색에 여러 버전이 반환될 수 있습니다.

해결

다음 로그 쿼리를 실행하면 설치된 정의 업데이트가 제대로 보고되고 있는지 확인할 수 있습니다. 이 쿼리는 Updates 테이블에 있는 KB2267602의 생성 시간, 버전, 업데이트 ID를 반환합니다. Computer의 값을 해당 머신의 정규화된 이름으로 바꿉니다.

Update
| where TimeGenerated > ago(14h) and OSType != "Linux" and (Optional == false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((
    Heartbeat
    | where TimeGenerated > ago(12h) and OSType =~ "Windows" and notempty(Computer)
    | summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
    | where Solutions has "updates"
    | distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, *) by Computer, SourceComputerId, UpdateID
| where UpdateState =~ "Needed" and Approved != false and Computer == "<computerName>"
| render table

쿼리를 실행하면 다음과 유사한 결과가 반환되어야 합니다.

로그 쿼리로 Updates 테이블에서 가져온 결과를 보여 주는 예.

다음 로그 쿼리를 실행하면 UpdatesRunProgress 테이블에 있는 KB2267602의 생성 시간, 버전 및 업데이트 ID를 가져올 수 있습니다. 이 쿼리는 해당 업데이트가 업데이트 관리에서 설치된 것인지 아니면 Microsoft 업데이트에서 머신으로 자동으로 설치된 것인지 파악하는 데 도움을 줍니다. CorrelationId의 값을 해당 업데이트의 Runbook 작업 GUID(즉, Patch-MicrosoftOMSComputer Runbook 작업의 MasterJOBID 속성 값)로 바꾸고 SourceComputerId를 머신의 GUID로 바꿔야 합니다.

UpdateRunProgress
| where OSType!="Linux" and CorrelationId=="<master job id>" and SourceComputerId=="<source computer id>"
| summarize arg_max(TimeGenerated, Title, InstallationStatus) by UpdateId
| project TimeGenerated, id=UpdateId, displayName=Title, InstallationStatus

쿼리를 실행하면 다음과 유사한 결과가 반환되어야 합니다.

업데이트RunProgress 테이블의 로그 쿼리 결과를 보여 주는 예제입니다.

Updates 테이블에서 가져온 로그 쿼리 결과의 TimeGenerated 값이 머신에서 업데이트가 설치된 때의 타임스탬프(즉, TimeGenerated의 값) 또는 UpdateRunProgress 테이블에서 가져온 로그 쿼리 결과의 값보다 이른 시간인 경우 다음 평가를 기다립니다. 그런 다음 Updates 테이블에 대해 로그 쿼리를 다시 실행합니다. KB2267602에 대해 업데이트가 표시되지 않거나 최신 버전으로 표시됩니다. 그러나 최근에 평가가 실행된 후에도 Updates 테이블에서 동일한 버전이 Needed로 표시되지만 이미 설치된 경우 Azure 지원 인시던트를 열어야 합니다.

시나리오: Linux 업데이트가 보류 중으로 표시되고 설치된 Linux 업데이트가 서로 다름

문제

Linux 머신의 경우 업데이트 관리가 분류 보안 및 기타에서 사용할 수 있는 특정 업데이트를 보여 줍니다. 그러나 머신에서 업데이트 일정을 실행하는 경우, 예를 들어 보안 분류와 일치하는 업데이트만 설치하는 경우 설치된 업데이트는 이전에 해당 분류와 일치하는 것으로 나타난 업데이트의 하위 집합과 다릅니다.

원인

Linux 머신 OS 업데이트에 대한 평가가 완료되면, 업데이트 관리는 분류를 위해 Linux 배포판 공급 업체에서 제공하는 OVAL(개방형 취약성 및 평가 언어) 파일을 사용합니다. 분류는 보안 문제나 취약성을 해결하는 업데이트를 나타내는 OVAL 파일을 기반으로 하여 Linux 업데이트의 경우 보안 또는 기타 방식으로 수행됩니다. 하지만 업데이트 일정을 실행하면 해당 패키지 관리자(예: YUM, APT 또는 ZYPPER)를 사용하여 설치하기 위해 Linux 머신에서 실행됩니다. Linux 배포판 패키지 관리자는 업데이트를 분류하는 다른 메커니즘을 사용할 수 있습니다. 이 경우 업데이트 관리를 사용하여 OVAL 파일에서 가져온 것과 다를 수 있습니다.

해결

배포판 패키지 관리자에 따라 Linux 머신, 해당 업데이트 및 해당 분류를 수동으로 확인할 수 있습니다. 패키지 관리자가 어떤 업데이트를 보안으로 분류했는지 이해하려면 다음 명령을 실행합니다.

YUM의 경우 다음 명령을 실행하면 Red Hat에 의해 보안으로 분류된 업데이트의 0이 아닌 목록을 반환합니다. CentOS의 경우 항상 빈 목록을 반환하며 보안 분류가 발생하지 않습니다.

sudo yum -q --security check-update

ZYPPER의 경우 다음 명령을 실행하면 SUSE에 의해 보안으로 분류된 업데이트의 0이 아닌 목록을 반환합니다.

sudo LANG=en_US.UTF8 zypper --non-interactive patch --category security --dry-run

APT의 경우 다음 명령을 실행하면 Canonical에 의해 보안으로 분류된 Ubuntu Linux 배포판에 대한 업데이트의 0이 아닌 목록을 반환합니다.

sudo grep security /etc/apt/sources.list > /tmp/oms-update-security.list LANG=en_US.UTF8 sudo apt-get -s dist-upgrade -oDir::Etc::Sourcelist=/tmp/oms-update-security.list

해당 목록에서 grep ^Inst 명령을 실행하여 모든 보류 중인 보안 업데이트를 가져옵니다.

시나리오: "업데이트 솔루션을 사용하도록 설정하지 못했습니다." 오류가 표시됨

문제

Automation 계정에서 업데이트 관리를 사용하도록 설정하려고 하면 다음과 같은 오류가 발생합니다.

Error details: Failed to enable the Update solution

원인

이 오류는 다음과 같은 이유로 발생할 수 있습니다.

Log Analytics 에이전트에 대한 네트워크 방화벽 요구 사항이 올바르게 구성되지 않았을 수 있습니다. 이러한 상황으로 인해 DNS URL을 확인할 때 에이전트가 실패할 수 있습니다.
업데이트 관리 대상이 잘못 구성되었으며 머신이 예상대로 업데이트를 받지 못합니다.
규정 준수에서 머신이 Non-compliant 상태를 표시하는 것을 확인할 수도 있습니다. 동시에 에이전트 데스크톱 분석에서 에이전트를 Disconnected로 보고합니다.

해결

OS에 따라 Windows 또는 Linux에 대한 문제 해결사를 실행합니다.
네트워크 구성으로 이동하여 업데이트 관리가 작동하려면 어떤 주소 및 포트를 허용해야 하는지 알아보세요.
범위 구성 문제가 있는지 확인합니다. 범위 구성은 업데이트 관리에 대해 구성되는 머신을 결정합니다. 머신이 작업 영역에 표시되지만 업데이트 관리에는 표시되지 않는 경우 해당 머신을 대상으로 하도록 범위 구성을 지정해야 합니다. 범위 구성에 대해 알아보려면 작업 영역에서 컴퓨터 사용를 참조하세요.
온-프레미스 Windows 컴퓨터에서 Hybrid Runbook Worker 제거 또는 컴퓨터에서 온-프레미스 Linux 컴퓨터에서 Hybrid Runbook Worker 제거의 단계에 따라 작업자 구성을 제거합니다.

시나리오: 대체된 업데이트가 업데이트 관리에 누락된 것으로 표시됨

문제

이전 업데이트가 대체된 경우에도 Automation 계정에 대해 누락된 것으로 나타납니다. 대체된 업데이트는 동일한 취약성을 해결하는 후속 업데이트를 사용할 수 있기 때문에 설치하지 않아도 되는 업데이트입니다. 업데이트 관리가 대체된 업데이트를 무시하고 대체하는 업데이트 대신 적용하지 않습니다. 관련 문제에 대한 자세한 내용은 업데이트가 대체됨을 참조하세요.

원인

대체된 업데이트는 WSUS(Windows Server Update Services)에서 거부되지 않으므로 해당되지 않는 것으로 간주할 수 있습니다.

해결

대체된 업데이트가 100% 적용할 수 없게 되면 WSUS에서 해당 업데이트의 승인 상태를 Declined로 변경해야 합니다. 모든 업데이트에 대한 승인 상태를 변경하려면

Automation 계정에서 업데이트 관리를 선택하여 머신 상태를 확인합니다. 업데이트 평가 보기를 참조하세요.
대체된 업데이트를 확인하여 100% 적용되지 않는지 확인합니다.
머신이 보고하는 WSUS 서버에서 업데이트를 거부합니다.
컴퓨터를 선택하고 규정 준수 열에서 규정 준수를 강제로 다시 검사합니다. VM에 대한 업데이트 관리를 참조하세요.
대체된 다른 업데이트에 대해 위 단계를 반복합니다.
WSUS(Windows Server Update Services)의 경우 대체된 모든 업데이트를 정리하기 위해 WSUS 서버 정리 마법사를 사용하여 인프라를 새로 고칩니다.
주기적으로 이 절차를 반복하여 표시 문제를 해결하고 업데이트 관리에 사용되는 디스크 공간의 크기를 최소화합니다.

시나리오: 포털의 업데이트 관리 아래에 머신이 표시되지 않음

문제

머신에 다음과 같은 증상이 있습니다.

머신은 VM의 업데이트 관리 보기에서 Not configured를 표시합니다.
Azure Automation 계정의 업데이트 관리 보기에 사용하는 머신이 없습니다.
사용하는 머신이 규정 준수에서 Not assessed로 표시됩니다. 그러나 Hybrid Runbook Worker에 대한 Azure Monitor 로그에는 하트비트 데이터가 표시되지만 업데이트 관리의 경우에는 표시되지 않습니다.

원인

이 이슈는 로컬 구성 이슈나 부적절하게 구성된 범위 구성으로 인해 발생할 수 있습니다. 가능한 구체적인 원인은 다음과 같습니다.

Hybrid Runbook Worker를 다시 등록하고 다시 설치해야 할 수 있습니다.
작업 영역에 정의한 할당량에 도달했으며 이로 인해 추가 데이터 저장이 진행되지 않았을 수 있습니다.

해결

OS에 따라 Windows 또는 Linux에 대한 문제 해결사를 실행합니다.
머신이 올바른 작업 영역에 보고하고 있는지 확인합니다. 이러한 측면을 확인하는 방법에 대한 참고 자료는 Azure Monitor에 대한 에이전트 연결 확인을 참조하세요. 또한 이 작업 영역이 Azure Automation 계정에 연결되어 있는지 확인합니다. 이를 확인하려면 Automation 계정으로 이동하고 관련 리소스에서 연결된 작업 영역을 선택합니다.
Automation 계정에 연결된 Log Analytics 작업 영역에 머신이 표시되는지 확인합니다. Log Analytics 작업 영역에서 다음 쿼리를 실행합니다.
```
Heartbeat
| summarize by Computer, Solutions
```
쿼리 결과에 머신이 표시되지 않으면 최근에 체크인되지 않은 것입니다. 로컬 구성 문제가 있는 것이므로 에이전트를 다시 설치해야 합니다.

머신이 쿼리 결과에 나열되는 경우 솔루션 속성에 업데이트가 나열되어 있는지 확인합니다. 이렇게 하여 업데이트 관리에 등록되었는지 확인합니다. 등록되지 않았으면 범위 구성 문제를 확인합니다. 범위 구성은 업데이트 관리에 대해 구성되는 머신을 결정합니다. 머신을 대상으로 하는 범위 구성을 구성하려면 작업 영역에서 머신 사용을 참조하세요.
작업 영역에서 이 쿼리를 실행합니다.
```
Operation
| where OperationCategory == 'Data Collection Status'
| sort by TimeGenerated desc
```
Data collection stopped due to daily limit of free data reached. Ingestion status = OverQuota 결과를 얻는 경우 작업 영역에 정의된 할당량에 도달하여 중지된 데이터를 저장하지 못한 것입니다. 작업 영역에서 사용량 및 예상 비용에서 데이터 볼륨 관리로 이동하고 할당량을 변경하거나 제거합니다.
그래도 문제가 해결되지 않으면 Windows Hybrid Runbook Worker 배포의 단계에 따라 Windows용 Hybrid Worker를 다시 설치합니다. Linux의 경우 Linux Hybrid Runbook Worker 배포의 단계를 따르세요.

시나리오: Automation 리소스 공급자를 구독에 등록할 수 없음

문제

Automation 계정에서 기능 배포를 사용하는 경우 다음과 같은 오류가 발생합니다.

Error details: Unable to register Automation Resource Provider for subscriptions

원인

Automation 리소스 공급자가 구독에 등록되어 있지 않습니다.

해결

Automation 리소스 공급자를 등록하려면 Azure Portal에서 다음 단계를 수행합니다.

포털의 맨 아래에 있는 Azure 서비스 목록에서 모든 서비스를 클릭하고 일반 서비스 그룹에서 구독을 선택합니다.
구독을 선택합니다.
설정 아래에서 리소스 공급자를 선택합니다.
리소스 공급자 목록에서 Microsoft.Automation 리소스 공급자가 등록되어 있는지 확인합니다.
나열되지 않은 경우 리소스 공급자 등록 오류 해결의 단계를 수행하여 Microsoft.Automation 공급자를 등록합니다.

시나리오: 예약된 업데이트가 일부 머신을 패치하지 않음

문제

업데이트 미리 보기에 포함된 머신 중 일부가 예약된 실행 중에 패치된 머신 목록에 표시되지 않거나 동적 그룹에서 선택된 범위의 VM이 포털의 업데이트 미리 보기 목록에 표시되지 않습니다.

업데이트 미리 보기 목록은 선택한 범위에 대해 Azure Resource Graph 쿼리를 실행하여 검색된 모든 머신으로 구성됩니다. 시스템 Hybrid Runbook Worker가 설치되어 있고 사용자에게 액세스 권한이 있는 머신에 대해 범위가 필터링됩니다.

원인

이 이슈는 다음 원인 중 하나 때문일 수 있습니다.

동적 쿼리의 범위에서 정의된 구독은 등록된 Automation 리소스 공급자에 대해 구성되지 않습니다.
일정이 실행될 때 머신을 사용할 수 없거나 머신에 적절한 태그가 없습니다.
선택한 범위에 대한 올바른 액세스 권한이 없습니다.
Azure Resource Graph 쿼리가 예상대로 머신을 검색하지 않습니다.
시스템 Hybrid Runbook Worker가 머신에 설치되어 있지 않습니다.

해결

등록된 Automation 리소스 공급자에 대해 구독이 구성되지 않음

Automation 리소스 공급자에 대해 구독이 구성되지 않은 경우 해당 구독의 머신에서 정보를 쿼리하거나 가져올 수 없습니다. 다음 단계를 사용하여 구독에 대한 등록을 확인합니다.

Azure Portal에서 Azure 서비스 목록에 액세스합니다.
모든 서비스를 선택한 후 일반 서비스 그룹에서 구독을 선택합니다.
배포 범위에서 정의된 구독을 찾습니다.
설정에서 리소스 공급자를 선택합니다.
Microsoft.Automation 리소스 공급자가 등록되어 있는지 확인합니다.
나열되지 않은 경우 리소스 공급자 등록 오류 해결의 단계를 수행하여 Microsoft.Automation 공급자를 등록합니다.

예약 실행 시 머신을 사용할 수 없거나 태그가 올바르게 지정되지 않음

구독이 Automation 리소스 공급자에 대해 구성되어 있지만 지정된 동적 그룹을 사용하여 업데이트 일정을 실행할 경우 일부 머신이 누락되면 다음 절차를 사용합니다.

Azure Portal에서 Automation 계정을 열고 업데이트 관리를 선택합니다.
업데이트 배포가 실행된 정확한 시간을 확인하려면 업데이트 관리 기록를 확인합니다.
업데이트 관리에서 누락된 것으로 의심되는 머신의 경우 ARG(Azure Resource Graph)를 사용하여 머신 변경 내용을 찾습니다.
업데이트 배포를 실행하기 전에 하루와 같은 상당히 긴 기간 동안의 변경 내용을 검색합니다.
이 기간 동안 삭제 또는 업데이트 변경과 같은 머신의 시스템 변경 내용을 검색 결과에서 확인합니다. 이러한 변경 내용은 머신 상태 또는 태그를 변경하여 업데이트를 배포할 때 머신 목록에서 머신이 선택되지 않도록 합니다.
머신 상태 또는 태그 문제를 해결하기 위해 필요에 따라 머신 및 리소스 설정을 조정합니다.
지정된 동적 그룹이 있는 배포에 모든 머신이 포함되도록 업데이트 일정을 다시 실행합니다.

선택한 범위에 대한 잘못된 액세스

Azure Portal에는 지정된 범위에서 쓰기 권한이 있는 머신만 표시됩니다. 범위에 대한 올바른 액세스 권한이 없는 경우 자습서: Azure Portal을 사용하여 Azure 리소스에 대한 사용자 액세스 권한 부여를 참조하세요.

Resource Graph 쿼리가 예상대로 머신을 반환하지 않음

아래 단계에 따라 쿼리가 제대로 작동하고 있는지 확인합니다.

Azure Portal의 Resource Graph 탐색기 블레이드에서 아래와 같이 형식이 지정된 Azure Resource Graph 쿼리를 실행합니다. Azure Resource Graph를 처음 사용하는 경우 빠른 시작에서 Resource Graph 탐색기를 사용하는 방법을 알아보세요. 이 쿼리는 업데이트 관리에서 동적 그룹을 만들 때 선택한 필터를 모방합니다. 업데이트 관리에서 동적 그룹 사용을 참조하세요.

where (subscriptionId in~ ("<subscriptionId1>", "<subscriptionId2>") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "<Windows/Linux>" and resourceGroup in~ ("<resourceGroupName1>","<resourceGroupName2>") and location in~ ("<location1>","<location2>") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" and tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "All" option selected for tags
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" or tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "Any" option selected for tags
| project id, location, name, tags

예를 들어 다음과 같습니다.

where (subscriptionId in~ ("20780d0a-b422-4213-979b-6c919c91ace1", "af52d412-a347-4bc6-8cb7-4780fbb00490") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "Windows" and resourceGroup in~ ("testRG","withinvnet-2020-01-06-10-global-resources-southindia") and location in~ ("australiacentral","australiacentral2","brazilsouth") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("ms-resource-usage")] =~ "azure-cloud-shell" and tags[tolower("temp")] =~ "temp")
| project id, location, name, tags

검색 중인 머신이 쿼리 결과에 나열되는지 확인합니다.
머신이 나열되지 않는 경우 동적 그룹에서 선택된 필터에 이슈가 있을 수 있습니다. 필요에 따라 그룹 구성을 조정합니다.

Hybrid Runbook Worker가 머신에 설치되지 않음

머신이 Azure Resource Graph 쿼리 결과에 표시되지만 여전히 동적 그룹 미리 보기에는 표시되지 않습니다. 이 경우 머신이 시스템 Hybrid Runbook Worker로 지정되지 않을 수 있으므로 Azure Automation 및 업데이트 관리 작업을 실행할 수 없습니다. 표시하려는 머신이 시스템 Hybrid Runbook Worker로 설정되었는지 확인하는 방법은 다음과 같습니다.

Azure Portal에서 올바르게 표시되지 않는 머신에 대한 Automation 계정으로 이동합니다.
프로세스 자동화에서 Hybrid Worker 그룹을 선택합니다.
시스템 Hybrid Worker 그룹 탭을 선택합니다.
해당 머신에 대한 Hybrid Worker가 있는지 확인합니다.
머신이 시스템 Hybrid Runbook Worker로 설정되지 않은 경우 다음 중 한 가지 방법을 검토하여 이를 사용하도록 설정합니다.
- Azure Arc 지원 서버를 포함하여 하나 이상의 Azure 및 비 Azure 머신에 대한 Automation 계정
- Enable-AutomationSolutionRunbook을 사용하여 Azure VM 온보딩을 자동화합니다.
- Azure Portal의 가상 머신 페이지에서 선택한 Azure VM의 경우. 이 시나리오는 Linux VM과 Windows VM에서 지원됩니다.
- 여러 Azure VM의 경우 Azure Portal의 가상 머신 페이지에서 해당 VM을 선택합니다.
사용하도록 설정하는 방법은 해당 머신이 실행 중인 환경에 따라 다릅니다.
미리 보기에 표시되지 않은 모든 머신에 대해 위 단계를 반복합니다.

시나리오: 업데이트 관리 구성 요소가 사용하도록 설정되었으나 VM이 계속 구성 중으로 표시됨

문제

배포를 시작하고 15분 후에 VM에서 다음 메시지가 계속 표시됩니다.

The components for the 'Update Management' solution have been enabled, and now this virtual machine is being configured. Please be patient, as this can sometimes take up to 15 minutes.

원인

이 오류는 다음과 같은 이유로 발생할 수 있습니다.

Automation 계정과의 통신이 차단되었습니다.
원본 컴퓨터 ID가 다른 중복된 컴퓨터 이름이 있습니다. 이 시나리오는 특정 컴퓨터 이름의 VM이 다른 리소스 그룹에 만들어지고 구독의 동일한 Logistics Agent 작업 영역에 보고하는 경우에 발생합니다.
배포되는 VM 이미지는 설치된 Windows용 Log Analytics 에이전트를 사용하여 시스템 준비(sysprep)로 준비되지 않은 복제된 머신에서 가져온 것일 수 있습니다.

해결

VM의 정확한 문제를 파악하기 위해 Automation 계정에 연결된 Log Analytics 작업 영역에서 다음 쿼리를 실행합니다.

Update
| where Computer contains "fillInMachineName"
| project TimeGenerated, Computer, SourceComputerId, Title, UpdateState

Automation 계정에 대한 통신이 차단됨

네트워크 계획으로 이동하여 업데이트 관리가 작동하려면 어떤 주소 및 포트를 허용해야 하는지 알아보세요.

중복 컴퓨터 이름

VM의 이름을 변경하여 환경에서 고유한 이름을 유지하도록 합니다.

복제된 머신에서 배포된 이미지

복제된 이미지를 사용하는 경우 다른 컴퓨터 이름의 원본 컴퓨터 ID가 같습니다. 이 경우 다음과 같습니다.

Log Analytics 작업 영역의 범위 구성(표시되는 경우) MicrosoftDefaultScopeConfig-Updates에 대한 저장된 검색에서 VM을 제거합니다. 저장된 검색은 작업 영역의 일반에서 찾을 수 있습니다.

다음 cmdlet을 실행합니다.

Remove-Item -Path "HKLM:\software\microsoft\hybridrunbookworker" -Recurse -Force

Restart-Service HealthService를 실행하여 상태 서비스를 다시 시작합니다. 이 작업을 수행하면 키가 다시 만들어지고 새 UUID가 생성됩니다.
이 방법이 작동하지 않으면 먼저 이미지에서 sysprep을 실행한 다음, Windows용 Log Analytics 에이전트를 설치합니다.

시나리오: 다른 Azure 테넌트에 있는 머신의 업데이트 배포를 만들 때 연결된 구독 오류가 발생함

문제

다른 Azure 테넌트에 있는 머신의 업데이트 배포를 만들려고 하면 다음 오류가 발생합니다.

The client has permission to perform action 'Microsoft.Compute/virtualMachines/write' on scope '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resourceGroupName/providers/Microsoft.Automation/automationAccounts/automationAccountName/softwareUpdateConfigurations/updateDeploymentName', however the current tenant '00000000-0000-0000-0000-000000000000' is not authorized to access linked subscription '00000000-0000-0000-0000-000000000000'.

원인

이 오류는 업데이트 배포에 포함된 다른 테넌트에 Azure VM이 있는 업데이트 배포를 만들 때 발생합니다.

해결

다음 해결 방법을 사용하여 이러한 항목을 예약합니다. ForUpdateConfiguration 매개 변수에서 New-AzAutomationSchedule cmdlet을 사용하여 일정을 만들 수 있습니다. 그런 다음, New-AzAutomationSoftwareUpdateConfiguration cmdlet을 사용하여 다른 테넌트의 머신을 NonAzureComputer 매개 변수에 전달할 수 있습니다. 다음 예제에서는 이를 수행하는 방법을 보여 줍니다.

$nonAzurecomputers = @("server-01", "server-02")

$startTime = ([DateTime]::Now).AddMinutes(10)

$s = New-AzAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdateConfiguration

New-AzAutomationSoftwareUpdateConfiguration  -ResourceGroupName $rg -AutomationAccountName $aa -Schedule $s -Windows -AzureVMResourceId $azureVMIdsW -NonAzureComputer $nonAzurecomputers -Duration (New-TimeSpan -Hours 2) -IncludedUpdateClassification Security,UpdateRollup -ExcludedKbNumber KB01,KB02 -IncludedKbNumber KB100

시나리오: 설명되지 않고 다시 부팅됨

문제

다시 부팅 제어 옵션을다시 부팅 안 함으로 설정한 경우에도 업데이트가 설치된 후에 머신이 다시 부팅됩니다.

원인

Windows 업데이트는 여러 레지스트리 키로 수정할 수 있으며, 이중 하나는 다시 부팅 동작을 수정할 수 있습니다.

해결

레지스트리를 편집하여 자동 업데이트 구성 및 다시 시작을 관리하는 데 사용되는 레지스트리 키에 나열된 레지스트리 키를 검토하여 머신이 올바르게 구성되었는지 확인합니다.

시나리오: 업데이트 배포에서 머신이 "시작하지 못함"을 표시함

문제

머신이 Failed to start 또는 Failed 상태를 표시합니다. 머신에 대한 특정 세부 정보를 볼 때 다음과 같은 오류가 표시됩니다.

For one or more machines in schedule, UM job run resulted in either Failed or Failed to start state. Guide available at https://aka.ms/UMSucrFailed.

원인

이 오류는 다음 이유 중 하나로 인해 발생할 수 있습니다.

머신이 더 이상 존재하지 않습니다.
머신이 꺼져 있고 연결할 수 없습니다.
머신에 네트워크 연결 이슈가 있으므로 머신의 Hybrid Worker에 연결할 수 없습니다.
원본 컴퓨터 ID를 변경한 Log Analytics 에이전트가 업데이트되었습니다.
Automation 계정에서 200개의 동시 작업 제한에 도달하여 업데이트 실행이 제한되었습니다. 각 배포는 하나의 작업으로 간주되며, 업데이트 배포의 각 머신은 하나의 작업으로 계산됩니다. Automation 계정에서 현재 실행되고 있는 다른 모든 Automation 작업 또는 업데이트 배포는 동시 작업 제한으로 계산됩니다.

해결

REST API를 사용하여 프로그래밍 방식으로 세부 정보를 검색할 수 있습니다. ID를 기준으로 업데이트 구성 머신 실행 목록 또는 단일 소프트웨어 구성 머신 실행을 검색하는 방법에 대한 자세한 내용은 소프트웨어 업데이트 구성 머신 실행을 참조하세요.

해당하는 경우 업데이트 배포에 동적 그룹을 사용합니다. 또한 다음 단계를 수행할 수 있습니다.

머신 또는 서버가 요구 사항을 충족하는지 확인합니다.
Hybrid Runbook Worker 에이전트 문제 해결사를 사용하여 Hybrid Runbook Worker에 대한 연결을 확인합니다. 이 문제 해결사에 대한 자세한 내용은 업데이트 에이전트 문제 해결을 참조하세요.

시나리오: 배포 없이 업데이트가 설치됨

문제

업데이트 관리에서 Windows 머신을 등록하면 배포 없이 설치된 업데이트가 표시됩니다.

원인

Windows에서는 업데이트가 사용 가능해지는 즉시 자동으로 설치됩니다. 머신에 업데이트를 배포하도록 예약하지 않은 경우 이 동작으로 인해 혼란이 발생할 수 있습니다.

해결

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU 레지스트리 키의 기본 설정은 4: auto download and install입니다.

업데이트 관리 클라이언트의 경우 이 키를 3: auto download but do not auto install로 설정하는 것이 좋습니다.

자세한 내용은 자동 업데이트 구성을 참조하세요.

시나리오: 컴퓨터가 이미 다른 계정에 등록되어 있음

문제

다음과 같은 오류 메시지가 표시됩니다.

Unable to Register Machine for Patch Management, Registration Failed with Exception System.InvalidOperationException: {"Message":"Machine is already registered to a different account."}

원인

머신이 이미 업데이트 관리를 위한 다른 작업 영역에 배포되었습니다.

해결

머신이 업데이트 관리에 표시되지 않음의 단계에 따라 머신이 올바른 작업 영역으로 보고하는지 확인합니다.
머신에서 Hybrid Runbook 그룹을 삭제하여 아티팩트를 정리한 후 다시 시도합니다.

시나리오: 머신이 서비스와 통신할 수 없음

문제

다음과 같은 오류 메시지 중 하나가 표시됩니다.

Unable to Register Machine for Patch Management, Registration Failed with Exception System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server can't communicate, because they do not possess a common algorithm

Unable to Register Machine for Patch Management, Registration Failed with Exception Newtonsoft.Json.JsonReaderException: Error parsing positive infinity value.

The certificate presented by the service <wsid>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.

Access is denied. (Exception form HRESULT: 0x80070005(E_ACCESSDENIED))

원인

네트워크 통신을 차단하는 프록시, 게이트웨이 또는 방화벽이 있을 수 있습니다.

해결 방법

네트워크를 검토하고 적합한 포트 및 주소가 허용되었는지 확인합니다. 업데이트 관리 및 Hybrid Runbook Worker에 필요한 포트 및 주소 목록은 네트워크 요구 사항을 참조하세요.

시나리오: 자체 서명된 인증서를 만들 수 없음

문제

다음과 같은 오류 메시지 중 하나가 표시됩니다.

Unable to Register Machine for Patch Management, Registration Failed with Exception AgentService.HybridRegistration. PowerShell.Certificates.CertificateCreationException: Failed to create a self-signed certificate. ---> System.UnauthorizedAccessException: Access is denied.

원인

Hybrid Runbook Worker가 자체 서명 인증서를 생성할 수 없습니다.

해결 방법

시스템 계정에 C:\ProgramData\Microsoft\Crypto\RSA 폴더에 대한 읽기 액세스 권한이 있는지 확인하고 다시 시도합니다.

시나리오: 예약된 업데이트가 MaintenanceWindowExceeded 오류로 인해 실패함

문제

업데이트를 위한 기본 유지 관리 기간은 120분입니다. 유지 관리 기간을 최대 6시간 또는 360분으로 늘릴 수 있습니다. 다음 오류 메시지가 나타날 수 있습니다. For one or more machines in schedule, UM job run resulted in Maintenance Window Exceeded state. Guide available at https://aka.ms/UMSucrMwExceeded.

해결

업데이트가 제대로 시작된 후 실행 중에 실패하는 일이 발생하는 이유를 이해하려면 실행 중에 영향을 받는 머신의 작업 출력을 확인합니다. 머신에서 특정 오류 메시지를 찾아 조치를 취할 수 있습니다.

모든 실패한 예약 업데이트 배포를 편집하고 유지 관리 기간을 늘립니다.

유지 관리 기간에 대한 자세한 내용은 업데이트 설치를 참조하세요.

시나리오: 컴퓨터가 평가되지 않음으로 표시되고 HRESULT 예외를 나타냄

문제

머신이 규정 준수에서 Not assessed로 표시되며 그 아래에 예외 메시지가 표시됩니다.
포털에 HRESULT 오류 코드가 표시됩니다.

원인

업데이트 에이전트(Windows의 Windows 업데이트 에이전트, Linux 배포용 패키지 관리자)가 올바르게 구성되어 있지 않습니다. 업데이트 관리는 머신의 업데이트 에이전트를 사용하여 필요한 업데이트, 패치의 상태 및 배포된 패치의 결과를 제공합니다. 이 정보가 없으면 업데이트 관리에서 필요하거나 설치된 패치를 제대로 보고할 수 없습니다.

해결

머신에서 로컬로 업데이트를 수행합니다. 이 작업이 실패하면 일반적으로 업데이트 에이전트 구성 오류가 있음을 의미합니다.

이 문제는 네트워크 구성 및 방화벽 이슈로 인해 발생하는 경우가 많습니다. 다음 검사를 사용하여 문제를 해결하세요.

Linux의 경우 해당 설명서를 확인하여 패키지 리포지토리의 네트워크 엔드포인트에 연결할 수 있는지 확인합니다.
Windows의 경우 업데이트가 인트라넷 엔드포인트(WSUS/SCCM)에서 다운로드되지 않음에 나열된 에이전트 구성을 확인합니다.
- Windows 업데이트에 대해 머신이 구성된 경우 HTTP/프록시와 관련된 이슈에 설명된 엔드포인트에 연결할 수 있는지 확인합니다.
- 머신이 WSUS(Windows Server Update Services)용으로 구성된 경우 WUServer 레지스트리 키로 구성된 WSUS 서버에 연결할 수 있는지 확인합니다.

HRESULT가 표시되는 경우 전체 예외 메시지를 보려면 빨간색으로 표시된 예외를 두 번 클릭합니다. 다음 표에서 잠재적 해결 방법 또는 권장 작업을 검토합니다.

예외	해결 방법 또는 작업
`Exception from HRESULT: 0x……C`	Windows 업데이트 오류 코드 목록에서 관련 오류 코드를 검색하여 예외의 원인에 대한 추가 세부 정보를 찾을 수 있습니다.
`0x8024402C` `0x8024401C` `0x8024402F`	네트워크 연결 이슈를 나타냅니다. 머신이 네트워크를 통해 업데이트 관리에 연결되어 있는지 확인합니다. 필요한 포트 및 주소 목록은 네트워크 계획 섹션을 참조하세요.
`0x8024001E`	서비스 또는 시스템이 종료 중이어서 업데이트 작업이 완료되지 않았습니다.
`0x8024002E`	Windows 업데이트 서비스를 사용할 수 없습니다.
`0x8024402C`	WSUS 서버를 사용하는 경우 레지스트리 키 `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate` 아래에 있는 `WUServer` 및 `WUStatusServer`의 레지스트리 값에 올바른 WSUS 서버를 지정합니다.
`0x80072EE2`	네트워크 연결 이슈 또는 구성된 WSUS 서버와의 통신 이슈가 있습니다. WSUS 설정을 확인하고 클라이언트에서 서비스에 액세스할 수 있는지 확인합니다.
`The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)`	Windows 업데이트 서비스(wuauserv)가 실행되고 있고 사용 안 함으로 설정되어 있지 않은지 확인합니다.
`0x80070005`	다음 중 하나로 인해 액세스 거부 오류가 발생할 수 있습니다. 감염된 컴퓨터 Windows 업데이트 설정이 올바르게 구성되지 않음 %WinDir%\SoftwareDistribution 폴더의 파일 사용 권한 오류 시스템 드라이브(C:)의 디스크 공간 부족
다른 제네릭 예외	인터넷에서 가능한 해결 방법을 검색하고 현지 IT 지원 팀과 함께 해결합니다.

%Windir%\Windowsupdate.log 파일을 검토하면 가능한 원인을 확인하는 데 도움이 될 수도 있습니다. 로그를 읽는 방법에 대한 자세한 내용은 Windowsupdate.log 파일을 읽는 방법을 참조하세요.

또한 Windows 업데이트 문제 해결사를 다운로드한 후 실행하여 머신의 Windows 업데이트에 이슈가 있는지 확인할 수 있습니다.

참고 항목

Windows 업데이트 문제 해결사 설명서는 해당 기능이 Windows 클라이언트용이지만 Windows Server에도 적용된다고 설명합니다.

시나리오: 업데이트 실행 시 실패 상태 반환(Linux)

문제

업데이트 실행은 시작되지만 실행 중 오류가 발생합니다.

원인

가능한 원인:

패키지 관리자가 비정상 상태입니다.
업데이트 에이전트(Windows용 WUA, Linux용 배포판 특정 패키지 관리자)가 잘못 구성되었습니다.
특정 패키지가 클라우드 기반 패치를 방해할 수 있습니다.
머신에 연결할 수 없습니다.
업데이트에 해결되지 않은 종속성이 있습니다.

해결

업데이트 실행이 제대로 시작된 후 실행 중에 실패할 경우 실행에서 영향을 받는 머신의 작업 출력을 확인합니다. 머신에서 특정 오류 메시지를 찾아 조치를 취할 수 있습니다. 업데이트 관리에서 업데이트 배포에 성공하려면 패키지 관리자가 정상 상태여야 합니다.

작업이 실패하기 직전에 특정 패치, 패키지 또는 업데이트가 표시되는 경우 다음 업데이트 배포에서 이러한 항목을 제외할 수 있습니다. Windows 업데이트에서 로그 정보를 수집하려면 Windows 업데이트 로그 파일을 참조하세요.

패치 이슈를 해결할 수 없는 경우 /var/opt/microsoft/omsagent/run/automationworker/omsupdatemgmt.log 파일의 복사본을 만들고, 다음 업데이트 배포가 시작되기 전에 문제를 해결할 수 있도록 유지합니다.

패치가 설치되지 않음

머신이 업데이트를 설치하지 않음

머신에서 직접 업데이트를 실행해 봅니다. 머신이 업데이트를 적용할 수 없는 경우 문제 해결 가이드의 잠재적 오류 목록을 참조하세요.

업데이트가 로컬로 실행되는 경우 업데이트 관리에서 VM 제거의 지침에 따라 머신에서 에이전트를 제거했다가 다시 설치해 봅니다.

업데이트를 사용할 수 있는 것을 알지만, 내 머신에는 업데이트가 사용 가능한 것으로 표시되지 않음

이 문제는 머신이 WSUS 또는 Microsoft Configuration Manager에서 업데이트를 가져오도록 구성되었지만 WSUS 및 Configuration Manager가 업데이트를 승인하지 않은 경우에 주로 발생합니다.

UseWUServer 레지스트리 키를 이 문서의 레지스트리를 편집하여 자동 업데이트 구성 섹션에 나오는 레지스트리 키와 상호 참조하여 머신이 WSUS 및 SCCM에 대해 구성되었는지 확인할 수 있습니다.

업데이트가 WSUS에서 승인되지 않으면 설치되지 않습니다. 다음 쿼리를 실행하여 Log Analytics에서 승인되지 않은 업데이트를 확인할 수 있습니다.

Update | where UpdateState == "Needed" and ApprovalSource == "WSUS" and Approved == "False" | summarize max(TimeGenerated) by Computer, KBID, Title

업데이트가 설치된 것으로 표시되지만, 머신에서 업데이트를 찾을 수 없음

업데이트가 종종 다른 업데이트로 대체됩니다. 자세한 내용은 Windows 업데이트 문제 해결 가이드의 업데이트가 대체됨을 참조하세요.

Linux에서 분류를 기준으로 업데이트 설치

분류("중요 업데이트 및 보안 업데이트")를 기준으로 Linux에 업데이트를 배포할 때, 특히 CentOS와 관련하여 중요한 주의 사항이 있습니다. 이러한 제한 사항은 업데이트 관리 개요 페이지에 설명되어 있습니다.

KB2267602가 지속적으로 누락

KB2267602는 Windows Defender 정의 업데이트이며 매일 업데이트됩니다.

다음 단계

문제가 표시되지 않거나 문제를 해결할 수 없는 경우 다음 채널 중 하나를 통해 추가 지원을 받으세요.

Azure 포럼을 통해 Azure 전문가로부터 답변을 얻습니다.
고객 환경을 개선하기 위한 공식 Microsoft Azure 계정인 @AzureSupport와 연결합니다.
Azure 지원 인시던트 제출 Azure 지원 사이트 로 가서 지원 받기를 선택합니다.