تم إيقاف تشغيل Azure Virtual Desktop Classic: الخطوات التالية لتكنولوجيا المعلومات

مقدمة

تقاعد Azure Virtual Desktop (الكلاسيكي) يخلق تمييزًا مهمًا بين فقدان خدمة الاتصال القديمة واستمرار توفر موارد Azure الأساسية. بالنسبة لفرق تكنولوجيا المعلومات التي فاتتها مهلة الهجرة، فإن فهم هذا التمييز أمر أساسي للتخطيط للتعافي دون استبدال البنية التحتية الحالية بشكل غير ضروري. يشرح هذا المقال ما يعنيه التقاعد للموارد الحالية، وكيفية تحديد النشر الكلاسيكي، وما هي خيارات الهجرة التي لا تزال تستحق التقييم، وكيفية اختيار بنية توصيل التطبيقات المدعومة.

ماذا يعني عندما يتقاعد Azure Virtual Desktop Classic؟

أعلنت مايكروسوفت رسميًا عن إيقاف خدمة Azure Virtual Desktop (الكلاسيكي) اعتبارًا من 30 سبتمبر 2026. بناءً على الوثائق الرسمية لمايكروسوفت، "سيتم حظر الاتصالات بالخدمات الكلاسيكية بعد الإيقاف." لذلك، يؤثر الإيقاف على نوع معين من الخدمات المتعلقة بإدارة أجهزة الكمبيوتر الافتراضية والتطبيقات باستخدام نموذج نشر Azure Virtual Desktop (الكلاسيكي).

ومع ذلك، فإن عملية التقاعد لا تنطبق على سطح المكتب الافتراضي الحديث في Azure الذي يستخدم مدير موارد Azure (ARM). وبالتالي، فإن القلق الرئيسي للمستخدمين الذين لا يزالون يستخدمون الموارد الكلاسيكية هو عدم القدرة على إنشاء اتصالات بالخدمات التي كانت تعمل سابقًا. لذلك، يجب أن يكون المستخدمون على دراية خاصة بإدارة الموارد الكلاسيكية حيث إن الموارد نفسها لن تختفي بعد تاريخ التقاعد.

ما الذي تم إحالته بالتحديد؟

سطح المكتب الافتراضي Azure (الكلاسيكي)، المعروف سابقًا باسم سطح المكتب الافتراضي Windows، كان لديه بنية إدارة تعتمد على cmdlets PowerShell المخصصة، وواجهات برمجة التطبيقات، وكائنات الخدمة.

على عكس Azure Virtual Desktop الحديثة، لم يتم تعريف مجموعات المضيفين الكلاسيكية ومجموعات التطبيقات كموارد موحدة لإدارة موارد Azure.

اليوم، يتم دمج هذه المكونات في نظام إدارة موارد Azure مما يسمح للمسؤولين بتطبيق التحكم في الوصول القائم على الأدوار في Azure (RBAC)، وإدارة الخدمة من خلال بوابة Azure، واستخدام أنماط البنية التحتية ككود الحديثة لأتمتة النشر.

قدرة	AVD كلاسيك (متقاعد)	AVD الحديثة
إدارة	طائرة التحكم القديمة	مدير موارد Azure
بوابة Azure	تكامل محدود	التكامل الأصلي
تحكم الوصول	أدوار المستأجرين القديمة	أزور RBAC
التلقائيّة	واجهات برمجة التطبيقات الكلاسيكية وPowerShell	ARM، واجهات برمجة التطبيقات، أزور باور شيل
توصيل سطح المكتب والتطبيقات	الاتصالات محظورة	مدعوم
حالة الخدمة	متقاعد	مدعوم

يمثل التقاعد تغييرًا في بنية الخدمة الأساسية، وليس مجرد إعادة تسمية للمنتج.

هل لا يزال يعمل سطح المكتب الافتراضي الحديث من Azure؟

نعم. يتم دعم Azure Virtual Desktop الحديث ويستمر في تقديم أجهزة سطح مكتب Windows كاملة، ومنصات متعددة الجلسات، وتوصيل التطبيقات الفردية من خلال RemoteApp.

المنظمات التي تستخدم بالفعل تجمعات المضيفين المدمجة مع Azure Resource Manager (ARM) لن تتأثر بإيقاف الخدمة الكلاسيكية.

