Azure Virtual Desktop Classic прекращен: следующие шаги для ИТ

Введение

Вывод Azure Virtual Desktop (классический) создает важное различие между потерей устаревшей службы подключения и продолжающейся доступностью основных ресурсов Azure. Для ИТ-команд, которые пропустили срок миграции, понимание этого различия имеет решающее значение для планирования восстановления без ненужной замены существующей инфраструктуры. Эта статья объясняет, что означает вывод для существующих ресурсов, как идентифицировать классические развертывания, какие варианты миграции остаются достойными оценки и как выбрать поддерживаемую архитектуру доставки приложений.

Что означает, когда Azure Virtual Desktop Classic прекращает свою работу?

Microsoft официально завершил поддержку Azure Virtual Desktop (классический) с 30 сентября 2026 года. Согласно официальной документации Microsoft, "подключения к классическим сервисам будут заблокированы после завершения поддержки." Таким образом, завершение поддержки затрагивает конкретный тип услуг, связанных с управлением виртуальными рабочими столами и приложениями с использованием модели развертывания Azure Virtual Desktop (классический).

Однако процесс вывода из эксплуатации не применяется к современному Azure Virtual Desktop, который использует Azure Resource Manager (ARM). Таким образом, основной проблемой для пользователей, которые все еще используют классические ресурсы, является невозможность установить соединения с ранее работающими сервисами. Поэтому пользователи должны особенно обращать внимание на управление классическими ресурсами, поскольку сами ресурсы не исчезнут после даты вывода из эксплуатации.

Что именно было снято с производства?

Azure Virtual Desktop (классический), ранее известный как Windows Virtual Desktop, имел свою инфраструктуру управления, основанную на специализированных командлетах PowerShell, API и объектах службы.

В отличие от современного Azure Virtual Desktop классические хост-пулы и группы приложений не были определены как единые ресурсы менеджера ресурсов Azure.

Сегодня эти компоненты интегрированы в систему управления ресурсами Azure, позволяя администраторам применять управление доступом на основе ролей Azure (RBAC), управлять сервисом через портал Azure и использовать современные шаблоны инфраструктуры как кода для автоматизации развертывания.

Возможность	AVD Classic (выведен из обращения)	Современный AVD
Управление	Наследуемая управляющая плоскость	Azure Resource Manager
Портал Azure	Ограниченная интеграция	Нативная интеграция
Контроль доступа	Устаревшие роли арендатора	Azure RBAC
Автоматизация	Классические API и PowerShell	ARM, API, Az PowerShell
Доставка рабочего стола и приложений	Подключения заблокированы	Поддерживаемый
Статус службы	Уволенный	Поддерживаемый

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

Современный Azure Virtual Desktop все еще работает?

Да. Современный Azure Virtual Desktop поддерживается и продолжает предлагать полные рабочие столы Windows, многосессионные платформы и доставку отдельных приложений через RemoteApp.

Организации, которые уже используют хост-пулы, интегрированные с Azure Resource Manager (ARM), не затронуты прекращением классического сервиса.

IT-менеджеры также должны обратить внимание на разницу между окончанием поддержки классического Azure Virtual Desktop и отдельным окончанием поддержки старых клиентов Remote Desktop. Клиент Remote Desktop для Windows (MSI) должен был прекратить поддержку для публичных облачных сред 27 марта 2026 года, а для Azure Virtual Desktop (классический) — 28 сентября 2026 года.

Как ИТ-команды могут идентифицировать развертывания Azure Virtual Desktop Classic?

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

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

Проверьте интеграцию Azure Resource Manager

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

Наличие следующих элементов Azure Virtual Desktop является сильным индикатором классического развертывания:

• Хост-пулы, которые используют классический модуль PowerShell Azure Virtual Desktop
• Исторические ссылки на классического арендатора сервиса или классический API сервиса
• Группы приложений, которым не хватает соответствующих ресурсов ARM
• Виртуальные машины хоста сеанса, которые ссылаются на устаревшую документацию

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

Обзор инструментов управления наследием и зависимостями

Скрипты развертывания и репозитории автоматизации могут служить дополнительными источниками доказательств.

Например, наличие скриптов, содержащих ссылки на Microsoft.RDInfra.RDPowerShell или классические операции управления на уровне арендатора, может свидетельствовать о том, что среда была настроена с использованием более старой управленческой платформы.

