شهادة MCSA الفصل 11 : ال PowerShell الجزء 3 والأخير

sparrow
0

 



الفصل : 11

الجزء : 3

العنوان : ال PowerShell



إدارة الخادم عن بُعد


الآن وقد عملنا قليلاً في بيئة PowerShell المحلية واستكشفنا بعض الطرق التي يمكن استخدامها لبدء إنشاء السكربتات، حان الوقت لنلقي نظرة أقرب على كيفية تناسب PowerShell مع احتياجات الإدارة المركزية لديك. إذا بدأت في استخدام PowerShell لإدارة الخادم ولكنك ما زلت تستخدم RDP للدخول إلى الخوادم ثم فتح PowerShell من هناك، فإنك تفعل ذلك بشكل خاطئ. نعلم بالفعل أنه يمكنك إدخال الخوادم البعيدة في Server Manager بحيث يمكن إدارتها مركزيًا. كما نعلم أن الأدوات داخل Server Manager تقوم، في الغالب، بإصدار سلسلة من أوامر PowerShell عند النقر على الأزرار. بدمج هاتين المعلومتين، يمكننا الاستنتاج أن أوامر PowerShell يمكن تنفيذها بسهولة على الأنظمة البعيدة، بما في ذلك الأنظمة التي لم تقم بتسجيل الدخول إليها حاليًا.


مع أخذ هذه الفكرة والاستمرار فيها، سنلقي نظرة على المعايير اللازمة لتحقيق ذلك في بيئتنا الخاصة. سنتأكد من أن أحد خوادمنا جاهز لاستقبال اتصالات PowerShell البعيدة، ثم نستخدم موجّه PowerShell على جهاز آخر لسحب المعلومات وإجراء التغييرات على هذا الخادم البعيد.


إعداد الخادم البعيد


هناك بعض الأمور التي تحتاج إلى التشغيل والتمكين على خوادمك البعيدة حتى يتمكن PowerShell من الاتصال بها من جهاز مختلف. إذا كانت جميع خوادمك تعمل بنظام Windows Server 2022 (في الواقع، إذا كانت جميعها تعمل بنظام Windows Server 2012 أو أعلى)، فإن PowerShell remoting يكون مفعلًا افتراضيًا، وقد تتمكن من تخطي الأقسام القليلة التالية. ومع ذلك، إذا حاولت استخدام PowerShell remoting ولم ينجح ذلك، فمن المهم أن تفهم كيف يعمل هذا النظام تحت السطح. بهذه الطريقة، يمكنك استكشاف المشكلات وإعداد القدرات البعيدة يدويًا في حالة واجهت مشاكل أو كنت تعمل بنظم تشغيل أقدم حيث قد تكون هذه الخطوات ضرورية. من الممكن أيضًا أن تكون لديك سياسات أمان مسبقة تعطل المكونات المستخدمة بواسطة إمكانيات الاتصال البعيد لـ PowerShell، لذا إذا وجدت أن الوصول البعيد محظور، فهذه هي العناصر التي يجب التحقق منها على هذه الأنظمة.


خدمة WinRM


جزء من حل إدارة الخادم البعيد هو خدمة WinRM. تأكد ببساطة من أن هذه الخدمة قيد التشغيل. إذا قمت بإيقافها كنوع من الفوائد الأمنية أو تقوية النظام، فستحتاج إلى عكس هذا التغيير وتشغيل الخدمة مرة أخرى لاستخدام PowerShell remoting. يمكنك التحقق من حالة خدمة WinRM من خلال services.msc، أو بما أننا نستخدم PowerShell في هذا الفصل، يمكنك التحقق من ذلك باستخدام الأمر التالي:


Get-Service WinRM


ال Enable-PSRemoting


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


Enable-PSRemoting -Force



