다음을 통해 공유

앱 연결 및 MSIX 앱 연결 - Azure Virtual Desktop

  • 아티클

Azure Virtual Desktop에서는 앱 연결과 MSIX 앱 연결이라는 두 가지 기능을 이용해 애플리케이션 패키지의 애플리케이션을 Azure Virtual Desktop의 사용자 세션에 동적으로 연결할 수 있습니다. 앱 연결과 MSIX 앱 연결을 모두 사용하면 애플리케이션은 세션 호스트 또는 이미지에 로컬로 설치되지 않으며, 따라서 세션 호스트에 대한 사용자 지정 이미지를 더 쉽게 만들고 조직의 운영 오버헤드와 비용을 줄일 수 있습니다. 애플리케이션은 사용자 데이터, 운영 체제 및 기타 애플리케이션을 분리하는 컨테이너 내에서 실행되므로 보안을 강화하고 문제를 쉽게 해결할 수 있습니다.

다음 표에서는 MSIX 앱 연결과 일반 앱 연결을 비교합니다.

MSIX 앱 연결 앱 연결
애플리케이션은 RemoteApp을 사용하여 제공되거나 데스크톱 세션의 일부로 제공됩니다. 사용 권한은 애플리케이션 그룹에 할당하여 제어되지만, 모든 데스크톱 사용자는 데스크톱 애플리케이션 그룹에서 모든 MSIX 앱 연결 애플리케이션을 볼 수 있습니다. 애플리케이션은 RemoteApp을 사용하여 제공되거나 데스크톱 세션의 일부로 제공됩니다. 권한은 사용자별, 애플리케이션별로 적용되므로, 사용자가 원격 세션에서 액세스할 수 있는 애플리케이션을 더 잘 제어할 수 있습니다. 데스크톱 사용자는 자신에게 할당된 앱 연결 애플리케이션만 볼 수 있습니다.
애플리케이션은 단일 호스트 풀에서만 실행될 수 있습니다. 다른 호스트 풀에서 실행하려면 다른 패키지를 만들어야 합니다. 동일한 애플리케이션 패키지를 여러 호스트 풀에서 사용할 수 있습니다.
애플리케이션은 애플리케이션이 추가된 호스트 풀에서만 실행할 수 있습니다. 애플리케이션은 애플리케이션 패키지와 동일한 Azure 지역에서 Windows 클라이언트 운영 체제를 실행하는 모든 세션 호스트에서 실행할 수 있습니다.
애플리케이션을 업데이트하려면 다른 버전의 패키지를 이용해 애플리케이션을 삭제하고 다시 만들어야 합니다. 유지 관리 기간에 애플리케이션을 업데이트해야 합니다. 유지 관리 기간 없이 새 디스크 이미지를 사용하여 애플리케이션을 새 애플리케이션 버전으로 업그레이드할 수 있습니다.
사용자는 동일한 세션 호스트에서 애플리케이션의 두 버전을 실행할 수 없습니다. 사용자는 동일한 세션 호스트에서 애플리케이션의 두 버전을 동시에 실행할 수 있습니다.
Azure Log Analytics를 통해 사용량 및 상태를 원격 분석할 수 없습니다. Azure Log Analytics를 통해 사용량 및 상태를 원격 분석할 수 있습니다.

다음 애플리케이션 패키지 형식과 파일 형식을 사용할 수 있습니다.

패키지 형식 파일 형식 기능 가용성
MSIX 및 MSIX 번들 .msix
.msixbundle		 MSIX 앱 연결
앱 연결
Appx 및 Appx 번들 .appx
.appxbundle		 앱 연결만

MSIX 및 Appx는 Windows 애플리케이션에 최신 패키징 환경을 제공하는 Windows 애플리케이션 패키지 형식입니다. 애플리케이션은 사용자 데이터, 운영 체제 및 기타 애플리케이션을 분리하는 컨테이너 내에서 실행되므로 보안을 강화하고 문제를 쉽게 해결할 수 있습니다. MSIX와 Appx는 비슷하며, 가장 큰 차이점은 MSIX가 Appx의 상위 집합이라는 점입니다. MSIX는 Appx의 모든 기능을 지원하며, 엔터프라이즈용으로 더 적합한 다른 기능도 지원합니다.

팁

이 문서의 맨 위에 있는 단추를 선택하여 앱 연결과 MSIX 앱 연결 중에서 선택하여 관련 설명서를 확인합니다.

소프트웨어 공급업체에서 MSIX 패키지를 가져올 수도 있고, 기존 설치 관리자에서 MSIX 패키지를 만들 수도 있습니다. MSIX에 대해 자세히 알아보려면 MSIX 앱 연결이란?을 참조하세요

사용자가 애플리케이션을 얻는 방법

동일한 호스트 풀 또는 동일한 세션 호스트에 있는 다른 사용자에게 다른 애플리케이션을 할당할 수 있습니다. 사용자가 적절한 시간에 적절한 애플리케이션을 얻으려면, 로그인하는 동안 다음 세 가지 요구 사항을 모두 충족해야 합니다.

  • 애플리케이션을 호스트 풀에 할당해야 합니다. 애플리케이션을 호스트 풀에 할당하면 애플리케이션을 사용할 수 있는 호스트 풀을 선택하여, 애플리케이션에서 올바른 하드웨어 리소스를 사용할 수 있는지 확인할 수 있습니다. 예를 들어 애플리케이션이 그래픽을 많이 사용한다면, GPU 최적화 세션 호스트가 있는 호스트 풀에서만 실행되게 할 수 있습니다.

  • 사용자는 호스트 풀에 있는 세션 호스트에 로그인할 수 있어야 하며, 따라서 데스크톱 또는 RemoteApp 애플리케이션 그룹에 속해야 합니다. RemoteApp 애플리케이션 그룹의 경우 앱 연결 애플리케이션을 애플리케이션 그룹에 추가해야 하지만, 데스크톱 애플리케이션 그룹에 애플리케이션을 추가할 필요는 없습니다.

  • 애플리케이션이 사용자 또는 그룹에 할당되어야 합니다. 그룹 또는 사용자 계정을 사용할 수 있습니다.

이러한 요구 사항이 모두 충족되면 사용자는 애플리케이션을 얻게 됩니다. 이 프로세스를 사용하면 누가 어떤 호스트 풀에서 애플리케이션을 얻는지를, 그리고 단일 호스트 풀 내의 사용자 또는 동일한 다중 세션 호스트에 로그인한 사용자가 다양한 애플리케이션 조합을 얻는 방법을 제어할 수 있습니다. 요구 사항을 충족하지 않는 사용자는 애플리케이션을 얻지 못합니다.

사용자가 애플리케이션을 얻는 방법

동일한 호스트 풀에 있는 다른 사용자에게 다른 애플리케이션을 할당할 수 있습니다. MSIX 앱 연결을 사용하면 호스트 풀에 MSIX 패키지를 추가하고, 데스크톱 또는 RemoteApp 애플리케이션 그룹을 사용하여 애플리케이션 할당을 제어합니다. 사용자가 적절한 시간에 적절한 애플리케이션을 얻으려면, 로그인하는 동안 다음 요구 사항을 모두 충족해야 합니다.

  • 사용자는 호스트 풀에 있는 세션 호스트에 로그인할 수 있어야 하며, 따라서 데스크톱 또는 RemoteApp 애플리케이션 그룹에 속해야 합니다.

  • MSIX 이미지를 호스트 풀에 추가해야 합니다.

이러한 요구 사항이 충족되면 사용자는 애플리케이션을 얻게 됩니다. 데스크톱 애플리케이션 그룹을 사용하여 애플리케이션을 할당하면 애플리케이션이 사용자의 시작 메뉴에 추가됩니다. 요구 사항을 충족하지 않는 사용자는 애플리케이션을 얻지 못합니다.

애플리케이션 이미지

Azure Virtual Desktop에서 애플리케이션 패키지를 사용하려면 먼저 MSIXMGR 도구를 사용하여 기존 애플리케이션 패키지에서 MSIX 이미지를 만들어야 합니다. 그런 다음 세션 호스트에서 액세스할 수 있는 파일 공유에 각 디스크 이미지를 저장해야 합니다. 파일 공유 요구 사항에 대한 자세한 내용은 파일 공유를 참조하세요.

디스크 이미지 형식

디스크 이미지에 Composite Image File System(CimFS), VHDX 또는 VHD를 사용할 수 있지만 VHD는 사용하지 않는 것이 좋습니다. CimFS 이미지 탑재 및 분리는 VHD 및 VHDX 파일보다 빠르며 CPU와 메모리를 적게 사용합니다. 세션 호스트가 Windows 11을 실행하는 경우에만 애플리케이션 이미지에 CimFS를 사용하는 것이 좋습니다.

CimFS 이미지는 여러 파일의 조합입니다. 한 파일은 .cim 파일 확장명을 가지며 메타데이터가 있고 두 개 이상의 다른 파일이 있으며, 다른 파일은 objectid_로 시작하고 또 다른 파일은 실제 애플리케이션 데이터를 포함하는 region_로 시작합니다. .cim 파일과 함께 제공되는 파일에는 파일 확장명이 없습니다. 다음 표는 CimFS 이미지에 대해 찾을 예제 파일 목록입니다.

File name 크기
MyApp.cim 1KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264,132KB

다음 표는 VHDX와 CimFS 간 성능 비교입니다. 이러한 숫자는 형식당 각각 300MB의 파일 500개가 있는 테스트 실행의 결과이며, 테스트는 DSv4 Azure 가상 머신에서 수행되었습니다.

메트릭 VHD CimFS
평균 탑재 시간 356ms 255ms
평균 분리 시간 1615ms 36ms
메모리 소비 6%(8GB) 2%(8GB)
CPU(스파이크 계산) 여러 번 최댓값 도달 영향 없음

애플리케이션 등록

앱 연결은 로그인하는 동안 파일 공유에 있는, 애플리케이션이 포함된 디스크 이미지를 사용자 세션에 마운트합니다. 이후 등록 프로세스를 통해 사용자는 애플리케이션을 사용할 수 있게 됩니다. 등록에는 두 가지 형식이 있습니다.

MSIX 앱 연결은 로그인하는 동안 파일 공유에 있는, 애플리케이션이 포함된 디스크 이미지를 사용자 세션에 마운트합니다. 이후 등록 프로세스를 통해 사용자는 애플리케이션을 사용할 수 있게 됩니다. 등록에는 두 가지 형식이 있습니다.

  • 주문형: 애플리케이션은 로그인 시 부분적으로만 등록되며, 애플리케이션 전체 등록은 사용자가 애플리케이션을 시작할 때까지 연기됩니다. 주문형은 Azure Virtual Desktop에 로그인하는 데 걸리는 시간에 영향을 주지 않으므로 사용하는 것이 좋습니다. 주문형은 기본 등록 방법입니다.

  • 로그온 차단: 사용자에게 할당한 각 애플리케이션이 완전히 등록됩니다. 등록은 사용자가 세션에 로그인하는 동안 진행되며, 이는 Azure Virtual Desktop에 로그인하는 데 걸리는 시간에 영향을 미칠 수 있습니다.

Important

모든 MSIX 및 Appx 애플리케이션 패키지에는 인증서가 포함되어 있습니다. 사용자 환경에서 인증서를 신뢰할 수 있는지 확인하는 것은 사용자의 책임입니다. 자체 서명된 인증서는 적절한 신뢰 체인이 있을 때 지원됩니다.

앱 연결은 사용자가 사용할 수 있는 애플리케이션 수를 제한하지 않습니다. 지원 가능한 사용자 또는 애플리케이션 수를 제한할 수 있으므로, 사용 가능한 네트워크 처리량과 파일 공유에서 지원하는 (각 이미지의) 파일당 열린 핸들 수를 고려해야 합니다. 자세한 내용은 파일 공유를 참조하세요.

Important

모든 MSIX 애플리케이션 패키지에는 인증서가 포함되어 있습니다. 사용자 환경에서 인증서를 신뢰할 수 있는지 확인하는 것은 사용자의 책임입니다. 자체 서명된 인증서는 지원됩니다.

MSIX 앱 연결은 사용자가 사용할 수 있는 애플리케이션 수를 제한하지 않습니다. 지원 가능한 사용자 또는 애플리케이션 수를 제한할 수 있으므로, 사용 가능한 네트워크 처리량과 파일 공유에서 지원하는 (각 이미지의) 파일당 열린 핸들 수를 고려해야 합니다. 자세한 내용은 파일 공유를 참조하세요.

애플리케이션 상태

MSIX 및 Appx 패키지는 활성 또는 비활성으로 설정됩니다. 활성으로 설정된 패키지는 사용자가 애플리케이션을 사용할 수 있게 합니다. 비활성으로 설정된 패키지는 Azure Virtual Desktop에서 무시되며 사용자가 로그인할 때 추가되지 않습니다.

MSIX 패키지는 활성 또는 비활성으로 설정됩니다. MSIX 패키지를 활성으로 설정하면 사용자가 애플리케이션을 사용할 수 있습니다. 비활성으로 설정된 MSIX 패키지는 Azure Virtual Desktop에서 무시되며 사용자가 로그인할 때 추가되지 않습니다.

애플리케이션 새 버전

업데이트된 애플리케이션을 포함하는 새 이미지를 제공하여 애플리케이션 새 버전을 추가할 수 있습니다. 이 새 이미지는 다음 두 가지 방법으로 사용할 수 있습니다.

  • 병렬: 새 디스크 이미지를 사용하여 새 애플리케이션을 만들고 기존 애플리케이션과 동일한 호스트 풀 및 사용자에게 할당합니다.

  • 현재 위치: 애플리케이션의 버전 번호가 변경되는 새 이미지를 만든 다음, 새 이미지를 사용하도록 기존 애플리케이션을 업데이트합니다. 버전 번호는 더 높거나 낮아도 되지만, 동일한 버전 번호로 애플리케이션을 업데이트할 수는 없습니다. 모든 사용자가 사용을 종료하기 전에는 기존 이미지를 삭제해선 안 됩니다.

업데이트가 끝나면 사용자는 다음에 로그인할 때 업데이트된 애플리케이션 버전을 이용하게 됩니다. 사용자는 이전 버전 사용을 중단하지 않고도 새 버전을 추가할 수 있습니다.

애플리케이션 새 버전

MSIX 앱 연결을 사용할 때는 애플리케이션 패키지를 삭제한 다음, 새 디스크 이미지를 사용하여 새 애플리케이션을 만들고 동일한 호스트 풀에 할당해야 합니다. 앱 연결과 달리 현재 위치에서는 업데이트할 수 없습니다. 사용자는 다음에 로그인할 때 새 이미지와 업데이트된 애플리케이션 버전을 이용하게 됩니다. 이러한 작업은 유지 관리 기간 동안 수행해야 합니다.

ID 공급자

앱 연결에 사용할 수 있는 ID 공급자는 다음과 같습니다.

ID 공급자 상태
Microsoft Entra ID 지원됨
AD DS(Active Directory Domain Services) 지원됨
Microsoft Entra Domain Services 지원되지 않음

MSIX 앱 연결에 사용할 수 있는 ID 공급자는 다음과 같습니다.

ID 공급자 상태
Microsoft Entra ID 지원되지 않음
AD DS(Active Directory Domain Services) 지원됨
Microsoft Entra Domain Services(Azure AD DS) 지원되지 않음

파일 공유

앱 연결을 사용하려면 애플리케이션 이미지가 SMB 파일 공유에 저장되어야 합니다. 이렇게 하면 로그인하는 동안 파일 공유가 각 세션 호스트에 탑재됩니다. 앱 연결에는 파일 공유에서 사용하는 스토리지 패브릭 유형에 대한 종속성이 없습니다. Microsoft Entra ID 또는 Active Directory Domain Services와 호환되며 비용 및 관리 오버헤드 균형 유지에도 큰 도움이 되므로, Azure Files를 사용하는 것이 좋습니다.

Azure NetApp Files를 사용할 수도 있지만, 이렇게 하려면 세션 호스트를 Active Directory Domain Services에 조인해야 합니다.

MSIX 앱 연결을 사용하려면 애플리케이션 이미지가 SMB 버전 3 파일 공유에 저장되어야 합니다. 이렇게 하면 로그인하는 동안 파일 공유가 각 세션 호스트에 탑재됩니다. MSIX 앱 연결에는 파일 공유에서 사용하는 스토리지 패브릭 유형에 대한 종속성이 없습니다. MSIX 앱 연결에 사용할 수 있는 지원되는 ID 공급자와 호환되며 비용 및 관리 오버헤드 균형 유지에도 큰 도움이 되므로, Azure Files 사용하는 것이 좋습니다. Azure NetApp Files를 사용할 수도 있지만, 이렇게 하려면 세션 호스트가 Active Directory Domain Services에 조인되어야 합니다.

다음 섹션에서는 파일 공유에 필요한 권한, 성능 및 가용성에 관한 몇 가지 지침을 제공합니다.

사용 권한

각 세션 호스트는 파일 공유에서 애플리케이션 이미지를 탑재합니다. 각 세션 호스트 컴퓨터 개체가 파일 및 파일 공유에 대한 읽기 액세스를 허용하도록 NTFS를 구성하고 권한을 공유해야 합니다. 올바른 권한을 구성하는 방법은 파일 공유 및 세션 호스트에 사용하는 스토리지 공급자 및 ID 공급자에 따라 달라집니다.

  • 세션 호스트가 Microsoft Entra ID에 조인할 때 Azure Files를 사용하려면 읽기 권한자 및 데이터 액세스 Azure 역할 기반 액세스 제어(RBAC) 역할을 Azure Virtual Desktop 및 Azure Virtual Desktop ARM 공급자 서비스 주체에 할당해야 합니다. 이 RBAC 역할 할당을 사용하면 세션 호스트가 액세스 키를 사용하여 스토리지 계정에 액세스하게 할 수 있습니다. 스토리지 계정은 세션 호스트와 동일한 Azure 구독에 있어야 합니다. Azure Virtual Desktop 서비스 주체에 Azure RBAC 역할을 할당하는 방법을 알아보려면 Azure Virtual Desktop 서비스 주체에 RBAC 역할 할당을 참조하세요.

    Microsoft Entra ID, Active Directory Domain Services 또는 Microsoft Entra Domain Services에 조인된 세션 호스트에서 Azure Files를 사용하는 방법에 대한 자세한 내용은 SMB 액세스 대한 Azure Files ID 기반 인증 옵션 개요를 참조하세요.

    Warning

    스토리지 계정에 Azure Virtual Desktop ARM 공급자 서비스 주체를 할당하면 스토리지 계정 내의 모든 데이터에 Azure Virtual Desktop 서비스가 부여됩니다. 이 스토리지 계정에서 앱 연결과 함께 사용할 앱만 저장하고 액세스 키를 정기적으로 회전하는 것이 좋습니다.

  • Azure NetApp Files의 경우 SMB 볼륨을 만들고, 각 세션 호스트의 컴퓨터 개체에 대한 읽기 권한을 부여하도록 NTFS 권한을 구성할 수 있습니다. 세션 호스트를 Active Directory Domain Services 또는 Microsoft Entra Domain Services에 조인해야 합니다.

PsExec를 사용하여 사용 권한이 올바른지 확인할 수 있습니다. 자세한 내용은 파일 공유 액세스 확인을 참조하세요.

성능

요구 사항은 이미지에 저장된 패키지된 애플리케이션 수에 따라 크게 달라질 수 있으며, 애플리케이션을 테스트해 요구 사항을 파악해야 합니다. 큰 이미지의 경우 더 많은 대역폭을 할당해야 합니다. 다음 표에서는 세션 호스트당 애플리케이션 하나가 필요한 단일 1GB MSIX 이미지의 요구 사항의 예시를 확인할 수 있습니다.

리소스 요구 사항
안정적인 상태 IOPs 하나의 IOP
머신 부팅 로그인 10 IOPs
대기 시간 400ms

애플리케이션 성능을 최적화하려면 다음을 수행하는 것이 좋습니다.

  • 파일 공유는 세션 호스트와 동일한 Azure 지역에 있어야 합니다. Azure Files를 사용하는 경우 스토리지 계정은 세션 호스트와 동일한 Azure 지역에 있어야 합니다.

  • 애플리케이션을 포함하는 디스크 이미지는 읽기 전용이므로 바이러스 백신 검사에서 제외합니다.

  • 스토리지 및 네트워크 패브릭이 적절한 성능을 제공할 수 있는지 확인합니다. FSLogix 프로필 컨테이너에서 동일한 파일 공유를 사용하지 않아야 합니다.

가용성

Azure Virtual Desktop에 대한 모든 재해 복구 계획은 보조 장애 조치(failover) 위치에 MSIX 앱 연결 파일 공유 복제를 포함해야 합니다. 또한 보조 위치에서 파일 공유 경로에 액세스할 수 있는지 확인해야 합니다. 예를 들어 Azure Files를 이용한 DFS(분산 파일 시스템) 네임스페이스를 사용하여 여러 파일 공유에서 단일 공유 이름을 제공할 수 있습니다. Azure Virtual Desktop용 재해 복구에 대해 자세히 알아보려면 비즈니스 연속성 및 재해 복구 계획 설정을 참조하세요.

Azure 파일

Azure Files에는 루트 디렉터리, 디렉터리 및 파일당 열린 핸들 수에 제한이 있습니다. 앱 연결 또는 MSIX 앱 연결을 사용하는 경우 VHDX 또는 CimFS 디스크 이미지는 세션 호스트의 컴퓨터 계정을 사용하여 탑재됩니다. 즉, 사용자가 아닌 디스크 이미지별로 세션 호스트당 핸들 하나가 열립니다. 제한 및 크기 조정 지침에 대한 자세한 내용은 Azure Files 확장성 및 성능 목표와 Azure Virtual Desktop에 대한 Azure Files 크기 조정 지침을 참조하세요.

MSIX 및 Appx 패키지 인증서

모든 MSIX 및 Appx 패키지에는 유효한 코드 서명 인증서가 필요합니다. 앱 연결과 함께 이러한 패키지를 사용하려면 전체 인증서 체인이 세션 호스트에서 신뢰할 수 있는지 확인해야 합니다. 코드 서명 인증서에는 개체 식별자가 있습니다 1.3.6.1.5.5.7.3.3. 다음에서 패키지에 대한 코드 서명 인증서를 가져올 수 있습니다.

  • 공용 CA(인증 기관)입니다.

  • Active Directory 인증서 서비스와 같은 내부 엔터프라이즈 또는 독립 실행형 인증 기관입니다. 프라이빗 키를 포함하여 코드 서명 인증서를 내보내야 합니다.

  • 자체 서명된 인증서를 생성하는 PowerShell cmdlet New-SelfSignedCertificate와 같은 도구입니다. 테스트 환경에서 자체 서명된 인증서만 사용해야 합니다. MSIX 및 Appx 패키지에 대한 자체 서명된 인증서를 만드는 방법에 대한 자세한 내용은 패키지 서명에 대한 인증서 만들기를 참조하세요.

인증서를 가져온 후에는 인증서를 사용하여 MSIX 또는 Appx 패키지에 디지털 서명을 해야 합니다. MSIX 패키지를 만들 때 MSIX 패키징 도구를 사용하여 패키지에 서명할 수 있습니다. 자세한 내용은 모든 데스크톱 설치 관리자에서 MSIX 패키지 만들기를 참조하세요.

인증서가 세션 호스트에서 신뢰할 수 있도록 하려면 세션 호스트가 전체 인증서 체인을 신뢰해야 합니다. 이 작업을 수행하는 방법은 인증서를 어디서 얻었는지와 세션 호스트 및 사용하는 ID 공급자를 관리하는 방법에 따라 달라집니다. 다음 표에서는 세션 호스트에서 인증서를 신뢰할 수 있도록 하는 방법에 대한 몇 가지 지침을 제공합니다.

  • 공용 CA: 공용 CA의 인증서는 기본적으로 Windows 및 Windows 서버에서 신뢰할 수 있습니다.

  • 내부 엔터프라이즈 CA:

    • AD CS가 내부 엔터프라이즈 CA로 구성되어 Active Directory에 조인된 세션 호스트의 경우 기본적으로 신뢰할 수 있으며 Active Directory Domain Services의 구성 명명 컨텍스트에 저장됩니다. AD CS가 독립 실행형 CA로 구성된 경우 루트 및 중간 인증서를 세션 호스트에 배포하도록 그룹 정책을 구성해야 합니다. 자세한 내용은 그룹 정책을 사용하여 Windows 디바이스에 인증서 배포를 참조하세요.

    • Microsoft Entra ID에 조인된 세션 호스트의 경우 Microsoft Intune을 사용하여 루트 및 중간 인증서를 세션 호스트에 배포할 수 있습니다. 자세한 내용은 Microsoft Intune에 대한 신뢰할 수 있는 루트 인증서 프로필을 참조하세요.

    • Microsoft Entra 하이브리드 조인을 사용하는 세션 호스트의 경우 필요에 따라 이전 방법 중 하나를 사용할 수 있습니다.

  • 자체 서명: 각 세션 호스트의 신뢰할 수 있는 루트 인증 기관 저장소에 신뢰할 수 있는 루트를 설치합니다. 테스트에만 사용되므로 그룹 정책 또는 Intune을 사용하여 이 인증서를 배포하지 않는 것이 좋습니다.

Important

유효성이 인증서의 만료 날짜를 초과할 수 있도록 패키지를 타임스탬프해야 합니다. 그렇지 않은 경우 인증서가 만료되면 패키지를 새 유효한 인증서로 업데이트하고 다시 한 번 세션 호스트에서 신뢰할 수 있는지 확인해야 합니다.

다음 단계

Azure Virtual Desktop에서 앱 연결 애플리케이션을 추가하고 관리하는 방법을 알아봅니다.