最終更新日付： 2017年9月21日
Windows 10になってから、Windows Updateを行うプロセスが少し複雑になりました。
- Delivery Optimization(DoSvc) 日本語名：配信の最適化
- Background Intelligent Transfer Service(BITS)
のどちらかがWSUSサーバーと通信します。
どちらのサービスを使ってWSUSサーバー(もしくはWindows Updateで)と通信しているか確認するにはどうしたら良いでしょうか？
レジュメ
環境・前提条件
- Windows 10 バージョン1703
- WSUS バージョン6.3.9600.18228 (windows server 2012 R2)
方法１、WSUSからダウンロード中時のサービス状態を確認
WSUSからダウンロード中に、
- Delivery Optimization(DoSvc) 日本語名：配信の最適化
- Background Intelligent Transfer Service(BITS)
のサービス状態を確認すれば、どちらのサービスが使われているのかわかります。
「配信の最適化」も「BITS」も通常のサービス状態は空ですので、「実行中」となっている方がWindows Updateサービスから使われています。
上記、画像の場合は「配信の最適化」サービスの方がWSUSクライアントとして使われていることがわかります。
方法２、プロセスIDから通信サービスを突き止める。netstat
これはWindows 10や、Windows Updateに限った方法では無いのですが、通信プロセスがなんなのか突き止める方法です。
今回はWSUSサーバーとは通信ポート「8530」で通信しているハズなので
netstat –ano | findstr :8530
でプロセスIDを取得し
タスクマネージャー「プロセス」タブを開き、右クリック「PID」にチェックを入れ、PIDを表示させます。
該当のPID番号のプロセス名を調べることにより、WSUSサーバーと通信しているプロセス・サービスがなんなのか突き止めることが出来ます。
今回の上記画面の場合は、
- Background Intelligent Transfer Service(BITS)
ということになりますね。
WSUSからダウンロードしている間、サービス状態が「開始」となっています。
PCをWindows10にしたらWSUSサーバーと通信しなくなった！？
実はWindows10はバージョン1703から「配信の最適化(DoSvc)」を採用するように変更がありました。
それ以前のWindows10のバージョンではWSUSと通信するデフォルトプロセス・サービスがBITSだったんですけどね。
バージョン1703以前のBITSに変更したい場合は、GPOの以下の設定を変更する必要があります。
[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [配信の最適化]
"ダウンロード モード" をバイパスに変更します。
- Windows Updateにて「配信の最適化」を利用している場合は、WSUSサーバー以外にインターネットとも通信する必要があり、
- Windows Updateにて「BITS」を利用している場合は、WSUSサーバーと通信出来ればインターネットとも通信する必要がありません。
BITSに変更することにより、インターネットに出れないWindows10パソコンでもWSUSサーバーと通信できるようになります。
時々Update Orchestrator ServiceもWSUSと通信している
時々、「Update Orchestrator Service」もWSUSサーバーと通信していました。
これが噂の、usoclientコマンドのサービスなんですね。
WSUSサーバーにWSUSクライアントとしてWindows10が見えてこない時に、
usoclient startscan
コマンドをコマンドプロンプトで実行することでWSUSサーバー上に見えてきます。
タスクスケジューラに、一時間に一回実行されるようにスケジュールされているんですね。
デフォルトでは22時間程度に一回実行されるようになっていました。
わかりやすい記事の公開ありがとうございます。現在、Windows10PCの展開に取り組んでいるため、大変為になります。
ところで記事の中で「タスクスケジューラに、一時間に一回実行されるようにスケジュールされているんですね。」とありますが、こちらはUpdate Orchestratorタスクのどちらの設定表示で確認できるのでしょうか。手元のWindows10 1703で見ても確認できなかったため、詳細を教えていただけますと幸いです。
＞Makiさん
検証した端末ではないWindows10で確認したところ、トリガーは一時間に一回実行ではありませんでした。
22時間程度に一回繰り返されていました。
勘違いかもしれませんので、また検証した端末で確認してみます。
＞Makiさん
確認しました。
検証した端末では、GPOの設定があり1時間に一回の頻度にカスタマイズされていました。
失礼しました、ご指摘ありがとうございました。
「コンピューターの構成」-「管理用テンプレート」-「Windowsコンポーネント」-「Windows Update」
の「自動更新の検出頻度」
になります。
ご確認ありがとうございます。
私も22時間（*80~100% 揺らぎ）に一回と認識していましたが、Windows10においては、再起動した際にも22時間のサイクルに反してUpdateが実行されているように見られて、疑問に思って調べていました。
そこで、putiseさんの「1時間に一回」がヒントになるかと思い、ご質問させていただいてましたが、GPOの設定だったということで承知しました。
おそらくは、タスクスケジューラの「Schedule Scan」のトリガーに、22時間のトリガーとは別に定義されている「カスタムトリガー」と「イベントトリガー」に起因していると思われますが、詳細はまだわかっておりません。
>Makiさん
なるほど、失礼しました。
Updateが実行されているというのは何から判断したのでしょうか？
タスクスケジュールが怪しく気になる場合は、タスクスケジュールの履歴をとれば
もしかしたらログからヒントがつかめるかもしれませんね。
〉 Updateが実行されているというのは何から判断したのでしょうか？
[設定] – [更新とセキュリティ] – [Windows Update] に表示される最終確認日時からです。
実際に起動後にすぐこのメニューを開くと「更新を確認しています・・」のアクションが実行されていることも確認いたしました。
前回の最終確認日時から22時間（*80~100% 揺らぎ）経過していないタイミングで起動しても、このような動きなるためなんだろうなと疑問に思ってます。
タスクスケジュールの履歴についてご助言ありがとうございます！
>Makiさん
本当ですね、不思議ですね（タスクスケジューラの動きを理解できていないのかもしれませんが）
システム起動時（少し後に）に、「Schedule Scan」が実行されていますね。
「タスクスケジューラはスケジュール通りにタスクを起動できませんでした」という
メッセージが気になりますね