استخدام -Force في نهاية الأمر Enable-PSRemoting يتسبب في تنفيذ الأمر دون طلب تأكيد. هناك بعض الأشياء المختلفة التي يقوم بها Enable-PSRemoting في الخلفية هنا. أولاً، يحاول بدء خدمة WinRM. لماذا قمت بتحديد أنه يجب عليك التحقق منها يدويًا؟ لأنه إذا قمت بتعطيلها كجزء من استراتيجية تأمين النظام، ستتداخل مع هذه العملية. التحقق من WinRM قبل استخدام Enable-PSRemoting يزيد من فرص نجاحك عند تشغيل أمر Enable-PSRemoting. هناك شيئين آخرين يقوم بهما هذا الأمر: بدء المستمع لاتصالات البعد وإنشاء قاعدة جدار ناري على النظام للسماح بمرور هذه الحركة بنجاح.


إذا كنت تنوي استخدام PowerShell remoting على نطاق واسع، فمن المرهق التفكير في تسجيل الدخول إلى كل خادم وتشغيل هذا الأمر. لحسن الحظ، لا يتعين عليك ذلك! كما هو الحال مع معظم الوظائف في عالم Windows، يمكننا استخدام Group Policy لإجراء هذا التغيير تلقائيًا. أنشئ GPO جديد، واربطه وقم بتصفيته بشكل مناسب بحيث ينطبق فقط على الخوادم التي تريد إدارتها مركزيًا، ثم قم بتكوين هذا الإعداد:


Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service Set Allow remote server management through WinRM to Enabled.


السماح للأجهزة من مجالات أو مجموعات عمل أخرى


إذا كنت تعمل مع خوادم جميعها جزء من نفس المجال المؤسسي، وهو غالبًا ما يكون الحال، فإن المصادقة بين الأجهزة تكون سهلة التحقيق. فهي تثق ببعضها البعض تلقائيًا عند هذا المستوى. ومع ذلك، على الخادم الذي تقوم بإعداده لقبول الاتصالات البعيدة، إذا كنت تتوقع أن تكون هذه الأجهزة البعيدة أعضاء في مجال مختلف غير موثوق - أو حتى أعضاء في مجموعة عمل - فسيتعين عليك إصدار أمر آخر يدويًا لثقة الأجهزة الفردية التي ستتصل. على سبيل المثال، إذا كنت أخطط لإدارة جميع خوادمي من جهاز عميل يسمى Win10Client غير موثوق به من قبل الخوادم، فسأحتاج إلى تشغيل الأمر التالي على هذه الخوادم:


Set-Item wsman:\localhost\client\trustedhosts Win10Client


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


الاتصال بالخادم البعيد


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


استخدام -ComputerName


العديد من أوامر cmdlets المتاحة في PowerShell، خصوصًا تلك التي تبدأ بـ Get-، يمكن استخدامها مع المعامل -ComputerName. هذا يحدد أن الأمر الذي ستقوم بتشغيله يحتاج إلى التنفيذ ضد النظام البعيد الذي تحدده في قسم -ComputerName. في أمثلة PowerShell البعيدة لدينا، سأستخدم موجّه PowerShell على جهاز العميل Windows 10 للوصول إلى المعلومات على بعض الخوادم في الشبكة. أريد استعلام خدمة WinRM، للتأكد من أنها قيد التشغيل. لإثبات أنني أتواصل عن بُعد مع WEB3، ستظهر في المخرجات أنني استعلمت أولاً خدمة WinRM المحلية الخاصة بي، والتي قمت بتعطيلها على جهاز Windows 10 الخاص بي.


سترى في الشكل أن خدمة WinRM المحلية الخاصة بي تظهر على أنها متوقفة، ولكن عندما أقوم بإصدار نفس الأمر محددًا استعلام -ComputerName لـ WEB3، فإنه يصل ويبلغني أن خدمة WinRM تعمل بنجاح على خادم WEB3:


Hostname

Get-Service WinRM

Get-Service WinRM -ComputerName WEB3



بدلاً من ذلك، ربما أريد استعلام المثال الجديد لـ Server Core الذي أعددناه قبل قليل والتحقق من الأدوار المثبتة حاليًا على WEB4:


Get-WindowsFeature -ComputerName WEB4 | Where Installed



