- Ang mga CIM cmdlet ng WMI at PowerShell ay nagbibigay-daan sa iyong mahusay na mag-query at magbago ng impormasyon sa lokal at malayuang pamamahala.
- Ang CimSessions na may WSMan o DCOM ay nagpapadali sa ligtas at tugmang pag-access sa mga moderno at lumang kagamitang naka-network.
- Ang paggamit ng mga advanced na function, module, job, at DSC ay ginagawang isang kumpletong wika ng automation ng imprastraktura ang PowerShell.
- Isinasama ng PowerShell ang lokal, remote, Azure, at Microsoft 365 na pamamahala sa iisang kapaligiran, na binabawasan ang paulit-ulit na manu-manong gawain.
Kung nagtatrabaho ka sa pangangasiwa ng mga sistema ng Windows, malao't madali ay makakaranas ka ng PowerShell, WMI, at advanced automation . Hindi lang ito tungkol sa pag-alam kung paano magpatakbo ng ilang command: kapag namamahala ka ng dose-dosenang o daan-daang server, kailangan mo ng seryoso, nakabalangkas, at ligtas na paraan sa pangangalap ng impormasyon, paglalapat ng mga pagbabago, at pag-uulit ng mga gawain nang hindi nagkakamali... o nagkakaproblema.
Sa mga sumusunod na linya, ating tatalakayin, nang mahinahon ngunit lubusan, kung paano gamitin ang WMI, CIM, at PowerShell remote communication upang i-automate ang lahat mula sa mga simpleng query hanggang sa mga kumplikadong senaryo ng imprastraktura. Makikita rin natin kung paano magkakaugnay ang lahat ng ito kasama ang mga module, mga gawain sa background, Azure, Microsoft 365, at ilang mga advanced na tampok na may malaking epekto sa pang-araw-araw na gawain ng isang system administrator.
Mga pagpapahusay sa PowerShell at isang pangkalahatang-ideya ng advanced automation
Malaki na ang naging unlad ng Windows PowerShell simula noong mga unang bersyon nito, at malaking bahagi ng ebolusyong iyon ay dumating sa Windows Server 2012, kung saan pinahusay ang malayuang komunikasyon, pinalawak ang mga magagamit na cmdlet, at pinadali ang mga bagay tulad ng pag-debug, mga trabaho sa background, at mga pinaghihigpitang endpoint upang mapabuti ang seguridad.
Isa sa mga pangunahing ideya sa likod ng kapaligirang ito ay ang mga administrador ay maaaring lumikha ng mga pag-uugaling parang cmdlet nang walang malawak na coding , paggamit ng mga advanced na tampok, magagamit muli na mga module , at isang komprehensibong sistema ng tulong. Nangangahulugan ito na sa halip na umasa sa magkakaibang mga graphical na tool, maaari kang bumuo ng isang magkakaugnay na hanay ng mga script at module na nag-a-automate ng mga proseso para sa pamamahala ng mga server, network, Active Directory, Azure, o Microsoft 365.
Sa larangan ng advanced automation, namumukod-tangi rin ang mga tampok tulad ng mga trabahong asynchronous na isinasagawa ang mga gawain, mga daloy ng trabaho, configuration-based administration gamit ang PowerShell DSC, at mga opsyon sa seguridad tulad ng JEA (Just Enough Administration) o PowerShell Web Access, na nagbibigay-daan para sa detalyadong kontrol sa kung ano ang maaaring gawin ng bawat tao at kung saan mula.
Ang buong ecosystem na ito ay lalong akma sa WMI at CIM, dahil ang impormasyon sa pamamahala na inilalantad ng operating system (hardware, serbisyo, proseso , configuration ng network, naka-install na software, atbp.) ay nagiging isang hanay ng mga bagay na maaari mong i-query, i-filter, at baguhin gamit ang mga command ng PowerShell na idinisenyo para sa mass automation.
WMI at CIM: Mga Pangunahing Konsepto at Praktikal na Pagkakaiba
Ang Windows Management Instrumentation, mas kilala bilang WMI, ay isang teknolohiyang hindi umaasa sa PowerShell na bahagi na ng Windows sa loob ng maraming taon. Inilalantad nito ang isang imbakan ng impormasyon sa pamamahala tungkol sa operating system, hardware, at maraming aplikasyon. Bagama't hindi ito umaasa sa PowerShell, malawakan itong ginagamit ng PowerShell upang i-automate ang mga gawain.
Ang natural na kahalili ng WMI sa ecosystem ng PowerShell ay ang mga cmdlet na CIM (Common Information Model) , na ipinakilala kasama ng PowerShell 3.0. Ang mga cmdlet na ito ay nakapangkat sa module na CimCmdlets at kinabibilangan ng mga command tulad ng Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance, at Remove-CimInstance, bukod sa iba pa.
Sa mga mas lumang bersyon ng Windows PowerShell, tulad ng Windows 10 PowerShell 5.1 o Windows 11 PowerShell, makikita mo pa rin ang mga klasikong WMI cmdlet (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Gayunpaman, ang mga cmdlet na ito ay hindi na ginagamit at hindi na kasama sa PowerShell 6 at mga mas bagong bersyon, kaya ang mga ito ay mahalaga lamang para sa pagpapanatili ng mga legacy script o pagsusuri ng lumang code.
Kapag may nagsalita tungkol sa "pag-query sa WMI gamit ang mga CIM cmdlet," hindi ito magkasalungat: Ina-access pa rin ng mga CIM cmdlet ang impormasyon ng WMI , ngunit ginagawa nila ito gamit ang mas modernong mga protocol tulad ng WSMan at isang mas pare-parehong API. Sa praktikal na termino, para sa mga bagong development, dapat kang tumuon sa CIM at isaalang-alang lamang ang mga WMI cmdlet kapag kailangan mong mag-migrate o umunawa ng mga legacy script.
Sa kasaysayan, maraming administrator ang gumamit ng VBScript kasama ang WQL query language upang mag-query sa WMI, halimbawa, sa pamamagitan ng pagkonekta sa root\CIMV2 namespace at pag-query sa mga klase tulad ng Win32_BIOS. Ang parehong WQL query na iyon ay maaaring gamitin muli ngayon gamit ang Get-CimInstance sa pamamagitan ng pagpasa ng parameter na -Query, na lubos na nagpapadali sa paglipat mula sa VBScript patungo sa PowerShell nang hindi kinakailangang muling isulat ang lohika mula sa simula.
Praktikal na paggamit ng Get-CimInstance at mahusay na mga query
Para sa pang-araw-araw na gawain, ang pinakanatural na paraan upang mag-query sa WMI gamit ang PowerShell ay ang paggamit ng Get-CimInstance gamit ang parameter na -ClassName , sa halip na magsulat ng kumpletong WQL query. Halimbawa, upang makakuha ng impormasyon sa BIOS, maaari mong gamitin ang Get-CimInstance -ClassName Win32_BIOS at makakatanggap ka ng isang object na may mga property tulad ng Manufacturer, Name, SerialNumber, o SMBIOSBIOSVersion.
Dahil lahat ng bagay sa PowerShell ay isang object, napakadaling i-filter at piliin lamang ang kailangan mo . Kung ang serial number lang ang interesado ka, maaari mong i-pipe ang resulta sa `Select-Object -Property SerialNumber`, o gamitin ang `Select-Object -ExpandProperty SerialNumber` para mag-output ng simpleng string sa halip na isang object na may property. Ang isa pang karaniwang opsyon ay ang paggamit ng dot syntax (`Get-CimInstance ...`).SerialNumber` para direktang ma-access ang value.
Mahalagang tandaan na, bilang default, ang mga query sa WMI ay nagbabalik ng mas maraming property kaysa sa aktwal mong gagamitin . Sa isang lokal na makina, kadalasan ayos lang ito, ngunit kapag nagsimula kang mag-query sa maraming remote na makina, isinasalin ito sa karagdagang oras ng pagproseso at hindi kinakailangang trapiko sa network. Dito pumapasok ang parameter na `-Property` ng `Get-CimInstance`, na nagbibigay-daan sa iyong limitahan kung aling mga property ang kinukuha mula sa pinagmulan.
Sa pamamagitan ng pagtukoy ng -Property SerialNumber, halimbawa, binabawasan mo ang dami ng data na inililipat, na ginagawang mas mabilis at mas mahusay ang query, lalo na sa malawakang saklaw . Ang mentalidad na "magtanong lamang para sa kung ano ang kailangan mo" ay mahalaga kapag nagdidisenyo ng mga script ng imbentaryo o audit na tumatakbo sa dose-dosenang o daan-daang makina.
Sa buod, ang Get-CimInstance ay nag-aalok ng isang malakas na balanse sa pagitan ng pagiging simple (isang command line) at kakayahang umangkop , gumagamit ka man ng mga konkretong klase, mga lumang WQL query, o mga partikular na katangian na gusto mong i-optimize para sa pagkuha.
Mga konsultasyon sa malayo kasama ang CIM, mga sesyon at mga protocol ng WSMan/DCOM
Kapag lumayo ka sa iyong lokal na makina at nagsimulang mag-access sa mga malalayong makina, maraming salik ang nakakaapekto: mga pahintulot, protocol ng komunikasyon, at pagganap . Bagama't maraming tao ang nakakakita sa PowerShell bilang "mapanganib," ang totoo ay hindi ka nito binibigyan ng anumang karagdagang pribilehiyo: mayroon kang eksaktong parehong mga pahintulot tulad ng sa graphical interface o anumang iba pang tool, walang higit at walang kulang.
Kung susubukan mong patakbuhin ang `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` nang walang sapat na mga pribilehiyo sa makinang iyon, makakatanggap ka ng error na "Access is denied" . Hindi ito dahil sa nabigo ang PowerShell; ito ay dahil lamang sa ang user na iyong pinapatakbo ang session ay walang karapatang i-access ang impormasyong iyon sa WMI. Siyempre, maaari kang magbukas ng console bilang isang domain administrator, ngunit nangangahulugan ito na ang anumang command ay isasagawa gamit ang mga pribilehiyong iyon, na isang hindi kinakailangang panganib sa maraming kapaligiran.
Ang rekomendasyon ay ilapat ang prinsipyo ng least privilege at itaas ang mga pribilehiyo kung kinakailangan lamang . Sa mga cmdlet na sumusuporta sa parameter na -Credential, maaari kang tumukoy ng mga alternatibong kredensyal para lamang sa utos na pinag-uusapan. Gayunpaman, hindi direktang tinatanggap ng Get-CimInstance ang -Credential, at dito pumapasok ang CimSessions bilang isang eleganteng solusyon.
Ang CimSession ay isang persistent na koneksyon sa isang remote computer na maaari mong gawin gamit ang New-CimSession, na ipinapasa ang pangalan at mga kredensyal ng computer (halimbawa, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Ang session na ito ay iniimbak sa isang variable, tulad ng $CimSession, at pagkatapos ay muling ginagamit gamit ang Get-CimInstance gamit ang parameter na -CimSession sa halip na -ComputerName, na nagbibigay-daan sa iyong pagsamahin ang maraming query sa isang koneksyon.
Bukod sa kinakailangan sa mga kredensyal, ginagamit ng Get-CimInstance ang WSMan protocol (batay sa WinRM) bilang default . Nangangahulugan ito na ang remote machine ay dapat mayroong WSMan stack version 3.0 o mas mataas, na karaniwang matatagpuan sa PowerShell 3.0 at mas bago. Maaari mong suriin ang WSMan stack version sa isang makina na may `Test-WSMan -ComputerName RemoteComputer` at i-verify na ang value na "Stack" ay 3.0 o mas mataas upang magamit ang paraan ng koneksyon na ito.
Mga sesyon ng CIM na may DCOM at backward compatibility
Ang mga mas lumang WMI cmdlet na nakabatay sa Get-WmiObject ay umaasa sa DCOM protocol, na sinusuportahan pa rin ng mga mas lumang bersyon ng Windows . Ang problema ay, sa mas modernong mga sistema, kadalasang hinaharangan ng mga firewall ang DCOM bilang default, na hinihiling sa iyo na magbukas ng mga partikular na port upang magamit ito nang walang anumang problema, na maaaring lumabag sa mga patakaran sa seguridad ng iyong organisasyon.
Ang mga CIM cmdlet ay nag-aalok ng isang makapangyarihang gitnang landas: maaari kang lumikha ng mga opsyon sa sesyon gamit ang `New-CimSessionOption -Protocol Dcom` , i-save ang mga ito sa isang variable (halimbawa, `$DCOM`), at pagkatapos ay pagsamahin ang mga ito sa `New-CimSession` upang makabuo ng isang CimSession na gumagamit ng DCOM sa halip na WSMan. Nagbibigay-daan ito sa iyong kumonekta sa mga napakalumang server, kahit na sa mga nauna pa sa Windows Server 2000, kung saan hindi pa naka-install ang PowerShell.
Karaniwang maginhawang iimbak ang mga kredensyal o kredensyal ng administrator ng domain para sa isang nakataas na account sa isang variable (halimbawa, $Cred = Get-Credential ) upang maiwasan ang pag-type ng mga ito sa bawat pagkakataon. Pagkatapos, gamit ang isang bagay tulad ng New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, maaari kang magsimula ng CimSession sa pamamagitan ng DCOM sa isang mas lumang server na hindi sumusuporta sa WSMan ngunit may WMI.
Mula sa pananaw ng manunulat ng iskrip, ang pangunahing bentahe ay ang output ng `Get-CimInstance` ay hindi nagbabago depende sa protocol : makukuha mo ang parehong mga object at property kahit WSMan o DCOM ang gamitin mo. Lubos nitong pinapasimple ang lohika dahil maaari mong isama ang pagtukoy ng naaangkop na protocol sa isang function at hayaan ang natitirang bahagi ng code na laging gumana nang malinaw sa CimSessions.
Sa katunayan, karaniwan nang lumikha ng mga pasadyang function na sumusubok sa WSMan gamit ang Test-WSMan at, kung hindi ito magagamit, awtomatikong mapapasailalim sa DCOM gamit ang New-CimSessionOption. Nagbibigay-daan ito sa iyong i- standardize ang paglikha ng CimSession sa magkahalong kapaligiran na may parehong moderno at legacy server, nang hindi kinokopya ang connection logic sa lahat ng iyong script.
Pamamahala, paglilista at paglilinis ng CimSessions
Kapag sinimulan mo nang gamitin nang husto ang CimSessions, mahalagang subaybayan ang mga ito upang maiwasan ang pag-iipon ng mga hindi kinakailangang koneksyon. Gamit ang Get-CimSession, maaari mong ilista ang lahat ng bukas na sesyon , tingnan kung aling makina ang kanilang itinuturo, at suriin kung aling protocol ang kanilang ginagamit (WSMAN o DCOM), na lubhang kapaki-pakinabang para sa pag-diagnose ng mga problema sa koneksyon o pagpapatotoo.
Maaari mo ring kunin ang mga umiiral na sesyon na iyon sa isang variable, halimbawa $CimSession = Get-CimSession , at gamitin ang mga ito sa iisang command na Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS upang mag-query sa ilang computer nang sabay-sabay, na pinagsasama ang mga sesyon ng WSMan at DCOM sa parehong operasyon.
Kapag natapos mo na ang pagsusuri sa impormasyong iyon, mainam na isara ang mga sesyon upang maiwasan ang pag-iwan ng mga mapagkukunang bukas nang hindi kinakailangan. Ang Get-CimSession | Remove-CimSession cmdlet ay nag-aalis ng lahat ng aktibong CimSession mula sa kasalukuyang profile nang sabay-sabay. Bilang kahalili, maaari mong ipasa ang mga partikular na sesyon sa Remove-CimSession cmdlet upang isara lamang ang ilan sa mga ito.
Ang ganitong paraan ng pagtatrabaho ay nagbibigay-daan sa iyo na magkaroon ng kontroladong mga cycle ng koneksyon at pagdiskonekta , na lubos na inirerekomenda kapag gumagamit ng mga script sa loob ng mga naka-iskedyul na gawain, mga automation runbook, o mga pipeline ng patuloy na integrasyon na maaaring mag-iwan ng mga session na nakabitin kung hindi mo tahasang pinaplano ang paglilinis na iyon.
PowerShell bilang isang komprehensibong wika ng automation
Higit pa sa WMI at CIM, ang PowerShell ay naging isang pangkalahatang-gamit na wika ng automation na higit pa sa karaniwang script ng pamamahala ng Windows. May mga libro at kumpletong kurso na nakatuon sa mga advanced na kakayahan nito, na sumasaklaw sa lahat mula sa pag-install sa Linux at Windows hanggang sa pagbuo ng mga distributable module sa pamamagitan ng NuGet, at maging sa mga modernong development environment tulad ng Visual Studio Code.
Ang isang karaniwang panimulang punto ay ang lubusang pag-unawa sa mga advanced na tampok ng PowerShell , na nagbibigay-daan sa iyong tukuyin ang mga parameter, magsagawa ng pagpapatunay, bumuo ng nakabalangkas na output, at ma-access ang integrated help halos sa antas ng isang katutubong cmdlet. Mula roon, ang pag-oorganisa ng code sa mga module ay nagpapadali sa collaborative work sa loob ng mga operations team, dahil maaari mong i-version at i-publish ang mga module na ito sa mga internal o pampublikong NuGet-based repository.
Mahalaga rin ang paggamit ng mga custom na object at klase , na nagbubukas ng pinto sa mas mayamang data model kaysa sa mga tipikal na linear script. Nagbibigay-daan ito sa iyong isama ang business logic, muling gamitin ang mga istruktura, at magdisenyo ng mga internal API para sa iyong sariling management team, na lahat ay pinapagana ng PowerShell engine.
Sa larangan ng advanced automation, ang mga background job at workflow ay may mahalagang papel , na nagbibigay-daan sa pamamahala ng mga asynchronous na gawain, ang pagpapatupad ng mahahabang operasyon nang hindi hinaharangan ang console, at ang orkestrasyon ng mga kumplikadong sequence sa maraming makina. Ang mga kakayahang ito ay perpektong akma para sa mga bulk query sa WMI/CIM at mga senaryo ng remote administration, kung saan madalas na kinakailangang maghintay para sa mga system na magpatupad ng mga pagbabago o magbalik ng data.
Ang isa pang mahalagang bahagi ay ang PowerShell DSC (Desired State Configuration), na nagbibigay-daan sa iyong tukuyin ang ninanais na configuration ng isang imprastraktura (mga tungkulin, feature, serbisyo, file, setting ng seguridad, atbp.) at paulit-ulit na ilapat ang mga estadong iyon. Kasama ng impormasyong nakukuha mo sa pamamagitan ng WMI/CIM, matutukoy mo ang mga paglihis, maagap na itama ang mga ito, at mapapanatili ang mga pare-parehong kapaligiran nang may mas kaunting manu-manong pagsisikap.
Pamamahala ng lokal, remote, at cloud gamit ang PowerShell
Sa lokal na antas, ang PowerShell ay nagbibigay ng mga cmdlet para sa pamamahala ng mga Serbisyo ng Domain ng Active Directory , pag-configure ng mga network, at pangangasiwa ng mga server. Sa Windows 10 at mga mas bagong bersyon, mas malalim pa ang integrasyon, na nagbibigay-daan sa iyong i-automate ang lahat mula sa paggawa ng mga website hanggang sa pamamahala ng mga Active Directory object at pag-configure ng mga network adapter.
Ang isang hindi gaanong kilala ngunit lubhang kapaki-pakinabang na bahagi ay ang PSProviders at PSDrives , na nagbibigay-daan sa iyong ituring ang iba't ibang lokasyon ng imbakan (file system, registry, Active Directory, atbp.) na parang mga navigable drive ang mga ito. Dahil dito, maaari kang, halimbawa, lumikha ng mga grupo ng Active Directory, mga registry key, o mga istruktura ng folder sa mga malalayong computer gamit ang parehong syntax na gagamitin mo upang mag-navigate sa hard drive.
Tungkol sa remote administration, isinasama ng PowerShell ang isang makapangyarihang hanay ng mga tampok para sa pagkonekta sa isa o higit pang mga computer at pagpapatupad ng mga utos para sa iyo . Maaari kang gumamit ng mga persistent PSSession session, mga advanced na pamamaraan sa pag-remote, mga one-to-many scenario (upang pamahalaan ang maraming server nang sabay-sabay), o mga one-to-one scenario para sa pag-debug ng mga partikular na kaso. Siyempre, ang lahat ng ito ay ginagawa habang nirerespeto ang arkitektura at modelo ng seguridad ng remote access.
Ang cloud ay gumaganap din ng mahalagang papel ngayon. Gamit ang Azure PowerShell at Azure Cloud Shell, maaari mong pamahalaan ang mga virtual machine, storage, at mga subscription nang direkta mula sa command line. Ang pag-install ng mga Azure PowerShell module at pagiging pamilyar sa mga ito ay halos kinakailangan kung namamahala ka ng mga hybrid o ganap na Azure-hosted na kapaligiran.
Sa kabilang banda, ang PowerShell ay napatunayan na rin bilang isang pangunahing kagamitan para sa pamamahala ng Microsoft 365 (Exchange Online, SharePoint Online, Teams, mga user, at mga lisensya). Mula sa paggawa at pamamahala ng mga account hanggang sa pangangasiwa ng mga mapagkukunan ng Exchange Online, kabilang ang mga grupo, mga site ng SharePoint, at Microsoft Teams, lahat ay maaaring isaayos gamit ang mga script na lubos na nakakabawas sa manu-manong trabaho sa web portal.
Pagsusulat ng script, mga pipeline, at mga pinakamahusay na kasanayan sa trabaho
Para masulit ang advanced automation gamit ang WMI at CIM, mahalagang maging dalubhasa sa pipeline model ng PowerShell . Hindi tulad ng ibang mga shell, hindi ka nagpapasa ng plain text dito, kundi mga kumpletong object, na nagbibigay-daan sa iyong pumili, mag-uri-uri, sukatin, i-filter, isa-isahin, at baguhin ang impormasyon nang may mahusay na katumpakan.
Ang pagkatutong gumamit ng mga pipeline ay kinabibilangan ng wastong paggamit ng mga selection at filtering cmdlet , pag-unawa kung paano isa-isahin ang mga kumplikadong bagay, at pag-aaral kung paano magpasa ng data sa pagitan ng mga command at script nang hindi nawawala ang impormasyon. Pinatitibay ito ng organisadong paggamit ng mga variable, array, at hash table, na nagsisilbing pansamantalang istruktura ng data kung saan bubuo ng mas advanced na lohika.
Ang susunod na hakbang ay ang pag-script mismo: pag-empake ng mga command sa mga reusable script na may flow control (kung, para sa, foreach), pag-import ng data mula sa mga CSV file o iba pang format, paghawak sa input ng user, paghawak ng error, at pag-log ng event. Ang lahat ng ito ay nagbibigay-daan sa iyong lumipat mula sa mga nakahiwalay na command patungo sa mas matatag at built-in na mga tool.
Ang pag-troubleshoot at paghawak ng error ay lalong mahalaga sa mga malawakang automation environment na may WMI/CIM, dahil ang network outage, maling pagkaka-configure ng permission, o nawawalang class ay maaaring makasira sa isang proseso kung hindi maayos na mapamahalaan. Gamit ang mga try/catch block, mga nako-configure na error action, at detalyadong pag-log, mas maaasahan at mas epektibo mong makaka-react sa mga sitwasyong ito.
Panghuli, lahat ng bagay na may kaugnayan sa mga function at module ang kumukumpleto sa bilog : pipirma ka ng mga script upang matiyak ang kanilang integridad, i-package ang mga function sa mga module, ipamahagi ang mga module na iyon sa mga internal o pampublikong repository, at lilikha ng isang ecosystem ng mga shared tool sa loob ng iyong organisasyon. Sa ganitong paraan, ang anumang bagong development sa WMI, CIM, o remoting ay isinasama sa isang magkakaugnay at madaling mapanatiling suite.
Kapag pinagsama mo ang lahat ng nabanggit—WMI/CIM, mga remote session, scripting, mga asynchronous job, DSC, Azure, at Microsoft 365—magkakaroon ka ng isang kapaligiran kung saan ang advanced automation gamit ang PowerShell ay magiging sentro ng administrasyon. Gamit ang matibay na pundasyon ng mga pinakamahusay na kasanayan, matalinong paggamit ng CimSessions (kasama ang parehong WSMan at DCOM), at isang modular script design, maaari mong pamahalaan ang magkakaibang mga imprastraktura nang palagian, ligtas, at mas mahusay kaysa sa pamamagitan lamang ng pag-asa sa mga graphical wizard o nakahiwalay na mga tool.
