管理タスクのスクリプト化による自動化は、IT担当者の負担軽減に役立ちます。本連載でもWindows Updateの更新タスクをスクリプト化する方法を紹介してきました。しかし、Windows 10/Windows Serverの最新バージョンでは、これまで用いてきた前提となる技術が幾つか廃止されました。最新バージョンを運用環境に展開する前に、利用中のスクリプトに影響しないかどうかを確認してください。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
本連載の以下の回では、Windows Updateをスクリプト化して、「Windows Script Host」(WSH)や「PowerShell」(Windows PowerShellおよびPowerShell Core)でコマンドラインから実行し、更新プログラムのインストールから再起動までを自動化する方法を幾つか紹介しました。
具体的には、次の方法を紹介しました。詳細については各記事をご覧ください。
以下の筆者の別連載でも少し触れましたが、2020年5月末にリリースされた「Windows 10」の最新バージョン「Windows 10 May 2020 Update(バージョン2004)」と、Windows Serverの最新の半期チャネル「Windows Server, version 2004」では、古くから利用できる「Windows Update Agent(WUA)API」のCOM(Component Object Model)インタフェース以外の選択肢は利用できなくなります。
「Windows Update WMIプロバイダー」とこのプロバイダーに依存するPowerShellの「WindowsUpdateProviderモジュール」は、特にWindows 10での使用において原因不明のエラーで期待通りに動作しないことがあることを筆者は確認しています(画面1)。
この問題を解消するためにMicrosoftは、Windows Update WMIプロバイダーとWindowsUpdateProviderモジュールの廃止を決めたのかもしれません。筆者はこの変更に関する公式のアナウンスを見ていませんが、実機で確認しています。
WindowsUpdateProviderモジュールの「Get-WUIsPendingReboot」コマンドレットは、更新プログラムのインストールにより、再起動待ちかそうでないかを判断するのに利用できて便利です。筆者がよく利用してきたコマンドレットの一つです。
しかし、Windows 10 バージョン2004にアップグレードしたPCでこのコマンドレットを含む、WindowsUpdateProviderモジュールの全てのコマンドレットが以前のように動作しないことに気が付きました。コマンドレットは全て「プロバイダーによる読み込みエラーです」のエラーが発生して失敗します。
Windows 10 バージョン2004やWindows Server, version 2004を新規インストールした環境で確認してみると、WindowsUpdateProviderモジュールそのものが存在しません(画面2)。この時点で利用できなかったアップグレードPCのWindowsUpdateProviderモジュールは、旧バージョンにあったものをそのまま引き継いだものであることが分かりました。
WindowsUpdateProviderモジュールは、Windows 10 バージョン1709およびWindows Server, version 1709以降で刷新された「Windows Update WMIプロバイダー」を利用しています。そこで、WindowsUpdateProviderモジュールのコマンドレットではなく、名前空間「root/Microsoft/Windows/WindowsUpdate」のCIM(Common Information Model)クラスを直接操作しようとしましたが、今度は「無効な名前空間」というエラーに遭遇しました(画面3)。
Copyright © ITmedia, Inc. All Rights Reserved.