none
Windows Server2016 のWSUSサーバからクライアントが更新ファイルをインストールできない RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    お世話になります。

    現在Windows Server 2016の仮想マシンをWSUSサーバとして構築しております。

    クライアントとしてWindows Server2012R2の仮想マシンを使用しております。

    WSUSサーバ、クライアントともにAD環境にはないため、クライアントはローカルグループポリシー

    を編集することで設定しております。

    現状、クライアント側からWSUSサーバへの状態の報告、

    WSUSサーバ側ではクライアントの認識と必要な更新プログラムの表示、更新プログラムの承認、

    クライアントで利用可能な更新プログラムを検索すると承認された更新プログラムの検出は可能です。

    しかし、クライアントで検出した更新プログラムをインストールしようとするとエラーが発生してしまいます。

    エラーコード:8024401F

    上記のエラー出力後、クライアントの\softwareDistribution\Downloadフォルダ内には

    新しくフォルダが作成されており、フォルダ内はcbshandlerフォルダ、statusファイル、BIT.tmpファイル

    のみ存在していました。

    更新プログラムの承認後、WSUSサーバ側のコンテンツディレクトリ内には新しくフォルダが作成され

    ますが、作成されたフォルダ内には.cabファイルと.txtファイルしかダウンロードされていません。

    またWSUSサーバのログにはDownload Retierdという記録がありました。

    そこで質問なのですが、WSUSサーバがMicrosoftUpdateサーバからダウンロードするファイルは上記のファイル形式のものだけで

    間違いないでしょうか。またクライアントがWSUSサーバからダウンロードするファイルは上記の形式のものだけで間違いないでしょうか。

    もし、更新ファイルのダウンロード自体に問題があるなら見直すべきはWSUSサーバのコンテンツディレクトリの権限などになるのでしょうか。

    質問が多くなり申し訳ありません。

    よろしくお願いいたします。

    2017年9月5日 14:38
    |

