문제 해결 엔터프라이즈 및 교육용 Microsoft 연결된 캐시

이 문서에는 연결된 캐시를 사용하는 동안 발생할 수 있는 다양한 문제를 해결하는 방법에 대한 지침이 포함되어 있습니다. 이러한 문제는 발생할 수 있는 작업에 따라 분류됩니다.

알려진 문제

이 섹션에서는 엔터프라이즈 및 교육용 Microsoft 연결된 캐시 최신 릴리스의 알려진 문제에 대해 설명합니다. 최신 릴리스에 포함된 수정 사항에 대한 자세한 내용은 릴리스 정보 페이지를 참조하세요.

연결된 캐시 Azure 리소스가 "메트릭" 탭 아래의 범위 선택에서 누락됨

연결된 캐시 Azure 리소스의 모니터링 섹션에서 메트릭 탭을 선택하여 연결된 캐시 Azure Portal 사용자 지정 차트를 만들 수 있습니다. 연결된 캐시 Azure 리소스는 기본적으로 범위로 올바르게 선택되지만 선택한 범위를 변경하면 연결된 캐시 Azure 리소스를 다시 선택할 수 없으므로 이후 사용자 지정 차트가 생성되지 않습니다.

임시 해결 방법으로 메트릭 탭에서 벗어나 다시 돌아갈 수 있습니다. 연결된 캐시 Azure 리소스가 다시 한 번 범위로 올바르게 선택됩니다.

importCert.ps1 제한 사항

스크립트는 importCert.ps1 Windows 호스팅 캐시 노드에 대한 HTTPS 구성 프로세스의 일부로 인증서를 Windows 인증서 저장소로 가져오는 데 사용됩니다. v1.0.24.0 연결된 캐시 Windows 애플리케이션은 gMSA 연결된 캐시 런타임 계정으로 Windows Server 2022 또는 Windows Server 2025에 배포된 캐시 노드에서 이 스크립트 실행을 지원하지 않습니다. v1.0.26.0 애플리케이션 이상을 사용하여 해당 환경에서 이 스크립트를 실행합니다.

연결된 캐시 Windows 설치 관리자 애플리케이션 제한 사항

연결된 캐시 Windows 설치 관리자 애플리케이션은 Windows 호스트 컴퓨터에 연결된 캐시를 배포하는 데 사용되는 MSIX 패키지입니다. 설치 관리자 애플리케이션은 현재 Windows Server Core를 지원하지 않습니다.

최신 릴리스에서 패치됨

GA 릴리스: 2025년 7월 23일

  • Windows 호스트 컴퓨터가 EN이 아닌 로캘로 구성된 경우 연결된 캐시 설치가 실패합니다.
  • Windows 호스팅 연결된 캐시 노드는 구성된 캐시 드라이브 크기를 초과하여 증가할 수 있습니다.

Azure 구독 ID를 가져오는 단계

  1. Azure Portal 로그인합니다.
  2. 구독을 선택합니다. 구독이 표시되지 않으면 검색 창에 구독을 입력합니다. 입력을 시작하면 입력에 따라 목록이 필터링됩니다.
  3. Azure 구독이 이미 있는 경우 5단계로 건너뜁니다. Azure 구독이 없는 경우 왼쪽 위에서 + 추가를 선택합니다.
  4. 종량제 구독을 선택합니다. 신용 카드 정보를 입력하라는 메시지가 표시되지만 Microsoft Connected Cache 서비스 사용에 대해서는 요금이 청구되지 않습니다.
  5. 구독 페이지에서 현재 구독 에 대한 세부 정보를 찾을 수 있습니다. 구독 이름을 선택합니다.
  6. 구독 이름을 선택하면 개요 탭에서 구독 ID를 찾을 수 있습니다. 구독 ID 옆에 있는 클립보드로 복사 아이콘을 선택하여 값을 복사합니다.

Azure 리소스 만들기 문제 해결

연결된 캐시 Azure 리소스 만들기는 Azure Portal 사용자 인터페이스 또는 Azure CLI 명령 집합을 사용하여 시작할 수 있습니다.

리소스를 만드는 동안 오류가 발생하는 경우 구독에서 Azure 리소스를 만드는 데 필요한 권한이 있고 리소스 만들기 프로세스 중에 필요한 모든 필드를 입력했는지 검사.

캐시 노드 구성 문제 해결

연결된 캐시 노드의 구성은 Azure Portal 사용자 인터페이스 또는 Azure CLI 명령 집합을 사용하여 수행할 수 있습니다.

