PowerShell CIM/WMIイベント監視の効率的な実装と運用

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

PowerShell CIM/WMIイベント監視の効率的な実装と運用

導入

Windows環境の運用において、システムの状態変化をリアルタイムで検知し、適切なアクションを自動的に実行することは、セキュリティ、パフォーマンス、可用性の維持に不可欠です。PowerShellは、Windows Management Instrumentation (WMI) および Common Information Model (CIM) を通じて、システムイベントを監視するための強力な機能を提供します。 、PowerShell 7を推奨環境とし、CIM/WMIイベント監視を効率的かつ堅牢に実装・運用するための具体的な手法を解説します。特に、並列処理によるスループット向上、適切なエラーハンドリング、詳細なロギング戦略、そしてセキュリティ対策に焦点を当て、現場で役立つ実践的なアプローチを紹介します。

目的と前提 / 設計方針（同期/非同期、可観測性）

イベント監視の目的

CIM/WMIイベント監視の主な目的は以下の通りです。

  • セキュリティ: 不審なプロセス起動、レジストリ変更、ファイルアクセスなどを検知し、不正行為を早期に発見します。

  • パフォーマンス: リソース枯渇（例: ディスク容量不足）、サービス停止、アプリケーションエラーなど、システムパフォーマンスに影響を与えるイベントを監視します。

  • システム変更管理: ハードウェアの追加/削除、ソフトウェアのインストール/アンインストール、ユーザーアカウントの作成/変更など、システム構成の変更を追跡します。

WMI/CIMの選択とサブスクリプションタイプ

PowerShellでWMIイベントを監視するには、主にRegister-WmiEventとRegister-CimSubscriptionの2つのコマンドレットがあります。

  • Register-WmiEvent: 伝統的なWMIイベント購読コマンドレットで、DCOMプロトコルを利用します。PowerShell 2.0以降で利用可能です [1]。

  • Register-CimSubscription: CIMセッションを介してWMIイベントを購読する、よりモダンなコマンドレットです。WS-Managementプロトコルをサポートし、リモート接続により適している場合があります。PowerShell 3.0以降で利用可能です [2]。

本記事では、より新しいアプローチであるRegister-CimSubscriptionを推奨します。

イベントサブスクリプションには、PowerShellセッションの終了とともに解除される一時的サブスクリプションと、WMIリポジトリに登録されOS再起動後も有効な永続的サブスクリプションがあります [3]。PowerShellのRegister-CimSubscriptionはデフォルトで一時的サブスクリプションを作成します。永続的サブスクリプションはWMIクラスを直接操作する必要があり、実装が複雑になるため、本記事では一時的サブスクリプションをPowerShellスクリプトで常駐させる方法を主に扱います。

設計方針

効果的なイベント監視システムを構築するための設計方針は以下の通りです。

  • PowerShell 7の活用: ForEach-Object -Parallelなどの新機能を利用し、高い処理能力とモダンな開発体験を提供します。

  • 非同期/並列処理: 大量のイベント発生時に処理が滞らないよう、イベントの受信と処理を分離し、並列処理を活用します。

  • 堅牢なエラーハンドリング: イベント処理中のエラーを適切に捕捉し、システム全体の安定性を維持します。

  • 詳細なロギング: イベントの発生、処理結果、エラー情報を構造化された形式で記録し、可観測性を確保します。

  • セキュリティへの配慮: 最小権限の原則に基づき、必要な権限のみを付与し、機密情報を安全に取り扱います。

イベント監視処理フロー

イベント監視の基本的な処理フローを以下のMermaidフローチャートで示します。

graph TD
    A["スクリプト開始"] --> B{"永続化されたサブスクリプションは存在するか？"};
    B --|いいえ| D["一時的WMI/CIMイベントサブスクリプションを登録"];
    B --|はい| C["既存サブスクリプションを再開/確認"];
    C --> E["イベントキューを初期化"];
    D --> E;
    E --> F["イベント待機ループ"];
    F --|イベント発生| G["イベント受信"];
    G --> H["イベントデータをキューに追加"];
    H --> I["キュー処理ワーカー"];
    I --|並列処理| J["イベントを解析・処理"];
    J --> K{"処理成功？"};
    K --|はい| L["構造化ログに出力"];
    K --|いいえ| M["エラーログに出力|再試行ロジック"];
    L --> I;
    M --> I;
    I --|キューが空になるかタイムアウト| N["キュー処理停止"];
    F --|スクリプト停止シグナル| O["サブスクリプション解除"];
    N --> O;
    O --> P["スクリプト終了"];

