Предварительные требования для Виртуального рабочего стола Azure

  • Статья

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

На высоком уровне вам потребуется:

  • Учетная запись Azure с активной подпиской
  • Поддерживаемый поставщик удостоверений
  • Поддерживаемая операционная система для виртуальных машин узла сеанса
  • соответствующие лицензии;
  • Сетевое соединение
  • клиент удаленного рабочего стола;

учетная запись Azure с активной подпиской.

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

Чтобы развернуть виртуальный рабочий стол Azure, необходимо назначить соответствующие роли управления доступом на основе ролей Azure (RBAC). Требования к конкретной роли рассматриваются в каждой из связанных статей по развертыванию виртуального рабочего стола Azure, которые перечислены в разделе "Дальнейшие действия ".

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

Внимание

Вам нужно получить разрешение на регистрацию поставщика ресурсов. Для этого выполните операцию */register/action. Разрешение входит в подписку, если вашей учетной записи назначена роль участника или владельца.

  1. Войдите на портал Azure.

  2. Выберите Подписки.

  3. Выберите имя подписки.

  4. Выберите параметр Поставщики ресурсов.

  5. Выполните поиск Microsoft.DesktopVirtualization.

  6. Если отображается состояние NotRegistered, выберите элемент Microsoft.DesktopVirtualization и нажмите кнопку Зарегистрировать.

  7. Убедитесь, что для состояния Microsoft.DesktopVirtualization отображается значение Registered.

Идентификация

Чтобы получить доступ к рабочим столам и приложениям с узлов сеансов, пользователям необходимо иметь возможность проходить проверку подлинности. Идентификатор Microsoft Entra — это централизованная облачная служба удостоверений Майкрософт, которая обеспечивает эту возможность. Идентификатор Microsoft Entra всегда используется для проверки подлинности пользователей для виртуального рабочего стола Azure. Узлы сеансов можно присоединить к одному клиенту Microsoft Entra или домену Active Directory с помощью служб домен Active Directory (AD DS) или доменных служб Microsoft Entra, предоставляя вам варианты гибкой конфигурации.

Узлы сеансов

Необходимо присоединить узлы сеансов, предоставляющие настольные компьютеры и приложения в тот же клиент Microsoft Entra, что и пользователи, или домен Active Directory (доменные службы AD DS или Microsoft Entra).

Примечание.

Для Azure Stack HCI можно присоединить только узлы сеансов к домену служб домен Active Directory.

Чтобы присоединить узлы сеансов к идентификатору Microsoft Entra или домену Active Directory, вам потребуются следующие разрешения:

  • Для идентификатора Microsoft Entra требуется учетная запись, которая может присоединить компьютеры к клиенту. Дополнительные сведения см. в разделе "Управление удостоверениями устройств". Дополнительные сведения о присоединении узлов сеансов к идентификатору Microsoft Entra см. в статье Microsoft Entra joined session hosts.

  • Для домена Active Directory требуется учетная запись домена, которая может присоединить компьютеры к вашему домену. Для доменных служб Microsoft Entra необходимо быть членом группы контроллера домена AAD Администратор istrator.

Пользователи

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

  • Если вы используете идентификатор Microsoft Entra с AD DS, необходимо настроить Microsoft Entra Подключение для синхронизации данных удостоверений пользователей между AD DS и Идентификатором Microsoft Entra.
  • Если вы используете идентификатор Microsoft Entra с доменными службами Microsoft Entra, учетные записи пользователей синхронизируются один из способов с идентификатора Microsoft Entra в доменные службы Microsoft Entra. Этот процесс синхронизации выполняется автоматически.

Внимание

Учетная запись пользователя должна существовать в клиенте Microsoft Entra, используемом для виртуального рабочего стола Azure. Виртуальный рабочий стол Azure не поддерживает учетные записи B2B, B2C или личные учетные записи Майкрософт.

При использовании гибридных удостоверений имя пользователя UserPrincipalName (UPN) или идентификатор безопасности (SID) должны совпадать между службами домен Active Directory и идентификатором Microsoft Entra. Дополнительные сведения см. в разделе Поддерживаемые удостоверения и способы проверки подлинности.

Поддерживаемые сценарии идентификации

В следующей таблице перечислены сценарии идентификации, которые сейчас поддерживает Виртуальный рабочий стол Azure:

Сценарии идентификации Узлы сеансов Учетные записи пользователей
Идентификатор Microsoft Entra + AD DS С присоединением к AD DS В microsoft Entra ID и AD DS синхронизированы
Идентификатор Microsoft Entra + AD DS Присоединено к идентификатору Microsoft Entra В microsoft Entra ID и AD DS синхронизированы
Идентификатор Microsoft Entra + Доменные службы Microsoft Entra Присоединено к доменным службам Microsoft Entra В идентификаторе Microsoft Entra и доменных службах Microsoft Entra синхронизированы
Идентификатор Microsoft Entra + Доменные службы Microsoft Entra + AD DS Присоединено к доменным службам Microsoft Entra В microsoft Entra ID и AD DS синхронизированы
Идентификатор Microsoft Entra + Доменные службы Microsoft Entra Присоединено к идентификатору Microsoft Entra В идентификаторе Microsoft Entra и доменных службах Microsoft Entra синхронизированы
Только Microsoft Entra Присоединено к идентификатору Microsoft Entra В идентификаторе Microsoft Entra

Дополнительные сведения о поддерживаемых сценариях идентификации, включая единый вход и многофакторную проверку подлинности, см. в статье "Поддерживаемые удостоверения" и методы проверки подлинности.

Контейнер профилей FSLogix

Чтобы использовать контейнер профиля FSLogix при присоединении узлов сеансов к идентификатору Microsoft Entra ID, необходимо хранить профили в Файлы Azure или Azure NetApp Files, а учетные записи пользователей должны быть гибридными удостоверениями. Эти учетные записи необходимо создать в AD DS и синхронизировать их с идентификатором Microsoft Entra. Дополнительные сведения о развертывании контейнера профилей FSLogix с различными сценариями удостоверений см. в следующих статьях:

Параметры развертывания

При развертывании узлов сеансов необходимо ввести следующие параметры удостоверения:

  • Доменное имя, если используется доменные службы AD DS или Microsoft Entra.
  • учетные данные для присоединения узлов сеансов к домену;
  • подразделение — необязательный параметр, который позволяет размещать узлы сеансов в нужном подразделении во время развертывания.

Внимание

Для учетной записи, используемой для присоединения к домену, нельзя включить многофакторную проверку подлинности (MFA).

Операционные системы и лицензии

У вас есть выбор операционных систем (ОС), которые можно использовать для узлов сеансов для предоставления рабочих столов и приложений. Для обеспечения гибкости пользователей можно использовать разные операционные системы с разными пулами узлов. Мы поддерживаем 64-разрядные операционные системы и номера SKU в следующих таблицах (где поддерживаемые версии и даты соответствуют политике жизненного цикла Майкрософт), а также методы лицензирования, применимые для каждой коммерческой цели:

Операционная система
(только 64-разрядная версия)		 Метод лицензирования
(Внутренние коммерческие цели)		 Метод лицензирования
(Внешние коммерческие цели)
  • Microsoft 365 E3, E5, A3, A5, F3, бизнес премиум, преимущество использования для учащихся;
  • Windows Корпоративная E3, E5;
  • Windows для образовательных учреждений A3, A5.
  • Windows VDA для каждого пользователя
  • Цены на доступ для пользователей путем регистрации подписки Azure.
  • Лицензия на клиентский доступ к службам удаленных рабочих столов (CAL) с Software Assurance (на пользователя или на устройство)
  • Лицензии на подписку пользователей RDS.
  • Лицензия на доступ к подписчику Windows Server 2022 RDS (SAL).

Цены на доступ для пользователей недоступны для операционных систем Windows Server.

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

Внимание

  • Следующие элементы не поддерживаются:

  • Поддержка Windows 7 закончилась 10 января 2023 г.

  • Поддержка Windows Server 2012 R2 закончилась 10 октября 2023 г.

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

Кроме того, для Azure Stack HCI можно использовать образы операционной системы из:

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

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

Для узлов сеансов в Azure Stack HCI необходимо лицензировать и активировать виртуальные машины, используемые перед их использованием с виртуальным рабочим столом Azure. Для активации Windows 10 и Windows 11 Корпоративная нескольких сеансов и Центра обработки данных Windows Server 2022: Azure Edition используйте проверку Azure для виртуальных машин. Для всех других образов ОС (таких как Windows 10 и Windows 11 Корпоративная и других выпусков Windows Server), следует продолжать использовать существующие методы активации. Дополнительные сведения см. в статье "Активация виртуальных машин Windows Server в Azure Stack HCI".

Примечание.

Чтобы обеспечить непрерывную функциональность с помощью последнего обновления системы безопасности, обновите виртуальные машины в Azure Stack HCI до последней накопительной версии к 17 июня 2024 года. Это обновление важно для виртуальных машин для продолжения использования преимуществ Azure. Дополнительные сведения см. в статье "Проверка Azure для виртуальных машин".

Совет

Чтобы упростить права доступа пользователей во время первоначальной разработки и тестирования, виртуальный рабочий стол Azure поддерживает цены на Azure Dev/Test. Если вы развертываете виртуальный рабочий стол Azure в подписке Azure Dev/Test, конечные пользователи могут подключаться к развертыванию без отдельной лицензии для выполнения тестов принятия или предоставления отзывов.

Network

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