유효성 검사 오류가 발생하는 경우 필요한 모든 구성 필드를 입력했는지 검사.

구성이 적용되지 않는 경우 Azure Portal 사용자 인터페이스의 구성 페이지 맨 위에 있는 저장 옵션을 선택한 검사.

프록시 구성을 변경한 경우 프록시 구성이 적용되려면 호스트 컴퓨터에서 연결된 캐시 소프트웨어를 다시 배포해야 합니다.

Windows 호스트 컴퓨터에 캐시 노드 배포 문제 해결

Windows 호스팅 설치 로그 수집

Windows 호스트 컴퓨터에 연결된 캐시 노드를 배포하려면 연결된 캐시 Windows 애플리케이션에 포함된 일련의 PowerShell 스크립트를 실행해야 합니다. 이러한 스크립트는 로 지정된 deliveryoptimization-cli mcc-get-scripts-path연결된 캐시 애플리케이션의 스크립트 디렉터리에 로그 파일을 쓰려고 시도합니다.

다음과 같은 세 가지 유형의 설치 로그 파일이 있습니다.

  1. WSL_Mcc_Install_Transcript: 이 로그 파일은 설치 스크립트를 실행할 때 PowerShell 창에 인쇄된 줄을 기록합니다.
  2. WSL_Mcc_Install_FromRegisteredTask_Status: 이 로그 파일은 등록된 작업 설치 중에 작성된 상위 수준 상태 기록합니다.
  3. WSL_Mcc_Install_FromRegisteredTask_Transcript: 이 로그 파일은 등록된 작업 설치 중에 작성된 자세한 상태 기록합니다.

등록된 작업 성적 증명서는 일반적으로 설치 문제를 진단하는 데 가장 유용합니다.

다른 Windows 호스팅 로그 수집

캐시 노드가 Windows 호스트 컴퓨터에 성공적으로 설치되면 정기적으로 로그 파일을 설치 디렉터리(C:\mccwsl01\ 기본적으로)에 씁니다.

다음과 같은 유형의 로그 파일을 볼 수 있습니다.

  1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: 이 로그 파일은 연결된 캐시가 계속 실행되도록 하는 "MCC_Monitor_Task" 예약된 작업의 출력을 기록합니다.
  2. WSL_Mcc_UserUninstall_Transcript: 이 로그 파일은 사용자가 호스트 컴퓨터에서 연결된 캐시 소프트웨어를 제거하는 데 실행할 수 있는 "uninstallmcconwsl.ps1" 스크립트의 출력을 기록합니다.
  3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: 이 로그 파일은 "uninstallmcconwsl.ps1" 스크립트에서 호출될 때 호스트 컴퓨터에서 연결된 캐시 소프트웨어를 제거하는 작업을 담당하는 "MCC_Uninstall_Task" 예약된 작업의 출력을 기록합니다.

연결된 캐시 런타임 계정으로 PowerShell 프로세스 시작

Windows 호스트 컴퓨터에서 연결된 캐시 소프트웨어 문제를 해결하려면 커넥티드 캐시 런타임 계정으로 명령을 실행해야 할 수 있습니다. 연결된 캐시 설치 중에 지정된 런타임 계정으로 PowerShell 프로세스를 시작하여 이 작업을 수행할 수 있습니다.

  • 런타임 계정이 로컬 계정인 경우 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 PowerShell 프로세스를 런타임 계정으로 시작할 수 있습니다.

    Start-Process powershell.exe -Credential (Get-Credential "<RuntimeAccountName>") -ArgumentList '-NoExit'

  • 런타임 계정이 도메인 또는 서비스 계정인 경우 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 PowerShell 프로세스를 런타임 계정으로 시작할 수 있습니다.

    Start-Process powershell.exe -Credential (Get-Credential "<Domain>\<RuntimeAccountName>") -ArgumentList '-NoExit'

  • 런타임 계정이 gMSA(그룹 관리 서비스 계정)인 경우PsExec 를 사용하여 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 PowerShell 프로세스를 런타임 계정으로 시작해야 합니다.

    psexec.exe -i -u <DOMAIN\GmsaAccountName$> -p ~ powershell.exe

연결된 캐시 컨테이너가 실행 중인지 확인