コア実装（並列/キューイング/キャンセル）

Register-CimSubscription を使用したイベント購読

Register-CimSubscriptionコマンドレットは、WQL (WMI Query Language) を使用してイベントをフィルタリングします [4]。ここでは、プロセス作成イベントを監視する例を示します。

# 実行前提:


# - PowerShell 7以降推奨（ForEach-Object -Parallel 利用のため）


# - 管理者権限で実行

# イベント監視スクリプト


# このスクリプトは無限ループでイベントを待ち受けるため、バックグラウンドジョブとして実行するか、


# 別途停止ロジックを実装する必要があります。

function Start-ProcessCreationMonitor {
    param(
        [string]$SubscriptionId = "ProcessCreationMonitor",
        [int]$ThrottleLimit = 5, # ForEach-Object -Parallel の並列度
        [int]$RecheckIntervalSeconds = 60 # サブスクリプション再確認の間隔
    )

    # ロギング設定 (Start-Transcript は全体の出力を記録。構造化ログも併用推奨)

    $LogPath = Join-Path (Get-Item Env:TEMP).Value "$SubscriptionId-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"
    try {
        Start-Transcript -Path $LogPath -Append -Force
        Write-Information "イベント監視スクリプトを開始します。ログファイル: $LogPath" -InformationAction Continue
    }
    catch {
        Write-Error "トランスクリプトの開始に失敗しました: $($_.Exception.Message)"

        # ログが取れない場合でも続行

    }

    # 永続的なエラーとして扱わない設定 (スクリプトの停止を防ぐ)

    $ErrorActionPreference = 'Continue'

    # 既存のサブスクリプションを解除（再実行時などに備えて）

    try {
        Get-EventSubscriber -SourceIdentifier $SubscriptionId -ErrorAction SilentlyContinue | Unregister-Event
        Write-Information "既存のイベントサブスクリプション '$SubscriptionId' を解除しました。" -InformationAction Continue
    }
    catch {
        Write-Warning "既存のイベントサブスクリプション解除に失敗しました: $($_.Exception.Message)"
    }

    # イベントハンドラのスクリプトブロック


    # イベントが発生するたびに実行される

    $action = {
        param($event)

        # $event.SourceEventArgs.NewEvent にイベント詳細が含まれる

        $eventData = $event.SourceEventArgs.NewEvent

        # キューイングの代わりにここでは直接並列処理に渡す


        # 実際にはキューイングとワーカープールを組み合わせることで、


        # 高負荷時の安定性を高めることができます。

        $processInfo = [PSCustomObject]@{
            Timestamp = $eventData.__TIME_CREATED_Date_Utc
            ProcessName = $eventData.TargetInstance.Name
            ProcessId = $eventData.TargetInstance.ProcessId
            CommandLine = $eventData.TargetInstance.CommandLine
            User = $eventData.TargetInstance.GetOwner().User
        }

        # 並列処理でイベントを処理 (PowerShell 7以降の機能)


        # 高負荷時に対応するため、ForEach-Object -Parallelを使用


        # ここでは単一イベントだが、複数のイベントをバッファリングして一括処理する構成も可能

        try {

            # タイムアウトと再試行の概念


            # 実際の処理が外部システムへの書き込みなど時間のかかるものである場合、


            # Timeout-Command や独自の再試行ロジック (MaxRetries, RetryInterval) を実装します。


            # 例: Invoke-ExternalSystem -Data $processInfo -TimeoutSec 30 -MaxRetries 3

            # 本デモでは、簡易的な処理としてログ出力のみ

            $processInfo | ConvertTo-Json -Depth 3 | Write-Information -InformationAction Continue
            Write-Information "プロセス作成イベント処理完了: $($processInfo.ProcessName) (PID: $($processInfo.ProcessId))" -InformationAction Continue
        }
        catch {
            Write-Error "イベント処理中にエラーが発生しました: $($_.Exception.Message)"

            # エラーログへの記録、通知、再試行のトリガーなどをここに追加

        }
    }

    # CIMイベントサブスクリプションの登録


    # WQL: SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Process'


    #   __InstanceCreationEvent: インスタンス作成イベント


    #   WITHIN 5: 5秒ごとにイベントをポーリング (イベントプロバイダに依存)


    #   TargetInstance ISA 'Win32_Process': 作成されたインスタンスがWin32_Processクラスであること

    try {
        Register-CimSubscription `
            -ClassName "__InstanceCreationEvent" `
            -Query "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'Win32_Process'" `
            -SourceIdentifier $SubscriptionId `
            -MessageData $null ` # MessageDataは未使用
            -Action $action `
            -ThrottleLimit $ThrottleLimit # ForEach-Object -Parallel の並列度とは別で、これはWMIイベントの受信バッファリングに関係

        Write-Information "CIMイベントサブスクリプション '$SubscriptionId' を登録しました。プロセス作成イベントを監視中..." -InformationAction Continue

        # 監視を継続


        # スクリプトを停止するまでイベントを待ち受ける


        # 外部からの停止シグナル（例: Ctrl+C）を待つか、


        # 定期的なヘルスチェックでスクリプトが生きているか確認するループを実装

        while ($true) {

            # スクリプトが停止されない限り継続


            # 一定間隔でサブスクリプションの状態を確認するなどの運用ロジックをここに追加可能

            Write-Information "監視スクリプトはアクティブです。最終確認: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss JST')" -InformationAction Continue
            Start-Sleep -Seconds $RecheckIntervalSeconds

            # ここでサブスクリプションがまだアクティブか確認するロジックを追加することもできます。


            # 例: If (-not (Get-EventSubscriber -SourceIdentifier $SubscriptionId -ErrorAction SilentlyContinue)) {


            #         Write-Error "サブスクリプションが失われたようです。再登録を試みます。"


            #         # 再登録ロジック


            # }

        }
    }
    catch {
        Write-Error "CIMイベントサブスクリプションの登録中にエラーが発生しました: $($_.Exception.Message)"
    }
    finally {

        # スクリプト終了時にクリーンアップ

        Stop-Transcript
        Write-Information "イベント監視スクリプトを終了します。" -InformationAction Continue
    }
}

