Поделиться через

Подключение приложений и подключение приложения MSIX в виртуальном рабочем столе Azure

  • Статья

Внимание

Технология присоединения приложений MSIX будет снята с поддержки 1 июня 2025 года. Обязательно переместите все приложения в App Attach до этой даты.

В виртуальном рабочем столе Azure есть две функции, которые позволяют динамически присоединять приложения из пакета приложения к сеансу пользователя в виртуальном рабочем столе Azure — присоединение приложений и подключение приложения MSIX. При использовании как app attach, так и MSIX app attach приложения не устанавливаются локально на узлах сеансов или образах, что упрощает создание пользовательских образов для узлов сеансов и снижает операционные расходы и затраты для вашей организации. Приложения выполняются в контейнерах, которые разделяют данные пользователя, операционную систему и другие приложения, повышая безопасность и упрощая их устранение неполадок.

В следующей таблице сравнивается подключение приложения MSIX с подключением приложения:

Подключение приложений MSIX Подключение приложения
Приложения предоставляются с помощью RemoteApp или в рамках сеанса рабочего стола. Назначение к группам приложений контролирует доступ, однако все пользователи настольных компьютеров видят все приложения MSIX app attach в группе приложений для настольных компьютеров. Приложения предоставляются с помощью RemoteApp или в рамках сеанса рабочего стола. Разрешения применяются для каждого пользователя, что дает более широкий контроль над тем, к каким приложениям пользователи могут обращаться в удаленном сеансе. Пользователи настольных компьютеров видят только те приложения, которые связаны с приложением и назначены им.
Приложения могут выполняться только в одном пуле узлов. Если вы хотите запустить его в другом пуле узлов, необходимо создать другой пакет. Один и тот же пакет приложения можно использовать в нескольких пулах узлов.
Приложения могут выполняться только в пуле узлов, в котором они добавлены. Приложения могут выполняться на любом узле сеансов под управлением клиентской операционной системы Windows в том же регионе Azure, что и пакет приложения.
Чтобы обновить приложение, необходимо удалить и повторно создать приложение с другой версией пакета. Приложение следует обновить в окне обслуживания. Приложения можно обновить до новой версии с новым образом диска без необходимости выделять период для обслуживания.
Пользователи не могут запускать две версии одного приложения на одном узле сеанса. Пользователи могут одновременно запускать две версии одного приложения на одном узле сеанса.
Телеметрия показателей использования и состояния недоступна через Azure Log Analytics. Данные телеметрии, связанные с использованием и работоспособностью, доступны через Azure Log Analytics.

Можно использовать следующие типы пакетов приложения и форматы файлов:

Тип пакета Форматы файлов Доступность функций
Пакет MSIX и набор MSIX .msix
.msixbundle		 Подключение приложений MSIX
Подключение приложения
Пакет Appx и Appx .appx
.appxbundle		 Только подключение приложений
App-V .appv Только присоединение приложения

MSIX и Appx — это форматы пакетов приложений Windows, которые обеспечивают современный интерфейс упаковки для приложений Windows. Приложения выполняются в контейнерах, которые разделяют данные пользователя, операционную систему и другие приложения, повышая безопасность и упрощая их устранение неполадок. MSIX и Appx похожи, где основное различие заключается в том, что MSIX является супермножеством Appx. MSIX поддерживает все функции Appx, а также другие функции, которые делают его более подходящим для корпоративного использования.

Microsoft Application Virtualization (App-V) для Windows предоставляет приложения Win32 пользователям в качестве виртуальных приложений. Виртуальные приложения устанавливаются на централизованно управляемых серверах и доставляются пользователям в качестве службы в режиме реального времени и по мере необходимости. Пользователи запускают виртуальные приложения из знакомых точек доступа и взаимодействуют с ними, как если бы они были установлены локально.

Совет

Нажмите кнопку в верхней части этой статьи, чтобы выбрать между присоединением приложений и подключением приложения MSIX, чтобы просмотреть соответствующую документацию.

Пакеты MSIX можно получить от поставщиков программного обеспечения или создать пакет MSIX из существующего установщика. Дополнительные сведения о MSIX см. в статье "Что такое MSIX?"

Как пользователь получает приложение