연결된 캐시 소프트웨어가 Windows 호스트 컴퓨터에 성공적으로 배포되면 Windows 호스트 컴퓨터에서 다음을 수행하여 캐시 노드가 제대로 실행되고 있는지 검사 수 있습니다.

  1. 연결된 캐시 설치 중에 런타임 계정으로 지정된 계정으로 PowerShell 프로세스를 시작합니다.
  2. 를 실행 wsl -d Ubuntu-24.04-Mcc 하여 연결된 캐시 컨테이너를 호스트하는 Linux 배포에 액세스합니다.
  3. 를 실행 sudo iotedge list 하여 IoT Edge 런타임 내에서 실행 중인 컨테이너를 표시합니다.

edgeAgent 및 edgeHub 컨테이너가 표시되지만 MCC가 표시되지 않는 경우 를 사용하여 sudo iotedge system logs -- -fIoT Edge 보안 관리자의 상태 볼 수 있습니다.

를 사용하여 sudo iotedge system restartIoT Edge 런타임을 다시 부팅할 수도 있습니다. IoT Edge 런타임 문제 해결에 대한 자세한 내용은 IoT Edge 문제 해결 설명서를 참조하세요.

캐시 노드 등록 중에 연결된 캐시 설치 실패

Windows 호스트 컴퓨터의 설치 프로세스의 일부로 연결된 캐시는 등록 엔드포인트 geomcc.prod.do.dsp.mp.microsoft.com를 호출하여 배달 최적화 서비스에 자신을 등록하려고 시도합니다. 이 호출은 연결된 캐시 컨테이너를 호스트하는 WSL2 배포 내에서 시작되며 캐시 노드를 설치하려면 성공해야 합니다.

연결 문제를 해결하려면 관리자 권한 PowerShell 창에서 연결된 캐시 런타임 계정으로 다음 명령을 실행해 볼 수 있습니다.

먼저 연결된 캐시 컨테이너를 호스트하는 WSL2 배포판에 액세스합니다.

wsl -d Ubuntu-24.04-Mcc

그런 다음, 다음 bash 명령을 실행하여 등록 엔드포인트의 DNS 확인을 검사.

nslookup geomcc.prod.do.dsp.mp.microsoft.com

등록 엔드포인트에 대한 TCP 연결(HTTPS의 경우 포트 443)을 확인합니다.

nc -vz geomcc.prod.do.dsp.mp.microsoft.com 443

등록 엔드포인트에서 HTTPS 응답을 확인합니다.

curl -v https://geomcc.prod.do.dsp.mp.microsoft.com

예약된 작업을 MCC_Install_Task 실행하지 못함

Windows 호스트 컴퓨터에서 연결된 캐시 설치는 "MCC_Install_Task" 예약된 작업을 사용하여 지정된 연결된 캐시 런타임 계정으로 설치 작업을 수행합니다. 이 작업을 실행하지 못하면 다음 이유 중 하나 때문일 수 있습니다.

그룹 정책 개체가 예약된 작업 등록과 충돌

그룹 정책 개체 사용: 네트워크 액세스: 네트워크 인증에 대한 암호 및 자격 증명의 스토리지를 허용하지 않으면 연결된 캐시 소프트웨어가 성공적인 캐시 노드 등록 및 작업에 필요한 예약된 작업을 등록하지 못하게 됩니다.

MCC 런타임 계정에 일괄 처리 작업으로 로그온할 수 있는 권한이 없습니다.

연결된 캐시 런타임 계정에 "일괄 작업으로 로그온" 권한을 부여했는지 확인합니다. 연결된 캐시 런타임 계정이 예약된 작업을 실행하려면 이 권한이 필요합니다.

엔터프라이즈 보안 정책으로 PowerShell 스크립트 실행 방지

Windows 호스트 컴퓨터의 PowerShell 실행 정책에서 스크립트 실행을 허용하는지 확인합니다. 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 현재 실행 정책을 검사 수 있습니다.

Get-ExecutionPolicy

gMSA 자격 증명 오류로 인해 MCC 예약된 작업 등록 실패

MCC 예약된 작업을 등록하려고 할 때 gMSA 사용자 이름 또는 암호가 올바르지 않음을 나타내는 설치 오류가 표시되면 MCC 호스트 컴퓨터와 도메인 컨트롤러 간의 Kerberos 암호화 유형이 일치하지 않는 문제가 발생할 수 있습니다. 이를 resolve 도메인 컨트롤러에 구성된 암호화 유형과 일치하도록 gMSA 계정의 암호화 유형을 업데이트해야 합니다.