回答

  • Question
    サインインして投票
    0
    サインインして投票

    なるほど、iSCSI 等でボリュームとしてマウントしているのでは無く、ネットワーク上のファイル共有をネットワーク ドライブにして利用しているのですね。

    Microsoft 公式情報に明確な記載を見つける事は出来ませんでしたが、既定ではファイル共有 (ネットワークドライブ) を WSUS のコンテンツ フォルダにする事は出来ない様です。

    https://www.winvistatips.com/threads/storing-wsus-content-on-nas.744415/

     

    また、質問内容については Microsoft が技術情報として公開していません (少なくとも私は見つけられません) ので、初歩的な質問では有りません。

     

    上述の通り、Microsoft の技術情報が有りませんので、以下は私見です。

    WSUS がインターネットから更新プログラムを同期・ダウンロードする際は BITS を用いますが、BITS サービスは既定で LOCAL SYSTEM で動作していますので、コンテンツ フォルダには LOCAL SYSTEM のアクセス権が必要です。

    また、WSUS Service は既定で Network Service で動作していますので、Network Service のアクセス権も必要です。

    LOCAL SYSTEM と Network Service は、ネットワーク アクセス時は "コンピューター名$" を用いますので、ネットワーク ドライブ (ファイル共有) に対して "コンピューター名$" のアクセス権を付与すれば、動作する可能性が有ります。

    ただし、ローカルのドライブをコンテンツ フォルダにするのが推奨と思われますので、 WSUS として正常に動作するかは保証出来ません。

    http://www.atmarkit.co.jp/ait/articles/0905/08/news095.html

     

    上記以外の方法ですと、NAS で iSCSI が利用可能であれば、iSCSI でマウントすれば動作する可能性が有ります。

    https://sites.google.com/site/careersofavi/storingwsuscontentonaremotedrive(howto)

     

    また、ファイル共有元のサーバーが Windows Server であれば、以下の様に iSCSI で接続する事が可能です。

    https://blogs.technet.microsoft.com/askcorejp/2012/04/09/microsoft-iscsi-software-target/

    • 回答としてマーク komanndaP 2017年9月13日 14:27
    2017年9月11日 1:27
    |

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    WSUS で使用するポートを既定値から変更している環境でしょうか？

    Windows Server 2016 の WSUS においてポートを既定値から変更した方が、同じエラーになった様です。

     

    http://blog.livedoor.jp/kotositu/archives/48748863.html

    2017年9月6日 5:15
    |
  • Question
    サインインして投票
    0
    サインインして投票
    クライアント側でグループポリシーエディタを起動して更新サービスの場所
    のところでhttp://WUSUサーバ名:8530というようにポート番号を既存
    の８０から8530に変更しないと駄目です。
    　また、WSUSサーバーでポート番号を8530から80に変更するかどちらかですが
    8530にした意味があるのでクライアント側で変えた方が無難です。
    2017年9月6日 5:38
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ご回答いただきましてありがとうございます。

    WSUSのポート番号はデフォルトの8530から変更しておりません。

    またクライアントのローカルグループポリシーのイントラネットの更新サービスの場所は

    http://WSUSサーバのIPアドレス:8530としております。（http://WSUSサーバのFQDN:8530とした場合更新元のWSUSサーバに接続ができなくなりました。）

    記載していただいたURLのページを参照いたしましたところ、IISのWSUSのサイトを削除しhttps用のポートをIISに設定している？とあったのですが、これらの設定は必要でしょうか？

    IISに関しては何も手を付けておらず、httpsのポートは8531であったと思います。

    WSUSの仕組みを把握しきれておらず初歩的な質問となってしまい申し訳ありません。

    よろしくお願いいたします。

    2017年9月6日 13:14
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ご回答いただきましてありがとうございます。

    WSUSサーバのポート番号はデフォルトの8530のままだったと思います。

    またクライアントのローカルグループポリシーの更新サービスの場所は

    http://WSUSサーバのIPアドレス:8530としております。(WSUSサーバのFQDNではWSUSサーバに接続できませんでした)

    サーバ名を指定していないため何か影響が出ているのでしょうか？

    お手数おかけしまして申し訳ありません。

    よろしくお願いいたします。

    2017年9月6日 13:21
    |
  • Question
    サインインして投票
    0
    サインインして投票

    失礼しました、ポート変更はしていない環境でしたか。

    ポート変更を行わない限り、IIS側の設定は不要な認識です。

     

    質問内容の確認ですが、更新プログラムの確認 (更新プログラムの検出) が行われた後にインストールしようとするとエラーになるとの事ですが、ダウンロード時にエラーが発生するのでしょうか？それともインストール時にエラーが発生するのでしょうか？

    エラーコードからするとダウンロード時にエラーが発生していると思われますが、念のため確認です。

    2017年9月7日 0:24
    |
  • Question
    サインインして投票
    0
    サインインして投票

    Lapivy様

    ご返信いただきありがとうございます。

    updateログからエラーはダウンロードの時点で発生しているようです。

    質問で記載し忘れていたのですが、WSUSサーバのコンテンツディレクトリはネットワーク上のストレージをサーバのローカルDドライブとしてマウントしたものを指定しております。

    当初、WSUSサーバのイベントログではコンテンツディレクトリにフォルダを作成できないという内容のエラーが記録されていました。コンテンツディレクトリの権限にNETWORK SERVICEをフルコントロールで指定するなどしましたがエラーは解決されず、ネット上でネットワーク上のフォルダをコンテンツディレクトリに指定した場合のエラーなどに関する質問は数件見つけられたのですが解決策、またはローカルにマウントしていようとも、そもそもネットワーク上のフォルダを指定することはできないというはっきりとした情報は見つけられていない状態です。

    現在はネットワーク上のフォルダがあるドメインにWSUSサーバを参加させたためか、更新ファイルのダウンロード時のフォルダ作成やanonymousCheckテキストへのアクセスでエラーは発生していなかったのですが、本日確認したところ「コンテンツディレクトリにアクセスできません。(500)内部サーバーエラーです。」というイベントログがWSUSサーバに残っていました。

    情報が不十分なまま質問してしまい申し訳ありません。

    これから見直すべき設定はコンテンツディレクトリの権限でしょうか？またもしコンテンツディレクトリにネットワーク上のストレージはどうしてもしようできないという情報があればお知らせいただけないでしょうか。

    長くなりまして申し訳ありません。よろしくお願いいたします。

    2017年9月7日 14:49
    |
  • Question
    サインインして投票
    0
    サインインして投票

    以下のスレッドからするとネットワーク上のストレージでも iSCSI 等でボリュームとしてマウントされていれば使用出来そうですが、色々と Web 検索すると必ずしも動作する訳では無い様です。

    参考までに、どの様な方法でネットワーク上のストレージをマウントされているか教えて頂く事は可能でしょうか？

     

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/be3ba99b-d9cf-460c-a839-b939809f0fb7/wsus-30-doesnt-download-any-update?forum=winserverwsus

     

    一応、アクセス権ですと "NETWORK SERVICE" と "LOCAL SYSTEM" 辺りが有れば問題無かったと思いますが、アクセス権的には問題無いでしょうか？


    2017年9月8日 1:42
    |
  • Question
    サインインして投票
    0
    サインインして投票

    Lapivy様

    ご返信ありがとうございます。

    ストレージはWSUSサーバのエクスプローラ上でPCを右クリックし、ネットワークドライブの割り当てからDドライブとしてマウントしております。

    ネットワーク上のコンテンツディレクトリはeveryoneにフルコントロールを持っていますが、NETWORK SERVICEはアクセス権として設定できていません。

    WSUSの仕組みがまだ把握しきれていないのですが、WSUSサービスがコンテンツディレクトリにアクセスする際に使用するローカルのアカウントがNETWORK SERVICEで間違いないでしょうか？

    他のサーバの共有フォルダのアクセス権としてローカルのアカウントを指定することは可能でしょうか？

    またしても初歩的な質問となってしまい申し訳ありません。

    よろしくお願いいたします。

    2017年9月8日 16:11
    |
  • Question
    サインインして投票
    0
    サインインして投票

    なるほど、iSCSI 等でボリュームとしてマウントしているのでは無く、ネットワーク上のファイル共有をネットワーク ドライブにして利用しているのですね。

    Microsoft 公式情報に明確な記載を見つける事は出来ませんでしたが、既定ではファイル共有 (ネットワークドライブ) を WSUS のコンテンツ フォルダにする事は出来ない様です。

    https://www.winvistatips.com/threads/storing-wsus-content-on-nas.744415/

     

    また、質問内容については Microsoft が技術情報として公開していません (少なくとも私は見つけられません) ので、初歩的な質問では有りません。

     

    上述の通り、Microsoft の技術情報が有りませんので、以下は私見です。

    WSUS がインターネットから更新プログラムを同期・ダウンロードする際は BITS を用いますが、BITS サービスは既定で LOCAL SYSTEM で動作していますので、コンテンツ フォルダには LOCAL SYSTEM のアクセス権が必要です。

    また、WSUS Service は既定で Network Service で動作していますので、Network Service のアクセス権も必要です。

    LOCAL SYSTEM と Network Service は、ネットワーク アクセス時は "コンピューター名$" を用いますので、ネットワーク ドライブ (ファイル共有) に対して "コンピューター名$" のアクセス権を付与すれば、動作する可能性が有ります。

    ただし、ローカルのドライブをコンテンツ フォルダにするのが推奨と思われますので、 WSUS として正常に動作するかは保証出来ません。

    http://www.atmarkit.co.jp/ait/articles/0905/08/news095.html

     

    上記以外の方法ですと、NAS で iSCSI が利用可能であれば、iSCSI でマウントすれば動作する可能性が有ります。

    https://sites.google.com/site/careersofavi/storingwsuscontentonaremotedrive(howto)

     

    また、ファイル共有元のサーバーが Windows Server であれば、以下の様に iSCSI で接続する事が可能です。

    https://blogs.technet.microsoft.com/askcorejp/2012/04/09/microsoft-iscsi-software-target/

    • 回答としてマーク komanndaP 2017年9月13日 14:27
    2017年9月11日 1:27
    |
  • Question
    サインインして投票
    0
    サインインして投票

    Lapivy様

    返信が遅くなりまして大変申し訳ありません。

    とてもご丁寧にお教えいただきありがとうございます。

    共有フォルダへの"コンピュータ名$"のアクセス許可を設定してもう一度クライアントの更新テストを行ってみます。

    この度は大変ありがとうございました。

    また、何か進展がありましたら報告させていただきます。

    2017年9月13日 14:27
    |