Вы можете назначить разные приложения разным пользователям в одном пуле узлов или на одном узле сеанса. Во время входа все три из следующих требований должны быть выполнены для того, чтобы пользователь получил правильное приложение в нужное время:

  • Приложение должно быть назначено хост-пулу. Назначение приложения пулу узлов позволяет быть выборочным в отношении пулов узлов, доступных приложению, чтобы убедиться, что нужные аппаратные ресурсы доступны для использования приложением. Например, если приложение требует интенсивной обработки графики, можно гарантировать, что оно запускается только на пуле узлов с серверами, оптимизированными для GPU.

  • Пользователь должен иметь возможность входа в узлы сеансов в пуле узлов, поэтому они должны находиться в группе приложений Desktop или RemoteApp. Для группы приложений RemoteApp приложение App Attach необходимо добавить в группу приложений, но не нужно добавлять приложение в группу приложений рабочего стола.

  • Приложение должно быть назначено пользователю. Вы можете использовать группу или учетную запись пользователя.

Если выполнены все эти требования, пользователь получает приложение. Этот процесс обеспечивает контроль над тем, кто получает приложение и в каком пуле узлов, а также то, как пользователи в одном пуле узлов или даже те, кто вошел в один и тот же узел мультисессионного хоста, могут получать различные комбинации приложений. Пользователи, которые не соответствуют требованиям, не получают приложение.

Как пользователь получает приложение

Вы можете назначить разные приложения разным пользователям в одном пуле узлов. С помощью функции присоединения приложений MSIX вы добавляете пакеты MSIX в пул узлов и управляете назначением приложений, используя группы приложений для desktop или RemoteApp. Во время входа необходимо выполнить следующие требования, чтобы пользователь получил правильное приложение в нужное время:

  • Пользователь должен иметь возможность входа в хосты сеансов в пуле узлов, поэтому им необходимо быть в группе приложений Desktop или RemoteApp.

  • Образ MSIX должен быть добавлен в пул хостов.

Если эти требования выполнены, пользователь получает приложение. Назначение приложений с помощью группы приложений рабочего стола добавляет их в меню Пуск пользователя. Пользователи, которые не соответствуют требованиям, не получают приложение.

Образы приложений

Прежде чем использовать пакеты приложений MSIX с виртуальным рабочим столом Azure, необходимо создать образ MSIX из существующих пакетов приложений. Кроме того, вместо этого можно использовать пакет App-V. Затем необходимо сохранить каждый образ MSIX или пакет App-V в файловом хранилище, доступном узлами сеансов. Дополнительные сведения о требованиях к общей папке см. в разделе "Общая папка".

Прежде чем использовать пакеты приложений MSIX с виртуальным рабочим столом Azure, необходимо создать образ MSIX из существующих пакетов приложений. Затем необходимо сохранить каждый образ диска в общей папке, которую могут использовать узлы сеансов. Дополнительные сведения о требованиях к общей папке см. в разделе "Общая папка".

Типы образов диска

Для образов дисков MSIX и Appx можно использовать составную файловую систему образов (CimFS), VHDX или VHD, но не рекомендуется использовать VHD. Подключение и отключение образов CimFS быстрее, чем образы VHD и VHDX, а также потребляет меньше ЦП и памяти. Мы рекомендуем использовать CimFS только для образов приложений, если узлы сеансов работают под управлением Windows 11.

Изображение CimFS — это сочетание нескольких файлов: один файл имеет расширение .cim и содержит метаданные, а также как минимум два других файла — один начиная с objectid_, а другой начиная с region_, которые содержат фактические данные приложения. Файлы, сопровождающие .cim файл, не имеют расширения. В следующей таблице приведен список примеров файлов, которые можно найти для образа CimFS:

Имя файла Размер
MyApp.cim 1 КБ
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27 КБ
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20 КБ
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42 КБ
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428 КБ
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217 КБ
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264,132 КБ

В следующей таблице приведено сравнение производительности между VHDX и CimFS. Эти числа были результатом тестового выполнения с 500 файлами в 300 МБ в каждом формате, и тесты были выполнены на виртуальной машине Azure DSv4.

Метрика VHD CimFS
Среднее время монтажа 356 мс 255 мс
Среднее время размонтирования 1615 мс 36 мс
потребление памяти; 6% (из 8 ГБ) 2% (из 8 ГБ)
центральный процессор (всплеск нагрузки) Достигала максимума несколько раз Не влияет

Осторожность

В настоящее время проблема влияет на образы CimFS с Windows 11 версии 24H2, что предотвращает монтирование образов. Мы активно работаем над исправлением, которое, по оценкам, будет доступно в июне 2025 года. Обходные пути: использование образов VHDX или версии Windows 11 до 24H2.

Регистрация приложения

Подключение приложения монтирует образы дисков или пакеты App-V, содержащие ваши приложения, из сетевой папки к сеансу пользователя во время его входа, затем регистрация приложения делает приложения доступными для пользователя. Существует два типа регистрации:

Приложение MSIX монтирует образы дисков, содержащие ваши приложения, из общей папки к сеансу пользователя во время входа в систему, а затем процесс регистрации делает эти приложения доступными для пользователя. Существует два типа регистрации:

  • По запросу: приложения регистрируются только частично при входе и полная регистрация приложения откладывается до тех пор, пока пользователь не запустит приложение. По запросу — это тип регистрации, который рекомендуется использовать, так как он не влияет на время входа в виртуальный рабочий стол Azure. Метод регистрации по умолчанию — "по требованию".

  • Блокировка входа в систему: каждое приложение, назначенное пользователю, полностью зарегистрировано. Регистрация происходит во время входа пользователя в сеанс, что может повлиять на время входа в Виртуальный рабочий стол Azure.

Внимание

Все пакеты приложений MSIX и Appx включают сертификат. Вы несете ответственность за обеспечение доверия сертификатов в вашей среде. Самозаверяющие сертификаты поддерживаются с соответствующей цепочкой доверия.

Подключение приложений не ограничивает количество приложений, которые могут использовать пользователи. Следует учитывать доступную пропускную способность сети и количество открытых дескрипторов на каждый файл (каждый образ), поддерживаемый общей папкой, так как это может ограничить количество пользователей или приложений, которые можно поддерживать. Дополнительные сведения см. в разделе "Общая папка".

Внимание

Все пакеты приложений MSIX включают сертификат. Вы несете ответственность за обеспечение доверия сертификатов в вашей среде. Поддерживаются самозаверяемые сертификаты.

Подключение приложений MSIX не ограничивает количество приложений, которые пользователи могут использовать. Следует учитывать доступную пропускную способность сети и количество открытых дескрипторов на каждый файл (каждый образ), поддерживаемый общей папкой, так как это может ограничить количество пользователей или приложений, которые можно поддерживать. Дополнительные сведения см. в разделе "Общая папка".

Состояние приложения

Пакеты приложений задаются как активные или неактивные. Пакеты, заданные для активного, делают приложение доступным для пользователей. Виртуальный рабочий стол Azure игнорирует пакеты, которые установлены как неактивные и которые не добавляются при входе пользователя.

Пакет MSIX устанавливается как активный или неактивный. Пакеты MSIX, установленные как активные, делают приложение доступным для пользователей. Виртуальный рабочий стол Azure игнорирует пакеты, которые установлены как неактивные и которые не добавляются при входе пользователя.

Новые версии приложений

Вы можете добавить новую версию приложения, предоставив новый образ, содержащий обновленное приложение. Этот новый образ можно использовать двумя способами:

  • Параллельно: создайте приложение с помощью нового образа диска и назначьте его тем же пулам узлов и пользователям, что и существующее приложение.

  • На месте создайте новый образ, в котором изменяется номер версии приложения, а затем обновите существующее приложение, чтобы использовать новый образ. Номер версии может быть выше или ниже, но вы не можете обновить приложение с одинаковым номером версии. Не удаляйте существующий образ, пока все пользователи не завершают его использование.

После обновления пользователи получат обновленную версию приложения при следующем входе. Пользователям не нужно останавливать использование предыдущей версии, чтобы добавить новую версию.

Новые версии приложений

При подключении приложения MSIX необходимо удалить пакет приложения, а затем создать приложение с помощью нового образа диска и назначить его тем же пулам узлов. Вы не можете обновить в режиме реального времени, как это можно сделать с использованием app attach. Пользователи получат новый образ с обновленным приложением при следующем входе. Эти задачи следует выполнять во время периода обслуживания.

Поставщики идентификационных услуг

Ниже приведены поставщики удостоверений, которые можно использовать с присоединением приложения:

Поставщик удостоверений Состояние
Microsoft Entra ID Поддерживается
Доменные службы Active Directory (AD DS) Поддерживается
Доменные службы Microsoft Entra Не поддерживается

Ниже приведены поставщики удостоверений, которые можно использовать с присоединением приложения MSIX:

Поставщик удостоверений Состояние
Microsoft Entra ID Не поддерживается
Доменные службы Active Directory (AD DS) Поддерживается
Доменные службы Microsoft Entra (Azure AD DS) Не поддерживается

Общий доступ к файлам