네트워크 보안: 도메인 컨트롤러 및 gMSA 계정 msDS-SupportedEncryptionTypes 의 특성 모두에서 Kerberos 정책에 허용되는 암호화 유형 구성을 검토하여 이러한 설정을 검사 정렬할 수 있습니다. 도메인 컨트롤러와 일치하도록 gMSA 계정의 암호화 유형을 업데이트하려면 Active Directory 팀에 문의하세요.

"지정된 로그온 세션이 없습니다"라는 메시지와 함께 WSL2를 설치하지 못했습니다.

Windows 호스트 컴퓨터에서 PowerShell 명령을 wsl.exe --install --no-distribution 실행하려고 할 때 이 오류 메시지가 발생하는 경우 로컬 관리자로 로그온하고 관리자 권한 PowerShell 창에서 명령을 실행했는지 확인합니다.

WSL2 커널 업데이트

WSL 관련 문제로 인해 연결된 캐시 설치가 실패하는 경우 를 실행 wsl.exe --update 하여 최신 버전의 WSL 커널을 가져옵니다.

예약된 작업을 MCC_Monitor_Task 실행하지 못함

연결된 캐시 컨테이너가 실행되면 MCC_Monitor_Task 예약된 작업이 연결된 캐시 런타임 계정에서 주기적으로 실행되어 WSL이 연결된 캐시 WSL 배포를 중지하지 못하도록 합니다. 캐시 노드가 사용자 작업 없이 오프라인으로 전환되는 경우 "MCC_Monitor_Task" 예약된 작업이 제대로 실행되지 않았기 때문일 수 있습니다.

호스트 컴퓨터에서 작업 스케줄러를 사용하여 이 예약된 작업의 상태 검사 수 있습니다.

  1. 호스트 컴퓨터에서 작업 스케줄러 열기
  2. 활성 작업 섹션으로 이동하고 MCC_Monitor_Task 두 번 클릭합니다.
  3. 마지막 실행 시간 및 마지막 실행 결과 열을 확인하여 작업이 성공적으로 완료되었는지 확인합니다.
  4. 트리거 탭을 선택하고 상태가 사용 상태인지 확인합니다.
  5. 기록 탭을 선택하고 작업 실행과 관련된 오류 또는 경고에 대해 검사.

MCC_Monitor_Task 성공적으로 실행되지 않으면 연결된 캐시 런타임 계정 자격 증명이 만료되었을 수 있습니다. 이 경우 스크립트를 updatetaskpasswords.ps1 사용하여 자격 증명을 업데이트할 수 있습니다.

  1. 관리자 권한으로 PowerShell 프로세스를 엽니다.

  2. 디렉터리를 스크립트 디렉터리로 변경하고 가 updatetaskpasswords.ps1있는지 확인합니다.

    • 공개 미리 보기 배포 패키지를 사용하여 연결된 캐시를 설치한 경우 스크립트 디렉터리가 원래 배포 명령(기본적으로 "C:\mccwsl01\MccScripts")에 지정된 installationFolder 내에 있습니다.
    • 연결된 캐시 Windows 애플리케이션을 사용하여 연결된 캐시를 설치한 경우 스크립트 디렉터리가 에서 deliveryoptimization-cli mcc-get-scripts-path반환하는 디렉터리 내에 있습니다.

  3. 새 암호를 사용하여 연결된 캐시 런타임 계정을 나타내는 이라는 $myLocalAccountCredentialPSCredential 개체를 만듭니다.

  4. updatetaskpasswords.ps1 다음 명령을 사용하여 스크립트를 실행합니다.

    .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential

캐시 노드가 성공적으로 배포되었지만 요청을 처리하지 않음

캐시 노드가 localhost 외부의 요청에 응답하지 않는 경우 연결된 캐시 설치 중에 호스트 컴퓨터의 포트 전달 규칙이 올바르게 설정되지 않았기 때문일 수 있습니다. WSL2는 기본적으로 가상화된 이더넷 어댑터를 사용하므로 트래픽이 LAN에서 WSL2 instance 도달할 수 있도록 포트 전달 규칙이 필요합니다. 자세한 내용은 WSL을 사용하여 네트워크 애플리케이션 액세스를 참조하세요.