يمكن أن يقبل المعامل -ComputerName حتى أسماء خوادم متعددة في نفس الوقت. إذا كنت أرغب في التحقق من حالة خدمة WinRM على بعض خوادمي، من خلال استخدام أمر واحد، يمكنني فعل شيء مثل هذا:


Get-Service WinRM -ComputerName WEB1,WEB2,DC1


استخدام Enter-PSSession


من ناحية أخرى، في بعض الأحيان يكون لديك العديد من أوامر cmdlets التي تريد تشغيلها ضد خادم معين. في هذه الحالة، يكون من المنطقي استدعاء جلسة PowerShell بعيدة كاملة إلى ذلك الخادم البعيد. إذا فتحت PowerShell على نظامك المحلي واستخدمت أمر Enter-PSSession، سيتحول موجّه PowerShell إلى تمثيل بعيد كامل لـ PowerShell على ذلك الخادم البعيد. يمكنك بعد ذلك إصدار الأوامر في ذلك الموجّه، وسيتم تنفيذها كما لو كنت تجلس على موجّه PowerShell من وحدة التحكم في ذلك الخادم. مرة أخرى، أنا مسجل الدخول إلى جهاز العميل Windows 10 الخاص بي وفتحت PowerShell. ثم استخدمت الأمر التالي للاتصال عن بعد بخادم WEB4:


Enter-PSSession -ComputerName WEB4


سيتغير الموجه، مما يشير إلى أنني أعمل الآن في سياق خادم WEB4.

إذا لم يكن لدى حساب المستخدم الخاص بك الوصول إلى الخادم، يمكنك تحديد بيانات اعتماد بديلة لاستخدامها عند إنشاء هذا الاتصال البعيد. ببساطة أضف -Credential USERNAME إلى أمر Enter-PSSession لتحديد حساب مستخدم مختلف.


الأوامر التي أصدرها من هذه النقطة فصاعدًا سيتم تنفيذها ضد WEB4. دعونا نتحقق من ذلك. إذا تحققت من متغير $env:computername، يمكنك أن ترى أنه يعرض لي اسم المضيف WEB4:



وللتأكد من ذلك بشكل أكبر، إذا تحققت من الأدوار والميزات المثبتة في Windows، يمكنك أن ترى أن دور خادم الويب مثبت، كما أنجزنا عند تكوين Server Core ليكون خادم ويب. من الواضح أنني لا أملك دور خادم الويب مثبتًا على جهاز Windows 10 الخاص بي؛ PowerShell يسحب هذه البيانات من خادم WEB4:


Get-WindowsFeature | Where Installed



هذه أشياء قوية جدًا. نحن نجلس على جهاز الكمبيوتر المحلي لدينا، ولدينا جلسة PowerShell بعيدة تعمل إلى خادم WEB4، ونحن الآن قادرون على سحب كل أنواع المعلومات من WEB4 لأنه كما لو كنا نعمل من PowerShell مباشرة على ذلك الخادم. دعونا نخطو خطوة أخرى ونحاول إجراء تغيير تكوين على WEB4، فقط للتحقق من قدرتنا على ذلك. ربما يمكننا تثبيت ميزة جديدة على هذا الخادم. أنا أستخدم Telnet Client كثيرًا لاختبار اتصال الشبكة ولكن يمكنني أن أرى أنه غير مثبت حاليًا على WEB4:


Get-WindowsFeature -Name *telnet*


باستخدام أمر Add-WindowsFeature، يجب أن أكون قادرًا على تثبيت هذه الميزة بسرعة:


Add-WindowsFeature Telnet-Client


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


تكوين الحالة المرغوبة (DSC)Desired State Configuration


هناك بعض الوظائف القوية في الإصدارات الحديثة من PowerShell، التي توفرها ميزة تسمى **Desired State Configuration (DSC)**. DSC هي منصة إدارة متكاملة في PowerShell، والتي توفر وظائف وأوامر cmdlets جديدة يمكنك الاستفادة منها في سكربتاتك لتفعيل بعض الميزات الرائعة. كما يشير الاسم، يتيح لك تكوين الإعدادات داخل PowerShell التي ستوفر حالة مرغوبة. ماذا يعني ذلك؟ بشكل أساسي، يجعل DSC السكربتات التي تقوم ببنائها تعمل بنفس الطريقة عبر جميع الخوادم التي تطبقها عليها من خلال التأكد من أن الخوادم نفسها مكونة بنفس الطريقة.




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




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




