الفصل : 15
الجزء : 2
العنوان : ال Remote Desktop Services
الاتصال بها
ال Contoso RDS (اسم مجموعتي) يعمل الآن ويمكن الاتصال به. في هذه المرحلة، يمكنني الاتصال بمجموعتي الجديدة باستخدام اسم **DNS** الخاص بخادم **connection broker** **RDS-MGMT.contoso.local**. ومع ذلك، حددت أيضًا اسم **DNS** **gateway.contoso.com** في إعدادات **RD Gateway**، وهذا هو الاسم الأنظف والأسهل للاستخدام سواء كنت داخل المكتب أو خارجه. لكي أتمكن من استخدام هذا الاسم نفسه داخل وخارج الشبكة، أحتاج إلى إنشاء سجل **DNS** بهذا الاسم وتوجيهه إلى خادم **Gateway/Connection Broker**، في حالتي **RDS-MGMT**. لقد أنشأت هذا السجل في **DNS** الداخلي الخاص بي وأكدت الآن أن **gateway.contoso.com** يحل إلى 10.10.10.45، عنوان **IP** الخاص بـ **RDS-MGMT**.
مع حل **DNS**، أسجل الدخول إلى كمبيوتر العميل، وأفتح متصفح ويب، وأتلقى مطالبة تسجيل دخول عند زيارة **https://gateway.contoso.com/rdweb**.
تذكر أنه إذا لم تقم بعمل الحصول على شهادة **SSL** حتى الآن لاسم **DNS** الذي تحاول استخدامه هنا، فقد تتلقى بعض الأخطاء من متصفح الويب الخاص بك. احصل على شهادتك، وقم بتثبيتها على خادم **Remote Desktop Gateway**، وحددها داخل خصائص نشر **RDS** لحل هذا الموقف.
الوصول إلى هذا الموقع يثبت أن **Remote Desktop Web Access** يعمل، ولكن في المرة الأولى التي سجلت فيها الدخول إلى البوابة، لم أجد أي تطبيقات في انتظاري للإطلاق. لن أكذب، كنت مرتبكًا تمامًا لماذا لم يكن اتصال **Contoso RDS** مدرجًا في البوابة. استغرق الأمر مني وقتًا طويلاً جدًا لإدراك أنه عندما أنشأنا هذه المجموعة الجديدة، قمت بإزالة مجموعة **Domain Users** الافتراضية من الوصول وبدلاً من ذلك ضيقتها فقط على مجموعة **AD** الخاصة بي المسماة **Contoso RDS Users**. ما لم أفعله هو إضافة حساب المسؤول الخاص بي إلى تلك المجموعة، وبالتالي كنت أواجه بوابة **RD Web Access**، ولكن بدون أي شيء للنقر عليه.
بمجرد أن أضفت حساب المستخدم الخاص بي إلى مجموعة **Contoso RDS Users**، سجلت الدخول مرة أخرى إلى صفحة **rdweb** هذه ووجدت اتصالي بـ **Contoso RDS** في انتظاري. هذا هو تحقق جيد من أنه عندما تنشر العناصر من خلال **RDS**، فإنها تكون مرئية ويمكن الوصول إليها فقط للمستخدمين أو المجموعات التي حددتها لكل مجموعة. النقر المزدوج على هذا الاتصال ينزل ملف **RDP** في الموقع الافتراضي للتنزيلات في متصفح الويب الخاص بك. من هنا يمكنك إطلاق الاتصال عن طريق النقر على ملف **RDP** الذي تم تنزيله، أو يمكنك حتى زيارة مجلد التنزيلات الخاص بك ثم نسخ هذا الملف **RDP** للاحتفاظ به. على سبيل المثال، إذا قام المستخدم بحفظ هذا الملف **RDP** على سطح المكتب الخاص به، فإن الاتصالات المستقبلية بالمزرعة تكون بسيطة مثل النقر المزدوج على ذلك الملف؛ لا يحتاج حتى إلى تسجيل الدخول إلى بوابة **rdweb**.
سواء أطلقت هذا الملف **RDP** من داخل متصفح الويب الخاص بك، أو من مجلد التنزيلات الخاص بك، أو عن طريق نسخ الملف **RDP** إلى كمبيوتر آخر والنقر المزدوج عليه هناك، ستتم مطالبتك بتسجيل الدخول إلى مجموعة **RDS**. بمجرد المصادقة، سيتم تسجيل دخولك ومشاهدة جلسة سطح المكتب الافتراضية التي تستضيف بالكامل على أحد خوادم **RDSH** الخاصة بك. يمكنك رؤية لقطة الشاشة التالية التي تبين أن جلستي الأولى قد هبطت على **RDSH1**.
العديد من الشركات لا تتطلب حتى من مستخدميها تسجيل الدخول إلى بوابة **rdweb**. بدلاً من ذلك، إذا كنت قد حصلت بالفعل على هذه الملفات **RDP**، يمكنك توزيعها بسهولة على سطح المكتب للجميع عبر **Group Policy**.
لقد فعلناها! لقد قمنا ببناء خوادم **RDS** بنجاح، وإنشاء مجموعة، والاتصال بها.
تحرير خصائص النشر والمجموعة
إذا كنت قد عملت في بيئة **RDS** من قبل، فمن المحتمل أنك تعرف أن هناك خيارات وإعدادات متنوعة يمكن تمكينها أو تعطيلها، ولم نرَ الكثير منها في نصنا حتى الآن. تشغيل معالجات التكوين الأولية سيجعلك تحصل على مجموعة **RDS** وتشغيلها، ولكن زيارة شاشات التكوين مرة أخرى ستوفر لك الوصول إلى المزيد. يتم تعريف هذه الوظائف داخل قسم **Remote Desktop Services** في **Server Manager**، والذي كنا نعمل فيه حتى الآن، ولكن الآن بعد أن لدينا مجموعة منشورة بالكامل، يمكننا زيارة هذه الشاشات مرة أخرى والعثور على بعض الأزرار الإضافية.
خصائص النشر
المستوى الأعلى حيث قد تحتاج إلى عرض أو تغيير الإعدادات هو خصائص النشر. يمكنك العثور على هذه الخصائص من خلال الانتقال إلى صفحة **Collections** داخل **Server Manager**، حيث يمكنك رؤية معلومات حول جميع مجموعات **RDS** المختلفة التي تم إنشاؤها ضمن نشراتك (نعم، يمكنك أن تمتلك العديد من المجموعات!). بالقرب من الزاوية العلوية اليمنى من شاشة **COLLECTIONS**، يوجد قائمة منسدلة صغيرة **TASKS**، يمكنك من خلالها اختيار **Create Session Collection**، لإضافة مجموعة أخرى إلى النشر الخاص بك، أو **Edit Deployment Properties**.
خصائص النشر هي المكان الذي تحدد فيه أو تغير معلومات حول **Remote Desktop Gateway**، خادم ترخيص **Remote Desktop**، إعدادات محددة حول كيفية عمل **Remote Desktop Web Access**، والشهادات. سنزور شاشة الشهادات عندما نتحدث لاحقًا عن صيانة **RDS**. خصائص النشر هي المكان للزيارة للحصول على الإعدادات أو التكوينات التي لا تخص مجموعة **RDS** فردية. بدلاً من ذلك، تتعلق هذه الإعدادات بالبيئة الكاملة لـ **RDS**.
خصائص المجموعة
بالإضافة إلى خصائص دور **RDS** الشاملة، لديك بالطبع خيارات داخل كل مجموعة **RDS** يمكن أيضًا تعديلها. هذه هي الإعدادات الأكثر إثارة للاهتمام للاستعراض. ما زلنا داخل **Server Manager**، عند إضافة مجموعات **RDS** جديدة، ستلاحظ أن كل واحدة مدرجة بشكل منفصل، تحت قسم **Collections** الأساسي. اختيار أي مجموعة سيعرض العديد من المعلومات حول تلك المجموعة، مثل أي خوادم **RDSH** هي جزء من المجموعة وما هي جلسات المستخدمين النشطة حاليًا على هذه المجموعة. يمكنك رؤية في لقطة الشاشة التالية أن جلسة المسؤول الخاصة بي لا تزال نشطة على **RDSH1**. بالقرب من الجزء العلوي من هذه الشاشة يوجد قسم **PROPERTIES**، مع قائمة منسدلة أخرى **TASKS**. هذه المرة داخل **TASKS**، لدينا فقط عنصر واحد للنقر عليه - **Edit Properties**.
خصائص كثيرة هنا واضحة بذاتها، مثل تغيير اسم التجميع الخاص بك وتعديل إعدادات الأمان العامة لاتصالات مستخدمي RDS. مجموعة المستخدمين هي المكان الذي يمكنك فيه تغيير المستخدمين أو المجموعات المسموح لها بالوصول إلى هذا التجميع في أي وقت. يمكنك حتى تكوين تفاصيل المقاييس الخاصة بتوزيع الأحمال، والتي تخبر الوسيط المسؤولة عن اتصالات RDS بكيفية توزيع الجلسات الواردة عبر خوادم RDSH المتعددة. هناك شاشتان أساسيتان أود أن أستعرضهما بالتفصيل، لأنهما الأماكن التي أجد أن العديد من مديري RDS يزورونها بانتظام لإجراء تغييرات.
الجلسة
عند اتصال المستخدمين بجلسة RDS، يقوم تسجيل دخولهم بتشغيل العمليات واستهلاك الموارد من خادم RDSH المتصلين به. عند تسجيل خروج المستخدمين من جلساتهم، نادراً ما يقومون بتسجيل خروج فعلي وبالتالي إطلاق سراح تلك الموارد. بدلاً من ذلك، يقوم معظم المستخدمين بالنقر فوق الزر X في أعلى نافذة RDP الخاصة بهم، مما يغلق اتصالهم ولكنه يترك الجلسة الافتراضية مفتوحة على الخادم، إلى جانب أي موارد تستهلكها الجلسة. هذا السلوك المتعلق بفصل الاتصال هو مقصود، بحيث يمكن للمستخدمين إعادة الاتصال بـ RDS لاحقًا في اليوم ومتابعة ما كانوا يقومون به، مثل وضع الكمبيوتر المحمول في وضع السكون وإيقاظه مرة أخرى. ومع ذلك، عندما يكون لديك 25 أو 50 أو أكثر من الأشخاص الذين يمكنهم تسجيل الدخول إلى نفس خادم RDSH، يمكن أن يعني ذلك الكثير من الموارد المستهلكة دون داع، مما يؤثر سلبًا على هؤلاء المستخدمين الذين تم تسجيل دخولهم فعليًا إلى جلساتهم.
كل هذا يعني أنه من الشائع جدًا أن تقوم الشركات بتنفيذ سياسات مهلة الجلسة. شاشة "الجلسة" هي المكان المناسب للقيام بذلك. أكثر قطعتين من المعلومات شيوعًا لتعبئة هذه الشاشة هما كما يلي:
1. **End a disconnected session**: يعني أنه سيتم تسجيل خروج كامل لأي جلسات مستخدمين في حالة فصل بعد عدد معين من الدقائق أو الساعات. من الشائع تعيين هذا بين 1 و4 ساعات.
2. **Idle session limit**: يتم تكوينه عادةً لمدة 6 أو 8 ساعات. من خلال دمج هذين الحدين للجلسة، تضمن غالبًا أن يتم قطع اتصال جميع جلسات RDS تلقائيًا، ثم تسجيل الخروج، كل ليلة.
هذا يساعد في الحفاظ على استهلاك الموارد عند مستوى ثابت عبر خوادم RDSH، وعندما يقوم المستخدمون بتسجيل الدخول في الصباح التالي، يحصلون ببساطة على جلسة جديدة ويعيدون تشغيل تطبيقاتهم من هناك.
إعدادات العميل
شاشة إعدادات العميل هي إعداد آخر يزورونه بشكل دوري. عندما يتصل المستخدم بمزرعة RDS، من الممكن سحب الموارد المحلية من جهاز الكمبيوتر الخاص به إلى جلسة RDS. على سبيل المثال، يمكن أن يتم تلقائيًا ربط محركات الأقراص الصلبة أو الطابعات أو حتى الحافظة بجهاز الكمبيوتر المستخدم لتكون متاحة من داخل جلسة RDS. بهذه الطريقة، يمكن للمستخدمين نسخ النصوص أو الملفات بين جلسة خادم RDS وجهاز الكمبيوتر المحلي الخاص بهم، ويمكنهم حتى النقر فوق File>Print داخل جلسة RDS واختيار الطباعة إلى طابعتهم المنزلية. تحدث هذه الربط داخل قنوات RDP، وما إذا كانت تلك الوظائف مسموح بها يتم تحديده من خلال شاشة إعدادات العميل. ببساطة تحقق أو ألغِ تحديد الموارد المحلية التي تريد أن تكون متاحة من داخل جلسات المستخدمين في RDS.
إضافة خوادم RDSH إلى التجميع الخاص بك
أثناء بناء تجميع RDS الخاص بنا، حددنا خادمًا لاستخدامه كـ Gateway/Licensing/Web Access/Connection Broker، وأضفنا خادمين RDSH إلى التجميع. دعنا نفترض أن هذا كان قيد التشغيل لفترة من الوقت ولكننا الآن بدأنا نتجاوز التصميم الأصلي. حددنا هذه الخوادم RDSH لتتعامل مع حوالي 25 مستخدمًا لكل منها، ولكن شركتنا استمرت في النمو ولدينا الآن 60 شخصًا يسجلون الدخول كل يوم. RDSH1 وRDSH2 يمكنهم التعامل مع الوضع، ولكن المستخدمين يلاحظون البطء خلال أوقات الذروة من اليوم. الإجابة على هذا السؤال واضحة – نحن بحاجة إلى RDSH3.
لقد أنشأت نسخة أخرى من Windows Server 2022، والأشياء الوحيدة التي قمت بها حتى الآن هي إعطاؤه عنوان IP واسم مضيف وإضافته إلى مجالي. في سيناريو العالم الحقيقي، سأحتاج أيضًا إلى التأكد من أن جميع التطبيقات المثبتة تعكس تلك الموجودة في RDSH1 وRDSH2، بحيث عندما نقدم RDSH3 إلى المزرعة، لا يفتقر المستخدمون إلى أي تطبيقات قد يحتاجون إلى تشغيلها. ولكن في مختبري التجريبي، لم أقم بتثبيت التطبيقات على أي من خوادم RDSH الخاصة بي، لذلك لا يعتبر ذلك اعتبارًا حاليًا.
بافتراض تحقيق هذه القطع، فإن الإجراء التالي الذي نحتاج إلى القيام به هو إضافة RDSH3 إلى نفس مثيل Server Manager الذي أُدير منه مزرعتي بالفعل. هذه الخطوة ليست واضحة - لا شيء في وحدة التحكم سيخبرك بذلك، ولكنه يصبح منطقيًا بمجرد التفكير فيه. كيف يمكن لهذه النسخة من Server Manager الوصول إلى RDSH3 والتعامل معه لإدخاله في التجميع إذا لم نقم أولاً بإضافة RDSH3 كخادم مُدار داخل Server Manager؟ لحسن الحظ، تعرف بالفعل كيفية القيام بذلك، ولكن كتذكير سريع، توجه ببساطة إلى Manage > Add Servers وأضف اسم الخادم الجديد الخاص بك.
الآن بعد أن عرف Server Manager عن RDSH3، أود العودة إلى قسم Remote Desktop Services في Server Manager وزيارة علامة التبويب الرئيسية Overview. تعرض هذه الشاشة معلومات عالية المستوى حول نشر RDS الخاص بي، وهناك بعض الروابط السريعة بالقرب من أعلى هذه الشاشة. أحد هذه الروابط، الخيار 2، يقول Add RD Session Host servers. انقر على هذا الرابط، وحدد العقدة الجديدة RDSH، ويبدأ المعالج في تكوين هذا الخادم ليكون جزءًا من نشر RDS الخاص بك.
ولكن انتظر، هناك المزيد! نحن تقريبًا في خط النهاية، ولكن هناك خطوة أخرى يجب إكمالها قبل أن تتدفق جلسات المستخدمين إلى RDSH3. في هذه المرحلة، قام Server Manager بالوصول إلى RDSH3 وتثبيت مكونات سطح المكتب البعيد الضرورية عليه، وRDSH3 مرئي الآن داخل Server Manager لأنه جزء من نشر RDS الخاص بنا. ومع ذلك، يمكن أن يحتوي نشر RDS على العديد من التجميعات المختلفة، وهو المستوى الذي يحدث فيه الاتصال فعليًا. لذلك، كل ما نحتاج إلى القيام به هو إضافة RDSH3 إلى التجميع المناسب لـ RDS؛ في حالتي، هو التجميع الخاص بي المسمى Contoso RDS. لا يزال داخل قسم Remote Desktop Services في Server Manager، كل ما علي فعله هو النقر على تجميع Contoso RDS الخاص بي ثم التمرير إلى أسفل حيث يوجد قسم يسمى HOST SERVERS. هنا ستجد واحدة أخرى من قوائم TASKS المنسدلة، داخلها يوجد خيار لإضافة RD Session Host Servers. في حين أن هذا الخيار يسمى نفس الشيء بالضبط مثل المعالج الذي قمنا بتشغيله منذ لحظات لإضافة RDSH3 إلى نشرنا العام، نحتاج إلى تشغيل هذا الخيار أيضًا الآن لإضافة RDSH3 إلى هذا التجميع المحدد.
الآن بعد أن أصبح RDSH3 جزءًا من نشرنا وتجميعنا، سيتم تضمينه في توازن التحميل لهذا التجميع وستبدأ جلسات المستخدمين في التدفق إليه.
إيقاف RDSH للصيانة
من حين لآخر، ستحتاج إلى إزالة عقدة RDSH من التجميع حتى تتمكن من إجراء الصيانة عليها. ربما تحتاج إلى تثبيت تطبيق جديد أو تحديث تطبيق موجود، أو التحقيق في شيء ما وإصلاحه داخل Windows على تلك العقدة. هذه الوظائف شائعة جدًا لإزالة خادم RDSH مؤقتًا من التجميع وإضافته مرة أخرى لاحقًا. هذه الوظائف سريعة وبسيطة جدًا، وإذا كانت اللقطة الأخيرة للشاشة لا تزال محفورة في عقلك، فأنت بالفعل في المكان المناسب للقيام بذلك.
داخل قسم Remote Desktop Services في Server Manager، حدد اسم التجميع الخاص بك وانتقل إلى أسفل هذه الشاشة. هنا ستجد جميع الخوادم المضيفة التي هي جزء من التجميع الخاص بك؛ هذه هي خوادم RDSH التي تخدم حاليًا اتصالات المستخدمين. ببساطة انقر بزر الماوس الأيمن على عقدة وحدد الخيار الوحيد، "Do not allow new connections".
سيؤدي هذا فورًا إلى إيقاف وصول اتصالات المستخدمين الجديدة إلى RDSH3، ويمكنك أن ترى في اللقطة أنني قد قمت بالفعل بنفس الشيء على RDSH2، والذي يشير إلى Allow New Connections = False لتلك العقدة.
في هذه المرحلة، جميع الجلسات الجديدة للمستخدمين في تجميع RDS الخاص بنا ستذهب إلى RDSH1 – هذا الخادم سيكون مشغولاً! بمجرد الانتهاء من الصيانة على RDSH2 وRDSH3، يمكنني ببساطة النقر بزر الماوس الأيمن عليهما مرة أخرى وتحديد "Allow new connections" لإعادتهما فورًا إلى المزرعة.
العنوان في هذا القسم قال "drain-stop" – ماذا أعني بذلك؟ عندما تمنع خادم RDSH من استقبال الجلسات الجديدة، فإنه لا يغير أي شيء مع الجلسات الحالية. إذا كان هناك بالفعل مستخدمين متصلين بـ RDSH2 وRDSH3 في المثال أعلاه، فإن إجراءاتي لن تؤثر عليهم، وسيظلون متصلين بسعادة بتلك الخوادم. لن تتدفق أي اتصالات جديدة إلى هذه الخوادم، لذا عندما ينهي هؤلاء المستخدمون جلساتهم بشكل طبيعي أو يسجلون الخروج في نهاية اليوم، ثم يسجلون الدخول مرة أخرى في المرة القادمة، سيتم توجيههم إلى RDSH1 أو أي عقدة أخرى لا تزال مهيأة لاستقبال الاتصالات. هذا مهم لفهمه لأنه لا يمكنك توقع منع خوادم RDSH من استقبال الاتصالات وبدء العمل على تلك الخوادم على الفور. ستحتاج إما إلى تسجيل خروج المستخدمين بالقوة من تلك العقد، مما سيكون تدخليًا ومزعجًا لهم، أو إزالة RDSH من التجميع الخاص بها ثم الانتظار، ربما حتى يوم العمل التالي، لإجراء الصيانة.
تثبيت التطبيقات على RDSH
تثبيت التطبيقات مهم جداً في عالم RDS: أنت تقدم للمستخدمين جلسة سطح مكتب افتراضية تتوقع أن يعملوا منها، وللعمل، سيحتاجون إلى تشغيل التطبيقات اللازمة لأداء وظائفهم. وهذا يعني أنه يجب تثبيت هذه التطبيقات على كل خادم RDSH الذي قد تهبط عليه جلسة المستخدم. بشكل عام، يجب أن يحتوي كل خادم RDSH الذي هو جزء من نفس المجموعة على نفس التطبيقات المثبتة. هذا يعني أيضًا تثبيت نفس الإصدارات من نفس التطبيقات، لذلك يمكنك أن تتخيل أن تحديث التطبيقات وصيانتها يكون أكثر تعقيدًا على RDSH مقارنة بجهاز العمل العادي.
عدم وجود مستخدمين متصلين
عند تثبيت التطبيقات على خادم RDSH، يوصى بالتأكد من تسجيل خروج جميع المستخدمين من هذا الخادم (بخلاف نفسك، بالطبع). هذا يعيدنا إلى فهم كيفية إزالة العقد من المزرعة لأغراض الصيانة. لأن إزالة RDSH من مجموعته لا يعني أنه يمكن الوصول إليه فوراً لأداء تلك الصيانة، حيث يستمر في خدمة الاتصالات الحالية، وهذا يعني أيضًا أن العديد من الأحيان يتطلب تثبيت البرامج الجديدة على مجموعة RDS الحالية أيامًا عديدة من العمل:
- اليوم الأول: إيقاف RDSH1.
- اليوم الثاني: تم الآن تسجيل خروج المستخدمين من RDSH1؛ قم بتثبيت التطبيق على RDSH1 وأعده إلى المزرعة. الآن إيقاف RDSH2.
- اليوم الثالث: تم الآن تسجيل خروج المستخدمين من RDSH2؛ قم بتثبيت التطبيق على RDSH2 وأعده إلى المزرعة. الآن إيقاف RDSH3.
- اليوم الرابع: تم الآن تسجيل خروج المستخدمين من RDSH3؛ قم بتثبيت التطبيق على RDSH3 وأعده إلى المزرعة.
و! هذا الكثير من الأيام لتثبيت تطبيق واحد. بدلاً من ذلك، يمكنك على الأرجح تثبيت التطبيق على الثلاثة في نفس اليوم، في الساعة 3:00 صباحًا، لكن... حقاً.
... نعم، حتى للتحديثات
قواعد تثبيت البرامج تنطبق سواء كنت تثبت تطبيقًا جديدًا لم يكن على خادم RDSH من قبل، أو ببساطة تثبت تحديثًا لذلك التطبيق. إذا كان هناك أي مستخدمين مسجلين بالفعل في خادم RDSH ويحتمل أنهم يستخدمون التطبيق الذي تحاول تحديثه، فقد تواجه مشاكل. أو الأسوأ من ذلك، قد ينتهي مثبت التحديث بنجاح ولكن ربما لا يستطيع فعل كل ما يحتاج إلى فعله في الخلفية، مما قد يسبب لك مشاكل غامضة لاحقًا. من الأفضل أن تكون آمنًا بدلاً من الندم: تأكد من أنك عند تثبيت التطبيقات أو تحديثات التطبيقات على خادم RDSH أنك المستخدم الوحيد المسجل دخوله إليه.
وضع التثبيت
خادم RDSH هو بيئة متعددة المستخدمين مع ملفات تعريف المستخدمين المختلفة وخلايا التسجيل المنتشرة في جميع أنحاء نظام التشغيل. عند تثبيت التطبيقات على RDSH، يجب أن يضمن شيء ما توزيع الملفات والمفاتيح الضرورية إلى المواقع الصحيحة بحيث يتمكن كل حساب مستخدم من استخدامها. هل سبق لك أن ثبتت تطبيقًا وسألك، "هل تريد تثبيت هذا التطبيق للمستخدم الحالي فقط، أم للجميع على النظام؟" على خادم RDSH، بالطبع ستختار "للجميع على النظام" وتستمر. لحسن الحظ، معظم التطبيقات تكون مدركة لـ RDS، وتتعرف تلقائيًا عندما تقوم بتثبيتها على خادم RDSH، وتقوم بالتعديلات اللازمة في الخلفية لضمان تثبيت التطبيق بشكل صحيح.
لكن...
بعض مثبتات التطبيقات لا تفعل ذلك. ليس لديهم أي فكرة أو اهتمام في العالم حول أين تقوم بتثبيت تطبيقهم، وإذا قمت ببساطة بتسجيل الدخول إلى RDSH1 وتشغيل المثبت، فقد يعمل بشكل جيد بالنسبة لك، ولكنه قد يواجه كل أنواع المشاكل في أي جلسة مستخدم أخرى. بالطبع، لا تريد إعادة تثبيت التطبيق داخل كل جلسة مستخدم. هذا هو السبب، في كل مرة تقوم فيها بتثبيت أي تطبيق على أي خادم RDSH، يجب عليك أولاً وضع هذا RDSH في وضع التثبيت.
وضع التثبيت فريد لخوادم RDS وإذا كنت ستعمل معهم، فهو أمر يجب أن تحفظه الآن. إنه بسيط جدًا: قبل تشغيل مثبت التطبيق أو مثبت التحديث، افتح نافذة Command Prompt أو PowerShell ونفذ التالي:
change user /install
هذا كل شيء! خادم RDS الخاص بك الآن في وضع التثبيت، وهذا يجعل Windows يفهم أن أي مثبتات تحتاج إلى القليل من العناية. إذا كان المثبت على وشك وضع ملف أو مفتاح تسجيل في مكان قد يواجه مشكلات من حسابات المستخدمين الأخرى، فإن Windows سيعيد توجيه تلك الأشياء إلى مواقع أكثر مركزية.
عند الانتهاء من تثبيت التطبيق، ببساطة ضع الخادم الخاص بك مرة أخرى في وضع التنفيذ القياسي:
change user /execute
إذا كنت غير متأكد من الوضع الذي تعمل فيه حاليًا (من السهل أن تفقد المسار إذا كنت تثبت أشياء متعددة وتعيد التشغيل بين الحين والآخر)، يمكنك بسهولة معرفة الوضع الذي يعمل فيه الخادم حاليًا باستخدام:
change user /query
تذكر وضع التثبيت – فهو يساعد في تجنب الصداع. وتذكر أيضًا أن كل خادم RDSH في نفس المجموعة يجب أن يحتوي على نفس التطبيقات المثبتة لتوفير تجربة موحدة للمستخدمين في كل مرة يسجلون فيها الدخول.
ترخيص RDS
كل اتصال وارد يهبط على خادم RDS يجب أن يكون لديه ترخيص وصول العميل (CAL) صالح. هذه التراخيص متاحة للشراء من أي وسيلة طبيعية من خلالها تشتري تراخيص Windows Server الخاصة بك، لذا لا أستطيع أن أخبرك بالمكان الأفضل للحصول على هذه التراخيص، فقط أنك تحتاجها، وكيف تعمل. هناك نوعان من RDS CAL، وسنصف كلاهما، لكن الحقيقة هي أن معظم مزارع RDS في العالم تستخدم User CALs.
ال User CALs
ال User CALs هي الطريقة العادية للذهاب. كما يشير الاسم، كل مستخدم يتصل بمزرعة RDS الخاصة بك يحتاج إلى User CAL. يتم تثبيت هذه CALs على خادم ترخيص Remote Desktop الخاص بك، والذي كما في مختبر الاختبار الخاص بنا قد يتعايش مع بعض الأدوار الأخرى لـ RDS، وبمجرد تثبيت التراخيص يقوم خوادم RDSH بالتحقق مع خادم ترخيص Remote Desktop للتأكد من وجود تراخيص كافية للسماح بالاتصال.
حدود User CAL ليست مقيدة على المستوى التقني. على غرار الطريقة التي يعمل بها الكثير من تراخيص Microsoft، فهي أساسًا نظام شرفي. يمكنك شراء 20 User CALs لـ RDS، أو يمكنك شراء 150. أيًا كان ما تثبته على خادم الترخيص الخاص بك، سيضيء ذلك الضوء الأخضر لخوادم RDSH للسماح للمستخدمين بالاتصال، ومن تلك النقطة لا توجد مراقبة تحدث في نظام الترخيص لمعرفة ما إذا كان لديك بالفعل 20 شخصًا متصلين أو 300.
أيضًا، كما هو الحال مع كل تراخيص Microsoft الأخرى، لا تريد خداع هذا النظام. قد تحتاج منظمتك إلى أن تكون جزءًا من تحقق سنوي حيث يجب عليك تحديد ودفع أي تناقضات، أو قد تكون كبيرًا بما يكفي لتكون لديك ممثل ترخيص Microsoft، أو قد تعمل مع مزود خدمة وهم لن يضعوا أعناقهم على المحك من خلال السماح لك بخداع نظام الترخيص وشراء عدد أقل من CALs مما لديك من المستخدمين. تأكد من أنك تمتلك ما يكفي! تقع على عاتقك مسؤولية التأكد من أن جميع المستخدمين لديهم ترخيص صالح.
رخصة جهاز Device CALs
من النادر جدًا العثور على Device CALs (رخصة جهاز) في الواقع. كما يوحي الاسم، في هذا النموذج الترخيصي، لا تهتم RDS بعدد المستخدمين الذين يتصلون بل بعدد أجهزة الكمبيوتر الفريدة التي تتصل بمزرعة RDS الخاصة بك. يتم تقييد Device CALs (رخصة جهاز) على المستوى الفني. ينطبق هذا النوع من التراخيص على الأعمال التي لديها عدة نوبات من الأشخاص الذين يستخدمون نفس أجهزة الكمبيوتر. الفكرة العامة هي أنك ستملك Device CAL لكل محطة عمل تمتلكها. يحتفظ مدير ترخيص RDS بسجل من خلال شهادة مؤقتة عن أجهزة الكمبيوتر التي تتصل، وطالما لديك عدد من CALs يعادل عدد أجهزة الكمبيوتر، ستكون في أمان في هذا السيناريو.
المشكلة هي أن ما وصفتُه نادرًا ما يكون الطريقة التي تحاول الشركات استخدام Device CALs بها. بدلاً من ذلك، في الأماكن التي وجدتها فيها، يستخدمونها ببساطة لأنها أرخص، ويحاولون استخدامها كما لو كانت "Concurrent Connection CALs" - وهي ليست كذلك.
أحد الفوائد الرئيسية لبيئات RDS هي السهولة التي يمكنك من خلالها توفير وصول المستخدمين إلى أجهزة سطح المكتب الافتراضية الخاصة بهم من جهاز الكمبيوتر المنزلي. هل ستشتري حقًا Device CALs لكل جهاز منزلي قد يمتلكه كل من مستخدميك؟
عندما يتصل جهاز كمبيوتر بمزرعة RDS التي تستخدم Device CALs، يعرف مدير الترخيص ذلك ويسجله. يتم بعد ذلك تخصيص تلك الـ CAL لذلك الكمبيوتر المحدد لمدة حوالي 8 أيام. إذا لم يُعد الاتصال خلال تلك الفترة الزمنية، فإنها عادةً تسقط من خريطة الترخيص، ما لم تتصل مرة أخرى. بهذه الطريقة، قد تتمكن من استخدام عدد أقل من Device CALs مقارنة بالأجهزة، ولكنك دائمًا تلعب بالنار. هناك أيضًا وظيفة لإلغاء CALs يدويًا، وقد شاهدتُ حرفيًا مدراء يتعاملون مع هذه CALs بعقلية أنهم سيقومون بإلغاء جميع Device CALs الخاصة بهم كل يوم. هذا ليس فقط سخيفًا، بل إن مدير الترخيص لن يسمح لك بفعل ذلك على أي حال. يُسمح لك فقط بإلغاء ما يصل إلى 20% من CALs النشطة في أي وقت معين. ليس 20% كل يوم - 20% فقط.
الحالات الصالحة لاستخدام Device CALs نادرة جدًا. عند شراء RDS CALs، من الآمن عمومًا الاقتراب من هذا الشراء من خلال الافتراض أنك ستحتاج إلى User CALs (رخصة مستخدم).
تحديد خادم ترخيص RD
ربما لا تتذكر إعداد أي إعدادات ترخيص RDS أثناء نشر المزرعة لدينا، وذلك لأننا
لم نفعل ذلك أبدًا. تدخل بيئات RDS الجديدة تلقائيًا في فترة سماح لمدة 120 يومًا، حيث يتم السماح بجلسات المستخدم والاتصالات دون وجود أي ترخيص. بمجرد حصولك على RDS CALs الخاصة بك، ستحتاج إلى تحقيق شيئين لتشغيلها. تحديد خادم ترخيص RD داخل خصائص النشر وتوصيل CALs في Remote Desktop License Manager.
اذهب وقم بتعديل خصائص النشر الخاصة بك (وليس خصائص المجموعة) وزيارة الشاشة المسماة RD Licensing. هنا ببساطة تختار ما إذا كنت تستخدم تراخيص Per Device أو Per User، وتأكد من تحديد اسم خادم ترخيص Remote Desktop الخاص بك. هذا كل ما تحتاج إلى فعله لإخبار نشر RDS الخاص بك بالكامل بمكان خادم ترخيص Remote Desktop.
مدير ترخيص RD
بشكل غريب، لا يوجد ترتيبات داخل شاشات تكوين RDS القياسية لتطبيق أو مراجعة ترخيص RDS. لهذه المهمة، يجب علينا زيارة وحدة التحكم القديمة المستندة إلى MMC المتعلقة بهذا الموضوع. بمجرد تكوين خادم عبر Server Manager كخادم ترخيص RD الخاص بك، كما تم تكوين RDS-MGMT في مختبر الاختبار لدينا، ستجد مجلدًا جديدًا مدرجًا داخل أدوات إدارية يسمى Remote Desktop Services، وداخل ذلك المجلد أداة إدارة تسمى Remote Desktop Licensing Manager. عند تشغيل Remote Desktop Licensing Manager ستنتقل إلى المكان الذي يمكنك فيه إضافة تراخيص RDS CALs الجديدة، عرض الحالية منها، أو حتى إلغاء Device CALs إذا كان هذا السيناريو ينطبق عليك.
عند إنشاء بيئة RDS جديدة، ستحتاج إلى زيارة هذه الوحدة، والنقر بزر الماوس الأيمن على اسم خادم ترخيص Remote Desktop الخاص بك، استخدام معالج تفعيل الخادم للصق المفتاح الذي تلقيته من Microsoft والذي يحتوي على RDS CALs الخاصة بك، والمرور عبر المعالج لتفعيل تلك CALs. سيتحقق ذلك من خوادم تفعيل Microsoft، وبعد التفعيل الناجح، ستكون تراخيص RDS الخاصة بك جاهزة للعمل!
ملفات تعريف المستخدمين في RDS
بشكل عام، ملفات تعريف المستخدمين في عالم Microsoft Windows واضحة نسبيًا. يتم توثيق حساب المستخدم، عادةً عبر Active Directory، ويُسمح للمستخدم بتسجيل الدخول إلى أي جهاز كمبيوتر أو خادم يجلس أمامه. إذا كانت هذه هي المرة الأولى التي يقوم فيها المستخدم بتسجيل الدخول إلى هذا الكمبيوتر، يتم إنشاء ملف تعريف مستخدم جديد على هذا الكمبيوتر. هذه الملفات، ما لم تقم ببعض التعديلات الكبيرة على أنظمة التشغيل الخاصة بك، تتواجد جميعها داخل مجلد يسمى C:\Users. بالإضافة إلى ذلك، يتم إنشاء جزء جديد من السجل يحتوي على إعدادات محددة لهذا الحساب.
الملفات المحلية
عندما بدأ RDS حياته، كان يُعرف بـ Terminal Server، وكان هذا السلوك الافتراضي لملف تعريف المستخدم في عالم Windows هو ما يحدث بالضبط على الخوادم عندما يسجل المستخدم الدخول. هذا يعني أن كل خادم Terminal Server كان له دليل C:\Users الخاص به، والذي يمكن أن يحتوي على مئات الملفات المختلفة، واحدة لكل شخص قام بتسجيل الدخول إلى الخادم. هذا بحد ذاته ليس مشكلة، لكنه كان بالتأكيد مرهقًا للمستخدمين عندما يسجلون الدخول يوم الإثنين إلى TS1 ويضبطون جميع ملفاتهم وإعداداتهم، وفي صباح يوم الثلاثاء يسجلون الدخول مرة أخرى ويجدون أنفسهم في TS2 وتكون جميع هذه الإعدادات "مفقودة". تظل هذه الإعدادات على TS1، وفي المرة التالية التي يسجل فيها المستخدم الدخول ويحدث أن يكون على TS1، يرى كل شيء مرة أخرى، لكن اليوم ليس ذلك اليوم، واليوم يعيد ضبط كل شيء على TS2.
السماح لـ Terminal Server أو بيئة RDS باستخدام الملفات المحلية لـ Windows يعتبر فكرة ميتة بشكل فعال. دعني أوضح ذلك: هي فكرة ميتة بشكل فعال في عالم RDS؛ أجهزة الكمبيوتر المكتبية لـ Windows تستمر في وضع بيانات المستخدمين داخل C:\Users كسلوك طبيعي.
الملفات المتجولة (Roaming profiles)
من الواضح أن هناك حاجة إلى بعض التوحيد في ملفات تعريف المستخدمين، مما يمكن المستخدمين من الاحتفاظ بمجموعة معينة من الإعدادات وجعل هذه الإعدادات تتبع المستخدم، بغض النظر عن الخادم الذي يسجل الدخول إليه. الحل لهذا السؤال في العقد الأول من القرن الواحد والعشرين كان يسمى الملفات المتجولة. الملفات المتجولة تشبه الملفات المحلية، إلا أنها مخزنة في موقع مركزي. على الأرجح، الملفات المتجولة مخزنة على مشاركة ملفات شبكية، ربما شيء مثل \\FS1\RoamingProfiles. قامت Microsoft بدمج هذه الفكرة بقوة في نظامها البيئي. عندما يسجل المستخدمون الدخول إلى خادم Terminal أو خادم RDS، يتعرف Active Directory على أن هذا الحساب يحتوي على موقع ملف تعريف متجول ويعرف أيضًا عندما يسجل المستخدم الدخول إلى كمبيوتر مكتبي عادي مقابل RDS. في حالة تسجيل المستخدم الدخول إلى RDS، يتم إعادة توجيه ملف تعريف المستخدم نحو ملف التعريف على تلك المشاركة الشبكية، بدلاً من استخدام ملف محلي. كانت هذه فكرة رائعة وكانت المعيار الفعلي لسنوات عديدة. كانت الملفات المتجولة كبيرة جدًا لدرجة أن Microsoft قامت بتعديل شاشات تكوين المستخدم في Active Directory بحيث إذا كانت شركتك تستخدم الملفات المتجولة، عند إعداد حسابات مستخدمين جديدة، كل ما تحتاج إلى فعله هو تحديد موقع الملف على هذه الشاشة و Windows سيتولى الباقي نيابةً عنك. الآن في عام 2023، لا يزال هذا الخيار موجودًا.
لسوء الحظ، اليوم إذا سألت أي شخص عمل في مجال تكنولوجيا المعلومات لأكثر من 15 عامًا عن آرائه حول الملفات المتجولة، كن مستعدًا لردة فعل سيئة. على الرغم من أنها كانت فكرة رائعة، فإن الواقع المحيط بالملفات المتجولة هو أنها كانت غريبة. كان لسرعة الشبكة وزمن الوصول الكثير من التأثير، ولكن كان من الشائع أن تأخذ الملفات وقتًا طويلاً للتحميل عند تسجيل المستخدمين الدخول، أو تتلف نفسها، أحيانًا مما يؤدي إلى فقدان بيانات المستخدم. هناك بالتأكيد طرق لجعل الملفات المتجولة تعمل، لكنها لم تعد ممارسة شائعة بسبب ظهور...
أقراص ملفات التعريف الشخصية (UPDs)
الآن نجد أنفسنا ننظر إلى خيار الملف الافتراضي لخوادم Remote Desktop الحالية. فكرة UPDs تشبه كثيرًا الملفات المتجولة، ولكن بدلاً من مجموعة من الملفات والمجلدات التي تحتوي على ملف تعريف المستخدم الموجود على مشاركة شبكية، يتم احتواء ملف تعريف المستخدم داخل ملف VHDX الخاص به. بالنسبة لأي شخص اجتاز فصلنا عن Hyper-V، ستعرف أن هذا هو ملف القرص الصلب الافتراضي الخاص بـ Microsoft، وهو نفس نوع الملف المستخدم كقرص صلب افتراضي على خادم افتراضي.
يتم تخزين UPDs على مشاركة شبكية، وكل مستخدم يقوم بتسجيل الدخول إلى بيئة RDS يحصل على قرص افتراضي VHDX خاص به يتم تشغيله أثناء عملية تسجيل الدخول. يستغرق تسجيل الدخول الأول وقتًا أطول قليلاً بسبب إنشاء هذا الملف، ولكن بعد ذلك يبقى الملف سليماً بحيث تكون تسجيلات الدخول المستقبلية أسرع. بينما يكون المستخدمون مسجلين الدخول إلى خادم RDSH، يعتمدون بشكل أساسي على UPD الخاص بهم بحيث يتم حفظ الملفات أو الإعدادات المحفوظة داخل ملف تعريفهم على هذا القرص الافتراضي، ولكن ستجد أن C:\Users على خادم RDSH لا يزال يحتوي على ما يبدو أنها مجلدات ملفات تعريف مستخدمين كلاسيكية. هذا لأن RDSH لا يزال يحتاج إلى مكان محلي على الخادم للتفاعل معه، وعندما يسجل حساب مستخدم يعتمد على UPD الدخول، يتم سحب أجزاء معينة من المعلومات من VHDX الخاص بهم وتخزينها محليًا على خادم RDSH. من السهل التفكير في هذه المجلدات داخل C:\Users على أنها مواقع ملفات تعريف مؤقتة، فقط تذكر أن ملف تعريف المستخدم الأساسي هو ذلك الملف VHDX. هذا، بالطبع، يتيح للمستخدمين الوصول إلى أي من خوادم RDSH في التجميع والحصول على نفس تنسيق الملف، والإعدادات، والملفات بغض النظر عن مكان تسجيل الدخول.
إخبار بيئة RDS الخاصة بك لاستخدام UPDs بسيط جدًا. في الواقع، لقد قمنا بالفعل بذلك إذا كنت تتبع إنشاء هذا المختبر التجريبي. قم بإنشاء مشاركة شبكية في موقع مركزي حيث يمكن لجميع خوادم RDSH الوصول إليها، وتأكد من أن أذونات NTFS تمكّن جميع حسابات كمبيوترات RDSH من التحكم الكامل على هذا المجلد المشترك. هذا مهم لأن خوادم RDSH ستقوم بإنشاء ملفات VHDX جديدة عند تسجيل المستخدمين الجدد الدخول. ثم، داخل خصائص التجميع لـ RDS (يتم تكوين UPDs لكل تجميع، وليس لكل نشر)، قم بزيارة شاشة User Profile Disks وقم ببساطة بتحديد خانة Enable user profile disks. حدد موقع المشاركة الشبكية التي قمت بإنشائها لهذه الملفات VHDX لتكون موجودة، ثم اختر ما إذا كنت تريد تخزين جميع إعدادات المستخدم في هذا القرص أو فقط أجزاء مختارة.
تعمل أقراص ملفات التعريف الشخصية بشكل جيد وتستخدم في العديد من نشرات RDS عبر العالم اليوم. لديهم بعض السلوكيات المثيرة للاهتمام، كما ذكرت، لا يزال يتم إنشاء ملف تعريف مؤقت داخل C:\Users لكل مستخدم عند تسجيل الدخول، ولسبب ما من الشائع جدًا أن تكون خوادم RDSH التي تم تكوينها باستخدام UPDs مليئة بنسخ متعددة من هذا الملف المؤقت. يحدث هذا في كثير من الأحيان نتيجة لشيء ما يحدث خطأ أثناء تسجيل الدخول أو الخروج. إذا كان الملف المؤقت موجودًا بالفعل لمستخدم ما، أحيانًا أثناء عملية تسجيل الدخول التالية، بدلاً من إعادة استخدام نفس المجلد، يقرر خادم RDSH إنشاء ملف آخر. يؤدي هذا إلى فوضى في مجلد C:\Users على خادم RDSH، ولكنه بشكل عام لا يخلق مشاكل فعلية للمستخدمين، حيث يتم حفظ بياناتهم وإعداداتهم في النهاية داخل VHDX. إذا قمت بزيارة C:\Users على خوادم RDSH الخاصة بك، قد تجد شيئًا مشابهًا للصورة التالية. هنا قمت بتسجيل دخول حساب المسؤول الخاص بي والخروج من مزرعة RDS عدة مرات، مما أدى إلى وجود ملفات تعريف مؤقتة متعددة لحساب المسؤول.
عندما يحدث هذا، يكون التنظيف بسيطًا جدًا. هذه الحسابات المؤقتة ليست ضرورية، مرة أخرى حيث أن البيانات الفعلية داخل ملف VHDX. لذلك طالما أن حساب المستخدم ليس مسجلاً الدخول حاليًا إلى خادم RDSH الذي تنظر إليه، فإنه عادة ما يكون آمنًا ببساطة لحذف جميع نسخ هذه الملفات المؤقتة لذلك الحساب. إذا كان المستخدم مسجلاً الدخول ويستخدم أحد هذه الحسابات المؤقتة بنشاط، فمن المؤكد أنك قد ترغب في الانتظار حتى لا يكون مسجلاً الدخول إلى هذا الخادم.
ال FSLogix
غالبًا ما يكون من المناسب التفكير في خيارات ملفات تعريف المستخدمين لـ RDS بعقلية "جيد، أفضل، الأفضل". الملفات المتجولة جيدة، UPDs أفضل، وملفات تعريف FSLogix هي الأفضل على الإطلاق. كانت FSLogix شركة مستقلة تحسن من قدرات الملفات المركزية كإضافة تابعة لجهة خارجية، حتى استحوذت عليها Microsoft في عام 2018. ملفات تعريف RDS التي تُدار عبر سياسات FSLogix تشبه في الأيديولوجية UPDs، حيث يتم تخزين الملفات في موقع مركزي وتستخدم ملفات VHDX للحفاظ على البيانات. أحد الأسباب الرئيسية لاستخدام ملفات تعريف FSLogix بدلاً من UPDs الكلاسيكية هو في السيناريوهات التي تريد فيها أن يحصل المستخدمون على تجربة جيدة مع تطبيقات Microsoft Office داخل مزرعة RDS. تطبيقات Office لا تعمل دائمًا بشكل جيد مع UPDs، خصوصًا أشياء مثل ملفات Outlook OST. يعالج FSLogix ذلك ويجعل أوقات تسجيل الدخول أسرع بكثير في هذه السيناريوهات.
سبب كبير آخر للانتقال نحو ملفات تعريف FSLogix هو إذا كانت شركتك تستخدم OneDrive لمزامنة مستندات/سطح المكتب/صور المستخدمين عبر جميع أجهزتهم. هذه الآن قدرة مضمنة في عميل OneDrive وهي مفيدة جدًا للحفاظ على التناسق عبر أجهزة متعددة قد يسجل المستخدمون الدخول إليها، وللحفاظ على نسخة احتياطية عبر الإنترنت لبيانات مستنداتهم. خوادم RDS ليست صديقة تمامًا لـ OneDrive: غالبًا ما يضطر المستخدمون إلى الانتظار لفترات مزامنة كبيرة في كل مرة يسجلون فيها الدخول إلى جلسة RDS، وفي كثير من الحالات يفشل OneDrive في العمل ببساطة. هذا أحد المجالات التي يقوم فيها FSLogix بعمل أفضل بكثير من UPDs.
يحتوي FSLogix على بعض التحسينات لملفات تعريف Windows التي تمكّن تطبيقات Microsoft Office من التفاعل بشكل أفضل مع خوادم RDS، ويشمل أيضًا وظائف التحكم في الوصول للتطبيقات، الطابعات، وعدد قليل من العناصر الأخرى. عند تثبيت شيء مثل تطبيق أو طابعة على خادم RDSH، يكون صحيحًا عمومًا أن كل مستخدم يسجل الدخول إلى RDSH سيصل إليه. تتيح لك مجموعة قواعد التطبيقات في FSLogix القدرة على التحكم في الوصول إلى هذه الموارد عبر قواعد المستخدم أو عضوية المجموعة.
يمكن أن يكون تكوين FSLogix بسيطًا جدًا أو معقدًا جدًا. أقدم هذا كسبب لعدم مشينا معًا خلال إعداد ملفات تعريف FSLogix، حيث يمكن أن يذهب في اتجاهات عديدة مختلفة. في كثير من الحالات، كل ما تحتاج إلى فعله هو استيراد بعض ADMX/ADML إلى Active Directory، مما يوفر لك إعدادات تكوين FSLogix داخل Group Policy، وتكوين ما تريد هناك! بمجرد تحديد إعدادات FSLogix وتعيين هذا GPO إلى خوادم RDSH الخاصة بك، هناك عميل FSLogix ليتم تثبيته على تلك الخوادم نفسها، وبعد ذلك تكون ملفات تعريف FSLogix قيد التشغيل.
يتم إصدار إصدارات جديدة من FSLogix بانتظام، وغالبًا ما يتم تحديث الوثائق لتعكس التغييرات التي يتم إجراؤها، لذلك لبدء رحلتك الرسمية مع FSLogix، أرى أنه من الأفضل توجيهك إلى بداية وثائق Microsoft حول هذا الموضوع حيث قد تتغير التفاصيل قبل نشر هذا الكتاب:
https://learn.microsoft.com/en-us/fslogix/
تقول Microsoft، اعتبارًا من كتابة هذا النص، أن FSLogix يمكن استخدامه على أي نظام تشغيل مدعوم حاليًا من Microsoft، حتى الإشارة إلى Server 2012R2. ومع ذلك، في تجربتي، لا يعمل FSLogix دائمًا بشكل صحيح مع الإصدارات القديمة من نظام التشغيل عند استخدامه لتخزين ملفات تعريف RDS. بالفعل، لن أقوم شخصيًا بنشر FSLogix على أي شيء أقدم من Server 2019، بناءً على تجربتي الخاصة.
النهاية
نكون هنا انتهينا من الجزء 2 من الفصل 14 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق ولكن في النهاية جدا
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