연결된 캐시는 를 사용하여 netsh portproxy 호스트 컴퓨터의 IP 주소에서 MCC 컨테이너를 실행하는 WSL 배포로 트래픽을 전달하는 포트 전달 규칙을 설정합니다. 이러한 규칙이 작동하려면 Windows IP 도우미 서비스를 사용하도록 설정해야 합니다. IP 도우미 서비스를 사용하지 않도록 설정하면 을 통해 netsh portproxy 설정된 포트 전달 규칙이 적용되지 않으며 MCC 컨테이너는 localhost 외부에서 클라이언트 요청을 받지 않습니다.

중요

포트 전달 규칙을 확인하거나 추가하기 전에 Windows IP 도우미 서비스가 사용하도록 설정되어 있는지 확인합니다. 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 상태 검사 사용하도록 설정할 수 있습니다.

Get-Service -Name iphlpsvc | Select-Object Name, Status, StartType
Set-Service -Name iphlpsvc -StartupType Automatic
Start-Service -Name iphlpsvc

호스트 컴퓨터의 포트 전달 규칙을 검사 하려면 다음 PowerShell 명령을 사용합니다.

netsh interface portproxy show v4tov4

포트 80에서 0.0.0.0에 대한 포트 전달 규칙이 표시되지 않으면 관리자 권한 PowerShell instance 다음 명령을 실행하여 적절한 전달을 WSL로 설정할 수 있습니다.

netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=<WSL IP Address>

연결된 캐시 애플리케이션의 설치 디렉터리(C:\mccwsl01기본적으로)에 있어야 하는 파일에서 wslip.txt WSL IP 주소를 검색할 수 있습니다.

누락된 WSL 포트 전달 규칙(443, 5000)

중요

포트 전달 규칙이 작동하려면 Windows IP 도우미 서비스를 사용하도록 설정 netsh portproxy 해야 합니다. IP 도우미 서비스를 확인하고 사용하도록 설정하는 방법에 대한 지침 은 캐시 노드가 성공적으로 배포되었지만 요청을 제공하지 않음 을 참조하세요.

HTTPS를 지원하도록 Windows 호스팅 캐시 노드를 성공적으로 구성하려면 호스트 컴퓨터의 포트 443에서 연결된 캐시 컨테이너를 호스트하는 WSL2 배포판의 포트 443으로 트래픽을 전달하는 포트 전달 규칙을 만들어야 합니다.

Windows 호스팅 캐시 노드의 Terse 요약 페이지에 원격으로 액세스하려면 호스트 컴퓨터의 포트 5000에서 연결된 캐시 컨테이너를 호스트하는 WSL2 배포판의 포트 5000으로 트래픽을 전달하는 포트 전달 규칙을 만들어야 합니다.

캐시 노드 배포를 완료한 후 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 이러한 포트 전달 규칙을 만들 수 있습니다.

$ipFilePath = Join-Path ([System.Environment]::GetEnvironmentVariable("MCC_INSTALLATION_FOLDER", "Machine")) "wslIp.txt"

$ipAddress = (Get-Content $ipFilePath | Select-Object -First 1).Trim()

netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=$ipAddress
netsh interface portproxy add v4tov4 listenport=5000 listenaddress=0.0.0.0 connectport=5000 connectaddress=$ipAddress

또한 호스트 컴퓨터의 방화벽이 포트 443 및 5000에서 인바운드 트래픽을 허용하는지 확인해야 합니다. 관리자 권한 PowerShell 창에서 다음 명령을 실행하여 이 작업을 수행할 수 있습니다.

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Outbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (MCC SUMMARY)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "5000")

"오류: 인증서를 확인할 수 없음"으로 인해 Windows에 대한 캐시 노드 배포가 실패합니다.

캐시 노드 배포 중에 "오류: 인증서를 확인할 수 없음"이라는 오류가 발생하는 경우 네트워크의 TLS 검사 프록시(예: ZScaler)가 연결된 캐시 소프트웨어와 배달 최적화 서비스 간의 통신을 가로채기 때문일 수 있습니다. 이 차단은 인증서 체인을 끊고 연결된 캐시가 성공적으로 배포되지 않도록 방지합니다.

이 문제를 resolve 위해 "*.prod.do.dsp.mp.microsoft.com"에 대한 호출이 TLS 검사 프록시를 우회할 수 있도록 네트워크 환경을 구성해야 합니다.

캐시 노드 에 대한 프록시 설정도 구성 한 다음 원하는 installationFolder 경로에 프록시 인증서 파일(.pem)을 배치하고 배포 명령에 추가 -proxyTlsCertificatePemFileName "mycert.pem" 해야 합니다. 예를 들어 .pem 파일을 에 C:\mccwsl01\mycert.pem 배치하고 배포 명령에 추가 -proxyTlsCertificatePemFileName "mycert.pem" 합니다.

