- WMI un PowerShell CIM cmdlet ļauj efektīvi vaicāt un modificēt lokālo un attālo pārvaldības informāciju.
- CimSessions ar WSMan vai DCOM nodrošina drošu un saderīgu piekļuvi modernām un novecojušām tīkla iekārtām.
- Izmantojot uzlabotas funkcijas, moduļus, uzdevumus un DSC, PowerShell pārvēršas par pilnīgu infrastruktūras automatizācijas valodu.
- PowerShell integrē lokālo, attālo, Azure un Microsoft 365 pārvaldību vienā vidē, samazinot atkārtotus manuālus uzdevumus.
Ja strādājat, administrējot Windows sistēmas, agrāk vai vēlāk jūs saskarsieties ar PowerShell, WMI un uzlabotu automatizāciju . Tas nav tikai jautājums par to, kā zināt, kā palaist dažas komandas: pārvaldot desmitiem vai simtiem serveru, jums ir nepieciešama nopietna, strukturēta un droša pieeja informācijas vākšanai, izmaiņu piemērošanai un uzdevumu atkārtošanai, neradot traku… vai neko nesabojājot.
Turpmākajās rindās mēs mierīgi, bet rūpīgi izpētīsim, kā izmantot WMI, CIM un PowerShell attālo saziņu , lai automatizētu visu, sākot no vienkāršiem vaicājumiem līdz sarežģītiem infrastruktūras scenārijiem. Mēs arī redzēsim, kā tas viss iederas kopā ar moduļiem, fona uzdevumiem, Azure, Microsoft 365 un dažām papildu funkcijām, kas būtiski ietekmē sistēmas administratora ikdienas darbu.
PowerShell uzlabojumi un uzlabotas automatizācijas pārskats
Kopš agrīnajām versijām Windows PowerShell ir ievērojami attīstījies , un liela daļa no šīs evolūcijas notika ar Windows Server 2012, kurā tika uzlabota attālā saziņa, paplašinātas pieejamās cmdlet iespējas un tādas lietas kā atkļūdošana, fona darbi un ierobežoti galapunkti tika atviegloti, lai uzlabotu drošību.
Viena no šīs vides galvenajām idejām ir tāda, ka administratori var izveidot cmdlet līdzīgas darbības bez plašas kodēšanas , izmantojot uzlabotas funkcijas, atkārtoti izmantojamus moduļus un visaptverošu palīdzības sistēmu. Tas nozīmē, ka tā vietā, lai paļautos uz atšķirīgiem grafiskiem rīkiem, var izveidot saskaņotu skriptu un moduļu kopu, kas automatizē serveru, tīklu, Active Directory, Azure vai Microsoft 365 pārvaldības procesus.
Uzlabotās automatizācijas jomā izceļas arī tādas funkcijas kā darbi uzdevumu asinhronai izpildei, darbplūsmas, uz konfigurāciju balstīta administrēšana ar PowerShell DSC un drošības opcijas, piemēram, JEA (Just Enough Administration) vai PowerShell Web Access, kas ļauj detalizēti kontrolēt, ko un no kurienes katra persona var darīt.
Visa šī ekosistēma īpaši labi iederas WMI un CIM, jo operētājsistēmas atklātā pārvaldības informācija (aparatūra, pakalpojumi, procesi , tīkla konfigurācija, instalētā programmatūra utt.) kļūst par objektu kopu, ko var vaicāt, filtrēt un modificēt, izmantojot PowerShell komandas, kas paredzētas masveida automatizācijai.
WMI un CIM: galvenie jēdzieni un praktiskās atšķirības
Windows pārvaldības instrumentācija (Windows Management Instrumentation), labāk pazīstama kā WMI, ir no PowerShell neatkarīga tehnoloģija , kas jau gadiem ilgi ir Windows sastāvdaļa. Tā nodrošina pārvaldības informācijas krātuvi par operētājsistēmu, aparatūru un daudzām lietojumprogrammām. Lai gan tā nav atkarīga no PowerShell, PowerShell to plaši izmanto uzdevumu automatizēšanai.
Dabisks WMI pēctecis PowerShell ekosistēmā ir CIM (Common Information Model) cmdlet , kas tika ieviesti ar PowerShell 3.0. Šīs cmdlet ir grupētas CimCmdlets modulī un ietver tādas komandas kā Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance un Remove-CimInstance, kā arī citas.
Vecākās Windows PowerShell versijās, piemēram, Windows 10 PowerShell 5.1 vai Windows 11 PowerShell, joprojām var atrast klasiskās WMI cmdlet (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Tomēr šīs cmdlet ir novecojušas un vairs nav iekļautas PowerShell 6 un jaunākās versijās, tāpēc tās ir svarīgas tikai mantotu skriptu uzturēšanai vai vecā koda pārskatīšanai.
Kad kāds runā par "WMI vaicājumu veikšanu ar CIM cmdlet", tas nav pretrunīgi: CIM cmdlet joprojām piekļūst WMI informācijai , taču to dara, izmantojot modernākus protokolus, piemēram, WSMan, un konsekventāku API. Praktiski jaunām izstrādēm jākoncentrējas uz CIM un jāapsver WMI cmdlet izmantošana tikai tad, ja ir nepieciešams migrēt vai saprast mantotos skriptus.
Vēsturiski daudzi administratori izmantoja VBScript ar WQL vaicājumu valodu, lai vaicātu WMI, piemēram, izveidojot savienojumu ar root\CIMV2 nosaukumtelpu un vaicājot tādas klases kā Win32_BIOS. To pašu WQL vaicājumu mūsdienās var atkārtoti izmantot ar Get-CimInstance, nododot parametru -Query, kas ievērojami vienkāršo pāreju no VBScript uz PowerShell, bez nepieciešamības pārrakstīt loģiku no jauna.
Get-CimInstance praktiska izmantošana un efektīvi vaicājumi
Ikdienas darbam dabiskākais veids, kā vaicāt WMI ar PowerShell, ir izmantot Get-CimInstance ar -ClassName parametru , nevis rakstīt pilnus WQL vaicājumus. Piemēram, lai iegūtu BIOS informāciju, varat izmantot Get-CimInstance -ClassName Win32_BIOS, un jūs saņemsiet objektu ar tādām īpašībām kā Ražotājs, Nosaukums, Sērijas numurs vai SMBIOSBIOSVersija.
Tā kā viss PowerShell ir objekts, ir ļoti viegli filtrēt un atlasīt tikai nepieciešamo . Ja jūs interesē tikai sērijas numurs, rezultātu var novirzīt uz `Select-Object -Property SerialNumber` vai izmantot `Select-Object -ExpandProperty SerialNumber`, lai izvadītu vienkāršu virkni objekta ar īpašību vietā. Vēl viena izplatīta iespēja ir izmantot punktu sintaksi (`Get-CimInstance ...`).SerialNumber`, lai tieši piekļūtu vērtībai.
Ir vērts atzīmēt, ka pēc noklusējuma WMI vaicājumi atgriež vairāk rekvizītu, nekā jūs faktiski izmantosiet . Lokālā datorā tas parasti ir labi, bet, ja sākat vaicāt daudzām attālām mašīnām, tas nozīmē papildu apstrādes laiku un nevajadzīgu tīkla trafiku. Šeit noder `Get-CimInstance` parametrs `-Property`, kas ļauj ierobežot no avota izgūtos rekvizītus.
Piemēram, norādot -Property SerialNumber, jūs samazināt pārsūtīto datu apjomu, padarot vaicājumu ātrāku un efektīvāku, īpaši plašā mērogā . Šī "prasiet tikai to, kas jums nepieciešams" mentalitāte ir ļoti svarīga, izstrādājot inventarizācijas vai audita skriptus, kas darbojas desmitiem vai simtiem mašīnu.
Rezumējot, Get-CimInstance piedāvā spēcīgu līdzsvaru starp vienkāršību (viena komandrinda) un elastību neatkarīgi no tā, vai strādājat ar konkrētām klasēm, mantotiem WQL vaicājumiem vai konkrētiem rekvizītiem, kurus vēlaties optimizēt izguvei.
Attālinātas konsultācijas ar CIM, sesijām un WSMan/DCOM protokoliem
Kad attālināties no lokālā datora un sākat piekļūt attāliem datoriem, ietekmē vairāki faktori: atļaujas, saziņas protokols un veiktspēja . Lai gan daudzi cilvēki uzskata PowerShell par "bīstamu", patiesībā tas nepiešķir nekādas papildu privilēģijas: jums ir tieši tādas pašas atļaujas kā grafiskajam interfeisam vai jebkuram citam rīkam, ne vairāk un ne mazāk.
Ja mēģināsiet palaist komandu `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` bez pietiekamām privilēģijām šajā datorā, jūs saņemsiet kļūdu "Piekļuve liegta" . Tas nav tāpēc, ka PowerShell nedarbojas; vienkārši lietotājam, ar kuru jūs palaižat sesiju, nav tiesību piekļūt šai informācijai WMI. Protams, jūs varat atvērt konsoli kā domēna administrators, taču tas nozīmē, ka jebkura komanda tiks izpildīta ar šīm privilēģijām, kas daudzās vidēs ir nevajadzīgs risks.
Ieteicams piemērot mazāko privilēģiju principu un paaugstināt privilēģijas tikai nepieciešamības gadījumā . Cmdlet komandās, kas atbalsta parametru -Credential, varat norādīt alternatīvus akreditācijas datus tikai attiecīgajai komandai. Tomēr Get-CimInstance tieši nepieņem -Credential, un šeit elegants risinājums ir CimSessions.
CimSession ir pastāvīgs savienojums ar attālo datoru, ko var izveidot ar New-CimSession, nododot datora nosaukumu un akreditācijas datus (piemēram, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Šī sesija tiek saglabāta mainīgajā, piemēram, $CimSession, un pēc tam atkārtoti izmantota ar Get-CimInstance, izmantojot parametru -CimSession parametra -ComputerName vietā, kas ļauj apvienot vairākus vaicājumus vienā savienojumā.
Papildus akreditācijas datu prasībai, Get-CimInstance pēc noklusējuma izmanto WSMan protokolu (pamatojoties uz WinRM) . Tas nozīmē, ka attālajam datoram ir jābūt WSMan steka versijai 3.0 vai jaunākai, kas parasti ir atrodama PowerShell 3.0 un jaunākās versijās. Varat pārbaudīt WSMan steka versiju datorā ar `Test-WSMan -ComputerName RemoteComputer` un pārliecināties, ka "Stack" vērtība ir 3.0 vai jaunāka, lai izmantotu šo savienojuma metodi.
CIM sesijas ar DCOM un atpakaļsaderību
Vecāki WMI cmdlet, kuru pamatā ir Get-WmiObject, izmanto DCOM protokolu, ko joprojām atbalsta vecākas Windows versijas . Problēma ir tā, ka modernākās sistēmās ugunsmūri bieži vien pēc noklusējuma bloķē DCOM, pieprasot atvērt noteiktus portus, lai to izmantotu tādā veidā, kas var pārkāpt jūsu organizācijas drošības politikas.
CIM cmdlet piedāvā spēcīgu kompromisu: sesijas opcijas var izveidot ar `New-CimSessionOption -Protocol Dcom` , saglabāt tās mainīgajā (piemēram, `$DCOM`) un pēc tam apvienot tās ar `New-CimSession`, lai ģenerētu CimSession, kas WSMan vietā izmanto DCOM. Tas ļauj izveidot savienojumu ar ļoti veciem serveriem, pat tiem, kas ir vecāki par Windows Server 2000, kur PowerShell pat nav instalēts.
Parasti ir ērti domēna administratora akreditācijas datus vai paaugstinātas piekļuves konta akreditācijas datus glabāt mainīgajā (piemēram, $Cred = Get-Credential ), lai tie nebūtu jāievada katru reizi. Pēc tam, izmantojot, piemēram, New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, varat sākt CimSession, izmantojot DCOM, uz vecāku serveri, kas neatbalsta WSMan, bet kam ir WMI.
No skriptētāja viedokļa galvenā priekšrocība ir tā, ka `Get-CimInstance` izvade nemainās atkarībā no protokola : jūs iegūstat tos pašus objektus un īpašības neatkarīgi no tā, vai izmantojat WSMan vai DCOM. Tas ievērojami vienkāršo loģiku, jo jūs varat iekapsulēt atbilstošā protokola noteikšanu funkcijā un ļaut pārējam kodam vienmēr darboties caurspīdīgi ar CimSessions.
Faktiski ir diezgan ierasts veidot pielāgotas funkcijas, kas testē WSMan ar Test-WSMan un, ja tas nav pieejams, automātiski nonāk DCOM, izmantojot New-CimSessionOption. Tas ļauj standartizēt CimSession izveidi jauktās vidēs gan ar moderniem, gan mantotiem serveriem, nereplicējot savienojuma loģiku visos skriptos.
CimSessions pārvaldība, saraksta izveide un tīrīšana
Kad sākat plaši izmantot CimSessions, ir svarīgi tās sekot līdzi, lai izvairītos no nevajadzīgu savienojumu uzkrāšanas. Izmantojot Get-CimSession, varat uzskaitīt visas atvērtās sesijas , redzēt, uz kuru datoru tās norāda, un pārbaudīt, kuru protokolu tās izmanto (WSMAN vai DCOM), kas ir ļoti noderīgi savienojamības vai autentifikācijas problēmu diagnosticēšanai.
Varat arī izgūt šīs esošās sesijas mainīgajā, piemēram, $CimSession = Get-CimSession , un izmantot tās vienā komandā Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS, lai vienlaikus veiktu vaicājumu vairākiem datoriem, apvienojot WSMan un DCOM sesijas vienā darbībā.
Kad esat pabeidzis šīs informācijas analīzi, ieteicams slēgt sesijas, lai nevajadzīgi neatstātu resursus atvērtus. Get-CimSession | Remove-CimSession cmdlet vienlaikus noņem visas aktīvās CimSession sesijas no pašreizējā profila. Varat arī nodot konkrētas sesijas cmdlet Remove-CimSession, lai aizvērtu tikai dažas no tām.
Šāda pieeja ļauj kontrolēt savienojuma un atvienošanas ciklus , kas ir ļoti ieteicams, ja skriptus izmantojat plānotajos uzdevumos, automatizācijas izpildes grāmatās vai nepārtrauktas integrācijas cauruļvados, kas var apturēt sesijas, ja šāda tīrīšana nav skaidri plānota.
PowerShell kā visaptveroša automatizācijas valoda
Papildus WMI un CIM, PowerShell ir kļuvusi par vispārējas nozīmes automatizācijas valodu , kas sniedzas tālu aiz tipiskā Windows pārvaldības skripta robežām. Tās paplašinātajām iespējām ir veltītas grāmatas un veseli kursi, kas aptver visu, sākot no instalēšanas operētājsistēmās Linux un Windows līdz izplatāmu moduļu izstrādei, izmantojot NuGet, un pat modernām izstrādes vidēm, piemēram, Visual Studio Code.
Bieži vien sākumpunkts ir rūpīgi izprast PowerShell uzlabotās funkcijas , kas ļauj definēt parametrus, veikt validāciju, ģenerēt strukturētu izvadi un piekļūt integrētai palīdzībai gandrīz vietējās cmdlet līmenī. Pēc tam koda organizēšana moduļos atvieglo sadarbību operāciju komandās, jo varat versijas veidot un publicēt šos moduļus iekšējās vai publiskās NuGet balstītās krātuvēs.
Darbs ar pielāgotiem objektiem un klasēm ir arī ļoti svarīgs , paverot durvis uz daudz bagātīgākiem datu modeļiem nekā tipiski lineārie skripti. Tas ļauj iekapsulēt biznesa loģiku, atkārtoti izmantot struktūras un izstrādāt iekšējās API jūsu vadības komandai, un to visu nodrošina PowerShell dzinējs.
Uzlabotas automatizācijas jomā fona darbplūsmām un darbplūsmām ir izšķiroša nozīme , kas ļauj pārvaldīt asinhronus uzdevumus, izpildīt garas darbības, nebloķējot konsoli, un organizēt sarežģītas secības vairākās iekārtās. Šīs iespējas ir ideāli piemērotas masveida vaicājumiem WMI/CIM un attālās administrēšanas scenārijos, kur bieži vien ir jāgaida, kamēr sistēmas ieviesīs izmaiņas vai atgriezīs datus.
Vēl viena svarīga sastāvdaļa ir PowerShell DSC (vēlamā stāvokļa konfigurācija), kas ļauj definēt vēlamo infrastruktūras konfigurāciju (lomas, funkcijas, pakalpojumus, failus, drošības iestatījumus utt.) un atkārtoti lietot šos stāvokļus. Apvienojumā ar informāciju, ko iegūstat, izmantojot WMI/CIM, varat atklāt novirzes, proaktīvi tās labot un uzturēt konsekventu vidi ar mazāku manuālu piepūli.
Lokāla, attāla un mākoņa pārvaldība ar PowerShell
Lokālā līmenī PowerShell nodrošina cmdlet Active Directory domēna pakalpojumu pārvaldībai , tīklu konfigurēšanai un serveru administrēšanai. Operētājsistēmā Windows 10 un jaunākās versijās integrācija ir vēl dziļāka, ļaujot automatizēt visu, sākot no tīmekļa vietņu izveides līdz Active Directory objektu pārvaldībai un tīkla adapteru konfigurēšanai.
Mazāk zināms, bet ļoti noderīgs komponents ir PSProviders un PSDrives , kas ļauj apstrādāt dažādas krātuves vietas (failu sistēmu, reģistru, Active Directory utt.) tā, it kā tās būtu navigācijas diski. Pateicoties tam, jūs varat, piemēram, izveidot Active Directory grupas, reģistra atslēgas vai mapju struktūras attālos datoros, izmantojot to pašu sintaksi, ko jūs izmantotu, lai pārvietotos cietajā diskā.
Runājot par attālo administrēšanu, PowerShell integrē jaudīgu funkciju kopumu, lai izveidotu savienojumu ar vienu vai vairākiem datoriem un izpildītu komandas jūsu vārdā . Varat izmantot pastāvīgas PSSession sesijas, uzlabotas attālinātās pārvaldības metodes, scenārijus “viens pret daudziem” (lai vienlaikus pārvaldītu vairākus serverus) vai scenārijus “viens pret vienu” konkrētu gadījumu atkļūdošanai. Tas viss, protams, ievērojot attālās piekļuves arhitektūru un drošības modeli.
Mūsdienās būtiska loma ir arī mākonim. Izmantojot Azure PowerShell un Azure Cloud Shell, varat pārvaldīt virtuālās mašīnas, krātuvi un abonementus tieši no komandrindas. Azure PowerShell moduļu instalēšana un iepazīšanās ar tiem ir gandrīz obligāta, ja pārvaldāt hibrīdas vai pilnībā Azure mitinātas vides.
No otras puses, PowerShell ir arī kļuvis par galveno rīku Microsoft 365 (Exchange Online, SharePoint Online, Teams, lietotāju un licenču) pārvaldībai. Sākot ar kontu izveidi un pārvaldību un beidzot ar Exchange Online resursu, tostarp grupu, SharePoint vietņu un Microsoft Teams, administrēšanu, visu var organizēt ar skriptiem, kas ievērojami samazina manuālo darbu tīmekļa portālā.
Skriptēšana, cauruļvadi un labākā darba prakse
Lai maksimāli izmantotu uzlaboto automatizāciju, izmantojot WMI un CIM, ir svarīgi apgūt PowerShell cauruļvada modeli . Atšķirībā no citiem čaulām, šeit netiek nodots vienkāršs teksts, bet gan pilni objekti, kas ļauj atlasīt, kārtot, mērīt, filtrēt, uzskaitīt un pārveidot informāciju ar lielu precizitāti.
Apguve strādāt ar cauruļvadiem ietver pareizu atlases un filtrēšanas cmdlet izmantošanu , izpratni par to, kā uzskaitīt sarežģītus objektus, un datu pārsūtīšanas starp komandām un skriptiem apguvi, nezaudējot informāciju. To pastiprina organizēta mainīgo, masīvu un jaucējtabulu izmantošana, kas darbojas kā pagaidu datu struktūras, uz kurām balstīt sarežģītāku loģiku.
Nākamais solis ir pati skriptēšana: komandu iepakošana atkārtoti izmantojamos skriptos ar plūsmas kontroli (if, for, foreach), datu importēšana no CSV failiem vai citiem formātiem, lietotāja ievades apstrāde, kļūdu apstrāde un notikumu reģistrēšana. Tas viss ļauj pāriet no izolētām komandām uz stabilākiem, iebūvētiem rīkiem.
Problēmu novēršana un kļūdu apstrāde ir īpaši svarīga liela mēroga automatizācijas vidēs ar WMI/CIM, jo tīkla pārtraukums, nepareizi konfigurēta atļauja vai trūkstoša klase var sabojāt procesu, ja tas netiek pareizi pārvaldīts. Izmantojot try/catch blokus, konfigurējamas kļūdu darbības un detalizētu reģistrēšanu, varat paredzēt un efektīvāk reaģēt uz šādām situācijām.
Visbeidzot, viss, kas saistīts ar funkcijām un moduļiem, noslēdz apli : jūs parakstāt skriptus, lai nodrošinātu to integritāti, iesaiņojat funkcijas moduļos, izplatāt šos moduļus iekšējās vai publiskās krātuvēs un izveidojat koplietojamu rīku ekosistēmu savā organizācijā. Tādā veidā jebkura jauna izstrāde WMI, CIM vai attālinātajā vidē tiek integrēta saskaņotā un viegli uzturējamā komplektā.
Apvienojot visu iepriekš minēto — WMI/CIM, attālinātās sesijas, skriptēšanu, asinhronos darbus, DSC, Azure un Microsoft 365 —, jūs iegūstat vidi, kurā uzlabota automatizācija ar PowerShell kļūst par administrēšanas pamatu. Ar stabilu labākās prakses pamatu, inteliģentu CimSessions izmantošanu (gan ar WSMan, gan DCOM) un modulāru skriptu dizainu jūs varat pārvaldīt heterogēnas infrastruktūras konsekventi, droši un daudz efektīvāk, nekā paļaujoties tikai uz grafiskiem vedņiem vai izolētiem rīkiem.