يجب على مديري تكنولوجيا المعلومات أيضًا ملاحظة الفرق بين انتهاء الدعم لسطح المكتب الافتراضي الكلاسيكي من Azure وانتهاء الدعم المنفصل لعملاء سطح المكتب البعيد الأقدم. كان من المقرر أن يصل عميل سطح المكتب البعيد لنظام Windows (MSI) إلى نهاية الدعم لبيئات السحابة العامة في 27 مارس 2026، ولسطح المكتب الافتراضي من Azure (الكلاسيكي) في 28 سبتمبر 2026.

كيف يمكن لفرق تكنولوجيا المعلومات تحديد نشرات Azure Virtual Desktop Classic؟

الخطوة الأولى هي تحديد ما إذا كانت أي أحمال إنتاج لا تزال تعتمد على البنية التحتية المتقاعدة.

هذا أمر بالغ الأهمية بشكل خاص للأنظمة التي تم تشغيلها في الإنتاج منذ سنوات وقد تكون قد استحوذ عليها مسؤولون جدد أو تم تجاهلها في وثائق البنية التحتية الحالية.

تحقق من تكامل Azure Resource Manager

يجب أن تبدأ بفحص موارد Azure Virtual Desktop في بوابة Azure. تكشف عمليات نشر Azure Virtual Desktop الحديثة عن مجموعات المضيفين، ومجموعات التطبيقات، ومساحات العمل كموارد Azure في اشتراك ومجموعة موارد. بالمقابل، كانت عمليات النشر الكلاسيكية تستخدم لكشف كائنات الخدمة المدارة بطرق مختلفة.

تعتبر وجود العناصر التالية من Azure Virtual Desktop مؤشراً قوياً على نشر تقليدي:

• تجمعات المضيفين التي تستخدم وحدة PowerShell الكلاسيكية لـ Azure Virtual Desktop
• الإشارات التاريخية إلى مستأجر خدمة كلاسيكية أو واجهة برمجة تطبيقات خدمة كلاسيكية
• مجموعات التطبيقات التي تفتقر إلى موارد ARM المقابلة
• آلات افتراضية لمضيف الجلسة تشير إلى وثائق أقدم

في الوقت نفسه، فإن عدم وجود مجموعة مضيفين في بوابة Azure ليس بالضرورة دليلاً على نشر تقليدي. يجب عليك دائمًا التحقق من الاشتراك، وموظف Microsoft Entra، والتحكم في الوصول القائم على الدور الذي يمتلكه المستخدم قبل أن تحلل المشكلة بشكل أعمق.

مراجعة أدوات إدارة التراث والاعتماديات

قد تعمل سكريبتات النشر ومستودعات الأتمتة كمصادر إضافية للأدلة.

على سبيل المثال، وجود سكربتات تحتوي على مراجع Microsoft.RDInfra.RDPowerShell أو عمليات إدارة على مستوى المستأجر التقليدية قد يشير إلى أن البيئة تم تكوينها باستخدام مجموعة الإدارة القديمة.

ستستفيد البيئات الحديثة من واجهات إدارة متكاملة مع Azure Resource Manager ووحدات Az PowerShell المرتبطة بها.

يجب على المسؤولين أيضًا جرد جميع التطبيقات وموارد المستخدم والبنية التحتية المرتبطة بمجموعات المضيفين التي قد تتأثر.

يشمل ذلك فحص الأجهزة الافتراضية لمضيف الجلسة، وتعيينات التطبيقات، ومواقع تخزين الملفات الشخصية، واعتماديات المصادقة، وتكوينات الشبكات، ومستودعات النسخ الاحتياطي. وثائق ترحيل يدوي من مايكروسوفت يحتوي على مقارنات مفصلة بين نموذج كائن الخدمة الكلاسيكية ونموذج الموارد المتكامل مع Azure Resource Manager (ARM).

ماذا يمكن أن يحدث لمواردك الحالية بعد انتهاء دعم Azure Virtual Desktop Classic؟

أهم فرق هو بين خدمة الاتصال المتقاعدة والبنية التحتية الأساسية لـ Azure.

بينما يتم حظر اتصالات سطح المكتب الكلاسيكية، يمكن أن تظل الآلات الافتراضية الحالية وموارد التخزين وبيانات التطبيقات في مكانها.

قد تظل الآلات الافتراضية والتخزين الحالية متاحة

تعد أجهزة Azure الافتراضية موارد تُدار بشكل مستقل، دون الاعتماد على وحدة التحكم في الخدمة الكلاسيكية المتقاعدة. وبالتالي، قد لا تزال توجد أجهزة افتراضية مضيفة للجلسات، وأقراص مُدارة، وموارد الشبكات التي تم إنشاؤها في الاشتراك.