يساعد DSC أيضًا في منع التغييرات غير المرغوبة على الخوادم. إذا حدد السكربت المدعوم بـ DSC أن خدمة معينة يجب أن تكون تعمل دائمًا على خوادمك، وتوقفت تلك الخدمة لسبب ما، يمكن أن يتدخل DSC للمساعدة في إعادة تشغيلها حتى لا تواجه تعطل. بدلاً من ذلك، قد يكون لديك سكربت يقوم بتكوين خادم وفقًا لمجموعة معينة من المعايير، ويأتي شخص آخر في قسم تكنولوجيا المعلومات ويقوم بتعديل التكوين على الخادم – ربما يقوم بإيقاف خدمة عن قصد لسبب ما. عادةً، قد يؤدي ذلك إلى تعطل لهذا الخادم، لكن DSC سيعيد تشغيل تلك الخدمة للحفاظ على حالتك المرغوبة المحددة أصلاً لهذا الخادم. يمكن اعتبار DSC كمشرف سكربتات، حيث يساعد في بناء تكوينات ستظل موحدة عبر منصات متعددة وتعمل بعد ذلك على التأكد من أن هذه التكوينات دائماً صحيحة.




بعد بناء تكوين يحدد العناصر التي تريد تثبيتها أو مراقبتها، يعمل محرك يسمى **Local Configuration Manager (LCM)** لضمان بقاء الموارد ضمن مواصفات التكوين. يقوم LCM بفحص النظام بانتظام، مراقبًا للانحرافات والتغييرات، ويتخذ الإجراءات اللازمة لإعادة خوادمك إلى DSC.




الهدف النهائي من DSC هو الحفاظ على كل شيء ثابت ومتسق عبر خوادمك وخدماتك. تنمو قدرات DSC وإمكانية الوصول إلى المزيد من الأماكن في نظام التشغيل باستمرار، حيث يتم إعادة كتابة الأدوار لقبول معلمات DSC والمراقبة. تساعد هذه التقنية في ضمان أن الخوادم تعمل دائمًا بمعاييرك المحددة، مما يساعد في الحفاظ على حالة التشغيل العالية بنسبة 99.999%.


موارد لتعلم المزيد عن DSC