Linux 호스트 컴퓨터에 대한 캐시 노드 배포 문제 해결

Linux 호스트 컴퓨터에 연결된 캐시 노드를 배포하려면 Linux 배포 패키지에 포함된 일련의 Bash 스크립트를 실행해야 합니다.

연결된 캐시 소프트웨어가 Linux 호스트 컴퓨터에 성공적으로 배포되면 Linux 호스트 컴퓨터에서 다음을 수행하여 캐시 노드가 제대로 실행되는지 검사 수 있습니다.

  1. 를 실행 sudo iotedge list 하여 IoT Edge 런타임 내에서 실행 중인 컨테이너를 표시합니다.

edgeAgent 및 edgeHub 컨테이너가 표시되지만 MCC가 표시되지 않는 경우 를 사용하여 sudo iotedge system logs -- -fIoT Edge 보안 관리자의 상태 볼 수 있습니다.

를 사용하여 sudo systemctl restart iotedgeIoT Edge 런타임을 다시 부팅할 수도 있습니다.

참고

GA 릴리스 컨테이너로 마이그레이션되도록 Linux 캐시 노드를 다시 배포한 후 사용자가 를 실행한 다음 연결된 캐시 컨테이너 sudo iotedge restart MCC를 다시 시작해야 chmod 777 -R /cachedrivepath 합니다. 그렇지 않으면 다시 배포된 노드가 실행되지만 콘텐츠 요청은 실패합니다.

"오류: 인증서를 확인할 수 없음"으로 Linux 대한 캐시 노드 배포가 실패합니다.

캐시 노드 배포 중에 "오류: 인증서를 확인할 수 없음"이라는 오류가 발생하는 경우 네트워크의 TLS 검사 프록시(예: ZScaler)가 연결된 캐시 소프트웨어와 배달 최적화 서비스 간의 통신을 가로채기 때문일 수 있습니다. 이 차단은 인증서 체인을 끊고 연결된 캐시가 성공적으로 배포되지 않도록 방지합니다.

이 문제를 resolve 위해 "*.prod.do.dsp.mp.microsoft.com"에 대한 호출이 TLS 검사 프록시를 우회할 수 있도록 네트워크 환경을 구성해야 합니다.

캐시 노드 에 대한 프록시 설정도 구성 한 다음 추출된 배포 패키지 디렉터리에 프록시 인증서 파일(.pem)을 배치하고 배포 명령에 추가 proxytlscertificatepath="/path/to/pem/file" 해야 합니다.

캐시 노드 진단 지원 번들 생성

설치 패키지에 포함된 스크립트를 실행 collectMccDiagnostics.sh 하여 자세한 진단 정보가 포함된 지원 번들을 생성할 수 있습니다.

Windows 호스트 컴퓨터의 경우 다음을 수행해야 합니다.

  1. 연결된 캐시 설치 중에 런타임 계정으로 지정된 계정으로 PowerShell 프로세스를 시작합니다.

  2. 연결된 캐시 애플리케이션의 설치 디렉터리 내에서 디렉터리를 "MccScripts" 디렉터리로 변경하고(배포 명령에 지정됨, 기본값: C:\mccwsl01\MccScripts) 의 존재를 확인합니다. collectmccdiagnostics.sh

  3. 를 실행 wsl bash collectmccdiagnostics.sh 하여 진단 지원 번들을 생성합니다.

  4. 스크립트가 완료되면 진단 지원 번들의 위치를 설명하는 콘솔 출력을 확인합니다.

    예를 들어 "패키지를 압축했습니다. /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz 만든 파일을 보내주세요."

  5. wsl cp 명령을 실행하여 Ubuntu 배포 내의 위치에서 Windows 호스트 OS로 지원 번들을 복사합니다.

    예를 들어 wsl cp /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz /mnt/c/mccwsl01/SupportBundles/

Linux 호스트 컴퓨터의 경우 다음을 수행해야 합니다.

  1. 디렉터리를 추출된 연결된 캐시 배포 패키지 내의 "MccScripts" 디렉터리로 변경하고 의 존재를 확인합니다. collectmccdiagnostics.sh

  2. 를 실행 collectmccdiagnostics.sh 하여 진단 지원 번들을 생성합니다.

  3. 스크립트가 완료되면 진단 지원 번들의 위치를 설명하는 콘솔 출력을 확인합니다.

    예를 들어 "패키지를 압축했습니다. /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz 만든 파일을 보내주세요."