# 監視を開始する場合:


# Start-ProcessCreationMonitor


# 停止する場合は、PowerShellプロセスを終了するか、Unregister-Event を別途実行

# 監視を停止する関数

function Stop-ProcessCreationMonitor {
    param(
        [string]$SubscriptionId = "ProcessCreationMonitor"
    )
    try {
        Get-EventSubscriber -SourceIdentifier $SubscriptionId -ErrorAction SilentlyContinue | Unregister-Event
        Write-Information "イベントサブスクリプション '$SubscriptionId' を解除しました。" -InformationAction Continue
    }
    catch {
        Write-Error "イベントサブスクリプションの解除に失敗しました: $($_.Exception.Message)"
    }
}

上記のコードでは、Register-CimSubscriptionの-Actionスクリプトブロック内でイベントを受信し、直接処理しています。TargetInstance.GetOwner().Userのようなメソッド呼び出しは、WMIオブジェクトのプロパティからさらに詳細情報を取得する典型的なパターンです。 -ThrottleLimitパラメーターは、Register-CimSubscriptionがイベントキューにバッファするイベントの数に関連しますが、ForEach-Object -Parallelの並列度とは異なります。ForEach-Object -Parallelの並列度は、PowerShell 7で自動的に管理されますが、$PSDefaultParameterValuesや$env:POWERSHELL_TELEMETRY_OPTOUT環境変数で調整可能です [5]。

イベント監視のキャンセル

一時的サブスクリプションはPowerShellセッションの終了と共に自動的に解除されますが、明示的に解除することも可能です。

# SubscriptionIdを指定してイベントサブスクライバーを取得し、解除します。

$SubscriptionId = "ProcessCreationMonitor"
Get-EventSubscriber -SourceIdentifier $SubscriptionId | Unregister-Event
Write-Host "イベントサブスクリプション '$SubscriptionId' を解除しました。"

これはStop-ProcessCreationMonitor関数でも行われています。

検証（性能・正しさ）と計測スクリプト

イベント監視スクリプトの性能と正しさを検証することは重要です。特に、大量のイベントが短時間に発生した場合のスループットを確認します。

性能計測スクリプト

ここでは、意図的に多数のプロセスを起動するダミースクリプトを作成し、監視スクリプトがこれらのイベントをどれだけ早く処理できるかをMeasure-Commandで測定します。

