- Cmdlets CIM WMI dan PowerShell membolehkan anda membuat pertanyaan dan mengubah suai maklumat pengurusan setempat dan jauh dengan cekap.
- CimSessions dengan WSMan atau DCOM memudahkan akses yang selamat dan serasi kepada peralatan rangkaian moden dan legasi.
- Penggunaan fungsi, modul, tugas dan DSC lanjutan menjadikan PowerShell sebagai bahasa automasi infrastruktur yang lengkap.
- PowerShell mengintegrasikan pengurusan setempat, jarak jauh, Azure dan Microsoft 365 ke dalam satu persekitaran, sekali gus mengurangkan tugasan manual yang berulang.
Jika anda bekerja mentadbir sistem Windows, lambat laun anda akan menemui PowerShell, WMI dan automasi lanjutan . Ia bukan sekadar soal mengetahui cara menjalankan beberapa arahan: apabila anda mengurus berpuluh-puluh atau beratus-ratus pelayan, anda memerlukan pendekatan yang serius, berstruktur dan selamat untuk mengumpulkan maklumat, menggunakan perubahan dan mengulangi tugas tanpa menjadi gila… atau merosakkan apa-apa.
Dalam baris berikut, kita akan meneroka, dengan tenang tetapi menyeluruh, cara memanfaatkan komunikasi jarak jauh WMI, CIM dan PowerShell untuk mengautomasikan segala-galanya daripada pertanyaan mudah kepada senario infrastruktur yang kompleks. Kita juga akan melihat bagaimana semua ini sesuai dengan modul, tugasan latar belakang, Azure, Microsoft 365 dan beberapa ciri lanjutan yang membuat perbezaan sebenar dalam kerja harian pentadbir sistem.
Penambahbaikan PowerShell dan gambaran keseluruhan automasi lanjutan
Windows PowerShell telah banyak berkembang sejak versi awalnya, dan sebahagian besar evolusi itu datang dengan Windows Server 2012, di mana komunikasi jarak jauh telah dipertingkatkan, cmdlet yang tersedia telah diperluas, dan perkara seperti penyahpepijatan, kerja latar belakang dan titik akhir terhad telah dipermudahkan untuk meningkatkan keselamatan.
Salah satu idea utama di sebalik persekitaran ini ialah pentadbir boleh mencipta tingkah laku seperti cmdlet tanpa pengekodan yang meluas , memanfaatkan ciri-ciri lanjutan, modul yang boleh diguna semula dan sistem bantuan yang komprehensif. Ini bermakna anda boleh membina satu set skrip dan modul yang koheren yang mengautomasikan proses untuk mengurus pelayan, rangkaian, Active Directory, Azure atau Microsoft 365 daripada bergantung pada alat grafik yang berbeza.
Dalam bidang automasi lanjutan, ciri-ciri seperti kerja untuk melaksanakan tugas secara tak segerak, aliran kerja, pentadbiran berasaskan konfigurasi dengan PowerShell DSC dan pilihan keselamatan seperti JEA (Just Enough Administration) atau PowerShell Web Access juga menonjol, membolehkan kawalan terperinci tentang apa yang setiap orang boleh lakukan dan dari mana.
Keseluruhan ekosistem ini amat sesuai dengan WMI dan CIM, memandangkan maklumat pengurusan yang didedahkan oleh sistem pengendalian (perkakasan, perkhidmatan, proses , konfigurasi rangkaian, perisian yang dipasang, dll.) menjadi satu set objek yang boleh anda tanya, tapis dan ubah suai menggunakan arahan PowerShell yang direka untuk automasi besar-besaran.
WMI dan CIM: Konsep Utama dan Perbezaan Praktikal
Instrumentasi Pengurusan Windows, lebih dikenali sebagai WMI, ialah teknologi bebas PowerShell yang telah menjadi sebahagian daripada Windows selama bertahun-tahun. Ia mendedahkan repositori maklumat pengurusan tentang sistem pengendalian, perkakasan dan banyak aplikasi. Walaupun ia tidak bergantung pada PowerShell, PowerShell memanfaatkannya secara meluas untuk mengautomasikan tugas.
Pengganti semula jadi kepada WMI dalam ekosistem PowerShell ialah cmdlet CIM (Common Information Model) , yang diperkenalkan dengan PowerShell 3.0. Cmdlet ini dikumpulkan dalam modul CimCmdlets dan merangkumi arahan seperti Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance dan Remove-CimInstance, antara lain.
Dalam versi Windows PowerShell yang lebih lama, seperti Windows 10 PowerShell 5.1 atau Windows 11 PowerShell, anda masih boleh menemui cmdlet WMI klasik (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Walau bagaimanapun, cmdlet ini tidak lagi digunakan dan tidak lagi disertakan dalam PowerShell 6 dan versi yang lebih baharu, jadi ia hanya relevan untuk menyelenggara skrip legasi atau menyemak kod lama.
Apabila seseorang bercakap tentang "mempertanyakan WMI dengan cmdlet CIM," ia tidak bercanggah: cmdlet CIM masih mengakses maklumat WMI , tetapi ia berbuat demikian menggunakan protokol yang lebih moden seperti WSMan dan API yang lebih konsisten. Secara praktikal, untuk perkembangan baharu, anda harus fokus pada CIM dan hanya mempertimbangkan cmdlet WMI apabila anda perlu berhijrah atau memahami skrip legasi.
Dari segi sejarah, ramai pentadbir menggunakan VBScript dengan bahasa pertanyaan WQL untuk membuat pertanyaan WMI, contohnya, dengan menyambung ke ruang nama root\CIMV2 dan membuat pertanyaan kelas seperti Win32_BIOS. Pertanyaan WQL yang sama boleh digunakan semula hari ini dengan Get-CimInstance dengan menghantar parameter -Query, yang sangat memudahkan peralihan daripada VBScript kepada PowerShell tanpa perlu menulis semula logik dari awal.
Penggunaan praktikal Get-CimInstance dan pertanyaan yang cekap
Untuk kerja harian, cara paling semula jadi untuk membuat pertanyaan WMI dengan PowerShell adalah dengan menggunakan Get-CimInstance dengan parameter -ClassName , daripada menulis pertanyaan WQL penuh. Contohnya, untuk mendapatkan maklumat BIOS, anda boleh menggunakan Get-CimInstance -ClassName Win32_BIOS dan anda akan menerima objek dengan sifat seperti Manufacturer, Name, SerialNumber atau SMBIOSBIOSVersion.
Memandangkan semua yang ada dalam PowerShell adalah objek, sangat mudah untuk menapis dan memilih hanya apa yang anda perlukan . Jika anda hanya berminat dengan nombor siri, anda boleh menghantar hasilnya ke `Select-Object -Property SerialNumber` atau gunakan `Select-Object -ExpandProperty SerialNumber` untuk mengeluarkan rentetan ringkas dan bukannya objek dengan sifat. Satu lagi pilihan biasa ialah menggunakan sintaks titik (`Get-CimInstance ...`).SerialNumber` untuk mengakses nilai secara langsung.
Perlu diingatkan bahawa, secara lalai, pertanyaan WMI mengembalikan lebih banyak sifat daripada yang sebenarnya anda gunakan . Pada mesin tempatan, ini biasanya baik-baik saja, tetapi apabila anda mula membuat pertanyaan kepada banyak mesin jauh, ia akan menyebabkan masa pemprosesan tambahan dan trafik rangkaian yang tidak perlu. Di sinilah parameter `-Property` bagi `Get-CimInstance` digunakan, yang membolehkan anda mengehadkan sifat yang diambil daripada sumber.
Dengan menyatakan -Property SerialNumber, sebagai contoh, anda mengurangkan jumlah data yang dipindahkan, menjadikan pertanyaan lebih pantas dan lebih cekap, terutamanya pada skala . Mentaliti "minta hanya untuk apa yang anda perlukan" ini adalah penting semasa mereka bentuk skrip inventori atau audit yang dijalankan pada berpuluh-puluh atau beratus-ratus mesin.
Secara ringkasnya, Get-CimInstance menawarkan keseimbangan yang hebat antara kesederhanaan (satu baris arahan) dan fleksibiliti , sama ada anda bekerja dengan kelas konkrit, pertanyaan WQL legasi atau sifat khusus yang anda ingin optimumkan untuk pengambilan semula.
Konsultasi jarak jauh dengan CIM, sesi dan protokol WSMan/DCOM
Apabila anda beralih daripada mesin tempatan anda dan mula mengakses mesin jauh, beberapa faktor akan memainkan peranan: kebenaran, protokol komunikasi dan prestasi . Walaupun ramai orang melihat PowerShell sebagai "berbahaya," sebenarnya ia tidak memberikan anda sebarang keistimewaan tambahan: anda mempunyai kebenaran yang sama seperti antara muka grafik atau mana-mana alat lain, tidak lebih dan tidak kurang.
Jika anda cuba menjalankan `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` tanpa keistimewaan yang mencukupi pada mesin tersebut, anda akan menerima ralat "Akses ditolak" . Ini bukan kerana PowerShell gagal; ia hanyalah pengguna yang anda jalankan sesi tersebut tidak mempunyai hak untuk mengakses maklumat tersebut dalam WMI. Anda boleh membuka konsol sebagai pentadbir domain, sudah tentu, tetapi itu bermakna sebarang arahan akan dilaksanakan dengan keistimewaan tersebut, yang merupakan risiko yang tidak perlu dalam banyak persekitaran.
Cadangannya adalah untuk menggunakan prinsip keistimewaan paling rendah dan meningkatkan keistimewaan hanya apabila perlu . Dalam cmdlet yang menyokong parameter -Credential, anda boleh menentukan kelayakan alternatif hanya untuk arahan yang dimaksudkan. Walau bagaimanapun, Get-CimInstance tidak menerima -Credential secara langsung, dan di sinilah CimSessions memainkan peranan sebagai penyelesaian yang elegan.
CimSession ialah sambungan berterusan ke komputer jauh yang boleh anda cipta dengan New-CimSession, yang memberikan nama dan kelayakan komputer (contohnya, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Sesi ini disimpan dalam pembolehubah, seperti $CimSession, dan kemudian digunakan semula dengan Get-CimInstance dengan menggunakan parameter -CimSession dan bukannya -ComputerName, yang membolehkan anda menyatukan berbilang pertanyaan ke dalam satu sambungan.
Selain keperluan kelayakan, Get-CimInstance menggunakan protokol WSMan (berdasarkan WinRM) secara lalai . Ini bermakna mesin jauh mesti mempunyai tindanan WSMan versi 3.0 atau lebih tinggi, biasanya terdapat dalam PowerShell 3.0 dan yang lebih baharu. Anda boleh menyemak versi tindanan WSMan pada mesin dengan `Test-WSMan -ComputerNameRemoteComputer` dan mengesahkan bahawa nilai "Stack" ialah 3.0 atau lebih tinggi untuk menggunakan kaedah sambungan ini.
Sesi CIM dengan DCOM dan keserasian ke belakang
Cmdlet WMI lama berdasarkan Get-WmiObject bergantung pada protokol DCOM, yang masih disokong oleh versi Windows lama . Masalahnya ialah, pada sistem yang lebih moden, tembok api sering menyekat DCOM secara lalai, yang memerlukan anda membuka port tertentu untuk menggunakannya seadanya, yang boleh melanggar dasar keselamatan organisasi anda.
Cmdlets CIM menawarkan jalan tengah yang hebat: anda boleh mencipta pilihan sesi dengan `New-CimSessionOption -Protocol Dcom` , menyimpannya dalam pembolehubah (contohnya, `$DCOM`), dan kemudian menggabungkannya dengan `New-CimSession` untuk menjana CimSession yang menggunakan DCOM dan bukannya WSMan. Ini membolehkan anda menyambung ke pelayan yang sangat lama, walaupun yang mendahului Windows Server 2000, di mana PowerShell tidak dipasang pun.
Biasanya mudah untuk menyimpan kelayakan pentadbir domain atau kelayakan untuk akaun yang ditinggikan dalam pembolehubah (contohnya, $Cred = Get-Credential ) bagi mengelakkan daripada menaipnya setiap kali. Kemudian, dengan sesuatu seperti New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, anda boleh memulakan CimSession melalui DCOM ke pelayan lama yang tidak menyokong WSMan tetapi mempunyai WMI.
Dari perspektif penulis skrip, kelebihan utama ialah output `Get-CimInstance` tidak berubah bergantung pada protokol : anda mendapat objek dan sifat yang sama sama ada anda menggunakan WSMan atau DCOM. Ini sangat memudahkan logik kerana anda boleh merangkum pengesanan protokol yang sesuai dalam fungsi dan membiarkan kod yang lain sentiasa berfungsi secara telus dengan CimSessions.
Malah, agak biasa untuk mencipta fungsi tersuai yang menguji WSMan dengan Test-WSMan dan, jika ia tidak tersedia, ia akan dimasukkan ke dalam DCOM secara automatik menggunakan New-CimSessionOption. Ini membolehkan anda menyeragamkan penciptaan CimSession merentasi persekitaran campuran dengan pelayan moden dan legasi, tanpa mereplikasi logik sambungan dalam semua skrip anda.
Pengurusan, penyenaraian dan pembersihan CimSessions
Apabila anda mula menggunakan CimSessions secara meluas, adalah penting untuk menjejakinya bagi mengelakkan pengumpulan sambungan yang tidak perlu. Dengan Get-CimSession, anda boleh menyenaraikan semua sesi terbuka , melihat mesin yang mereka tuju dan menyemak protokol yang mereka gunakan (WSMAN atau DCOM), yang sangat berguna untuk mendiagnosis masalah sambungan atau pengesahan.
Anda juga boleh mendapatkan sesi sedia ada dalam pembolehubah, contohnya $CimSession = Get-CimSession , dan menggunakannya dalam satu arahan Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS untuk membuat pertanyaan kepada beberapa komputer sekaligus, menggabungkan sesi WSMan dan DCOM dalam operasi yang sama.
Setelah anda selesai menganalisis maklumat tersebut, adalah idea yang baik untuk menutup sesi tersebut bagi mengelakkan sumber daripada terbuka tanpa perlu. Cmdlet Get-CimSession | Remove-CimSession mengalih keluar semua CimSession aktif daripada profil semasa sekaligus. Sebagai alternatif, anda boleh menghantar sesi tertentu ke cmdlet Remove-CimSession untuk menutup sebahagian daripadanya sahaja.
Bekerja dengan cara ini membolehkan anda mempunyai kitaran sambungan dan pemutusan yang terkawal , yang sangat disyorkan apabila menggunakan skrip dalam tugasan berjadual, buku larian automasi atau saluran paip integrasi berterusan yang boleh menyebabkan sesi tergantung jika anda tidak merancang secara eksplisit untuk pembersihan tersebut.
PowerShell sebagai bahasa automasi yang komprehensif
Selain WMI dan CIM, PowerShell telah menjadi bahasa automasi tujuan umum yang jauh melangkaui skrip pengurusan Windows biasa. Terdapat buku dan keseluruhan kursus yang dikhaskan untuk keupayaan canggihnya, merangkumi segala-galanya daripada pemasangan pada Linux dan Windows hinggalah membangunkan modul yang boleh diedarkan melalui NuGet, malah persekitaran pembangunan moden seperti Visual Studio Code.
Titik permulaan yang biasa adalah untuk memahami ciri-ciri lanjutan PowerShell secara menyeluruh , yang membolehkan anda menentukan parameter, melakukan pengesahan, menjana output berstruktur dan mengakses bantuan bersepadu hampir pada tahap cmdlet asli. Dari situ, menyusun kod ke dalam modul memudahkan kerja kolaboratif dalam pasukan operasi, kerana anda boleh membuat versi dan menerbitkan modul ini ke repositori dalaman atau awam berasaskan NuGet.
Bekerja dengan objek dan kelas tersuai juga penting , membuka pintu kepada model data yang jauh lebih kaya daripada skrip linear biasa. Ini membolehkan anda merangkum logik perniagaan, menggunakan semula struktur dan mereka bentuk API dalaman untuk pasukan pengurusan anda sendiri, semuanya dikuasakan oleh enjin PowerShell.
Dalam bidang automasi lanjutan, kerja latar belakang dan aliran kerja memainkan peranan penting , membolehkan pengurusan tugasan tak segerak, pelaksanaan operasi yang panjang tanpa menyekat konsol dan pengaturan jujukan kompleks merentasi berbilang mesin. Keupayaan ini sangat sesuai untuk pertanyaan pukal kepada WMI/CIM dan senario pentadbiran jauh, di mana ia sering perlu menunggu sistem melaksanakan perubahan atau mengembalikan data.
Satu lagi komponen utama ialah PowerShell DSC (Konfigurasi Keadaan yang Diingini), yang membolehkan anda menentukan konfigurasi infrastruktur yang diingini (peranan, ciri, perkhidmatan, fail, tetapan keselamatan, dll.) dan menggunakan keadaan tersebut berulang kali. Digabungkan dengan maklumat yang anda peroleh melalui WMI/CIM, anda boleh mengesan sisihan, membetulkannya secara proaktif dan mengekalkan persekitaran yang konsisten dengan usaha manual yang kurang.
Pengurusan setempat, jarak jauh dan awan dengan PowerShell
Di peringkat tempatan, PowerShell menyediakan cmdlet untuk mengurus Perkhidmatan Domain Direktori Aktif , mengkonfigurasi rangkaian dan mentadbir pelayan. Dalam versi Windows 10 dan yang lebih baharu, penyepaduannya lebih mendalam, membolehkan anda mengautomasikan segala-galanya daripada mencipta laman web kepada mengurus objek Direktori Aktif dan mengkonfigurasi penyesuai rangkaian.
Komponen yang kurang dikenali tetapi sangat berguna ialah PSProviders dan PSDrives , yang membolehkan anda mengendalikan lokasi storan yang berbeza (sistem fail, pendaftaran, Active Directory, dll.) seolah-olah ia adalah pemacu yang boleh dilayari. Disebabkan ini, anda boleh, sebagai contoh, mencipta kumpulan Active Directory, kunci pendaftaran atau struktur folder pada komputer jauh menggunakan sintaks yang sama yang anda gunakan untuk menavigasi cakera keras.
Berkenaan pentadbiran jarak jauh, PowerShell mengintegrasikan satu set ciri yang berkuasa untuk menyambung ke satu atau lebih komputer dan melaksanakan arahan bagi pihak anda . Anda boleh menggunakan sesi PSSession yang berterusan, teknik pengasingan jauh lanjutan, senario satu-ke-banyak (untuk mengurus berbilang pelayan secara serentak), atau senario satu-ke-satu untuk menyahpepijat kes tertentu. Semua ini, sudah tentu, sambil menghormati seni bina dan model keselamatan akses jauh.
Awan juga memainkan peranan penting pada masa kini. Dengan Azure PowerShell dan Azure Cloud Shell, anda boleh mengurus mesin maya, storan dan langganan terus daripada baris arahan. Memasang modul Azure PowerShell dan membiasakannya adalah hampir wajib jika anda mengurus persekitaran hibrid atau persekitaran yang dihoskan sepenuhnya oleh Azure.
Sebaliknya, PowerShell juga telah mengukuhkan kedudukannya sebagai alat pilihan untuk mengurus Microsoft 365 (Exchange Online, SharePoint Online, Teams, pengguna dan lesen). Daripada mencipta dan mengurus akaun hinggalah mentadbir sumber Exchange Online, termasuk kumpulan, tapak SharePoint dan Microsoft Teams, semuanya boleh diatur dengan skrip yang dapat mengurangkan kerja manual di portal web secara drastik.
Skrip, saluran paip dan amalan kerja terbaik
Untuk memanfaatkan sepenuhnya automasi lanjutan dengan WMI dan CIM, adalah penting untuk menguasai model saluran paip PowerShell . Tidak seperti shell lain, anda tidak menghantar teks biasa di sini, tetapi sebaliknya melengkapkan objek, membolehkan anda memilih, mengisih, mengukur, menapis, menyenaraikan dan mengubah maklumat dengan ketepatan yang tinggi.
Pembelajaran untuk bekerja dengan saluran paip melibatkan penggunaan cmdlet pemilihan dan penapisan dengan betul , memahami cara menyenaraikan objek kompleks dan mempelajari cara menghantar data antara arahan dan skrip tanpa kehilangan maklumat. Ini diperkukuh oleh penggunaan pembolehubah, tatasusunan dan jadual hash yang teratur, yang bertindak sebagai struktur data sementara untuk membina logik yang lebih maju.
Langkah seterusnya ialah penskripan itu sendiri: pembungkusan arahan ke dalam skrip yang boleh diguna semula dengan kawalan aliran (jika, untuk, untuk setiap), mengimport data daripada fail CSV atau format lain, mengendalikan input pengguna, pengendalian ralat dan pengelogan peristiwa. Semua ini membolehkan anda beralih daripada arahan terpencil kepada alatan terbina dalam yang lebih mantap.
Penyelesaian masalah dan pengendalian ralat amat penting dalam persekitaran automasi berskala besar dengan WMI/CIM, kerana gangguan rangkaian, kebenaran yang salah konfigurasi atau kelas yang hilang boleh merosakkan proses jika tidak diuruskan dengan betul. Dengan blok cuba/tangkap, tindakan ralat yang boleh dikonfigurasikan dan pembalakan terperinci, anda boleh menjangka dan bertindak balas dengan lebih berkesan terhadap situasi ini.
Akhir sekali, semua yang berkaitan dengan fungsi dan modul melengkapkan bulatan ini : anda menandatangani skrip untuk memastikan integritinya, membungkus fungsi ke dalam modul, mengedarkan modul tersebut dalam repositori dalaman atau awam dan mewujudkan ekosistem alatan kongsi dalam organisasi anda. Dengan cara ini, sebarang pembangunan baharu pada WMI, CIM atau pengalihan jauh disepadukan ke dalam suit yang koheren dan mudah diselenggara.
Apabila anda menggabungkan semua perkara di atas—WMI/CIM, sesi jarak jauh, skrip, kerja tak segerak, DSC, Azure dan Microsoft 365—anda akan mendapat persekitaran di mana automasi lanjutan dengan PowerShell menjadi teras pentadbiran. Dengan asas amalan terbaik yang kukuh, penggunaan CimSessions yang bijak (dengan WSMan dan DCOM) dan reka bentuk skrip modular, anda boleh mengurus infrastruktur heterogen secara konsisten, selamat dan jauh lebih cekap berbanding hanya bergantung pada ahli sihir grafik atau alatan terpencil.