Современные среды будут использовать интегрированные интерфейсы управления Azure Resource Manager и связанные модули Az PowerShell.

Администраторы также должны провести инвентаризацию всех приложений, пользователей и инфраструктурных ресурсов, связанных с потенциально затронутыми пулами хостов.

Это включает в себя изучение виртуальных машин хостов сеансов, назначений приложений, мест хранения профилей, зависимостей аутентификации, сетевых конфигураций и репозиториев резервного копирования. Документация по ручной миграции Microsoft содержит подробные сравнения между классической моделью объектов службы и интегрированной моделью ресурсов Azure Resource Manager (ARM).

Что может произойти с вашими существующими ресурсами после завершения работы Azure Virtual Desktop Classic?

Самое важное отличие заключается в устаревшей службе подключения и основной инфраструктуре Azure.

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

Существующие виртуальные машины и хранилище могут оставаться доступными

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

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

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

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

Доступ к приложениям и данные пользователей требуют отдельных проверок

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

Результатом прекращения обслуживания может стать потеря доступа к рабочим столам, опубликованным приложениям и сбои в бизнес-процессах.

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

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

Таким образом, перед выводом из эксплуатации или миграцией вовлеченных систем IT-отделы должны убедиться, что они сохранили все необходимые данные.

Команда все еще может мигрировать Azure Virtual Desktop Classic после его завершения?

Microsoft описывает два пути миграции для перехода от Azure Virtual Desktop (классический) к новому интегрированному в ARM Azure Virtual Desktop: автоматическая миграция и ручная миграция.

Обе опции должны были быть жизнеспособными до 30 сентября 2026 года.

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

Документация Microsoft не предоставляет рекомендаций по переходному периоду.

Поэтому организациям не следует полагаться на какие-либо инструменты и процессы перехода после выхода на пенсию.

Опция 1: Автоматическая миграция

Автоматический процесс миграции Microsoft использует инструмент на основе PowerShell для переноса подходящих классических конфигураций служб в ресурсы ARM.

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

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

Однако важно понимать, что инструмент не может гарантировать восстановление данных после выхода из эксплуатации.

Организации с активными классическими развертываниями должны обратиться в службу поддержки Microsoft, чтобы подтвердить, доступен ли процесс миграции для их среды.

Опция 2: Ручная миграция или реконструкция

Ручная миграция требует создания современных ресурсов Azure Virtual Desktop и перенастройки конфигурации сервиса.

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

• Создайте интегрированные хост-пулы на базе ARM, группы приложений и рабочие пространства
• Установите или замените виртуальные машины хоста сеанса
• Зарегистрируйте совместимые хосты сеансов с новыми пулами хостов
• Восстановить связи между пользователем и приложениями
• Настройте параметры идентификации, сети, безопасности и профиля

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

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

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

Решение должно основываться на текущем состоянии существующих ресурсов и доступной поддержке от Microsoft.

Ситуация	Подход к оценке
Подходящая классическая конфигурация и Microsoft подтверждает поддержку миграции	Автоматическая миграция
Сложная или недоступная классическая конфигурация	Ручная реконструкция
Существующие виртуальные машины и данные остаются доступными	Восстановить службы доставки и оценить повторное использование
Наследуемые рабочие нагрузки больше не требуются	Безопасная утилизация
Десктопы, размещенные в Azure, больше не нужны	Альтернативная архитектура доставки

Что должны делать ИТ-команды, если они пропустили срок выхода на пенсию?

Организации, которые не завершат свою миграцию к 30 сентября 2026 года, должны приоритизировать сохранение ресурсов и восстановление доступа к бизнес-приложениям.

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

Шаг 1: Оцените влияние на сервис

Определите, какие пользователи, рабочие столы и приложения недоступны.

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

Шаг 2: Сохранение инфраструктуры и данных

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

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

Шаг 3: Подтвердите параметры восстановления с Microsoft

Свяжитесь с поддержкой Microsoft, чтобы убедиться, что все еще доступны поддерживаемые процедуры миграции/восстановления.

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

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

Шаг 4: Восстановление доставки приложений и рабочего стола

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

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

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

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

Как проверить миграцию Azure Virtual Desktop?

Восстановление инфраструктуры не гарантирует нормальную работу пользователей.