Пользователи, подключающиеся к Виртуальному рабочему столу Azure, безопасно устанавливают обратное подключение к службе. Это означает, что вам не нужно открывать входящие порты. Протокол управления передачей (TCP) по умолчанию используется через порт 443, однако RDP Shortpath можно использовать для управляемых сетей и общедоступных сетей, которые устанавливают прямой транспорт на основе протокола пользовательских датаграмм (UDP).

Чтобы успешно развернуть виртуальный рабочий стол Azure, необходимо выполнить следующие требования к сети:

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

  • Убедитесь, что эта виртуальная сеть может подключаться к контроллерам домена и соответствующим DNS-серверам, если вы используете доменные службы AD DS или Microsoft Entra, так как необходимо присоединить узлы сеансов к домену.

  • Узлы и пользователи сеансов должны иметь возможность подключения к службе "Виртуальный рабочий стол Azure". Кроме того, эти подключения используют протокол TCP в порте 443 для определенного списка URL-адресов. Дополнительные сведения см. в статье Список обязательных URL-адресов. Необходимо убедиться, что эти URL-адреса не блокирует сетевая фильтрация или брандмауэр, чтобы ваше развертывание работало правильно и поддерживалось. Если вашим пользователям требуется доступ к Microsoft 365, убедитесь, что узлы сеансов могут подключаться к конечным точкам Microsoft 365.

Учтите также следующие рекомендации:

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

  • Время кругового пути (RTT) при передаче данных из сети клиента в регион Azure, где содержатся пулы узлов, должна составлять менее 150 мс. Воспользуйтесь оценщиком удобства работы, чтобы просмотреть сведения о работоспособности подключения и рекомендуемом регионе Azure. Чтобы оптимизировать производительность сети, мы рекомендуем создавать узлы сеансов в ближайшем к пользователям регионе Azure.

  • Развертывания Брандмауэра Azure для Виртуального рабочего стола Azure помогут вам заблокировать среду и отфильтровать исходящий трафик.

  • Чтобы защитить среду виртуального рабочего стола Azure в Azure, рекомендуется не открывать входящий порт 3389 на узлах сеансов. Для виртуального рабочего стола Azure не требуется открытый входящий порт. Если вам все же нужно открыть порт 3389 для устранения неполадок, мы рекомендуем использоватьJIT-доступ к виртуальным машинам. Мы также рекомендуем не назначать общедоступный IP-адрес узлам сеансов.

Дополнительные сведения см. в статье Общие сведения о сетевом подключении к Виртуальному рабочему столу Azure.

Примечание.

Для обеспечения надежности и масштабируемости Виртуальных рабочих столов Azure мы объединяем шаблоны трафика и использования для проверки работоспособности и производительности уровня управления инфраструктурой. Мы агрегируем эту информацию изо всех расположений, где работает инфраструктура службы, а затем отправляем их в регион США. Данные, отправляемые в регион США, включают в себя очищенные данные, а не данные клиента. Дополнительные сведения см. в статье Расположения данных для Виртуального рабочего стола Azure.

Управление узлом сеанса

При управлении узлами сеансов следует учитывать следующие моменты:

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

  • Если вы присоединяете узлы сеансов к домену AD DS и хотите управлять ими с помощью Intune, необходимо настроить Microsoft Entra Подключение, чтобы включить гибридное соединение Microsoft Entra.

  • При присоединении узлов сеансов к домену доменных служб Microsoft Entra невозможно управлять ими с помощью Intune.

  • Если вы используете присоединение Microsoft Entra к Windows Server для узлов сеансов, их нельзя зарегистрировать в Intune, так как Windows Server не поддерживается в Intune. Необходимо использовать гибридное соединение Microsoft Entra и групповую политику из домена Active Directory или локальной групповой политики на каждом узле сеанса.

Регионы Azure

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

  • Восточная Австралия
  • Центральная Канада
  • Восточная Канада
  • Центральная Индия
  • Центральная часть США
  • Восточная часть США
  • Восточная часть США 2
  • Восточная Япония
  • Центрально-северная часть США
  • Северная Европа
  • Центрально-южная часть США
  • южная часть Соединенного Королевства
  • западная часть Соединенного Королевства
  • центрально-западная часть США
  • Западная Европа
  • Западная часть США
  • западная часть США 2
  • Западная часть США — 3

Виртуальный рабочий стол Azure также доступен в национальных облаках, таких как Azure для государственных организаций США и Azure, управляемых 21Vianet в Китае.

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

Клиенты удаленного рабочего стола

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

Внимание

Виртуальный рабочий стол Azure не поддерживает подключения от клиента подключения к удаленным рабочим столам и приложениям RemoteApp (RADC) или клиента подключения к удаленному рабочему столу (MSTSC).

Чтобы узнать, какие URL-адреса клиенты используют для подключения, которые необходимо разрешить через брандмауэры и фильтры Интернета, см. статью Список требуемых URL-адресов.

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