- [Getting Started with DSC](https://docs.microsoft.com/en-us/powershell/scripting/dsc/getting-started/wingettingstarted?view=powershell-7.1)


- [Writing, Compiling, and Applying Configurations](

https://docs.microsoft.com/en-us/powershell/scripting/dsc/configurations/write-compile-apply-configuration?view=powershell-7.1)


- [Microsoft Virtual Academy Course on DSC](https://mva.microsoft.com/en-US/training-courses/getting-started-with-powershelldesired-state-configuration-dsc--8672?l=ZwHuclG1_2504984382)



ال Windows Terminal


في بداية هذا الفصل، أشرنا إلى **Windows Terminal**، وإذا كنت مستخدمًا لنظام Windows 11 فمن المحتمل أنك تفاعلت مع هذا الكونسول الجديد بالفعل. Windows Terminal ليس بديلاً عن الأوامر أو cmdlets التي تأتي عبر Command Prompt أو PowerShell، ولكنه كونسول جديد يمكننا من خلاله استخدام أي أمر، cmdlet، سكربت، أو أي شيء آخر لتشغيله الذي كنا نفتحه تقليديًا في إحدى الكونسولات الأخرى لتحقيقه. يمكن لـ Windows Terminal تشغيل العناصر من Command Prompt، PowerShell، WSL، SSH، وحتى Azure Cloud Shell Connector.


مزايا Windows Terminal


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


التثبيت على Windows Server 2022


لسوء الحظ، لا يتم تثبيت Windows Terminal افتراضيًا في Windows Server 2022. ولكن يمكنك تنزيل حزمة وتثبيتها بسهولة. إليك كيفية القيام بذلك:


1. تعرف على الإصدار الذي تقوم بتنزيله. تفضل بزيارة [GitHub](https://github.com/microsoft/terminal/releases) للحصول على أحدث إصدار.

2. استخدم PowerShell لتنزيل الحزمة:

Invoke-WebRequest -Uri https://github.com/microsoft/terminal/releases/download/ v1.16.10261.0/Microsoft.WindowsTerminal_Win10_1.16.10261.0_8wekyb3d8bbwe. msixbundle -outfile Microsoft.WindowsTerminal_Win10_1.16.10261.0_8wekyb3d8bbwe. msixbundle


3. بعد التنزيل، قم بتشغيل الأمر التالي في PowerShell لتثبيت الحزمة:


Add-AppxPackage -Path .\Microsoft.WindowsTerminal_Win10_1.16.10261.0_8wekyb3d8bbwe.msixbundle


4. إذا تلقيت أي رسائل خطأ حول الاعتماديات المفقودة، قم بتنزيل وتثبيت الملف الثاني من صفحة GitHub نفسها، والتي تنتهي بـ PreinstallKit.zip. قم بتنزيل هذا الملف واستخراجه في نفس الدليل ثم استخدم نفس الأمر Add-AppxPackage لتشغيل ملف APPX المناسب لخادمك.


ملخص


في Windows Server 2022، نرى في أماكن متعددة أن الإدارة عبر PowerShell هي المسار الموصى به للتفاعل مع خوادمنا. نظرًا لأن واجهات إدارة الرسوم البيانية هي الآن مجرد أصداف تقوم بتشغيل سكربتات PowerShell وخيار التثبيت الافتراضي لـ Windows Server هو Server Core، يمكننا أن نفترض أن الخوادم غير الموصولة والرائدة نحو الأوامر ستكون هي خوادم المستقبل لدينا.


على الرغم من أن PowerShell كان في جوهر وظائف نظام التشغيل منذ Server 2012، إلا أنني أعتقد أن العديد من المسؤولين لا يزالون ينظرون إلى PowerShell على أنه مجرد طريقة بديلة لإدارة الخوادم. "نعم، أعلم أنه موجود وأنه يجب أن أبدأ في استخدامه، وأن السكربتات تبدو رائعة، لكنني ما زلت أستطيع فعل أي شيء أريده باستخدام Command Prompt القديم أو زر الفأرة." تلك العقلية القديمة تتغير بسرعة.


لقد قمنا للتو بتثبيت Windows Terminal لأنفسنا، والذي يقدم بلا شك طريقة أفضل لتشغيل سكربتات وأوامر PowerShell مقارنةً بـ PowerShell shell نفسه؛ الشيء الوحيد الذي يمنعك من استخدامه هو أنت!


مع ازدياد التقنيات الجديدة، مثل DSC و PowerShell 7 مفتوح المصدر، يمكننا أن نرى أن PowerShell يبدأ في تطوير وظائف لا توجد ببساطة في أي مكان آخر في نظام التشغيل. هذا، بالإضافة إلى إمكانية الإدارة عن بُعد المقدمة بواسطة منصة PowerShell الموحدة التي يمكن استخدامها عبر جميع أجهزة Windows الحالية لديك (حتى ضد الخوادم الموجودة داخل Azure!)، يعني أننا سنرى بالتأكيد المزيد والمزيد من PowerShell في أنظمة تشغيل وخدمات Microsoft المستقبلية.



النهاية


نكون هنا انتهينا من الفصل 11 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق


و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها 


واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا  


او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله 


ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من     هنا 


يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من  

هنا


وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما



Tags

إرسال تعليق

0تعليقات

إرسال تعليق (0)

#buttons=(موافق!) #days=(20)

يستخدم موقعنا ملفات تعريف الارتباط لتحسين تجربتك. تاكد الان
Ok, Go it!