HTTPS 구성 문제 해결

CA(인증 기관)가 .pem 또는 .cer 형식으로만 서명된 인증서를 생성할 수 있는 경우 파일이 Base64 인코딩에 있는 경우 인증서 파일의 파일 확장자를 .crt로 변경할 수 있습니다.

캐시 노드 모니터링 문제 해결

연결된 캐시 노드 상태 및 성능은 Azure Portal 사용자 인터페이스를 사용하여 모니터링할 수 있습니다.

개요 탭의 기본 모니터링 시각적 개체에 예기치 않거나 잘못된 값이 표시되는 경우 브라우저 창을 새로 고칩니다. 문제가 지속되면 타임스팬 및 캐시 노드 필터를 원하는 대로 구성한 검사.

"정상" 상태 배달 최적화 서비스와 성공적으로 통신하는 연결된 캐시 컨테이너의 기능에 따라 결정됩니다. 캐시 노드에 "비정상" 상태 표시되는 경우 캐시 노드가 인터넷에 대한 아웃바운드 연결이 있고 배달 최적화 서비스 엔드포인트에 연결할 수 있는지 검사.

"정상" 상태 연결된 캐시 컨테이너가 배달 최적화 서비스와 통신할 수 있는지 여부만 반영합니다. 네트워크의 DO 클라이언트 디바이스가 캐시 노드에 도달할 수 있는지는 확인하지 않습니다. 방화벽 규칙, WSL2 포트 전달 간격 또는 네트워크 세분화로 인해 클라이언트에서 "정상" 노드에 연결할 수 없습니다.

캐시 노드에 대한 클라이언트 연결 문제 해결

클라이언트 연결 가능성을 테스트하려면 캐시 노드와 동일한 네트워크에 있는 클라이언트 디바이스에서 다음 URL을 방문하여 를 캐시 노드의 IP 주소로 바꿉 CacheNodeIPAddress 니다.

http://[CacheNodeIPAddress]/filestreamingservice/files/7bc846e0-af9c-49be-a03d-bb04428c9bb5/Microsoft.png?cacheHostOrigin=dl.delivery.mp.microsoft.com

자세한 지침은 캐시 노드 확인 문서를 참조하세요.

LocalPolicyMerge 설정으로 인해 DHCP 옵션 235가 검색되지 않음

DHCP 옵션 235를 사용하여 연결된 캐시 노드를 클라이언트에 보급하는 경우 LocalPolicyMerge 설정을 사용하면 DHCP 클라이언트가 옵션 235를 검색하지 못할 수 있습니다. 이 문제는 보안 기준이 적용되는 Windows Autopilot 프로비저닝 시나리오에서 특히 일반적입니다.

클라이언트가 DHCP를 통해 캐시 노드를 검색하지 않는 경우 설정이 사용자 환경에서 구성되었는지 여부를 LocalPolicyMerge 검사. 이 경우 DHCP 옵션 235 검색에서 캐시 노드의 호스트 이름 또는 IP 주소를 사용하여 DOCacheHost 정책을 직접 구성하는 것으로 전환하는 것이 좋습니다.

클라이언트 연결성 오류 진단

위의 확인 단계를 완료한 후에도 네트워크의 클라이언트가 캐시 노드에 연결할 수 없는 경우 다음 단계를 사용하여 문제를 진단합니다.

1단계: MCC_Monitor_Task 예약된 작업이 실행되어 있는지 확인합니다.

참고

이 단계는 Windows 호스팅 캐시 노드에만 적용됩니다.

MCC_Monitor_Task 예약된 작업은 Windows 호스트 컴퓨터에서 연결된 캐시 WSL 배포를 계속 실행합니다. 작업이 실행되고 있지 않으면 캐시 노드가 오프라인 상태일 수 있으므로 클라이언트 연결성이 실패할 수 있습니다.

  1. Windows 호스트 컴퓨터에서 작업 스케줄러 를 엽니다.
  2. 활성 작업 섹션에서 MCC_Monitor_Task 찾습니다.
  3. 마지막 실행 시간 및 마지막 실행 결과 열을 확인하여 작업이 성공적으로 실행되었는지 확인합니다.
  4. 트리거 탭 을 선택하고 트리거 상태가사용 상태인지 확인합니다.