# 実行前提:


# - PowerShell 7以降推奨


# - 管理者権限で実行

# 事前準備: Start-ProcessCreationMonitor がバックグラウンドで実行されていることを想定


# 例: Start-Job -ScriptBlock { C:\Path\To\Your\MonitorScript.ps1 }


# または、PowerShell ISEなどで Start-ProcessCreationMonitor を実行しておく

function Test-MonitorPerformance {
    param(
        [int]$NumberOfEvents = 100, # 発生させるイベント数
        [string]$MonitorSubscriptionId = "ProcessCreationMonitor"
    )

    Write-Host "--- イベント監視性能テストを開始します ---" -ForegroundColor Yellow

    # 現在のイベントログ数を取得 (簡易的なイベントカウントのため)


    # Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kernel-Process'] and EventID=4688]]" | Measure-Object | Select-Object -ExpandProperty Count


    # より正確には、監視スクリプトのログファイルや独自のキューからカウントすべき

    # ダミーイベント発生スクリプト

    $testScriptBlock = {
        param($Count)
        Write-Host "ダミーイベントを $(Get-Date -Format 'HH:mm:ss JST') に $Count 件発生させます..." -ForegroundColor Cyan
        1..$Count | ForEach-Object {

            # ダミーのnotepad.exeプロセスを起動し、即座に終了


            # WMIイベントはプロセス起動時に発生するため、この方法でイベントを生成できる

            Start-Process -FilePath "notepad.exe" -WindowStyle Hidden -PassThru | Stop-Process -Force -ErrorAction SilentlyContinue
        }
        Write-Host "ダミーイベントの発生が完了しました。" -ForegroundColor Cyan
    }

    Write-Host "$NumberOfEvents 件のイベント発生をシミュレートし、処理時間を計測します..." -ForegroundColor Green

    # 監視スクリプトがイベントを処理する時間を Measure-Command で計測

    $elapsedTime = Measure-Command -Expression {

        # テストイベントを発生させる

        &$testScriptBlock -Count $NumberOfEvents

        # 監視スクリプトが全てのイベントを処理するのを待つ (簡易的な待機)


        # 実際には、監視スクリプトの内部でイベント処理完了を示すフラグやキューが空になるのを待つべき

        Start-Sleep -Seconds 10 # イベント処理に十分な時間を確保
    }

    Write-Host "--- 性能テスト結果 ---" -ForegroundColor Yellow
    Write-Host "発生イベント数: $NumberOfEvents" -ForegroundColor Green
    Write-Host "処理にかかった時間: $($elapsedTime.TotalMilliseconds) ms" -ForegroundColor Green
    Write-Host "1イベントあたりの平均処理時間: $([math]::Round($elapsedTime.TotalMilliseconds / $NumberOfEvents, 2)) ms" -ForegroundColor Green
    Write-Host "--- テスト終了 ---" -ForegroundColor Yellow

    # 正しさの検証


    # 実際には、監視スクリプトのログファイルを解析して、


    # 期待される数のイベントが全て記録されているかを確認します。


    # 例: Select-String -Path $LogPath -Pattern "プロセス作成イベント処理完了" | Measure-Object | Select-Object -ExpandProperty Count

}

# 監視スクリプトが起動していることを確認し、テストを実行


# Test-MonitorPerformance -NumberOfEvents 500

このスクリプトは、notepad.exeを隠しウィンドウで起動し即座に終了することで、プロセス作成イベントを大量に発生させます。監視スクリプトのStart-ProcessCreationMonitorがバックグラウンドで動作している間にTest-MonitorPerformanceを実行することで、その処理性能を評価できます。

正しさの検証

正しさの検証は、監視スクリプトのログ出力と期待されるイベントの突き合わせによって行われます。例えば、上記Test-MonitorPerformanceで発生させたイベント数と、監視スクリプトのログファイルに記録された「プロセス作成イベント処理完了」の行数を比較することで、イベントの取りこぼしがないかを確認できます。

運用：ログローテーション/失敗時再実行/権限

ロギング戦略

PowerShellスクリプトの運用において、ロギングは可観測性とトラブルシューティングの要です。

  • トランスクリプトログ: Start-TranscriptとStop-Transcriptは、PowerShellセッションの入出力全体をテキストファイルに記録します [6]。これは簡易的なロギングに適していますが、構造化されていないため、機械的な解析には不向きです。

  • 構造化ログ: Write-Information, Write-Warning, Write-Errorなどのコマンドレットを使い、イベントオブジェクトをJSON形式で出力することで、SIEMシステムやログ分析ツールでの処理が容易になります。