Миграция или реконструкция должны быть подтверждены на уровне сервиса и приложений.

Проверка аутентификации и доступа пользователей

Подтвердите, что пользователи могут аутентифицироваться и получать доступ к ресурсам, которые были им назначены.

Проверьте Microsoft Entra, многофакторную аутентификацию, политики условного доступа и назначения Azure RBAC, если это применимо.

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

Тестирование критически важных бизнес-приложений

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

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

Унаследованные приложения должны быть приняты во внимание, так как они могут требовать специфической конфигурации ОС, сетевого пути или компонента приложения.

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

Проверка профилей, производительности и операций

Компании, которые используют FSLogix или любые другие инструменты профилирования, должны убедиться, что все правильно прикреплено, является постоянным и может быть правильно доступно.

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

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

Стоит ли организациям пересмотреть свою архитектуру доставки рабочего стола?

Вывод Azure Virtual Desktop (классический) в основном является вопросом жизненного цикла платформы, но также предоставляет возможность оценить, поддерживает ли текущая платформа доставки рабочего стола ваши потребности.

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

У других организаций требования менее сложные.

Когда имеет смысл современный виртуальный рабочий стол Azure?

Современный Azure Virtual Desktop может подойти организациям, которым требуется централизованное управление рабочими столами и приложениями Windows, размещенными в Azure.

Это позволяет использовать многосессионные модели RemoteApp, а также инструменты Microsoft ID и администрирования.

Это имеет смысл для предприятий, которые уже имеют присутствие в Azure, но ИТ-отделы все равно должны справляться со сложностями облака, включая лицензирование, сетевое взаимодействие, хранение, администрирование и операционные аспекты.

Когда еще подходит архитектура публикации приложений Windows?

Не все организации требуют полностью реализованной среды виртуализации рабочего стола, размещенной в Microsoft Azure.

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

Эти организации могут рассмотреть возможность публикации приложений, которые размещены на централизованно управляемых серверах Windows, вместо развертывания обобщенной инфраструктуры виртуальных рабочих столов (VDI).

Современный Azure Virtual Desktop — это не только виртуализация рабочих столов или приложений, но и публикация приложений.

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

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

Обсуждение должно сосредоточиться на поиске наиболее подходящей архитектуры доставки приложений для данной организации и случаев использования.

Например, если существует долгоработающее приложение, размещенное в папке Windows Server, к которому имеют доступ группа авторизованных пользователей, организации не нужно публиковать его в Azure Virtual Desktop, когда устаревшая инфраструктура все еще работает должным образом.

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

Какие факторы должны руководить решением?

IT-отделы должны оценить выбор с учетом критериев потребностей в развертывании, а не функций выведенной из эксплуатации системы.

Рассмотрение	Ключевой вопрос
Хостинг	Должны ли рабочие нагрузки выполняться в Azure?
Пользовательский опыт	Полные рабочие столы или выбранные приложения?
Совместимость	Существующие приложения Windows будут работать?
Безопасность	Как защищены идентификация и доступ к сессии?
Управление	Кто поддерживает инфраструктуру?
Лицензирование	Какие лицензии Microsoft и программного обеспечения применяются?
Масштабируемость	Сколько одновременных пользователей требуется?
Стоимость	Какова общая стоимость владения?

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

Ищете альтернативу для доставки приложений и рабочего стола Windows?

Миграция на современный Azure Virtual Desktop не обязательно является лучшим вариантом для каждой организации. Бизнесы, которым в первую очередь нужен доступ к существующим приложениям Windows или централизованным рабочим столам, могут извлечь выгоду из более простой архитектуры, особенно если им не требуется полностью Azure-хостинг виртуальной рабочей среды.

TSplus Удаленный доступ позволяет ИТ-командам публиковать приложения Windows и полные удаленные рабочие столы через совместимые с RDP клиенты или веб-портал HTML5. С поддержкой локальных и облачных серверов Windows, он предлагает практичную альтернативу для организаций, стремящихся сохранить свои существующие приложения, упрощая при этом доставку удаленных приложений.

Заключение

Вывод Azure Virtual Desktop (классический) делает необходимым выявление затронутых развертываний, сохранение существующих ресурсов и восстановление доступа через поддерживаемую инфраструктуру. Команды ИТ должны проверить доступные варианты восстановления перед попыткой миграции или реконструкции.

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