PowerShell, WMI ו-CIM לאוטומציה מתקדמת במערכות Windows

אינפורמטק דיגיטל » Recursos » PowerShell, WMI ו-CIM לאוטומציה מתקדמת במערכות Windows

אם אתם עובדים בניהול מערכות Windows, במוקדם או במאוחר תיתקלו ב- PowerShell, WMI ואוטומציה מתקדמת . זה לא רק עניין של לדעת איך להריץ כמה פקודות: כשאתם מנהלים עשרות או מאות שרתים, אתם זקוקים לגישה רצינית, מובנית ומאובטחת לאיסוף מידע, יישום שינויים וחזרה על משימות מבלי להשתגע... או לשבור שום דבר.

בשורות הבאות, נחקור, ברוגע אך ביסודיות, כיצד למנף תקשורת מרחוק באמצעות WMI, CIM ו-PowerShell כדי להפוך הכל לאוטומטי, החל משאילתות פשוטות ועד לתרחישי תשתית מורכבים. נראה גם כיצד כל זה משתלב יחד עם מודולים, משימות רקע, Azure, Microsoft 365 וכמה תכונות מתקדמות שעושות שינוי אמיתי בעבודתו היומיומית של מנהל מערכת.

שיפורי PowerShell וסקירה כללית של אוטומציה מתקדמת

Windows PowerShell התפתח רבות מאז הגרסאות המוקדמות שלו, וחלק גדול מהאבולוציה הזו הגיע עם Windows Server 2012, שם שופרה התקשורת מרחוק, הורחבו רכיבי ה-cmdlet הזמינים, ודברים כמו ניפוי שגיאות, משימות רקע ונקודות קצה מוגבלות הפכו לקלים יותר כדי לשפר את האבטחה.

אחד הרעיונות המרכזיים מאחורי סביבה זו הוא שמנהלי מערכת יכולים ליצור התנהגויות דמויות cmdlet ללא קידוד נרחב , תוך ניצול תכונות מתקדמות, מודולים לשימוש חוזר ומערכת עזרה מקיפה. משמעות הדבר היא שבמקום להסתמך על כלים גרפיים שונים, ניתן לבנות קבוצה קוהרנטית של סקריפטים ומודולים אשר הופכים תהליכים לאוטומטיים לניהול שרתים, רשתות, Active Directory, Azure או Microsoft 365.

בתחום האוטומציה המתקדמת, בולטות גם תכונות כגון עבודות לביצוע משימות באופן אסינכרוני, זרימות עבודה, ניהול מבוסס תצורה עם PowerShell DSC, ואפשרויות אבטחה כגון JEA (Just Enough Administration) או PowerShell Web Access, המאפשרות שליטה מפורטת על מה שכל אדם יכול לעשות ומהיכן.