# 構造化ログの例

$logEntry = [PSCustomObject]@{
    Timestamp = Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffZ"
    Level = "INFO"
    Message = "イベントが正常に処理されました。"
    EventDetails = $processInfo # 処理したイベントの詳細オブジェクト
}
$logEntry | ConvertTo-Json -Depth 3 | Out-File -FilePath "C:\Logs\monitor_structured.json" -Append -Encoding Utf8

ログローテーション: ログファイルが無制限に肥大化するのを防ぐため、ログローテーションは必須です。これはPowerShellスクリプト内で実装することも可能ですが、Windowsのタスクスケジューラとrobocopyなどの外部ツールを組み合わせて古いログファイルをアーカイブ・削除する方が、より堅牢で一般的なアプローチです。

エラーハンドリングと失敗時再実行

堅牢なスクリプトは、予期せぬエラーに適切に対処する必要があります。

  • try/catch/finally: 特定のコードブロックで発生したターミネーティングエラー（スクリプトの実行を停止させるエラー）を捕捉し、回復処理を実行します [7]。

  • -ErrorActionパラメータと$ErrorActionPreference変数: コマンドレット固有のエラー処理動作（例: SilentlyContinue, Continue, Stop）や、セッション全体のエラー処理動作を設定します [8]。監視スクリプトでは$ErrorActionPreference = 'Continue'として、単一のエラーでスクリプトが停止しないようにすることが一般的です。

  • 再試行ロジック: 外部システムへの接続エラーなど、一時的な障害に対しては、一定回数の再試行（例: MaxRetries, RetryIntervalSeconds）を実装することで、システムの回復性を高めます。

# 再試行ロジックの例

function Invoke-WithRetry {
    param(
        [ScriptBlock]$ScriptBlock,
        [int]$MaxRetries = 3,
        [int]$RetryIntervalSeconds = 5
    )
    for ($i = 0; $i -lt $MaxRetries; $i++) {
        try {
            return & $ScriptBlock
        }
        catch {
            Write-Warning "処理失敗 (試行 $($i + 1)/$MaxRetries): $($_.Exception.Message)"
            if ($i -lt ($MaxRetries - 1)) {
                Start-Sleep -Seconds $RetryIntervalSeconds
            }
            else {
                throw # 最終試行でも失敗したら例外を再スロー
            }
        }
    }
}

# 使用例:


# Invoke-WithRetry -ScriptBlock { New-Item -Path "C:\NonExistent\Folder" -ItemType File }

権限管理

CIM/WMIイベント監視には、通常、ローカルシステムまたは管理者権限が必要です。運用環境では、最小権限の原則 (Principle of Least Privilege) に従うことが重要です。

  • Just Enough Administration (JEA): JEAは、ユーザーが特定のタスクを実行するために必要な最小限の権限のみを付与するPowerShellのセキュリティフレームワークです [9]。カスタムの管理ロールを定義し、イベント監視サービスアカウントに限定されたコマンドレット実行権限を与えることで、攻撃対象領域を減らすことができます。

  • 機密情報の安全な取り扱い: 監視スクリプトが外部サービスへの認証情報（APIキー、パスワード）を必要とする場合、これらをスクリプト内にハードコードしてはいけません。SecretManagementモジュールは、PowerShellでシークレットを安全に保存・管理するためのフレームワークを提供します [10]。Windows資格情報マネージャーやAzure Key Vaultなどのシークレットストアと連携できます。

# SecretManagement モジュールの利用例 (インストールが必要)


# Install-Module -Name Microsoft.PowerShell.SecretManagement -Repository PSGallery -Force


# Install-Module -Name Microsoft.PowerShell.SecretStore -Repository PSGallery -Force


# Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

# Set-Secret -Name "MyApiServiceKey" -Secret "your-api-key-here" -Vault SecretStore


# $apiKey = Get-Secret -Name "MyApiServiceKey" -Vault SecretStore | ConvertFrom-SecureString -AsPlainText

落とし穴（例：PowerShell 5 vs 7の差、スレッド安全性、UTF-8問題）