ومع ذلك، لا يمكن استخدامها لاستعادة وسيط الاتصال المتقاعد. لا توجد آلات افتراضية تم إنشاؤها في بنية Azure التحتية الجديدة متاحة لإعادة تجربة سطح المكتب الخاصة بالمنظمة إلى الحالة العملية.

يجب على المسؤولين فحص كل مورد بعناية، وإذا كان يمكن إعادة استخدامه لتكوين مدعوم، يجب عليهم تنفيذ الخطوات التالية.

من الضروري التحقق مما إذا كان نظام التشغيل للآلة الافتراضية مدعومًا وإذا كانت التطبيقات وتكوينات الأمان متوافقة.

يتطلب الوصول إلى التطبيقات وبيانات المستخدمين فحوصات منفصلة

لن يتمكن المستخدمون الذين اتصلوا عبر نوع جلسة سطح المكتب الكلاسيكي أو RemoteApp من تشغيل تطبيقاتهم من خلال هذه الخدمة بعد الآن.

قد يؤدي إنهاء الخدمة إلى فقدان الوصول إلى أجهزة الكمبيوتر المكتبية، والتطبيقات المنشورة، واضطرابات في العمليات التجارية.

ومع ذلك، فإن إنهاء الخدمة لا يضمن حذف البيانات المتعلقة بالمستخدم.

في معظم الحالات، من المحتمل أن تكون بيانات المستخدمين محفوظة على Azure Files أو أقراص VM أو وسائط تخزين أخرى، لكن الاحتفاظ بهذه المعلومات وإمكانية الوصول إليها سيكون بناءً على كيفية تكوينها وتأمينها بالأذونات، والنسخ الاحتياطي، وما إلى ذلك...

لذلك، قبل إيقاف تشغيل الأنظمة المعنية أو ترحيلها، تحتاج إدارات تكنولوجيا المعلومات إلى التأكد من أنها قد حافظت على جميع البيانات الضرورية.

هل لا يزال بإمكان الفريق ترحيل Azure Virtual Desktop Classic بعد انتهاء صلاحيته؟

توثق Microsoft مسارين للهجرة للانتقال من Azure Virtual Desktop (الكلاسيكي) إلى Azure Virtual Desktop الجديد المدمج مع ARM: الهجرة التلقائية والهجرة اليدوية.

كان من المقرر أن تكون كلا الخيارين قابلة للتطبيق حتى 30 سبتمبر 2026.

نظرًا لأن هذا التاريخ في الماضي، يجب على المسؤولين عدم اعتبار الأدوات الموصوفة في الوثائق جاهزة للإنتاج لجميع السيناريوهات.

لا توفر وثائق Microsoft إرشادات حول فترة الانتقال.

لذلك، يجب على المنظمات ألا تعتمد على أي أدوات وعمليات انتقال بعد التقاعد.

الخيار 1: الهجرة التلقائية

عملية الترحيل التلقائية من مايكروسوفت يستخدم أداة تعتمد على PowerShell لنقل تكوينات الخدمة الكلاسيكية المؤهلة إلى موارد ARM.

توفر وثائق الشركة توصيات بأن يكون لدى المستخدمين اشتراك نشط في Azure مع الأذونات اللازمة وتلبية متطلبات البيئة المدرجة بواسطة وحدة الهجرة.

على سبيل المثال، تقترح إرشادات Microsoft أن يتم منح المستخدمين أذونات المساهم لإنشاء موارد Azure وأذونات مسؤول وصول المستخدم لإدارة عضوية مجموعة التطبيقات.

ومع ذلك، من الضروري الاعتراف بأن الأداة لا يمكنها ضمان استعادة البيانات بعد التقاعد.

يجب على المؤسسات التي لديها نشر كلاسيكي نشط استشارة دعم Microsoft لتأكيد ما إذا كانت عملية الترحيل خيارًا متاحًا لبيئتها.

الخيار 2: الهجرة اليدوية أو إعادة البناء

يتطلب الترحيل اليدوي إنشاء موارد Azure Virtual Desktop الحديثة وإعادة تكوين إعدادات الخدمة.

اعتمادًا على الحالة المحددة، قد يحتاج المسؤولون إلى:

• إنشاء مجموعات مضيفين قائمة على ARM، ومجموعات تطبيقات، ومساحات عمل
• إنشاء أو استبدال آلات افتراضية لمضيف الجلسة
• تسجيل مضيفي الجلسات المتوافقة مع مجموعات المضيفين الجديدة
• إعادة إنشاء ارتباطات المستخدم والتطبيقات
• تعديل الهوية والشبكة والأمان وإعدادات الملف الشخصي

تصبح الطريقة اليدوية ضرورية عندما تحتوي التكوينات القديمة على تعقيد غير موثق، أو تخصيص واسع النطاق، أو عندما تثبت أدوات الهجرة الحديثة أنها غير كافية.

من الجدير بالذكر أن إعادة بناء بنية التوصيل لا تتطلب دائمًا استبدالًا كاملاً للتطبيقات والبيانات.

يمكن غالبًا إعادة استخدام المكونات المتبقية من خلال تقييمات التوافق المناسبة، وتقييمات الترخيص، وعمليات تدقيق الأمان.

يجب أن يستند القرار إلى الحالة الحالية للموارد الموجودة والدعم المتاح من Microsoft.

الوضع	نهج للتقييم
تكوين كلاسيكي مؤهل ومايكروسوفت تؤكد دعم الهجرة	الهجرة التلقائية
تكوين كلاسيكي معقد أو غير قابل للوصول	إعادة البناء اليدوي
تظل الأجهزة الافتراضية والبيانات الحالية متاحة	إعادة بناء خدمات التسليم وتقييم إعادة الاستخدام
لم تعد الأحمال القديمة مطلوبة	إيقاف آمن
لم تعد أجهزة الكمبيوتر المكتبية المستضافة على Azure ضرورية	بنية تسليم بديلة

ماذا يجب أن تفعل فرق تكنولوجيا المعلومات إذا فاتتهم مهلة التقاعد؟

يجب على المنظمات التي لم تكمل هجرتها بحلول 30 سبتمبر 2026 أن تعطي الأولوية للحفاظ على الموارد واستعادة الوصول إلى تطبيقات الأعمال.

بدلاً من محاولة إجراء اتصالات متعددة بالخدمة المتوقفة، يُنصح المسؤولون بتنفيذ عملية استرداد.

الخطوة 1: تقييم تأثير الخدمة

حدد المستخدمين وأجهزة الكمبيوتر والتطبيقات غير المتاحة.

اكتشف ما إذا كانت بيئة كاملة أو أحمال عمل محددة هي المتأثرة. تأكد من أن المشكلة تتعلق بتقاعد كلاسيكي وليس بمشكلة أخرى تتعلق بالمصادقة أو الشبكات أو مضيف الجلسة.

الخطوة 2: الحفاظ على البنية التحتية والبيانات

راجع اشتراكات Azure لتحديد الآلات الافتراضية الحالية، والأقراص المدارة، وحسابات التخزين، وموارد الشبكة

اعتماد المستندات وضمان نسخ احتياطية توجد قبل اتخاذ أي إجراء. لا تقم بحذف الموارد حتى يتم تحديد بيانات التطبيق وملفات تعريف المستخدم ومعلومات التكوين.

الخطوة 3: تأكيد خيارات الاسترداد مع Microsoft

اتصل بدعم Microsoft للتأكد من أن هناك إجراءات ترحيل/استرداد مدعومة لا تزال متاحة.

تم تطوير تعليمات الترحيل التلقائي/اليدوي الأولية مع مراعاة تاريخ التقاعد، وبالتالي لا ينبغي افتراض أنها تنطبق.

في حالة عدم إمكانية ترحيل التكوين الكلاسيكي، قد يكون من الضروري إعادة بناء البيئة باستخدام موارد Azure Virtual Desktop المدعومة.

الخطوة 4: استعادة تطبيقات وتوصيل سطح المكتب

اختر بنية تدعم التطبيقات وسطح المكتب التي يحتاجها المستخدمون.

للمؤسسات التي تخطط للبقاء على Azure Virtual Desktop، يتضمن ذلك عادةً إعداد مجموعات المضيفين المتكاملة مع ARM، والمضيفين المدعومين للجلسات، ومجموعات التطبيقات، وتعيينات المستخدمين.

قد تجد بعض المنظمات أن هناك أخرى نشر التطبيقات أو أن حل سطح المكتب يناسب احتياجاتهم بشكل أفضل.

الهدف هو إعادة تأسيس الوصول مع تجنب التعقيد والأعباء غير الضرورية للإعداد السابق.