Присоединение приложений требует, чтобы образы приложений хранились в общей папке SMB, которая затем подключается к каждому узлу сеанса во время входа. У присоединения приложений нет зависимостей от типа структуры хранилища, используемого файловым хранилищем. Мы рекомендуем использовать Файлы Azure, так как она совместима с Microsoft Entra ID или службами Active Directory Domain Services и представляет отличное соотношение между затратами и сложностью управления.

Вы также можете использовать Azure NetApp Files, но для этого требуется, чтобы узлы сеансов были присоединены к службам домен Active Directory.

Подключение приложений MSIX требует, чтобы образы приложений хранились в общей папке SMB версии 3, которая затем подключается к каждому сеансовому хосту во время входа в систему. Подключение приложения MSIX не зависит от типа системы хранения, используемой файловым ресурсом. Мы рекомендуем использовать Файлы Azure, так как они совместимы с поддерживаемыми поставщиками идентичности, которые можно использовать для подключения приложений MSIX, и обеспечивают отличное соотношение между затратами и накладными расходами на управление. Вы также можете использовать Azure NetApp Files, но для этого требуются узлы сеансов, присоединенные к службам домен Active Directory.

В следующих разделах приведены некоторые рекомендации по разрешениям, производительности и доступности, необходимых для файлового обмена.

Разрешения

Каждый хост сеанса монтирует образы приложений из сетевого ресурса. Необходимо настроить разрешения NTFS и общего доступа, чтобы предоставить каждому объекту компьютера узла сеанса доступ для чтения к файлам и общему доступу к файлам. Настройка правильных прав доступа зависит от того, какой поставщик хранилища и поставщик удостоверений используется для общих файлов и узлов сеанса.

  • Чтобы использовать Azure Files при подключении узлов сеансов к Microsoft Entra ID, необходимо назначить роль Reader and Data Access (Чтение и доступ к данным) для управления доступом на основе ролей (RBAC) как виртуальному рабочему столу Azure, так и объектам службы поставщика Azure Virtual Desktop ARM. Это назначение ролей RBAC позволяет серверам сеансов получать доступ к хранилищу с помощью ключей доступа или Microsoft Entra.

  • Чтобы узнать, как назначить роль RBAC для субъектов-служб Azure Виртуальных рабочих столов, см. Назначение ролей RBAC субъектам-службам Azure Виртуальных рабочих столов. В будущем обновлении вам не потребуется назначать служебного принципала для Azure Virtual Desktop ARM Provider.

    Дополнительные сведения об использовании Azure Files с узлами сеансов, присоединенными к Microsoft Entra ID, службам доменов Active Directory или Microsoft Entra Domain Services, см. в разделе Обзор параметров проверки подлинности Azure Files на основе удостоверений для доступа к SMB.

    Предупреждение

    Назначение главного пользователя службы поставщика ARM виртуального рабочего стола Azure учетной записи хранения предоставляет службе Виртуального рабочего стола Azure доступ ко всем данным в учетной записи хранения. Мы рекомендуем хранить только приложения, которые будут использоваться с присоединением приложений в этой учетной записи хранения, и регулярно поворачивать ключи доступа.

  • Для Azure NetApp Files можно создать том SMB и настроить разрешения NTFS для предоставления доступа на чтение к объекту компьютера каждого узла сеанса. Сеансовые узлы должны быть присоединены к службам доменных служб Active Directory или доменным службам Microsoft Entra.

Вы можете проверить правильность разрешений с помощью PsExec. Дополнительные сведения см. в разделе "Проверка доступа к общей папке".

Производительность

Требования могут значительно отличаться в зависимости от количества упакованных приложений, хранящихся в образе, и необходимо протестировать приложения для понимания ваших требований. Для больших образов необходимо выделить больше пропускной способности. В следующей таблице приведен пример требований, необходимых для одного образа размером 1 ГБ или пакета App-V, содержащего одно приложение, для каждого узла сеанса.

Ресурс Требования
Число операций ввода-вывода в секунду в устойчивом состоянии Один IOP
Вход в систему при загрузке компьютера 10 операций ввода-вывода в секунду
Задержка 400 мс

Чтобы оптимизировать производительность приложений, рекомендуется:

  • Общая папка должна находиться в том же регионе Azure, что и сеансовые хосты. Если вы используете Файлы Azure, учетная запись хранения должна находиться в том же регионе Azure, что и узлы сеансов.

  • Исключите образы дисков, содержащие приложения, из антивирусной программы проверки, так как они доступны только для чтения.

  • Убедитесь, что хранилище и сетевая структура могут обеспечить достаточную производительность. Следует избегать использования одной общей папки с контейнерами профилей FSLogix.

Доступность

