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 cmdlets, APIs и обекти на услугата.

За разлика от съвременния Azure Virtual Desktop, класическите хост пулове и групи приложения не бяха определени като обединени ресурси на Azure Resource Manager.

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

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

Пенсионирането представлява промяна в основната архитектура на услугата, а не просто преименуване на продукта.

Работи ли все още Modern 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?

Първата стъпка е да се установи дали някои производствени натоварвания все още зависят от retired архитектурата.

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

Проверете интеграцията на 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 бъде прекратен?

Най-важната разлика е между retired connection service и underlying Azure infrastructure.

Докато класическите десктоп връзки са блокирани, съществуващите виртуални машини, ресурси за съхранение и данни за приложения могат да останат на място.

Съществуващите виртуални машини и хранилища може да останат налични

Azure виртуални машини са ресурси, които се управляват самостоятелно, без да разчитат на остарялата класическа контролна платформа за услуги. Така че виртуалните машини на хостовете на сесии, управляваните дискове и мрежовите ресурси, които са създадени в абонамента, все още могат да съществуват.

Въпреки това, те не могат да се използват за възстановяване на оттегления брокер на връзки. Няма виртуални машини, създадени в новата инфраструктура на Azure, които да върнат работния опит на организацията в нормално състояние.

Администраторите трябва внимателно да прегледат всеки ресурс и, ако може да бъде повторно използван за поддържана конфигурация, те трябва да извършат следните стъпки.

Необходимо е да се провери дали операционната система на виртуалната машина е поддържана и дали приложенията и конфигурациите за сигурност са съвместими.

Достъп до приложения и потребителски данни изискват отделни проверки

Потребителите, които са се свързали чрез класическия десктоп или тип сесия RemoteApp, вече няма да могат да стартират своите приложения чрез тази услуга.

Резултатът от прекратяването на услугата може да бъде загуба на достъп до десктопи, публикувани приложения и прекъсвания на бизнес процесите.

Въпреки това, прекратяването на услугата не гарантира, че данните, свързани с потребителя, ще бъдат изтрити.

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

Поради това, преди да се изключат или мигрират засегнатите системи, ИТ отделите трябва да се уверят, че са запазили всички необходими данни.

Може ли екипът все още да мигрира 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 г., трябва да приоритизират запазването на ресурси и възстановяването на достъпа до бизнес приложения.

Вместо да се опитват да направят множество връзки към retired service, администраторите се съветват да извършат процес на възстановяване.

Стъпка 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 Virtual Desktop?

Модерен 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, когато наследствената инфраструктура все още работи правилно.

Вместо това, може да бъде полезно за такива предприятия да оставят местоположението на хостинга на своето приложение на място, докато обновяват метода за достъп до приложението си.

Какви фактори трябва да ръководят решението?

ИТ отделите трябва да оценят избора спрямо критериите за нуждите от внедряване, а не спрямо характеристиките на деактивираната система.

Съображение	Ключов въпрос
Хостинг	Трябва ли работните натоварвания да работят в Azure?
Потребителски опит	Пълни десктопи или избрани приложения?
Съвместимост	Ще работят ли съществуващите приложения за Windows?
Сигурност	Как се защитават идентичността и достъпът до сесията?
Управление	Кой поддържа инфраструктурата?
Лицензиране	Кои лицензи на Microsoft и софтуер са приложими?
Мащабируемост	Колко едновременни потребители са необходими?
Цена	Каква е общата цена на притежание?

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

Търсите алтернатива за доставка на приложения и работен плот за Windows?

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

TSplus Remote Access позволява на ИТ екипите да публикуват Windows приложения и пълни дистанционни работни плотове чрез RDP-съвместими клиенти или HTML5 уеб портал. С поддръжка за локални и облачно хоствани Windows сървъри, предлага практична алтернатива за организации, които искат да запазят съществуващите си приложения, докато опростяват доставката на дистанционни приложения.

Заключение

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

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