ما هي الطريقة للتحقق من هجرة سطح المكتب الافتراضي Azure؟

استعادة البنية التحتية لا تضمن العمليات العادية للمستخدمين.

يجب بالتالي التحقق من صحة الهجرة أو إعادة البناء على مستوى الخدمة والتطبيق.

تحقق من المصادقة والوصول إلى المستخدم

أكد أن المستخدمين يمكنهم المصادقة والوصول إلى الموارد التي تم تعيينها لهم.

تحقق من Microsoft Entra، المصادقة متعددة العوامل، سياسات الوصول المشروط وتعيينات Azure RBAC حسب الاقتضاء.

يجب على المسؤولين التأكد من أن الأذونات متوافقة مع مبدأ الحد الأدنى من الامتيازات وأنه لا توجد أنماط وصول قديمة تم نقلها عن غير قصد.

اختبار التطبيقات الحيوية للأعمال

اختبر التطبيقات المكتبية المنشورة وسطح المكتب من خلال استخدام حسابات مستخدمين تمثيلية مميزة.

يجب أن تشمل أنشطة التحقق إطلاق التطبيق، اتصالات قاعدة البيانات، المشاركة عبر الشبكة، الطباعة، إعادة توجيه الحافظة، والأجهزة الطرفية المطلوبة إن وجدت.

يجب أخذ التطبيقات القديمة بعين الاعتبار بشكل خاص لأنها قد تتطلب تكوين نظام تشغيل محدد، أو مسار شبكة، أو مكون تطبيق.

قد يكون مثال على تطبيق قديم هو تطبيق ERP الذي يتم تشغيله بنجاح ولكنه يفشل في الاتصال بقاعدة بياناته من مضيف الجلسة الجديد.

تحقق من الملفات الشخصية والأداء والعمليات

يجب على الشركات التي تستخدم FSLogix أو أي من أدوات التوصيف الأخرى التأكد من أن كل شيء متصل بشكل صحيح، ومستمر، ويمكن الوصول إليه بشكل صحيح.

من الضروري اختباره من خلال تسجيل الدخول للمرة الأولى والتحقق مما إذا كان كل شيء سيعمل بشكل جيد عندما يفتح المستخدم تطبيقًا وأثناء تسجيل الدخول التالي. من الضروري أيضًا التأكد من أن العمليات تتم مراقبتها، ونسخها احتياطيًا، واستعادتها.

الهجرة مكتملة فقط عندما يكون كل شيء جاهزًا، بما في ذلك قدرة المستخدمين على الوصول إلى تطبيقاتهم. يجب أن يكون من الممكن الحفاظ على النظام بشكل صحيح.

هل يجب على المؤسسات إعادة النظر في بنية تسليم سطح المكتب الخاصة بها؟

تقاعد Azure Virtual Desktop (الكلاسيكي) هو في الأساس قضية دورة حياة المنصة، ولكنه يقدم أيضًا فرصة لتقييم ما إذا كانت منصة تسليم سطح المكتب الحالية لا تزال تدعم احتياجاتك.

التحول إلى Azure Virtual Desktop الحديث هو الخيار الواضح للعديد، وخاصة أولئك الذين يعتمدون بالفعل على Azure ويستخدمون أجهزة سطح المكتب المستضافة على Azure.

تتمتع المنظمات الأخرى بمتطلبات أقل تعقيدًا.

متى يكون استخدام سطح المكتب الافتراضي الحديث من Azure منطقيًا؟

سطح المكتب الافتراضي الحديث في Azure قد تكون مناسبة للمنظمات التي تتطلب إدارة مركزية لسطح المكتب والتطبيقات على نظام Windows، المستضافة على Azure.

يتيح نماذج متعددة الجلسات وRemoteApp وأدوات إدارة ومعرف Microsoft.

من المنطقي بالنسبة للمؤسسات التي لديها وجود سابق في Azure، ولكن لا تزال إدارات تكنولوجيا المعلومات مضطرة للتعامل مع تعقيدات السحابة، بما في ذلك الترخيص، والشبكات، والتخزين، والإدارة، والجوانب التشغيلية.

متى يكون نشر تطبيقات ويندوز آخر مناسبًا؟

ليس كل المؤسسات تتطلب بيئة افتراضية مكتبية مُنفذة بالكامل مستضافة في Microsoft Azure.

