الفصل : 15
الجزء : 3
العنوان : ال Remote Desktop Services
ال RemoteApp
فهمت الآن طوبولوجيا RDS والخطوات المطلوبة لنشر مجموعة RDS، والتي يمكن أن تهبط عليها الجلسات الافتراضية ويتمكن المستخدمون من الوصول إلى سطح مكتب افتراضي كامل. ومع ذلك، هذا يمكن أن يكون أكثر من اللازم بالنسبة للشركات في بعض الأحيان، ويمكن أن يصبح معقدًا للغاية لبعض الاستخدامات. ربما ترغب فقط في توفير الوصول إلى تطبيق أو تطبيقين عندما يتصل المستخدمون؛ لا يحتاجون إلى الوصول إلى سطح مكتب كامل حيث يمكنهم تشغيل أي شيء مثبت على الخادم، أو لحفظ الملفات داخل ملفهم الشخصي. نشر برامج RemoteApp من خلال مجموعة RDS هو وسيلة لنشر الوصول إلى تطبيق واحد أو مجموعة من التطبيقات من خلال بوابة Remote Desktop Web Access.
في الواقع، جاءني مثال مثالي على استخدام RemoteApps الأسبوع الماضي. مكتب طبيب يحتاج إلى السماح للمستشفى المحلي بالوصول إلى أحد أنظمة الرعاية الصحية لديهم الموجودة في الموقع. هذا المكتب الطبي لديه بالفعل مزرعة RDS، وكان بإمكاننا ببساطة توفير تسجيلات الدخول وجلسات افتراضية لموظفي المستشفى على تلك المزرعة، ولكن ذلك كان سيمنحهم القدرة على النقر المزدوج على أي تطبيق مثبت على خوادم RDSH، وكانوا يفضلون تقييد موظفي المستشفى بتشغيل تطبيق واحد فقط. الإجابة؟ نشر ذلك التطبيق الوحيد كـ RemoteApp داخل مجموعة RDS جديدة. هذه هي الخطوات الأساسية لاستخدام RemoteApp:
1. إنشاء نشر RDS؛ ربما لديك واحد بالفعل.
2. إنشاء مجموعة RDS جديدة للحفاظ على هذه التطبيقات RemoteApps منفصلة عن جلساتك الافتراضية الكاملة. من الممكن استضافة جلسات سطح المكتب الكاملة وRemoteApps على نفس مجموعة RDS ونفس خوادم RDSH، ولكن مايكروسوفت لا توصي بذلك. من الأفضل إبقائها منفصلة.
3. عادة ما يكون من المنطقي تضييق نطاق هذه المجموعة الجديدة بحيث يكون الوصول محصورًا على أعضاء مجموعة محددة. بهذه الطريقة يمكنك بسهولة تقييد من لديه صلاحية إطلاق هذا التطبيق.
4. تثبيت التطبيق الضروري على خوادم RDSH في المجموعة.
5. نشر RemoteApp داخل خصائص مجموعة RDS.
6. إرشاد المستخدمين لتسجيل الدخول إلى بوابة RDWeb. عندما يقومون بتسجيل الدخول، طالما أنك قمت بجعلهم أعضاء في المجموعة المناسبة، سيجدون الآن رمزًا لإطلاق هذا التطبيق RemoteApp من داخل البوابة. هذا يطلق جلسة RDP في الخلفية، ولكن المعلومات الوحيدة التي تنتقل إلى جهاز المستخدم هي شاشة التطبيق الفردي الذي يتم النقر عليه. لن يتم عرض سطح المكتب الافتراضي للمستخدم، فقط التطبيق.
7. عندما ينتهي المستخدمون من التطبيق، ينقرون ببساطة على X في الزاوية العلوية اليمنى، ويغلق التطبيق. بالنسبة للمستخدم، يتصرف التطبيق كما لو كان مثبتًا على جهاز الكمبيوتر المحلي (مع أنه لم يكن كذلك). في الخلفية، خوادم RDSH تدير جلسة RDP للمستخدم، وعند النقر على X، تدخل الجلسة في حالة غير متصلة.
لننشر تطبيقًا أو اثنين في مجموعة RDS حتى تتمكن من رؤية كيفية عملها حقًا. لقد انتهيت للتو من إنشاء مجموعة جديدة باسم Contoso RemoteApps. قمت بإزالة RDSH3 من المجموعة الحالية وأضفته إلى هذه المجموعة الجديدة. الآن، داخل خصائص المجموعة، أريد زيارة القسم في المنتصف المسمى REMOTEAPP PROGRAMS. هنا، ببساطة انقر على قائمة TASKS أو الرابط في وسط هذه الشاشة الذي يقول Publish RemoteApp Programs.
أروع شيء بخصوص RemoteApps هو مدى بساطتها للنشر. هذا المعالج يستعلم عن قائمة التطبيقات المثبتة على خوادم RDSH؛ لذا طالما أنك قد قمت بالفعل بتثبيت أي تطبيقات تحتاج إلى نشرها، ستظهر في هذه القائمة. الآن تقرر ببساطة أي التطبيقات تحتاج إلى نشرها داخل هذه المجموعة، تحددها، وتنهي المعالج! لم أقم بتثبيت أي تطبيقات مخصصة على RDSH3، ولكن لدي الكثير من الخيارات للتطبيقات المثبتة مسبقًا. على سبيل المثال، سأقوم بنشر Calculator وNotepad.
نحن في الأساس قد انتهينا. الشيء الوحيد المتبقي هو تسجيل الدخول كحساب مستخدم واختبار للتأكد من أنني أرى وأستطيع تشغيل هذه التطبيقات من بوابة Remote Desktop web. تسجيل الدخول إلى تلك البوابة، يمكنك رؤية في الصورة التالية أن برنامجي RemoteApp الخاصين بي ينتظرانني بسعادة. ستلاحظ أيضًا أنني لا أزال أرى الرمز الثالث، Contoso RDS. هذا لأن حساب المستخدم الذي أختبر به هو عضو في المجموعة التي تمنحني الوصول إلى هذه المجموعة الجديدة ولا يزال أيضًا عضوًا في المجموعة التي تمنحني الوصول لرؤية المزرعة الأخرى لـ RDS التي لا تزال موجودة لـ RDSH1 وRDSH2. يمكنني الآن النقر على أي من هذه الأيقونات وتشغيل مستوى الوصول الذي أحتاجه لأداء عملي.
كما هو الحال عند النقر على الاتصال بجلسة Contoso RDS الكاملة، يؤدي النقر على إحدى هذه التطبيقات RemoteApps إلى تنزيل ملف اتصال RDP في متصفح الويب الخاص بي. هذا الملف RDP مهيأ مسبقًا للإطلاق مباشرة إلى مجموعتي الجديدة لـ RDS وتشغيل أي تطبيقات RemoteApp التي نقرت عليها. يمكن للمستخدمين اختيار زيارة واجهة RDWeb دائمًا والنقر على تطبيقاتهم من هنا، مع العلم أنهم سيقومون بتنزيل نسخة جديدة من ذلك الملف RDP في كل مرة. ثم يتعين عليهم النقر على ذلك الملف الذي تم تنزيله من داخل المتصفح لإطلاق الاتصال. أو…
إذا كنت تريد نسخ ملف اتصال RDP المحفوظ من مجلد التنزيلات، يمكن بعد ذلك نسخ هذا الملف إلى سطح المكتب أو حتى توزيعه على مستخدمين آخرين، حيث يمكنهم ببساطة النقر المزدوج على ملف الاتصال RDP لتشغيل برنامج RemoteApp الخاص بهم.
لقد حاولت إظهار كل هذا في الصورة التالية. يمكنك رؤية صفحة RDWeb المفتوحة، ومجلد التنزيلات حيث تم تنزيل ملف الاتصال RDP عندما نقرت على Notepad، ونافذة Notepad المفتوحة. الآن، لماذا تصدق أن هذه النسخة من Notepad تعمل فعلاً على RDSH3 وليس ببساطة Notepad المثبت على جهاز WIN10 الخاص بي؟ إذا نقرت على File>Open داخل Notepad، فأنا أتصفح بوضوح بنية المجلدات لمحرك الأقراص الخاص بـ RDSH3. هذه نافذة Notepad التي أتفاعل معها تعمل بالكامل على RDSH3، من خلال جلسة RDS افتراضية.
الفائدة الرئيسية لـ RemoteApps هي تقييد الوصول. هذه وسيلة بسيطة لتوفير الوصول للعديد من المستخدمين إلى العديد من التطبيقات المختلفة المثبتة على نفس مجموعة خوادم RDS، وفي الوقت نفسه التأكد من أن المستخدمين لديهم فقط الوصول إلى التطبيقات التي تريدهم أن يلمسوها.
اعتبارات الصيانة لـ RDS
صيانة واستكشاف أخطاء خوادم RDS يمكن أن يكون فنًا بحد ذاته. هي حالات خوادم Windows، نعم، ولكن في نواح كثيرة تعاملها أكثر مثل محطات العمل، نظرًا لأنها المكان الذي يسجل فيه المستخدمون الدخول لاستخدام التطبيقات وحفظ المستندات. ومع ذلك، العديد من المستخدمين المختلفين مسجلون في هذه "محطات العمل" في نفس الوقت، مما يخلق تعقيدات لا نواجهها عادة على محطات العمل أو أنواع الخوادم الأخرى. هذه الفقرة الأخيرة هي جلسة نصائح وحيل لبعض الاعتبارات الشائعة للصيانة التي ستواجهها بلا شك خلال فترة إدارتك لـ RDS.
وضع التثبيت
لا داعي لإعادة شرح هذا؛ لقد غطينا وضع التثبيت بالتفصيل في وقت سابق في هذا الفصل. لكن إذا كان هناك شيء واحد أجد أن المدراء ينسون القيام به في أغلب الأحيان عند التعامل مع خوادم RDS، فهو وضعهم في وضع التثبيت قبل تثبيت التطبيقات، بل وأكثر من ذلك ينسون القيام بذلك قبل تحديث التطبيقات الحالية. لا تنسَ دائمًا استخدام وضع التثبيت!
بالإضافة إلى ذلك، تأكد من تسجيل خروج جميع المستخدمين من خادم RDSH عند تثبيت أو تحديث التطبيقات. يجب أن يكون حساب المسؤول الخاص بك هو الحساب الوحيد المسجل الدخول إلى الخادم بأكمله عند تنفيذ هذه الوظائف.
أخطاء Server Manager المتعلقة بـ RDS
تحدث معظم تكوينات RDS من داخل Server Manager، وغالبًا ما أجد المدراء يتجهون إلى مثيل Server Manager على أي خادم يكون خادم إدارة RDS الخاص بك. هذا الخادم ربما يستضيف بعض أو كل أدوار RDS، باستثناء RDSH بالطبع. في حالتي، كان هذا هو خادم RDS-MGMT الذي أشرنا إليه مرات عديدة طوال هذا الفصل. لا يوجد سبب تقني يجبرك على استخدام خادم الإدارة المركزي لـ RDS لأداء هذه المهام - تم تصميم Server Manager ليكون لامركزيًا وقادرًا على إدارة الخوادم خارج نفسه، أليس كذلك؟ مشكلة شائعة جدًا أشاهد المدراء يكافحون من خلالها هي عند محاولة تشغيل Server Manager، بقصد تغيير إعداد تكوين RDS، من خادم RDS مختلف في النشر. دعونا نجربها معًا ونرى ما يحدث.
أنا مسجل الدخول مباشرة إلى RDSH2. مهمة هذا الخادم في الحياة هي استضافة جلسات المستخدم، لكنني لم أحاول أبدًا تشغيل أي أدوات إدارة RDS عليه. عند تشغيل Server Manager، بما أن RDSH2 يحتوي على مكون Remote Desktop مثبت عليه، بالطبع أرى الخيار داخل Server Manager لخدمات Remote Desktop. عندما أنقر عليه، ومع ذلك، تبدو الأمور محطمة للغاية…
هذه هي النقطة التي يعلق عندها العديد من المدراء. يفترضون أن هناك شيئًا ما محطما حقًا، أو مكوّنًا بشكل خاطئ مع RDS، ويصعدون أي تذكرة يعملون عليها. في بعض الحالات، يحاولون إعادة تشغيل هذا الخادم مرارًا وتكرارًا، دون جدوى. الحقيقة القاسية لهذه الرسالة الخطأ هي أنها تخبرك، وجهًا لوجه، كيفية إصلاح المشكلة. معظم الناس فقط يفوتهم ذلك. "لإدارة نشر، يجب عليك إضافة جميع الخوادم في النشر إلى مجموعة الخوادم." هذا هو Server Manager الذي يخبرك (أنا أقتبس هنا)، "مرحبًا يا مسؤول، إذا كنت تريد إدارة RDS من هذه النافذة، عليك إضافة جميع خوادم RDS إلى Server Manager، حتى أتمكن من الوصول إليها!"
الشيء الوحيد الذي تحتاج إلى فعله هو النقر على Manage في أعلى Server Manager، ثم Add Servers. من هنا تعرف ماذا تفعل، أضف جميع الخوادم المتعلقة بـ RDS إلى Server Manager حتى يكون قادرًا على الوصول إليها، وإذا قمت بتحديث شاشة Remote Desktop، فسوف تضيء الآن بجميع المعلومات والخيارات التي تتوقعها.
تسجيل الدخول مباشرة إلى خوادم RDSH
معظم مثيلات Windows Server سهلة الاتصال بها عن بعد، باستخدام أداة Remote Desktop Connection وإنشاء اتصال RDP لتسجيل الدخول إليها ببساطة. خوادم RDSH، عندما تكون جزءًا من مجموعة RDS، فجأة تصبح حساسة بشأن اتصالات RDP القادمة إليها إلا إذا كانت تلك الاتصالات تتم عبر المزرعة. سأعرض لك مثالًا. خوادم RDSH1 وRDSH2 الخاصة بي هي مجرد مثيلات Windows Server 2022، وتمكنت من الاتصال بها بنجاح عبر RDP قبل أن أجعلها خوادم RDS داخل مجموعتي. الآن بعد أن أصبحت جزءًا من المجموعة، يمكنني بالطبع الاتصال بها باستخدام ملف اتصال RDS الذي يربطني عبر المزرعة، تمامًا كما سيفعل المستخدمون.
الاتصال بهذه الطريقة سيضعني على RDSH1 أو RDSH2، لكنني لا أستطيع اختيار أي منهما. إذا كنت أقوم بالاتصال بأحد هذه الخوادم لأغراض الصيانة، سأرغب في أن أتمكن من الدخول بسهولة إلى أحدهما أو الآخر حسب اختياري.
من جهاز WIN10 الخاص بي، حاولت ببساطة الاتصال بـ RDSH2، باستخدام أداة mstsc.exe.
هنا النتيجة:
إذا كان لديك نوع آخر من أداة الاتصال لتتصل مباشرة بوحدة التحكم في RDSH2، يمكنك بالطبع استخدامها لتسجيل الدخول مباشرة. بخلاف ذلك، إذا كان RDSH2 جهازًا افتراضيًا، كما هو الحال في حالتي، فيمكنني استخدام جلسة Hyper-V لتسجيل الدخول مباشرة إليه أيضًا. ومع ذلك، هناك خيار ثالث يحدق في وجوهنا، مدفون في أسفل النص في إخراج الخطأ السابق لدينا:
mstsc.exe /admin
عند تشغيل mstsc.exe، هناك بعض الخيارات الإضافية التي يمكنك استدعاؤها، والتي تمكن وظائف خاصة داخل هذه الأداة. هذه الخيارات تمكنك من تحديد ارتفاع وعرض جلسة سطح المكتب البعيد، تحديد استخدام ملف اتصال RDP محفوظ، أو حتى الاتصال بطريقة تمكنك من تتبع جلسة مستخدم آخر. لأغراضنا اليوم، نريد ببساطة أن نتمكن من تسجيل الدخول مباشرة إلى RDSH2، وخيارنا للقيام بذلك يسمى mstsc.exe /admin.
خيار /admin يربطك مباشرة بجلسة خاصة على RDS، مخصصة لإدارة الجهاز. في حالتنا مع RDSH2، يعني أنه سيسمح لنا فعليًا بالاتصال بهذا الخادم مباشرة، في حين أن اتصال mstsc.exe العادي لن يسمح بذلك.
استبدال شهادات SSL
على افتراض أنك كنت تتبع طول هذا الفصل، تعرف أن بوابة Remote Desktop تستخدم شهادة SSL، وهو منطقي لأنها تسمح بالاتصال وتدفقات الحركة الواردة إلى بيئتك من أي مكان في العالم. مكون Remote Desktop Web Access يستخدم أيضًا شهادة SSL، لأنها صفحة ويب تعمل على المنفذ 443 وأي متصفح للمستخدم سيصدر اعتراضًا إذا لم يكن هناك شهادة صالحة على ذلك الموقع.
تحتاج شهادات SSL إلى التجديد كل عام في معظم الحالات. خطأ شائع أشاهده من مدراء RDS هو أنه أثناء تجديد شهادة SSL لمثيل RD Gateway، يتجهون مباشرة إلى أداة Remote Desktop Gateway Manager. لم ننظر حتى إلى هذه الأداة خلال فصلنا حول RDS، لأنها تُستخدم فقط لبعض الوظائف ولا حاجة للمسها في العديد من بيئات RDS. يمكن استبدال شهادة SSL الخاصة بـ RD Gateway من داخل Remote Desktop Gateway Manager، لكن هذا ليس المكان المناسب تقنيًا لأداء هذه المهمة.
استبدال الشهادة بشهادة جديدة عبر RD Gateway Manager سيجعل الشهادة الجديدة تعمل على بوابة RD Gateway الخاصة بك، ولكن فقط على بوابة RD Gateway. المكونات الأخرى داخل RDS التي تستخدم شهادات SSL لن يتم تغييرها أو تحديثها، مما قد يتسبب لك في مشاكل أخرى بمجرد انتهاء صلاحية الشهادة القديمة.
تجنب هذا الخطأ هو مسألة بسيطة لتغيير العادات. بدلاً من الحصول على الشهادة الجديدة والتوجه مباشرة إلى Remote Desktop Gateway Manager، قم بزيارة Server Manager وخصائص نشر RDS الشاملة. لا توجد الكثير من الأسباب الشائعة لزيارة خصائص النشر الشاملة بانتظام، ولكن استبدال شهادات SSL هو واحد منها. داخل خصائص النشر، هناك شاشة تسمى Certificates.
هذه الشاشة قد تكون مربكة بعض الشيء، ولكن ما تحاول إخبارك به هو أن هناك في الواقع أربعة مكونات مختلفة في RDS تستخدم الشهادة. هذه هي الكيانات الأربعة الموضحة في لقطة الشاشة السابقة. Remote Desktop Connection Broker لديه اثنتان، ثم Remote Desktop Web Access وRemote Desktop Gateway، كما ناقشنا بالفعل.
عند استبدال شهادة بشهادة جديدة، تريد تغييرها لجميع المكونات الأربعة على هذه الشاشة. إذا كنت ستستبدل شهادة Remote Desktop Gateway عبر Remote Desktop Gateway Manager، فستكون قد أكملت فقط 25٪ من استبدال الشهادة.
خيار "Create new certificate..." مثير للاهتمام، حيث يتيح لك إنشاء شهادة موقعة ذاتيًا للمهمة، ولكن من المحتمل ألا يكون هذا ما تريد تحقيقه. بدلاً من ذلك، احصل على الشهادة الجديدة من خلال الوسائل المعتادة، وفي النهاية تأكد من أن لديك ملف PFX يحتوي على كل من الشهادة والمفتاح الخاص. لا تتردد في العودة وزيارة فصل الشهادات إذا كان أي من ذلك لا معنى له. انسخ ملف PFX إلى الخادم الذي تدير منه نشر RDS الخاص بك، واستخدم الآن زر "Select existing certificate..." لوضعها في مكانها.
المعلومة الأساسية التي يجب فهمها هي أنك يجب أن تكرر هذه العملية لكل من هذه المكونات الأربعة لـ RDS. اخترهم بشكل فردي، واتبع شاشة "Select existing certificate..." لكل منهم، وفي النهاية، سيعمل نشر RDS بالكامل على الشهادة الجديدة.
استنساخ خوادم RDSH
عند بناء مزرعة RDS لاختبار المعمل، كانت الأمور سهلة بالنسبة لي لأنني كنت بحاجة إليها فقط لأغراض الاختبار والتقاط لقطات الشاشة، لذا قمت ببساطة بإنشاء أربع آلات افتراضية جديدة تعمل بنسخ جديدة من Windows Server 2022 وقمت بتكوينها حسب الحاجة. عند بناء مزرعة RDS في بيئة إنتاج، يكاد يكون من المؤكد أنك ستقوم بتثبيت العديد من التطبيقات الإضافية على خوادم RDSH الخاصة بك، حتى يتمكن المستخدمون من تشغيل هذه التطبيقات بمجرد الاتصال. بدلاً من تحضير جميع خوادم RDSH من البداية والاضطرار إلى تشغيل مثبتات التطبيقات على كل منها، سيكون من المغري جدًا بطريقة ما تصويرها أو استنساخها من بعضها البعض. ربما تقوم بإنشاء RDSH1 ثم تثبيت كل ما تحتاجه. هذا الخادم RDSH هو الآن المثال المثالي لتكرار 3 أو 4 أو 46 مرة أخرى، وللخوادم الجديدة RDSH، تقوم ببساطة باستنساخ الخادم الحالي.
إذا فعلت ذلك، تأكد من تشغيل sysprep على كل خادم جديد!
لقد غطينا بالفعل موضوع sysprep في هذا الكتاب، لذلك لن أعيد شرحه هنا. إذا استنسخت خادمًا ولم تقم بتشغيل sysprep عليه، فستتسبب بالتأكيد في حدوث تصادمات ومشكلات داخل شبكتك وActive Directory. يعمل sysprepping على تنظيف قطع رئيسية من المعلومات من داخل Windows، مما يتيح له العمل جنبًا إلى جنب مع الاستنساخ.
اعتمادًا على كيفية تصرف تطبيقاتك، قد تتمكن أو لا تتمكن من الاستنساخ وتشغيل sysprep. بعض التطبيقات تضع معلومات في الملفات والسجل التي تستخدم اسم المضيف للخادم، والذي سيتغير بالتأكيد أثناء عملية الاستنساخ. لا يمكنني إخبارك بما إذا كنت ستتمكن من استنساخ خوادم RDSH في بيئتك؛ سيكون الأمر مسألة تجريب وخطأ. ولكن إذا فعلت، تأكد من أن sysprep جزء من تلك المعادلة. أعرف بعض مدراء RDS الذين يستنسخون الخوادم طوال الوقت ويحبون ذلك، وأعرف بعض الذين كانت لديهم تجارب سيئة بما فيه الكفاية لدرجة أنهم لا يفكرون حتى في فعل ذلك. القرار لك...
ال Sidder
في مرحلة ما في رحلتك في إدارة RDS، ستجد نفسك تحدق في موقع الشبكة المشتركة حيث توجد جميع UPDs وتخدش رأسك. تعرف أن كل جلسة مستخدم تنشئ UPD جديدًا داخل هذا الموقع، كما حددت أثناء معالج نشر RDS. تعرف بالفعل أن كل UPD هو في الواقع ملف VHDX يجلس في هذا الموقع. ما لم نناقشه هو أن هذه الملفات VHDX مسماة بطريقة غير بديهية للغاية. أسماء هذه الملفات هي GUID طويل، وهو معرف لحساب المستخدم الذي ترتبط به. ملفات FSLogix profiles تقوم بعمل أفضل بوضع اسم المستخدم مباشرة في اسم هذا الملف بحيث يمكنك تحديد بسرعة أي VHDX ينتمي لأي مستخدم، ولكن بالنسبة لـ UPDs الكلاسيكية، تنظر إلى الكثير من الهراء، مثل هذا:
لحسن الحظ، هناك أداة مجانية متاحة تملأ هذه الفجوة المعرفية! تسمى Sidder، ولكن لأنها ليست أداة أنشأتها Microsoft، لن أعطيك رابط تنزيل رسمي. إنها سهلة البحث على الإنترنت، ولكن أقدم هذه النصيحة مع "استخدمها على مسؤوليتك الخاصة".
إذا قررت المضي قدمًا وتنزيل Sidder، فهي أداة تنفيذية مستقلة يمكنك نسخها إلى الخادم حيث يتم تخزين UPDs، وتشغيل Sidder يعرض معلومات لتحديد بسرعة أي UPD ينتمي لأي حساب مستخدم.
ال GPOs و RDS
تُستخدم GPOs عادةً لتأمين أو معالجة محطات العمل المنضمة إلى النطاق لشركة ويمكن استخدامها بسهولة لتعديل خوادم RDSH. ومع ذلك، من المحتمل أن تكون التكوينات والإعدادات التي تريد دفعها إلى محطات العمل لا تنطبق مباشرة على نواياك لخوادم RDSH، والعكس صحيح. من الشائع جدًا العثور على جميع خوادم RDSH معزولة في OU خاصة بها داخل Active Directory وأن تكون تلك OU لديها Block Inheritance ممكنة. من السهل كسر خادم RDSH عن طريق تطبيق سياسات النطاق العام عليه، لذلك أوصي بحجب هذا الوراثة كأفضل ممارسة عامة.
ما يعنيه هذا بالطبع هو أن أي GPOs تريد تطبيقها على خوادم RDSH الخاصة بك يجب أن تكون مرتبطة عمدًا بـ OU الخاصة بها. هذا شيء جيد يجب أن تضعه في اعتبارك عند بناء بيئة RDS جديدة، وأيضًا عند تعديل GPOs بأي شكل، كن واعيًا لكيفية تأثير تغييراتك أو عدم تأثيرها على مستخدمي مزرعة RDS الخاصة بك.
ملخص
خدمات Remote Desktop موجودة منذ أكثر من 20 عامًا ولا تزال مستخدمة على نطاق واسع حول العالم. لقد شهدت العديد من التحسينات على مر السنين ولا تزال طريقة رائعة لتوفير منصة افتراضية متعددة المستخدمين للعاملين لديك، حيث لا يحتاجون إلى القلق بشأن الكمبيوتر المحلي الذي يستخدمونه لأداء العمل، ولا تحتاج إلى القلق بشأن تأمين أي جهاز يبدو عليه. أنت تحتفظ بالسيطرة الكاملة على بيئة الحوسبة المركزية لـ RDS، مما يوفر وصولاً آمنًا إلى الموارد التي يحتاجها الموظفون.
في الواقع، لا تزال RDS مستخدمة على نطاق واسع لدرجة أنها انتقلت إلى واحدة من أكثر مجموعات الموارد القائمة على Azure شيوعًا التي أجدها في سوق SMB. Azure Virtual Desktop (AVD)، المعروف سابقًا باسم Windows Virtual Desktop، هو طريقة لتوفير تسجيل الدخول للمستخدمين من أي مكان إلى الخوادم المستندة إلى Azure التي تحتوي على جلسات مستخدم افتراضية. القدرات في AVD مشابهة جدًا لـ RDS المحلي، باستثناء أن نظام التشغيل الأساسي لـ AVD هو عادةً منصة Windows 10 متعددة المستخدمين، بدلاً من Windows Server 2022. حتى AVD يستخدم ملفات تعريف FSLogix للحفاظ على أمان معلومات المستخدم وعملها بشكل صحيح.
النهاية
نكون هنا انتهينا من الفصل 15 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق ولكن في النهاية جدا
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