כל המערכת האקולוגית הזו משתלבת במיוחד עם WMI ו-CIM, מכיוון שמידע הניהול שנחשף על ידי מערכת ההפעלה (חומרה, שירותים, תהליכים , תצורת רשת, תוכנה מותקנת וכו') הופך לקבוצת אובייקטים שניתן לבצע שאילתות, לסנן ולשנות באמצעות פקודות PowerShell המיועדות לאוטומציה המונית.

WMI ו-CIM: מושגים מרכזיים והבדלים מעשיים

Windows Management Instrumentation, הידועה יותר בשם WMI, היא טכנולוגיה שאינה תלויה ב-PowerShell והיא חלק מ-Windows מזה שנים. היא חושפת מאגר של מידע ניהולי אודות מערכת ההפעלה, החומרה ויישומים רבים. למרות שהיא אינה תלויה ב-PowerShell, PowerShell ממנפת אותה באופן נרחב כדי להפוך משימות לאוטומטיות.

היורש הטבעי של WMI במערכת האקולוגית של PowerShell הוא פקודות ה-cmdlet של CIM (Common Information Model) , שהוצגו עם PowerShell 3.0. פקודות ה-cmdlet הללו מקובצות במודול CimCmdlets וכוללות פקודות כגון Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance ו-Remove-CimInstance, בין היתר.

בגרסאות ישנות יותר של Windows PowerShell, כגון Windows 10 PowerShell 5.1 או Windows 11 PowerShell, עדיין ניתן למצוא את פקודות ה-cmdlet הקלאסיות של WMI (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). עם זאת, פקודות ה-cmdlet הללו הוצאו משימוש ואינן כלולות עוד ב-PowerShell 6 ובגרסאות מאוחרות יותר, ולכן הן רלוונטיות רק לתחזוקת סקריפטים מדור קודם או סקירת קוד ישן.

כשמישהו מדבר על "שאילתות WMI עם cmdlets של CIM", זה לא סותר: cmdlets של CIM עדיין ניגשים למידע של WMI , אבל הם עושים זאת באמצעות פרוטוקולים מודרניים יותר כמו WSMan ו-API עקבי יותר. מבחינה מעשית, עבור פיתוחים חדשים, עליך להתמקד ב-CIM ולשקול cmdlets של WMI רק כאשר אתה צריך להעביר או להבין סקריפטים מדור קודם.

מבחינה היסטורית, מנהלים רבים השתמשו ב-VBScript עם שפת השאילתות WQL כדי לבצע שאילתות על WMI, לדוגמה, על ידי התחברות למרחב השמות root\CIMV2 ושאילתות על מחלקות כמו Win32_BIOS. ניתן לעשות שימוש חוזר באותה שאילתת WQL כיום עם Get-CimInstance על ידי העברת הפרמטר -Query, מה שמפשט מאוד את המעבר מ-VBScript ל-PowerShell מבלי שיהיה צורך לכתוב מחדש את הלוגיקה מאפס.

שימוש מעשי ב-Get-CimInstance ושאילתות יעילות

עבור עבודה יומיומית, הדרך הטבעית ביותר לבצע שאילתה ב-WMI באמצעות PowerShell היא להשתמש ב- Get-CimInstance עם הפרמטר -ClassName , במקום לכתוב שאילתות WQL מלאות. לדוגמה, כדי לקבל מידע על BIOS, ניתן להשתמש ב-Get-CimInstance -ClassName Win32_BIOS ותקבלו אובייקט עם מאפיינים כמו Manufacturer, Name, SerialNumber או SMBIOSBIOSVersion.

מכיוון שכל דבר ב-PowerShell הוא אובייקט, קל מאוד לסנן ולבחור רק את מה שאתה צריך . אם אתה מעוניין רק במספר הסידורי, אתה יכול לשלוח את התוצאה ל-`Select-Object -Property SerialNumber`, או להשתמש ב-`Select-Object -ExpandProperty SerialNumber` כדי להפיק מחרוזת פשוטה במקום אובייקט עם מאפיין. אפשרות נפוצה נוספת היא להשתמש בתחביר נקודה (`Get-CimInstance ...`).SerialNumber` כדי לגשת לערך ישירות.

ראוי לציין שכברירת מחדל, שאילתות WMI מחזירות יותר מאפיינים ממה שתשתמשו בהם בפועל . במחשב מקומי, זה בדרך כלל בסדר, אבל כשמתחילים לבצע שאילתות על מכונות מרוחקות רבות, זה מתבטא בזמן עיבוד נוסף ותעבורת רשת מיותרת. כאן נכנס לתמונה הפרמטר `-Property` של `Get-CimInstance`, המאפשר לכם להגביל אילו מאפיינים יאוחזרו מהמקור.

על ידי ציון -Property SerialNumber, לדוגמה, אתם מפחיתים את כמות הנתונים המועברים, מה שהופך את השאילתה למהירה ויעילה יותר, במיוחד בקנה מידה גדול . גישה זו של "בקשו רק את מה שאתם צריכים" היא המפתח בעת תכנון סקריפטים של מלאי או ביקורת הפועלים על עשרות או מאות מכונות.

לסיכום, Get-CimInstance מציע איזון רב עוצמה בין פשטות (שורת פקודה אחת) וגמישות , בין אם אתם עובדים עם מחלקות קונקרטיות, שאילתות WQL מדור קודם, או מאפיינים ספציפיים שברצונכם לייעל לצורך אחזור.

ייעוץ מרחוק עם CIM, מפגשים ופרוטוקולי WSMan/DCOM

כשאתם מתרחקים מהמחשב המקומי שלכם ומתחילים לגשת למכונות מרוחקות, מספר גורמים נכנסים לתמונה: הרשאות, פרוטוקול תקשורת וביצועים . למרות שאנשים רבים רואים ב-PowerShell "מסוכן", האמת היא שהוא לא מעניק לכם הרשאות נוספות: יש לכם בדיוק את אותן הרשאות כמו בממשק הגרפי או בכל כלי אחר, לא יותר ולא פחות.

אם תנסה להפעיל את `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` ללא הרשאות מספיקות במחשב זה, תקבל שגיאת "Access is denied" . הסיבה לכך אינה ש-PowerShell נכשל; אלא פשוט שלמשתמש שבאמצעותו אתה מפעיל את הסשן אין הרשאה לגשת למידע זה ב-WMI. ניתן לפתוח קונסולה כמנהל תחום, כמובן, אך משמעות הדבר היא שכל פקודה תבוצע עם הרשאות אלו, וזהו סיכון מיותר בסביבות רבות.

ההמלצה היא ליישם את עקרון ההרשאות הנמוכות ביותר ולהעלות הרשאות רק בעת הצורך . ב-cmdlets התומכים בפרמטר -Credential, ניתן לציין אישורים חלופיים רק עבור הפקודה המדוברת. לעומת זאת, Get-CimInstance אינו מקבל ישירות את -Credential, וכאן נכנס לתמונה CimSessions כפתרון אלגנטי.

CimSession הוא חיבור מתמשך למחשב מרוחק שניתן ליצור באמצעות New-CimSession, תוך העברת שם המחשב והאישורים (לדוגמה, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). הפעלה זו מאוחסנת במשתנה, כגון $CimSession, ולאחר מכן נעשה בה שימוש חוזר באמצעות Get-CimInstance באמצעות הפרמטר -CimSession במקום -ComputerName, מה שמאפשר לך לאחד שאילתות מרובות לחיבור יחיד.

בנוסף לדרישת האישורים, Get-CimInstance משתמש כברירת מחדל בפרוטוקול WSMan (מבוסס על WinRM) . משמעות הדבר היא שהמכונה המרוחקת חייבת להיות בעלת גרסת מחסנית WSMan 3.0 ומעלה, הנמצאת בדרך כלל ב-PowerShell 3.0 ומעלה. ניתן לבדוק את גרסת מחסנית WSMan במחשב באמצעות `Test-WSMan -ComputerName RemoteComputer` ולוודא שערך ה-"Stack" הוא 3.0 ומעלה כדי להשתמש בשיטת חיבור זו.

מפגשי CIM עם DCOM ותאימות לאחור

מערכות ה-cmdlet הישנות יותר של WMI, המבוססות על Get-WmiObject, מסתמכות על פרוטוקול DCOM, שעדיין נתמך על ידי גרסאות ישנות יותר של Windows . הבעיה היא שבמערכות מודרניות יותר, חומות אש חוסמות לעתים קרובות את DCOM כברירת מחדל, ומחייבות אותך לפתוח פורטים ספציפיים כדי להשתמש בו כפי שהוא, דבר שעלול להפר את מדיניות האבטחה של הארגון שלך.

רכיבי cmdlet של CIM מציעים דרך ביניים חזקה: ניתן ליצור אפשרויות הפעלה באמצעות `New-CimSessionOption -Protocol Dcom` , לשמור אותן במשתנה (לדוגמה, `$DCOM`), ולאחר מכן לשלב אותן עם `New-CimSession` כדי ליצור CimSession המשתמש ב-DCOM במקום ב-WSMan. זה מאפשר לך להתחבר לשרתים ישנים מאוד, אפילו כאלה שקדמו ל-Windows Server 2000, שבהם PowerShell אפילו לא מותקן.

בדרך כלל נוח לאחסן אישורי מנהל תחום או אישורי חשבון מוגבה במשתנה (לדוגמה, $Cred = Get-Credential ) כדי להימנע מהצורך להקליד אותם בכל פעם. לאחר מכן, בעזרת משהו כמו New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, ניתן להפעיל CimSession דרך DCOM לשרת ישן יותר שאינו תומך ב-WSMan אך יש לו WMI.

מנקודת מבטו של כותב התסריטים, היתרון העיקרי הוא שהפלט של `Get-CimInstance` לא משתנה בהתאם לפרוטוקול : מקבלים את אותם אובייקטים ומאפיינים בין אם משתמשים ב-WSMan או ב-DCOM. זה מפשט מאוד את הלוגיקה מכיוון שניתן לכלול את זיהוי הפרוטוקול המתאים בפונקציה ולתת לשאר הקוד לעבוד תמיד בשקיפות עם CimSessions.

למעשה, די נפוץ ליצור פונקציות מותאמות אישית שבודקות את WSMan באמצעות Test-WSMan, ואם הוא אינו זמין, נופלות אוטומטית לתוך DCOM באמצעות New-CimSessionOption. זה מאפשר לך לתקנן את יצירת CimSession בסביבות מעורבות עם שרתים מודרניים ושרתים מדור קודם, מבלי לשכפל לוגיקת חיבור בכל הסקריפטים שלך.

ניהול, רישום וניקוי של CimSessions

כאשר מתחילים להשתמש ב-CimSessions באופן נרחב, חשוב לעקוב אחריהם כדי להימנע מצבירת חיבורים מיותרים. בעזרת Get-CimSession, ניתן לרשום את כל ההפעלות הפתוחות , לראות לאיזו מכונה הן מצביעות ולבדוק באיזה פרוטוקול הן משתמשות (WSMAN או DCOM), דבר שימושי מאוד לאבחון בעיות קישוריות או אימות.

ניתן גם לאחזר את ההפעלות הקיימות במשתנה, לדוגמה $CimSession = Get-CimSession , ולהשתמש בהן בפקודה אחת Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS כדי לבצע שאילתה למספר מחשבים בו זמנית, תוך שילוב הפעלות WSMan ו-DCOM באותה פעולה.

לאחר שתסיים לנתח את המידע, מומלץ לסגור את ההפעלות כדי להימנע מהשארת משאבים פתוחים ללא צורך. ה- cmdlet Get-CimSession | Remove-CimSession מסיר את כל ה-CimSessions הפעילים מהפרופיל הנוכחי בבת אחת. לחלופין, ניתן להעביר הפעלות ספציפיות ל-cmdlet Remove-CimSession כדי לסגור רק חלק מהן.

עבודה בדרך זו מאפשרת לך לקבל מחזורי חיבור וניתוק מבוקרים , דבר המומלץ מאוד בעת שימוש בסקריפטים בתוך משימות מתוזמנות, ספרי ריצה של אוטומציה או צינורות אינטגרציה רציפה שיכולים להשאיר הפעלות תלויות אם לא מתכננים במפורש ניקוי זה.

PowerShell כשפת אוטומציה מקיפה

מעבר ל-WMI ול-CIM, PowerShell הפכה לשפת אוטומציה כללית , החורגת הרבה מעבר לסקריפט ניהול טיפוסי של Windows. ישנם ספרים וקורסים שלמים המוקדשים ליכולות המתקדמות שלה, המכסים הכל, החל מהתקנה על לינוקס ו-Windows ועד לפיתוח מודולים הניתנים להפצה דרך NuGet, ואפילו סביבות פיתוח מודרניות כמו Visual Studio Code.

נקודת התחלה נפוצה היא להבין לעומק את התכונות המתקדמות של PowerShell , המאפשרות לך להגדיר פרמטרים, לבצע אימות, ליצור פלט מובנה ולגשת לעזרה משולבת כמעט ברמה של cmdlet מקורי. משם, ארגון קוד למודולים מקל על עבודה שיתופית בתוך צוותי תפעול, שכן ניתן לגרסא ולפרסם מודולים אלה למאגרים פנימיים או ציבוריים מבוססי NuGet.

עבודה עם אובייקטים ומחלקות מותאמים אישית היא גם מפתח , ופותחת את הדלת למודלי נתונים עשירים בהרבה מאשר סקריפטים ליניאריים טיפוסיים. זה מאפשר לך ללכוד לוגיקה עסקית, לעשות שימוש חוזר במבנים ולתכנן ממשקי API פנימיים עבור צוות הניהול שלך, והכל מופעל על ידי מנוע PowerShell.

בתחום האוטומציה המתקדמת, משימות רקע וזרימות עבודה ממלאות תפקיד מכריע , ומאפשרות ניהול משימות אסינכרוניות, ביצוע פעולות ארוכות מבלי לחסום את הקונסולה ותזמור של רצפים מורכבים על פני מספר מכונות. יכולות אלו מתאימות באופן מושלם לשאילתות בכמות גדולה ל-WMI/CIM ותרחישי ניהול מרחוק, שבהם לעתים קרובות יש צורך להמתין למערכות שיישמו שינויים או יחזירו נתונים.

רכיב מפתח נוסף הוא PowerShell DSC (Desired State Configuration), המאפשר לך להגדיר את התצורה הרצויה של תשתית (תפקידים, תכונות, שירותים, קבצים, הגדרות אבטחה וכו') ולהחיל מצבים אלה שוב ושוב. בשילוב עם המידע שאתה מקבל דרך WMI/CIM, אתה יכול לזהות סטיות, לתקן אותן באופן יזום ולתחזק סביבות עקביות עם פחות מאמץ ידני.

ניהול מקומי, מרוחק וענן באמצעות PowerShell

ברמה המקומית, PowerShell מספקת פקודות cmdlet לניהול Active Directory Domain Services , הגדרת רשתות וניהול שרתים. ב-Windows 10 וגירסאות מאוחרות יותר, האינטגרציה עמוקה אף יותר, ומאפשרת לך להפוך הכל לאוטומטי, החל מיצירת אתרי אינטרנט ועד ניהול אובייקטי Active Directory ותצורת מתאמי רשת.

רכיב פחות מוכר אך שימושי מאוד הוא PSProviders ו-PSDrives , המאפשרים לך להתייחס למיקומי אחסון שונים (מערכת קבצים, רישום, Active Directory וכו') כאילו היו כוננים הניתנים לניווט. הודות לכך, תוכל, למשל, ליצור קבוצות Active Directory, מפתחות רישום או מבני תיקיות במחשבים מרוחקים באמצעות אותו תחביר שבו היית משתמש כדי לנווט בכונן הקשיח.

בכל הנוגע לניהול מרחוק, PowerShell משלב מערך רב עוצמה של תכונות לחיבור למחשב אחד או יותר וביצוע פקודות בשמך . ניתן להשתמש בהפעלות PSSession מתמשכות, בטכניקות מרחוק מתקדמות, תרחישים של אחד לרבים (לניהול שרתים מרובים בו זמנית), או תרחישים של אחד לאחד לאיתור ניפויים במקרים ספציפיים. כל זאת, כמובן, תוך כיבוד הארכיטקטורה ומודל האבטחה של הגישה מרחוק.

גם לענן יש תפקיד מהותי כיום. בעזרת Azure PowerShell ו-Azure Cloud Shell, ניתן לנהל מכונות וירטואליות, אחסון ומנויים ישירות משורת הפקודה. התקנת מודולי Azure PowerShell והיכרות איתם הן כמעט חובה אם אתם מנהלים סביבות היברידיות או סביבות המאוחסנות במלואן ב-Azure.

מצד שני, PowerShell גם ביסס את מעמדו ככלי מומלץ לניהול Microsoft 365 (Exchange Online, SharePoint Online, Teams, משתמשים ורישיונות). החל מיצירה וניהול חשבונות ועד לניהול משאבי Exchange Online, כולל קבוצות, אתרי SharePoint ו-Microsoft Teams, ניתן לתזמר הכל באמצעות סקריפטים שמפחיתים באופן דרסטי את העבודה הידנית בפורטל האינטרנט.

סקריפטים, צינורות עבודה ושיטות עבודה מומלצות

כדי להפיק את המרב מאוטומציה מתקדמת עם WMI ו-CIM, חיוני לשלוט במודל הצינור של PowerShell . בניגוד למעטפות אחרות, כאן לא מעבירים טקסט רגיל, אלא אובייקטים שלמים, מה שמאפשר לבחור, למיין, למדוד, לסנן, למנות ולשנות מידע בדיוק רב.

לימוד עבודה עם צינורות (pipelines) כרוך בשימוש נכון ב-cmdlets של בחירה וסינון , הבנת אופן ספירת אובייקטים מורכבים ולמידה כיצד להעביר נתונים בין פקודות וסקריפטים מבלי לאבד מידע. דבר זה מחוזק על ידי שימוש מאורגן במשתנים, מערכים וטבלאות גיבוב, אשר משמשים כמבני נתונים זמניים עליהם ניתן לבנות לוגיקה מתקדמת יותר.

השלב הבא הוא כתיבת הסקריפטים עצמם: אריזת פקודות לסקריפטים לשימוש חוזר עם בקרת זרימה (if, for, foreach), ייבוא ​​נתונים מקבצי CSV או פורמטים אחרים, טיפול בקלט משתמש, טיפול בשגיאות ורישום אירועים. כל זה מאפשר לך לעבור מפקודות מבודדות לכלים מובנים וחזקים יותר.

פתרון בעיות וטיפול בשגיאות חשובים במיוחד בסביבות אוטומציה בקנה מידה גדול עם WMI/CIM, מכיוון שהפסקת רשת, הרשאה שתצורתה אינה מוגדרת כראוי או מחלקה חסרה עלולים לשבש תהליך אם לא מנוהלים כראוי. בעזרת בלוקי try/catch, פעולות שגיאה הניתנות להגדרה ורישום מפורט, ניתן לצפות ולהגיב בצורה יעילה יותר למצבים אלה.

לבסוף, כל מה שקשור לפונקציות ולמודולים משלים את המעגל : אתם חותמים על סקריפטים כדי להבטיח את שלמותם, אורזים פונקציות למודולים, מפיצים מודולים אלה במאגרים פנימיים או ציבוריים ויוצרים מערכת אקולוגית של כלים משותפים בתוך הארגון שלכם. בדרך זו, כל פיתוח חדש ב-WMI, CIM או שליטה מרחוק משולב בחבילה קוהרנטית וקלה לתחזוקה.

כאשר משלבים את כל האמור לעיל - WMI/CIM, הפעלות מרחוק, סקריפטים, משימות אסינכרוניות, DSC, Azure ו-Microsoft 365 - מקבלים סביבה שבה אוטומציה מתקדמת עם PowerShell הופכת לליבת הניהול. עם בסיס איתן של שיטות עבודה מומלצות, שימוש חכם ב-CimSessions (עם WSMan ו-DCOM כאחד) ועיצוב סקריפטים מודולרי, ניתן לנהל תשתיות הטרוגניות באופן עקבי, מאובטח ויעיל בהרבה מאשר הסתמכות אך ורק על אשפים גרפיים או כלים מבודדים.