가 실행되지 않는 경우 MCC_Monitor_Task MCC_Monitor_Task 예약된 작업이 실행되지 않음 섹션을 참조하여 해결 단계를 확인합니다.

2단계: WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt 검토

참고

이 단계는 Windows 호스팅 캐시 노드에만 적용됩니다.

로그 파일은 WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt 각 MCC_Monitor_Task 실행의 출력을 기록하며 연결된 캐시 WSL 배포 또는 컨테이너에 오류가 발생했는지 여부를 식별하는 데 유용합니다.

  1. Windows 호스트 컴퓨터에서 연결된 캐시 설치 디렉터리로 이동합니다.
    • 기본 설치 디렉터리가 입니다 C:\mccwsl01\.
    • 관리자 권한 PowerShell 창에서 를 실행 deliveryoptimization-cli mcc-get-scripts-path 하여 정확한 경로를 확인할 수 있습니다.
  2. 텍스트 편집기에서 엽니다 WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt .
  3. WSL 배포를 시작하지 못했거나 연결된 캐시 컨테이너가 예기치 않게 중지되었음을 나타내는 오류는 로그를 검토합니다.

3단계: B1.DOWNLOAD.WINDOWSUPDATE.COM 대한 DNS 확인 및 HTTP 연결 유효성 검사

클라이언트에 요청을 제공하려면 연결된 캐시 노드가 업스트림 Microsoft 콘텐츠 배달 엔드포인트에 연결할 수 있어야 합니다. 다음 명령을 사용하여 캐시 노드 호스트가 resolve 에 연결할 수 있는지 확인합니다b1.download.windowsupdate.com.

Windows 호스팅 캐시 노드

  1. 연결된 캐시 런타임 계정으로 PowerShell 프로세스를 시작합니다.

  2. WSL2 배포에 액세스합니다.

    wsl -d Ubuntu-24.04-Mcc

  3. DNS 확인 확인:

    nslookup b1.download.windowsupdate.com

  4. HTTP 연결을 확인합니다.

    curl -v http://b1.download.windowsupdate.com

Linux 호스트 캐시 노드

Linux 호스트 컴퓨터에서 직접 다음 명령을 실행합니다.

  1. DNS 확인 확인:

    nslookup b1.download.windowsupdate.com

  2. HTTP 연결을 확인합니다.

    curl -v http://b1.download.windowsupdate.com

DNS 확인이 실패하거나 HTTP 요청이 차단된 경우 4단계로 진행하여 네트워크 계층 차단기를 조사합니다.

4단계: 방화벽, 프록시 및 TLS 검사 설정 확인

3단계 DNS 또는 HTTP 검사가 실패하면 다음 네트워크 계층 구성 중 하나 이상이 캐시 노드 호스트에서 업스트림 연결을 차단할 수 있습니다.

5단계: 진단 수집

이전 단계를 완료한 후에도 문제가 지속되면 Microsoft 지원과 공유할 진단 지원 번들을 생성합니다. 지침 은 캐시 노드 진단 지원 번들 생성 을 참조하세요.

사용자 고유의 DNS 확인자를 사용하도록 Docker DNS 업데이트

Linux 호스팅 캐시 노드에 네트워크 연결 문제가 발생하는 경우 organization 자체 DNS 확인자를 사용하도록 Docker의 DNS 구성을 업데이트하면 문제가 resolve 수 있습니다.

  1. Docker 디먼 구성 파일을 엽니다.

    nano /etc/docker/daemon.json

  2. organization DNS 확인자 IP 주소를 포함하도록 파일 내용을 업데이트합니다.

    "log-driver": "json-file", "log-opts": {"max-size": "10m","max-file": "3"},"dns":["<Your organization's DNS resolver IP address>"]

  3. Ctrl+X를 사용하여 파일을 저장하고 닫은 다음, Y를 사용하여 확인합니다.

  4. 변경 내용이 적용되려면 Docker를 다시 시작합니다.

    systemctl restart docker

  5. IoT Edge 검사 명령을 다시 실행하여 적절한 연결의 유효성을 검사합니다.

    iotedge check --verbose

진단 및 해결

Azure Portal 인터페이스에서 제공하는 문제 진단 및 해결 기능을 사용할 수도 있습니다. Microsoft Connected Cache Azure 리소스 내의 이 탭은 문제에 대한 해결 방법을 좁히는 데 도움이 되는 몇 가지 프롬프트를 안내합니다.

  • Last updated on