الفصل : 15
الجزء : 1
العنوان : ال Remote Desktop Services
كلمة "Remote Desktop" عادةً ما تثير في الذهن عميل Remote Desktop Connection البسيط الذي استخدمناه لعقود للتحكم عن بعد في الخوادم ومحطات العمل. خدمات Remote Desktop هي أكثر قوة وقد كانت موجودة منذ سنوات عديدة، ولكنها كانت تُعرف في الأصل باسم Terminal Services. عن طريق إنشاء بيئة Remote Desktop Services (RDS)، والتي تتكون بشكل مثالي من عدة نسخ من Windows Server، فإنك تبدأ أولى خطواتك في عالم سطح المكتب الافتراضي والحوسبة المركزية. مزرعة RDS، كما يُطلق عليها بمحبة، توفر للمستخدمين الوصول الآمن إلى جلسة افتراضية سواءً داخل المكتب أو خارجه، حيث يمكنهم تشغيل التطبيقات التي يحتاجونها والوصول إلى البيانات اللازمة لأداء وظائفهم. يمكن أن يكون تنفيذ RDS طريقة لتوفير قدرات العمل من المنزل، حتى من الأجهزة الشخصية، ويمكن أن يسمح للشركات باستخدام محطات العمل الرقيقة الرخيصة بدلاً من أجهزة الكمبيوتر المكتبية والمحمولة التقليدية إذا كان بإمكان فريق العمل العمل تمامًا داخل بيئة RDS. يتناول هذا الفصل مكونات RDS وكيف يمكنك البدء فورًا في استخدامها في شبكاتك الخاصة.
- مكونات بيئة RDS
- نشر جلسات RDS
- ترخيص RDS
- ملفات تعريف المستخدمين في RDS
- الRemoteApp
- اعتبارات صيانة RDS
دورك، أين أنت؟
ما هو أول شيء تحتاج عادةً إلى إنجازه على نسخة Windows Server لجعلها تقوم بأي نوع من العمل الحقيقي؟ نعم، تثبيت دور. المشكلة في هذا هي أن أصابعنا تعتاد على التنقل عبر شاشات معالج Add Roles and Features Wizard لدرجة أنك قد تكون بالفعل تحدق في قائمة أدوار Windows Server وتستعد للنقر على الدور المسمى Remote Desktop Services. توقف!
تراجع. إذا قمت بالإبطاء والانتباه عند إطلاق المعالج لتثبيت دورك الجديد، ستلاحظ أنك عادةً تتجاوز شاشة تسألك عما إذا كنت تريد تثبيت مكون RDS أو أي مكون آخر من Windows Server. لدى RDS قسم خاص به في معالج Add Roles and Features Wizard. أسهل طريقة لنشر RDS هي استخدام هذا الخيار الثاني والاستمرار من هنا.
الآن بعد أن تتنقل في طريق التثبيت الصحيح للدور، علينا أن نختار أي من مكونات RDS نرغب في تثبيتها على أي خادم. بينما من الممكن وضع جميع أجزاء RDS على خادم واحد، مما يخلق نوعًا من "RDS الكل في واحد"، إلا أنه لا يُنصح عمومًا بذلك. يغطي القسم التالي من هذا الفصل أوصاف واختلافات مكونات RDS، ولكن من المهم ملاحظة أن خوادم RDSH يجب أن تكون دائمًا خوادم RDSH فقط، بينما يمكن لباقي أدوار RDS أن تتواجد معًا على نوع من خوادم الإدارة أو الإدارة لـ RDS. في بيئة المعمل الخاصة بنا طوال هذا الفصل، سأستخدم أربعة خوادم متعلقة بـ RDS. ثلاثة منها ستكون ببساطة خوادم RDSH، والرابع سيكون خادم RDS-MGMT يحتوي على جميع الأجزاء الأخرى المتعلقة بـ RDS المثبتة عليه. قبل تشغيل معالج Add Roles and Features Wizard على أول خادم RDS لي، أريد التأكد من أن جميع خوادم RDS الخاصة بي جاهزة، حتى يتمكن هذا المعالج من الوصول إلى جميع الأربعة منها لتكوين المكونات التي أحددها.
إذا كنت تضيف عقدة إلى بنية RDS الحالية، فلا داعي لتشغيل هذا الإصدار الخاص من معالج تثبيت الدور. سنتحدث عن ذلك بشكل أعمق في وقت لاحق من الفصل.
مكونات بيئة RDS
يحتوي RDS على العديد من الأجزاء المتحركة، وقد تتعرض أصابعك للخطر إذا لم تكن واضحًا بشأن ما يخدمه كل مكون. لنأخذ بعض الصفحات لوصف الأدوار المختلفة لخوادم RDS التي سنعمل معها.
ال Remote Desktop Session Host
النوع الأكثر شيوعًا من خوادم RDS يسمى Remote Desktop Session Host (RDSH). هذه هي الأكثر شيوعًا لأن هناك عادةً المزيد من خوادم RDSH أكثر من أي نوع آخر من مكونات RDS. جميع جلسات المستخدمين ستنتهي على خادم RDSH. هذه هي الخوادم التي تقوم بالعمل الحقيقي: الجميع يسجل الدخول إلى RDS وينتهي بهم المطاف في جلسات افتراضية تعمل على خوادم RDSH. نظرًا لأن كل تسجيل دخول للمستخدم يستهلك الموارد (CPU، RAM، إلخ)، وفي معظم الحالات، يتم تكوين خادم RDSH لاستضافة عدة جلسات مستخدم في وقت واحد، فإن خوادم RDSH عادةً ما تكون مجهزة بموارد أكثر من أنواع خوادم RDS الأخرى.
من المهم ملاحظة أنك عادةً ما تريد أن يكون خادم RDSH خادم RDSH فقط ولا شيء آخر. لا تقم بتثبيت RDS Connection Broker، License Manager، Gateway، أو أي شيء آخر على هذه الخوادم.
ال Remote Desktop Connection Broker
طريقة جيدة للتفكير في Remote Desktop Connection Broker هي كونه موازن تحميل مدمج لجلسات RDS. تسجيلات الدخول الجديدة للمستخدمين القادمة إلى مزرعة RDS سيتم توزيعها عبر عدة خوادم RDSH بناءً على الأوزان المعرفة ضمن خصائص Remote Desktop Connection Broker، وRemote Desktop Connection Broker هو أيضًا ما يتيح للمستخدمين فصل جلساتهم من RDS وإعادة الاتصال تلقائيًا إلى نفس الجلسة عند إعادة الاتصال في وقت لاحق من اليوم. يتخذ Remote Desktop Connection Broker القرارات حول من سيهبط على أي خادم RDSH.
ال Remote Desktop License Manager
هذا واضح بذاته. Remote Desktop License Manager هو الدور والأدوات التي تحدد ترخيص RDS. ما يمكن أن يكون معقدًا في هذا الموضوع هو الأنواع المختلفة من تراخيص RDS المتاحة، والتي سنتحدث عنها لاحقًا في هذا الفصل.
كلما تقدمت في إدارة RDS، ستدرك بسرعة أن تقريبًا كل شيء يحتاج إلى التكوين في عالم RDS يحدث داخل Server Manager. هذا صحيح جزئيًا فقط فيما يتعلق بتراخيص RDS. صحيح أنك ستحدد أي خادم يحتوي على مكونات ترخيص RDS من داخل Server Manager، ولكن هناك أداة إدارة أكثر تحديدًا يتم تثبيتها على خادم ترخيص RDS تحتاج إلى استخدامها لاستيراد تراخيص الوصول للعميل (CALs) الخاصة بـ RDS.
ال Remote Desktop Web Access
ال Remote Desktop Web Access هو بوابة ويب يمكن للمستخدمين تسجيل الدخول إليها من متصفح والوصول إلى تطبيقاتهم أو أجهزة سطح المكتب الافتراضية المنشورة بواسطة RDS. يتم نشر مكون Web Access بواسطة IIS، لذا ستجد هذا الدور مثبتًا على أي خادم RDS يستضيف Remote Desktop Web Access. من الشائع دمج هذا مع Remote Desktop Gateway، الذي سنناقشه لاحقًا. إذا كنت ستعمل بانتظام مع بيئات Remote Desktop، فقد يكون من الجيد حفظ مصطلح "rdweb". هذا هو الجزء الأخير من عنوان URL الذي يشكل الوصول إلى بوابة الويب. على سبيل المثال، إذا كان اسم DNS الذي تستخدمه لبيئة RDS هو gateway.contoso.com، فإن بوابة Remote Desktop Web Access ستكون:
https://gateway.contoso.com/rdweb
ال Remote Desktop Gateway
نادراً ما أجد بيئة RDS لا تشمل أيضًا نسخة من Remote Desktop Gateway. Remote Desktop Gateway هو المكون السري الذي يربط بين الموظفين الموجودين في الموقع وخارج الموقع. بناء مزرعة RDS داخل الشبكة وترخيصها والسماح لموازن الاتصال بتوزيع جلسات المستخدمين عبر جميع خوادم المزرعة أمر رائع، ولكن إذا كنت تقدم بالفعل للمستخدمين جلسة سطح مكتب افتراضية لأداء عملهم، فلماذا لا تمنحهم أيضًا القدرة على تسجيل الدخول إلى سطح المكتب الافتراضي من خارج المكتب، مثل من منازلهم؟
ال RD Gateway يقوم بذلك بالضبط. إنه مصمم للاستماع للاتصالات الواردة من الإنترنت على المنفذ 443 (على الرغم من أنه يمكن تعديل ذلك)، حتى يتمكن المستخدمون عن بُعد من استخدام ملف رمز RDP بسيط على أجهزة الكمبيوتر الخاصة بهم مصمم لتدفق الحركة عبر البوابة والدخول إلى مزرعة RDS الموجودة داخل مركز بياناتك.
بدلاً من ذلك، يمكنك حتى استخدام Remote Desktop Gateway بدون مزرعة RDSH للاتصال مباشرة بمحطات العمل الموجودة داخل المكتب! في بعض الحالات، أجد أن الخادم الوحيد الذي تمتلكه الشركة من RDS هو خادم Remote Desktop Gateway واحد. الغرض من هذا الخادم في هذه الحالات هو أخذ الاتصالات الواردة من العاملين عن بُعد ونقل اتصالات RDP الخاصة بهم بأمان إلى أجهزة الكمبيوتر الخاصة بهم داخل جدران الشركة. هذا يتيح للمستخدمين الحصول على جهاز كمبيوتر مكتبي للعمل دائمًا في المكتب، وعند العمل عن بُعد يمكنهم إطلاق اتصال Remote Desktop Gateway الذي يتيح لهم الوصول الآمن إلى ذلك الكمبيوتر المكتبي من جهاز شخصي (ربما حتى من Mac!).
ال RD Gateway هو مكون آخر من مكونات RDS له مكانين مختلفين للتكوين. يتم تكوين الوظيفة الرئيسية داخل Server Manager، بينما يتم تثبيت Remote Desktop Gateway Manager منفصل لمستويات أعمق من التكوين.
في بيئة RDS كبيرة ومتينة، سيتم تثبيت جميع الأدوار التي ناقشناها على خوادم مختلفة، مع أي منها يحتوي على إمكانيات التكرار بحيث يمكنك البقاء بسهولة في حالة فشل خادم واحد. ومع ذلك، فإن معظم الشركات التي تستخدم RDS لا تذهب إلى هذا الحد عند إنشاء المرونة على هذه الخوادم، وسوف نتبع الأغلبية
مع الصفحات المتبقية من هذا الفصل أثناء إعداد بيئة RDS الخاصة بنا في معمل الاختبار. ستعكس خطوات التكوين التي أتابعها في هذه الصفحات بيئات الإنتاج التي أجدها غالبًا في سوق الشركات الصغيرة والمتوسطة.
نشر جلسات RDS
تتمحور RDS حول إنشاء بيئة حوسبة مركزية للمستخدمين للاستفادة منها وترك تعيين الموارد واستخدامها للخوادم، مما يقلل بشكل كبير الحاجة إلى الاهتمام بنوع محطة العمل أو الكمبيوتر المحمول الذي يستخدمه شخص ما للاتصال. هناك نوعان أساسيان من الاتصالات في بيئة RDS: نشر أجهزة سطح المكتب الافتراضية الكاملة ونشر التطبيقات الفردية، والتي سنتحدث عنها قرب نهاية هذا الفصل.
سوف نقوم بإنشاء بيئة RDS تحتوي على جميع المكونات التي حددناها سابقًا، وسنستخدم هذه المزرعة RDS لنشر جلسات سطح المكتب الافتراضية الكاملة التي سيتمكن المستخدمون من تسجيل الدخول إليها والعمل منها.
عند بناء بيئة RDS جديدة، من المفيد أن تكون جميع الخوادم التي تنوي تضمينها قيد التشغيل بالفعل وتم تجهيزها مبدئيًا. يجب أن تكون هذه الخوادم قد تم تحديد اسمها النهائي، وأن تحتوي على عناوين IP محجوزة أو ثابتة، وأن تكون قد انضمت بالفعل إلى نطاقك. بالنسبة لمعملي اليوم، سأستخدم الخوادم التالية:
-ال RDS-MGMT – سيكون هذا الخادم هو السكين السويسري الخاص بي، يقوم بكل شيء باستثناء استضافة جلسات المستخدمين. سنقوم بتنفيذ Remote Desktop Gateway وRemote Desktop Connection Broker وRemote Desktop Licensing وRemote Desktop Web Access عليه.
- ال RDSH1 – سيكون هذا واحدًا من خوادم استضافة الجلسات الأولية الخاصة بي، حيث سنقوم بتثبيت التطبيقات واستضافة الجلسات الافتراضية للمستخدمين عليه.
-ال RDSH2 – خادم RDSH آخر: هذا الخادم وRDSH1 سيكونان الأعضاء الأوليين في مزرعة RDS الخاصة بي. سيتم موازنة جلسات المستخدمين بينهما.
-ال RDSH3 – لاحقًا سأضيف هذه العقدة الثالثة إلى مزرعتي، حتى نتمكن من إلقاء نظرة حقيقية على ما يتطلبه الأمر لتوسيع بيئة RDS التي تعمل بالفعل.
إنشاء بيئة RDS
خوادمي الأربعة قيد التشغيل بالفعل، ولكن في هذه المرحلة لم أقم بتثبيت أي أدوار أو مكونات RDS عليها. هنا سنقوم بتوضيح الخطوات اللازمة لبناء مزرعة RDS هذه، والتي يمكن أن تتم جميعها من خلال مثيل واحد من Server Manager. من المهم التأكد من أن جميع الخوادم التي تنوي تعديلها قد تمت إضافتها بالفعل إلى Server Manager قبل بدء المعالج. تعرف بالفعل كيفية إضافة خوادم متعددة إلى نفس مثيل Server Manager، ولكن إذا كنت بحاجة إلى تذكير، ما عليك سوى النقر فوق Manage > Add Servers وإضافة جميع الخوادم ذات الصلة التي ستقوم بتعديلها. سيكون هذا مهمًا لاحقًا في المعالج عندما تحتاج إلى تحديد هذه الخوادم لتكون مالكة لمكونات RDS المختلفة.
بتسجيل الدخول إلى RDS-MGMT، سأستخدم وظيفة Add Roles and Features وأتأكد من اختيار نوع التثبيت الثاني الذي نظرنا إليه سابقًا، Remote Desktop Services installation. في الشاشة التالية، ستلاحظ خيار Quick Start، وهو مثير للاهتمام لأنه يوفر طريقة مختصرة لإنشاء بيئة RDS الكل في واحد على خادم واحد، ولكن هذا نادرًا ما يكون ما ترغب الشركات في القيام به في الإنتاج، ولذلك لن نقوم بذلك هنا أيضًا. بدلاً من ذلك، استمر في المضي قدمًا مع الخيار Standard deployment.
الآن في شاشة سيناريو النشر، يتم تقديمنا بخيار مثير للاهتمام. من السهل خلط المصطلحات بين سطح المكتب الافتراضي، الجلسة، والجلسة الافتراضية. هنا نواجه منعطفًا في الطريق. الخيار الأول لنشر سطح مكتب يعتمد على جهاز افتراضي ليس شائعًا جدًا؛ هذا هو بيئة VDI الكلاسيكية حيث قد يكون لديك أجهزة افتراضية مخصصة لكل مستخدم. بدلاً من ذلك، عندما نتحدث عن RDS، فإننا نتحدث عادةً عن نشر جلسات سطح المكتب الافتراضية للمستخدمين، حيث سيسجل العديد من المستخدمين الدخول إلى نفس خادم RDSH، ويشاركون موارد الأجهزة. هذا هو الاتجاه الذي نريد اتباعه اليوم والأكثر احتمالًا الذي ستجده في بيئاتك المؤسسية. لذلك، تابع وحدد Session-based desktop deployment.
يقوم المعالج الآن بتلخيص ما سنقوم بتثبيته استنادًا إلى اختياراتنا حتى الآن: Remote Desktop Connection Broker وRemote Desktop Web Access وRemote Desktop Session Host.
بالنسبة لكل من هذه المكونات الثلاثة، فإن الشاشات التالية في المعالج تكون بسيطة للغاية. اختر الخادم الذي تريد استضافة كل دور من أدوار RDS عليه، واسحبه إلى الجانب الأيمن من الشاشة. على سبيل المثال، هنا قمت بتحديد أنني أرغب في أن يكون RD Connection Broker على الخادم RDS-MGMT.
تابع نفس الخطوات لتحديد المنزل لـ RD Web Access، الذي سأضعه أيضًا على RDS-MGMT، والآن نزور الشاشة الأخيرة التي تطلب منا اتخاذ قرارات، وهي ما هي الخوادم التي ستكون RD Session Hosts. لا أريد أن يستضيف RDS-MGMT جلسات المستخدمين، لأنه سيكون مشغولًا بأداء جميع الوظائف الأخرى، لذلك أعلن أن RDSH1 وRDSH2 هما الخوادم التي ستكون RD Session Hosts. سيقوم معالج التكوين هنا بالاتصال بهذه الخوادم وتكوينها حسب الحاجة لتكون خوادم RDSH.
بمجرد أن ينتهي هذا المعالج من تثبيت الأدوار ومجموعات الميزات على خوادم بيئة RDS الخاصة بك، ستجد أنها مستعدة لعدم القيام بأي شيء على الإطلاق. خطوتنا التالية الحاسمة في بناء هذا النظام البيئي لـ RDS هي تكوين النظام نفسه، أو بدقة أكثر، مجموعة RDS الخاصة بنا.
مجموعتك الأولى من RDS
من خلال تثبيت أدوار أخرى في Windows Server، أنت على دراية بالفعل بحقيقة أن تثبيت الأدوار لا يؤدي إلى وظائف حتى تستثمر المزيد من الوقت والجهد في تكوين تلك الأدوار. نظام RDS لا يختلف. الآن بعد تثبيت الأدوار، اذهب وافتح Server Manager وتأكد مرة أخرى من أن جميع خوادم RDS الخاصة بك مضافة إلى Server Manager، حتى يتمكن من الاتصال بأي منها لسحب أو دفع المعلومات حسب الحاجة. سأستخدم Server Manager على RDS-MGMT، لأنني أخطط لأن يكون هذا الخادم هو مركز إدارة RDS الرئيسي.
تُعتبر مجموعة RDS عمومًا مجموعة من خوادم RDSH التي تكون جزءًا من تجمع أو "مزرعة" كما نذكر باستمرار. المجموعة في الواقع هي أكثر بكثير من مجرد الخوادم التي تتضمنها؛ فهي تشمل أيضًا جميع التكوينات والإعدادات التي ستلتزم بها الخوادم المعنية.
عندما يكون Server Manager متصلاً بالخوادم التي تم تثبيت مكونات RDS عليها، ستجد أن وظيفتك الأساسية في إدارة RDS تكون بالنقر على الكلمات Remote Desktop Services المدرجة على الجانب الأيسر من Server Manager. هذا هو المكان الذي ستقوم فيه بتكوين مجموعات RDS (نعم، يمكنك أن تكون لديك مجموعات متعددة)، إضافة أو إزالة خوادم RDSH من تلك المجموعات، وضبط إعدادات المجموعة؛ كما أنه المكان الذي ستضيف فيه المكونات الإضافية لنظام RDS التي لم نتمكن من إضافتها خلال معالج تثبيت الأدوار الأولي. ستلاحظ الرموز الخضراء بجانب RD Gateway وRD Licensing، وهنا بالضبط ستضغط لإضافة هذين المكونين. في الواقع، دعنا نفعل ذلك الآن.
إضافة RD Gateway و RD Licensing
الضغط على الرموز بجانب RD Gateway و RD Licensing سيؤدي إلى استدعاء معالجات صغيرة مشابهة لتلك التي استخدمناها قبل بضع دقائق لتحديد الوسيط وخوادم RDSH. ببساطة اختر الخادم الذي تريد أن يحتوي على كل من هذه الأدوار؛ سأضعهما معًا على RDS-MGMT. ستحتاج إلى اتخاذ بعض القرارات الإضافية حول كيفية عمل مكونات Gateway وLicensing. لاستخدام Remote Desktop Gateway يعني أنك ستقبل حركة المرور التي تأتي من خارج الشبكة، وستصل تلك الحواسيب العميلة إلى اسم DNS مثل gateway.contoso.com. لحماية هذه الحركة بشكل صحيح، ستحتاج بالطبع إلى تحديد اسم، الحصول على شهادة SSL لحماية ذلك الاسم، تثبيت الشهادة على خادم Remote Desktop Gateway، ثم تحديد اسمها هنا. بما أن هذا مختبر تجريبي وخادمي لا يمتلك حتى اتصالًا حقيقيًا بالإنترنت، يتعرف المعالج على عدم وجود شهادة SSL مثبتة وبدلاً من ذلك يطلب مني تحديد اسم يمكنه استخدامه لتوليد شهادة SSL موقعة ذاتيًا.
المعالج الصغير التالي لإضافة Remote Desktop Licensing بسيط جدًا، حيث يتطلب فقط تحديد RDS-MGMT كموقع لـ RD Licensing وتركه يقوم بالتثبيت. تثبيت تراخيص RDS CALs في License Manager هو أمر مختلف تمامًا، سنتحدث عنه لاحقًا في الفصل.
تكوين المجموعة (Collection configuration)
في هذه المرحلة، تكون جميع مكونات RDS قد تم تثبيتها على الخوادم الثلاثة. يتحمل RDS-MGMT معظم المسؤوليات، وخادما RDSH ينتظران بصبر، جاهزين لاستقبال جلسات المستخدمين التي سيتم إرسالها إليهما من خلال البوابة والوسيط.
كيف نفعل ذلك؟
الخطوة الوحيدة المتبقية لتوصيل العملاء بهذه البيئة من RDS هي تكوين المجموعة رسميًا، وهي مجموعة الإعدادات والخوادم التي ستجعل اتصالات RDS ممكنة. لا تزال داخل قسم Remote Desktop Services في Server Manager، ابحث عن الخيار في الجزء الأوسط من الشاشة المسمى Collections واضغط عليه. كما ترى، لا توجد مجموعات مدرجة حاليًا، ولكن إذا قمت بإسقاط قائمة TASKS في الزاوية العلوية اليمنى من الشاشة، يمكنك اختيار Create Session Collection لبدء العملية.
الخطوة الأولى هي ببساطة إنشاء اسم لمجموعتك: لا حاجة لشرح ذلك، ولكن من المهم ملاحظة أن هذا الاسم سيكون مرئيًا للمستخدمين عند تسجيل الدخول إلى Remote Desktop Web Access.
بعد ذلك، نحدد أي خوادم الجلسة (RDSH) ستكون جزءًا من هذه المجموعة. كما ذكرت سابقًا، سأقوم بتكوين مجموعتي الجديدة في البداية مع عقدتين، RDSH1 وRDSH2. نقل هذين الخادمين إلى العمود المحدد يعني أن هذين الخادمين سيكونان قادرين على استقبال الاتصالات لمجموعتي.
الآن ننتقل إلى شاشة مجموعات المستخدمين، وهنا تبدأ الأمور تصبح مثيرة. بشكل افتراضي، سترى مجموعة Domain Users الخاصة بنطاقك مدرجة هنا. إذا تقدمت للأمام بهذا الإعداد الافتراضي، في النهاية، أي مستخدم لديه حساب Active Directory في شبكتك سيكون لديه إذن لتسجيل الدخول إلى هذه المجموعة من RDS. بما أنني أريد أن أكون أكثر انتقائية بشأن من أسمح له بالدخول هنا، قمت بإزالة تلك المجموعة وأضافت بدلاً منها مجموعة أمان جديدة في Active Directory أنشأتها لهذا الغرض بالضبط، تسمى Contoso RDS Users.
شاشة الاختيار التالية تسمى **User Profile Disks**. سنناقش ما هي **UPDs** بالضبط في وقت لاحق في هذا الفصل، ولكن ملخص سريع هو أن كل مستخدم يسجل الدخول إلى **RDSH** يتلقى ملف تعريف **Windows**، تمامًا مثل أي كمبيوتر **Windows** آخر، وللحفاظ على اتساق ملف تعريف المستخدم بين خادمي **RDSH**، يجب تخزينه في موقع مركزي، بدلاً من تخزينه مباشرة على **RDSH1** و **RDSH2**. لقد أنشأت مشاركة ملفات بسيطة على خادم **RDS-MGMT** وسأستخدم هذا الموقع لتخزين **User Profile Disks**. ستلاحظ مربع معلومات بالقرب من أسفل هذه الشاشة يوضح أن كل خادم **RDSH** يحتاج إلى الحصول على أذونات التحكم الكامل ضمن هذه المشاركة. لقد أضفت **RDSH1** و **RDSH2** و **RDSH3** (للمستقبل) للحصول على أذونات التحكم الكامل على **NTFS** في المجلد والمشاركة الجديدة للملفات الشخصية لتلبية هذا المتطلب.
هذا هو كل شيء! استخدم شاشة التأكيد للتحقق من أن كل شيء يبدو صحيحًا، وعندما تنقر على زر **Create**، سنجد الآن مجموعتنا الجديدة داخل **Server Manager**.
النهاية
نكون هنا انتهينا من الجزء 1 من الفصل 14 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق ولكن في النهاية جدا
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
