- WMIとPowerShellのCIMコマンドレットを使用すると、ローカルおよびリモートの管理情報を効率的に照会および変更できます。
- CimSessionsとWSManまたはDCOMを組み合わせることで、最新のネットワーク機器と旧式のネットワーク機器の両方への安全かつ互換性のあるアクセスが可能になります。
- 高度な関数、モジュール、ジョブ、およびDSCを使用することで、PowerShellは完全なインフラストラクチャ自動化言語へと進化します。
- PowerShellは、ローカル、リモート、Azure、およびMicrosoft 365の管理を単一の環境に統合し、反復的な手作業を削減します。
Windows システムの管理業務に従事している場合、遅かれ早かれ次のような問題に遭遇するでしょう。 PowerShell、WMI、および高度な自動化単に4つのコマンドの実行方法を知っているだけでは十分ではありません。数十台、数百台ものサーバーを管理する場合、情報を収集し、変更を適用し、タスクを繰り返しても混乱したり、何かを壊したりすることなく、真剣で体系的かつ安全なアプローチが必要になります。
以下の文章では、冷静かつ徹底的に、 WMI、CIM、PowerShellによるリモート通信 単純なクエリから複雑なインフラストラクチャシナリオまで、あらゆるものを自動化します。また、これらすべてがモジュール、バックグラウンドタスク、Azure、Microsoft 365、そしてシステム管理者の日々の業務に大きな違いをもたらす高度な機能とどのように連携するのかについても見ていきます。
PowerShellの機能強化と高度な自動化の概要
Windows PowerShellは飛躍的に進化しました 初期バージョンから進化を遂げてきたWindows Server 2012では、リモート通信が改善され、利用可能なコマンドレットが拡張され、デバッグ、バックグラウンドジョブ、制限付き接続ポイントなどの機能が容易になり、セキュリティが向上しました。
この環境の重要なアイデアの1つは、管理者が 高度なプログラミングを必要とせずに、コマンドレットのような動作を作成する高度な機能に頼り、 再利用可能なモジュール さらに、非常に包括的なヘルプシステムも備えています。つまり、散在するグラフィカルツールに頼るのではなく、サーバー、ネットワーク、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はタスクの自動化にこれを幅広く活用しています。
PowerShell エコシステムにおける WMI の自然な後継者は CIM（共通情報モデル）コマンドレットPowerShell 3.0 で導入されたこれらのコマンドレットは、CimCmdlets モジュールにまとめられており、Get-CimInstance、Get-CimClass、New-CimInstance、Invoke-CimMethod、Register-CimIndicationEvent、Set-CimInstance、Remove-CimInstance などのコマンドが含まれています。
Windows PowerShell の古いバージョン、例えば Windows 10 や Windows 11 のバージョン 5.1 では、 従来の WMI コマンドレット (Get-WmiObject、Invoke-WmiMethod、Register-WmiEvent、Remove-WmiObject、Set-WmiInstance)。ただし、これらのコマンドレットは非推奨となり、PowerShell 6 以降のバージョンには含まれていないため、レガシー スクリプトの保守や古いコードのレビューにのみ関連します。
「CIMコマンドレットを使用してWMIを照会する」という話は、矛盾するものではありません。 CIM コマンドレットは引き続き WMI 情報にアクセスしますしかし、それらはWSManのようなより現代的なプロトコルと、より一貫性のあるAPIを使用して実現されています。実用的な観点から言えば、新規開発においてはCIMに重点を置き、WMIコマンドレットは移行や既存スクリプトの理解が必要な場合にのみ検討すべきです。
歴史的に、多くの管理者は、WMI を照会するために、WQL クエリ言語を使用した VBScript を使用していました。たとえば、名前空間に接続することによって。 root\CIMV2 また、Win32_BIOS のようなクラスを照会することもできます。同じ WQL クエリは、Get-CimInstance コマンドレットで -Query パラメーターを渡すことで再利用できるため、ロジックを最初から書き直す必要なく、VBScript から PowerShell への移行が大幅に簡素化されます。
Get-CimInstance の実践的な使用法と効率的なクエリ
日常業務では、PowerShell で WMI を照会する最も自然な方法は、 -ClassName パラメーターを指定した Get-CimInstance コマンドレット完全な WQL クエリを作成する代わりに、Get-CimInstance -ClassName Win32_BIOS を使用して BIOS 情報を取得できます。これにより、製造元、名前、シリアル番号、SMBIOSBIOSVersion などのプロパティを持つオブジェクトが返されます。
PowerShell ではすべてがオブジェクトなので、とても簡単です 必要なものだけを絞り込んで選択するシリアル番号のみが必要な場合は、結果を `Select-Object -Property SerialNumber` にパイプするか、`Select-Object -ExpandProperty SerialNumber` を使用してプロパティを持つオブジェクトではなく単純な文字列を出力できます。もう 1 つの一般的なオプションは、ドット構文 (`Get-CimInstance ...`).SerialNumber` を使用して値に直接アクセスすることです。
デフォルトでは、 WMIクエリは、実際に使用するよりも多くのプロパティを返します。ローカルマシンでは通常、これは問題を引き起こしませんが、多数のリモートマシンにクエリを実行すると、処理時間の増加と不要なネットワークトラフィックの増加につながります。そこで役立つのが、`Get-CimInstance` コマンドレットの `-Property` パラメーターです。このパラメーターを使用すると、ソースから取得するプロパティを制限できます。
例えば、-Property SerialNumber を指定することで、転送される情報量を減らし、クエリを より速く、より効率的に、特に大規模な場合この「必要なものだけを注文する」という考え方は、数十台、数百台のマシンで実行される在庫管理や監査のスクリプトを設計する際に非常に重要です。
要約すると、Get-CimInstance は、 シンプルさ（コマンドライン1つ）と柔軟性特定のクラス、従来のWQLクエリ、または取得を最適化したい特定のプロパティを扱う場合でも。
CIM、セッション、WSMan/DCOMプロトコルを使用した遠隔相談
ローカルチームから離れてリモートマシンへのクエリを開始すると、いくつかの要因が影響してきます。 権限、通信プロトコル、パフォーマンスPowerShellを「危険なもの」と捉える人も多いが、実際には特別な権限を与えるものではない。グラフィカルインターフェースや他のツールと全く同じ権限しか持たず、それ以上でもそれ以下でもない。
十分な権限がない状態で Get-CimInstance -ComputerName Server -ClassName Win32_BIOS を実行しようとすると、 「アクセスが拒否されました」というエラーが表示されます。PowerShell自体に問題があるわけではなく、単にセッションを実行しているユーザーにWMI内の情報にアクセスする権限がないだけです。もちろん、ドメイン管理者としてコンソールを開くことはできますが、その場合、すべてのコマンドがその権限で実行されるため、多くの環境では不必要なリスクとなります。
推奨事項は、 最小限の権限のみを与え、必要な場合にのみ権限を付与する。-Credential パラメーターをサポートするコマンドレットでは、そのコマンドに対してのみ代替資格情報を指定できます。しかし、Get-CimInstance は -Credential を直接受け付けないため、CimSessions が優れた解決策として役立ちます。
CimSession は、リモート コンピューターへの永続的な接続であり、New-CimSession コマンドレットを使用してコンピューター名と資格情報を渡して作成できます (例: New-CimSession -ComputerName dc01 -Credential (Get-Credential))。このセッションは、次のような変数に格納されます。 $CimSession は、Get-CimInstance で再利用されます。 -ComputerName パラメーターの代わりに -CimSession パラメーターを使用することで、複数のクエリを単一の接続に集中させることができます。
資格情報の問題に加えて、Get-CimInstance はデフォルトを使用します WSManプロトコル（WinRMベース）つまり、リモート コンピューターには WSMan スタック バージョン 3.0 以上がインストールされている必要があります。これは、PowerShell 3.0 以降で一般的に使用されているバージョンです。この接続方法を使用するには、コンピューターの WSMan スタック バージョンを `Test-WSMan -ComputerName RemoteComputer` コマンドで確認し、「Stack」の値が 3.0 以上であることを確認してください。
CIMセッションとDCOMおよび下位互換性
Get-WmiObject に基づく古い WMI コマンドレットは、 DCOMプロトコルは、古いバージョンのWindowsとも互換性があります。問題は、より現代的なシステムでは、ファイアウォールがデフォルトでDCOMをブロックしていることが多く、そのまま使用するには特定のポートを開放する必要があり、それが組織のセキュリティポリシーに反する可能性があるということです。
CIM コマンドレットは強力な中間的な手段を提供します。セッション オプションを作成するには、 New-CimSessionOption -Protocol Dcomこれらを変数（例えば、$DCOM）に格納し、New-CimSessionと組み合わせて、WSManではなくDCOMを使用するCimSessionを生成できます。これにより、PowerShellがインストールされていないWindows Server 2000以前の古いサーバーにも接続できるようになります。
ドメイン管理者または特権を持つアカウントの認証情報を変数に保存しておくと便利な場合が多い（例： $Cred = Get-Credential毎回入力する必要がないようにするためです。その後、New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred のようなコマンドを使用すると、WSMan をサポートしていないが WMI を備えている古いサーバーに対して、DCOM 経由で CimSession を開始できます。
脚本家の視点からすると、大きな利点は Get-CimInstance の出力はプロトコルによって変化しませんWSManを使用する場合でもDCOMを使用する場合でも、同じオブジェクトとプロパティを取得できます。これにより、適切なプロトコルの検出を関数にカプセル化し、残りのコードが常にCimSessionsと透過的に連携するようにできるため、ロジックが大幅に簡素化されます。
実際、Test-WSMan を使用して WSMan をテストし、利用できない場合は New-CimSessionOption を使用して自動的に DCOM に移行するカスタム関数を作成することはよくあります。 混合環境における CimSession の作成を標準化する 最新のサーバーと従来のサーバーの両方に対応し、すべてのスクリプトに接続ロジックを重複して記述する必要がありません。
CimSessionsの管理、リスト化、およびクリーニング
CimSessionsを頻繁に使用するようになると、不要な接続が蓄積されるのを避けるために、この点を常に把握しておくことが重要です。 Get-CimSession コマンドレットを使用すると、開いているすべてのセッションを一覧表示できます。それらがどのデバイスを指しているかを確認し、どのプロトコル（WSMANまたはDCOM）を使用しているかをチェックします。これは、接続や認証の問題を診断するのに非常に役立ちます。
既存のセッションを変数に取得することもできます。たとえば $CimSession = Get-CimSessionそして、それらを単一の Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS コマンドで使用して、複数のコンピューターに一度にクエリを実行し、WSMan セッションと DCOM セッションを同じ操作で組み合わせます。
情報の確認が終わったら、不要なリソースを開いたままにしないためにも、セッションを閉じるのが最善です。 Get-CimSession | Remove-CimSession これにより、現在のプロファイルからすべてのアクティブな CimSession が一度に削除されます。あるいは、特定のセッションを Remove-CimSession コマンドレットに渡して、一部のセッションのみを閉じることもできます。
この方法で作業すると、 制御された接続および切断サイクルこれは、スケジュールされたタスク、自動化ランブック、または継続的インテグレーションパイプライン内でスクリプトを使用する場合に強く推奨されます。これらのスクリプトは、クリーンアップを明示的に計画しないと、セッションがハングアップしてしまう可能性があるためです。
PowerShellは包括的な自動化言語である。
WMIとCIMを超えて、PowerShellは 汎用自動化言語 これは、一般的なWindows管理スクリプトをはるかに超えるものです。LinuxやWindowsへのインストールから、NuGetを介した配布可能なモジュールの開発、Visual Studio Codeのような最新の開発環境まで、その高度な機能に特化した書籍や講座が数多く存在します。
共通の出発点は、 高度な PowerShell 機能これらのモジュールを使用すると、パラメーター、検証、構造化出力、および統合ヘルプを、ネイティブのコマンドレットとほぼ同等のレベルで定義できます。さらに、コードをモジュールに整理することで、運用チームでの共同作業が容易になります。これらのモジュールは、社内または公開のNuGetベースのリポジトリでバージョン管理および公開できるためです。
協力することも重要です カスタムオブジェクトとクラスこれにより、従来の直線的なスクリプトよりもはるかにリッチなデータモデルへの道が開かれます。PowerShellエンジンを活用することで、ビジネスロジックのカプセル化、構造の再利用、そして自社管理チーム向けの内部APIの設計が可能になります。
高度な自動化の分野では、以下の要素が重要な役割を果たします。 バックグラウンドジョブとワークフローこれらの機能により、非同期タスクの管理、コンソールをブロックすることなく長時間かかる操作の実行、複数のマシンにまたがる複雑なシーケンスのオーケストレーションが可能になります。これらは、システムによる変更の実装やデータの返却を待つ必要があることが多い、大量のWMI/CIMクエリやリモート管理シナリオに最適です。
もう1つの重要なコンポーネントはPowerShell DSC（Desired State Configuration）で、これにより インフラストラクチャの望ましい構成を定義する （役割、機能、サービス、ファイル、セキュリティ設定など）の状態を繰り返し適用します。WMI/CIM を介して取得した情報と組み合わせることで、逸脱を検出し、事前に修正し、手作業を減らしながら一貫性のある環境を維持できます。
PowerShell を使用したローカル、リモート、およびクラウド管理
純粋にローカルなレベルでは、PowerShell は、 Active Directoryドメインサービス管理ネットワーク構成とサーバー管理。Windows 10以降のバージョンでは、統合がさらに強化され、Webサイトの作成からActive Directoryオブジェクトの管理、ネットワークアダプタの構成まで、あらゆることを自動化できます。
あまり知られていないが、非常に便利なアイテムは PSProvidersとPSDrivesこれらの機能により、ファイルシステム、レジストリ、Active Directoryなど、さまざまなストレージ場所を、あたかもナビゲーション可能なドライブであるかのように扱うことができます。これにより、たとえば、ハードドライブを操作する際に使用するのと同じ構文を使用して、リモートコンピュータ上にActive Directoryグループ、レジストリキー、またはフォルダ構造を作成できます。
リモート管理に関して、PowerShell は非常に強力な一連の機能を統合しています。 1台以上のコンピュータに接続し、 コマンドを実行する あなたの名前で永続的なPSSessionセッション、高度なリモート処理技術、1対多シナリオ（複数のサーバーを同時に管理する場合）、または1対1シナリオを使用して特定のケースをデバッグできます。もちろん、これらすべてはリモートアクセスのアーキテクチャとセキュリティモデルを遵守しながら行う必要があります。
クラウドも今日では重要な役割を果たしています。 Azure PowerShell と Azure Cloud Shell 仮想マシン、ストレージ、サブスクリプションは、コマンドラインから直接管理できます。ハイブリッド環境または完全にAzureでホストされている環境を管理する場合は、Azure PowerShellモジュールをインストールして使いこなせるようになることがほぼ必須です。
一方、PowerShellは、 Microsoft 365を管理するためのリファレンスツール （Exchange Online、SharePoint Online、Teams、ユーザー、ライセンスなど）。アカウントの作成と管理から、グループ、SharePointサイト、Microsoft TeamsなどのExchange Onlineリソースの管理まで、すべてをスクリプトでオーケストレーションできるため、Webポータルでの手作業を大幅に削減できます。
スクリプト作成、パイプライン構築、および最適な作業方法
WMIとCIMによる高度な自動化を最大限に活用するには、 PowerShellパイプラインモデル他のシェルとは異なり、ここではプレーンテキストではなく完全なオブジェクトを渡すため、情報を非常に高い精度で選択、ソート、測定、フィルタリング、列挙、変換することができます。
チャネリングの活用法を学ぶには、それを正しく使うことが必要です。 選択およびフィルタリングコマンドレットこれには、複雑なオブジェクトを列挙する方法や、情報を失うことなくコマンドとスクリプト間でデータを渡す方法を理解することが含まれます。これは、より高度なロジックを構築するための一時的なデータ構造として機能する変数、配列、ハッシュテーブルを構造的に使用することで強化されます。
次のステップは スクリプト作成とは、コマンドを再利用可能なスクリプトにパッケージ化することです。フロー制御（if、for、foreach）、CSVファイルやその他の形式からのデータインポート、ユーザー入力処理、エラー処理、イベントログ記録などの機能により、個々のコマンドからより堅牢な内部ツールへと移行できます。
WMI/CIM を使用した大規模な自動化環境では、トラブルシューティングとエラー処理が特に重要です。 ネットワーク障害、権限設定ミス、または存在しないクラス 適切に管理しないと、プロセスが中断される可能性があります。try/catchブロック、設定可能なエラー処理、詳細なログ記録機能を使用することで、こうした状況を予測し、より適切に対応できます。
最後に、 関数とモジュールが円環を閉じるスクリプトに署名して整合性を確保し、機能をモジュールにパッケージ化し、それらのモジュールを社内または公開リポジトリに配布し、組織内で共有ツールのエコシステムを構築します。こうすることで、WMI、CIM、リモート処理に関するあらゆる新しい開発を、一貫性があり保守しやすいスイートに統合できます。
上記すべて（WMI/CIM、リモートセッション、スクリプト、非同期ジョブ、DSC、Azure、Microsoft 365）を合計すると、次のような環境になります。 PowerShell を使用した高度な自動化 これは管理の中核となるハブとなります。ベストプラクティスの確固たる基盤、CimSessions（WSManとDCOMの両方を使用）の賢明な活用、そしてモジュール式のスクリプト設計により、グラフィカルウィザードや個別のツールだけに頼る場合よりも、異種混在のインフラストラクチャを、一貫性があり、安全かつはるかに効率的に管理できます。