بعض المؤسسات تحتاج فقط إلى محدود الوصول عن بعد إلى تطبيقات Windows محددة، مثل التطبيقات المالية أو تطبيقات تخطيط موارد المؤسسات أو التطبيقات القديمة الخاصة بالعمل.

يمكن لهذه المنظمات أن تفكر في نشر التطبيقات التي تستضيفها خوادم ويندوز المدارة مركزيًا بدلاً من نشر بنية تحتية عامة لسطح المكتب الافتراضي (VDI).

سطح المكتب الافتراضي الحديث من Azure لا يتعلق فقط بvirtualization سطح المكتب أو التطبيقات، بل يتعلق أيضًا بنشر التطبيقات.

اليوم، من الممكن نشر تطبيقات Azure باستخدام طريقة RemoteApp.

الواقع هو أنه لا يوجد انقسام في مجال توصيل التطبيقات، بل هناك استمرارية تمتد من نشر التطبيقات إلى افتراضية سطح المكتب.

يجب أن تركز المناقشة على إيجاد بنية تسليم التطبيقات الأكثر ملاءمة للمنظمة المعنية وحالات الاستخدام.

على سبيل المثال، إذا كان هناك تطبيق قديم مستضاف في مجلد خادم ويندوز يتم الوصول إليه من قبل مجموعة من المستخدمين المصرح لهم، فلا تحتاج المنظمة إلى نشره في Azure Virtual Desktop عندما تكون البنية التحتية القديمة لا تزال تعمل بشكل صحيح.

بدلاً من ذلك، قد يكون من المفيد لهذه المؤسسات ترك موقع استضافة تطبيقاتها في الموقع أثناء ترقية طريقة وصولهم إلى التطبيق.

ما العوامل التي يجب أن توجه القرار؟

يجب على إدارات تكنولوجيا المعلومات تقييم الاختيار بناءً على معايير احتياجات النشر، بدلاً من ميزات النظام الذي تم إيقافه.

اعتبار	السؤال الرئيسي
استضافة	هل يجب أن تعمل الأحمال في Azure؟
تجربة المستخدم	هل تريد أجهزة سطح المكتب الكاملة أم التطبيقات المحددة؟
التوافق	هل ستعمل تطبيقات Windows الحالية؟
الأمان	كيف يتم حماية الهوية والوصول إلى الجلسة؟
إدارة	من يقوم بصيانة البنية التحتية؟
ترخيص	ما هي تراخيص Microsoft والبرامج التي تنطبق؟
التوسعية	كم عدد المستخدمين المتزامنين المطلوبين؟
التكلفة	ما هو إجمالي تكلفة الملكية؟

الغرض هو اختيار بنية مؤسسية تلبي متطلبات التوافر والأمان وتقليل التعقيد الإداري.

هل تبحث عن بديل لتوصيل تطبيقات ويندوز وسطح المكتب؟

الهجرة إلى سطح المكتب الافتراضي الحديث من Azure ليست بالضرورة الخيار الأفضل لكل منظمة. قد تستفيد الشركات التي تحتاج بشكل أساسي إلى الوصول إلى تطبيقات Windows الحالية أو أجهزة الكمبيوتر المكتبية المستضافة مركزيًا من بنية أبسط، خاصة عندما لا تتطلب بيئة سطح مكتب افتراضي مستضافة بالكامل على Azure.

TSplus الوصول عن بُعد يمكن فرق تكنولوجيا المعلومات من نشر تطبيقات Windows وسطح المكتب البعيد الكامل من خلال عملاء متوافقين مع RDP أو بوابة ويب HTML5. مع دعم خوادم Windows المستضافة محليًا والسحابية، فإنه يوفر بديلاً عمليًا للمنظمات التي تسعى للحفاظ على تطبيقاتها الحالية مع تبسيط تسليم التطبيقات عن بُعد.

الختام

تقاعد Azure Virtual Desktop (الكلاسيكي) يجعل من الضروري تحديد النشر المتأثر، والحفاظ على الموارد الحالية واستعادة الوصول من خلال البنية التحتية المدعومة. يجب على فرق تكنولوجيا المعلومات التحقق من خيارات الاسترداد المتاحة قبل محاولة الهجرة أو إعادة البناء.

سواء استمرت المؤسسات في استخدام Azure Virtual Desktop الحديثة أو اعتمدت بنية تسليم أخرى، تظل الأولوية هي ضمان الوصول الآمن والموثوق للتطبيقات دون تعقيد تشغيلي غير ضروري.