Любые планы аварийного восстановления для Azure Virtual Desktop должны включать репликацию файлового ресурса в резервное место для переключения при отказе. Необходимо также убедиться, что путь к общей папке доступен в резервной локации. Например, можно использовать пространства имен распределенной файловой системы (DFS) с помощью Azure Files для предоставления единого имени для доступа к разным файл-шарам. Дополнительные сведения о аварийном восстановлении для виртуального рабочего стола Azure см. в статье "Настройка плана непрерывности бизнес-процессов и аварийного восстановления".

Файлы Azure

Файлы Azure имеют ограничения на количество открытых описателей на корневой каталог, каталог и файл. При использовании привязки приложений или привязки приложений MSIX образы дисков VHDX или CimFS монтируются, используя учетную запись компьютера узла сеанса, что означает, что один дескриптор открывается на каждый узел сеанса на образ диска, а не на пользователя. Дополнительные сведения об ограничениях и рекомендациях по размеру см. в разделах целевые показатели масштабируемости и производительности Azure Files и рекомендации по размеру для Azure Virtual Desktop.

Сертификаты пакетов MSIX и Appx

Для всех пакетов MSIX и Appx требуется действительный сертификат подписи кода. Чтобы использовать эти пакеты с функцией подключения приложений, необходимо убедиться, что вся цепочка сертификатов является доверенной на всех узлах сеансов. Сертификат подписи кода имеет идентификатор 1.3.6.1.5.5.7.3.3объекта. Вы можете получить сертификат подписи кода для пакетов:

  • Общедоступный центр сертификации (ЦС).

  • Внутренний корпоративный или автономный центр сертификации, например службы сертификатов Active Directory. Необходимо экспортировать сертификат подписи кода, включая его закрытый ключ.

  • Средство, такое как командлет PowerShell New-SelfSignedCertificate, которое создает самоподписанный сертификат. В тестовой среде следует использовать только самозаверяемые сертификаты. Дополнительные сведения о создании самозаверяющего сертификата для пакетов MSIX и Appx см. в статье "Создание сертификата для подписывания пакета".

После получения сертификата необходимо цифрово подписать пакеты MSIX или Appx с помощью сертификата. Вы можете использовать Средство упаковки MSIX для подписывания своих пакетов при создании пакета MSIX. Дополнительные сведения см. в разделе "Создание пакета MSIX" из любого классического установщика.

Чтобы убедиться, что сертификат является доверенным на узлах сеансов, необходимо, чтобы узлы сеансов доверяли всей цепочке сертификатов. Как узлы сеансов доверяют цепочке сертификатов, зависит от того, откуда вы получили сертификат, как вы управляете узлами сеансов и используемого вами поставщика удостоверений. В следующей таблице приведены некоторые рекомендации по обеспечению доверия сертификата на узлах сеансов:

  • Общедоступный ЦС: сертификаты из общедоступного ЦС по умолчанию являются доверенными в Windows и Windows Server.

  • Внутренний корпоративный центр сертификации

    • Для узлов сеансов, входящих в состав Active Directory, где AD CS настроен как внутренний корпоративный ЦС, по умолчанию доверяют и хранят в контексте именования конфигурации доменных служб Active Directory. Если служба AD CS настроена как автономный ЦС, необходимо настроить групповую политику для распространения корневых и промежуточных сертификатов на узлы сеансов. Дополнительные сведения см. в статье "Распространение сертификатов на устройствах Windows с помощью групповой политики".

    • Для узлов сеансов, присоединенных к идентификатору Microsoft Entra, можно использовать Microsoft Intune для распространения корневых и промежуточных сертификатов на узлы сеансов. Для получения дополнительных сведений см. профили доверенных корневых сертификатов для Microsoft Intune.

    • Для хостов сеансов, использующих гибридное соединение Microsoft Entra, можно использовать любой из предыдущих методов, в зависимости от ваших требований.

  • Самоподписанный: установите доверенный корень в хранилище доверенных корневых центров сертификации на каждом сеансовом хосте. Мы не рекомендуем распространять этот сертификат с помощью групповой политики или Intune, так как его следует использовать только для тестирования.

Внимание

Необходимо добавить метку времени к вашему пакету, чтобы его срок действия продлевался после истечения срока действия сертификата. В противном случае после истечения срока действия сертификата необходимо обновить пакет с новым действительным сертификатом и еще раз убедиться, что узлы сеансов доверяют цепочке сертификатов.

Следующие шаги

Узнайте, как добавлять и управлять приложениями с привязкой в службе виртуального рабочего стола Azure.