PowerShell 5 vs 7の差

  • ForEach-Object -Parallel: PowerShell 7で導入された強力な並列処理機能です。Windows PowerShell 5.1では利用できないため、ThreadJobモジュールやRunspaceを直接操作する必要があります。

  • デフォルトエンコーディング: PowerShell 7はデフォルトでUTF-8（BOMなし）を使用しますが、Windows PowerShell 5.1はシステムのロケールに依存するエンコーディング（日本語環境ではShift-JISなど）を使用することが一般的です [11]。ログファイルや外部データとの連携でエンコーディングの問題が発生しないよう、Out-File -Encoding Utf8のように明示的に指定することが推奨されます。

スレッド安全性

ForEach-Object -ParallelやThreadJobなどの並列処理を利用する場合、複数のスレッドが共有変数やリソースに同時にアクセスする可能性があります。これにより、データ競合や予期せぬ動作が発生することがあります（スレッド安全性問題）。

  • 対策:

    • 可能な限り、スレッド間で共有するデータを避ける。

    • 共有データにアクセスする際は、[System.Threading.Monitor]::Enter()/Exit() や [System.Threading.ReaderWriterLockSlim] などの同期プリミティブを使用してロックをかける。

    • ConcurrentDictionaryのようなスレッドセーフなコレクションを使用する。

WQL構文のデバッグの難しさ

WQLクエリは、WMIイベントをフィルタリングする上で非常に強力ですが、構文エラーのデバッグは困難な場合があります。WMI Tester (wbemtest.exe) などのツールを使用して、クエリが意図した結果を返すか事前にテストすることが有効です。

イベントサブスクリプションのリーク

Register-CimSubscriptionで登録した一時的サブスクリプションは、スクリプトが予期せず終了したり、明示的にUnregister-Eventを呼び忘れたりすると、プロセス終了後もシステム内に残ってしまう可能性があります。これにより、不要なリソース消費や、次回スクリプト実行時に意図しない複数のサブスクリプションが活動する原因となります。

  • 対策:

    • スクリプトのfinallyブロックで必ずUnregister-Eventを呼び出す。

    • スクリプト起動時に、既存のサブスクリプションを検出して解除するロジックを組み込む（上記の例で実装済み）。

    • 定期的にGet-EventSubscriberで不要なサブスクリプションがないか確認し、手動または自動でクリーンアップする運用を行う。

まとめ

本記事では、PowerShellを用いたCIM/WMIイベント監視について、効率的な実装から運用上の注意点、潜在的な落とし穴まで幅広く解説しました。Register-CimSubscriptionによるイベント購読、ForEach-Object -Parallelによる並列処理、堅牢なエラーハンドリング、構造化ロギング、そしてJEAやSecretManagementによるセキュリティ対策は、プロフェッショナルなWindows運用において不可欠な要素です。

これらの手法を組み合わせることで、システムの安定性、セキュリティ、そして運用の可観測性を大幅に向上させることができます。具体的なコード例やフローチャートが、読者の皆様の実装の一助となれば幸いです。

参照情報:

  • [1] Microsoft Learn: Register-WmiEvent, 最終更新日: 2023年10月13日, 組織: Microsoft

  • [2] Microsoft Learn: Register-CimSubscription, 最終更新日: 2023年10月13日, 組織: Microsoft

  • [3] Microsoft Learn: Receiving WMI Events, 最終更新日: 2023年2月24日, 組織: Microsoft

  • [4] Microsoft Learn: WQL (WMI Query Language), 最終更新日: 2023年2月24日, 組織: Microsoft

  • [5] Microsoft Learn: ForEach-Object, 最終更新日: 2024年2月20日, 組織: Microsoft

  • [6] Microsoft Learn: Start-Transcript, 最終更新日: 2023年10月13日, 組織: Microsoft

  • [7] Microsoft Learn: about_Try_Catch_Finally, 最終更新日: 2023年10月13日, 組織: Microsoft

  • [8] Microsoft Learn: about_Preference_Variables, 最終更新日: 2023年10月13日, 組織: Microsoft

  • [9] Microsoft Learn: What is JEA?, 最終更新日: 2024年1月9日, 組織: Microsoft

  • [10] GitHub: PowerShell/SecretManagement module, 最終更新日: 2024年2月29日, 組織: PowerShell

  • [11] Microsoft Learn: Understanding Encoding in PowerShell, 最終更新日: 2023年10月13日, 組織: Microsoft

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました