2018年2月19日

【ＩＴの引っ越し～持っていけば動くわけではありません～】

～最近のＷｉｎｄｏｗｓ Ｕｐｄａｔｅについて～

今回は趣向を変えてWindows10の運用について考えてみます。

Windows10がリリースされてはや2年半ほどが経ち、半年ごとの大規模なアップデートもすでに4回を過ぎました。デスクトップOSのバージョン別シェア調査でも、今年の1月にWindows7を超えたことが報告（参照：statcounter）されているように、一般的なOSとして普及したようです。

Windows8からすでに変わっていたのですが、Windows7の普及度合いと比べると企業内では広がらなかったせいなのかあまり話題にならなかったのですが、Windows10への移行が進んで触れる機会が増えたせいで、Windows Updateのユーザーインターフェースと動作の変化、特に「更新しています」の状態が長く続くことに戸惑ったのではないでしょうか。以前のスタイルでも再起動が必要な更新の場合、シャットダウンまでと再起動が始まってからかなり長時間待たされる場合があり、こうなってしまえば実は現行のスタイルと大差はありません。あまり目にする機会が多くなかったということなのでしょう。

Windows10で行われるようになった半年ごとの大規模アップデートの場合、Windows自体をまるごと書き換えているといってもよい規模の更新になるため、ゼロからWindowsをインストールするのと大差ない時間がかかるようになりました。また、Windowsをセットアップして特段の指定をしないデフォルトのままだと、バックグラウンドで更新処理が走り不意に再起動がかかってしまい、しばらく手を出せない状態に見舞われるという事例も見聞きします。

もちろん更新とセキュリティの設定に用意されているアクティブ時間の設定や再起動の日時を指定するなどの対処をしておけば、少なくともいきなりの再起動は回避することが可能です。しかし、これらの設定をエンドユーザー任せにしておくと、対処法についてきちんと案内しておいても、漏れが出てしまって意図しないタイミングで再起動してしまい仕事にならないとか、作成中で未保存のファイルを失ってしまうという事故を引き起こすこともあり得ます。

また、Updateを取得する先は単にマイクロソフトのサイトだけでなく、LAN内部にあるすでにUpdateをダウンロード済みのパソコンから取得することも可能ですが、今まで触れた範囲では内部の別のクライアントから取得している事例には遭遇していません。そうなると数GBクラスの更新プログラムを複数のクライアントパソコンが並行してダウンロードするために外部との接続帯域を圧迫してしまし、ネットワーク全体が重たくなる弊害も引き起こす懸念もあります。

Windows ServerでActive Directoryを内部で運用している場合は、これらの事故を防ぐためのポリシーを定義して集中管理することが可能です。Active Directoryを運用していてまだこの部分を定義していないのであれば、Windows Updateとグループポリシーの2語で検索すればすぐに参考になる情報にたどり着けるので、見直しをお勧めします。

ポリシー管理に加えて、WSUS（Windows Server Update Services）をまだ導入していないのであれば、これも導入を検討する価値が大いにあります。WSUSを構築する場合、更新プログラムを累積的にWSUSサーバに蓄積しなければならないためのこのサービス用にもう1台サーバを導入しなければ間に合わないことが多かったのですが、サーバ機のディスク容量に余裕があればHyper-Vで仮想サーバを構築して、ここにWSUSをセットアップすることが無理なことではなくなってきました。

Windows Serverの場合、Standard版でもサーバ機のプロセッサコアの総数に注意は必要ですが、ミニマムな構成でもホストサーバに加えて仮想サーバを2台までライセンスが有効なので、ハード・ソフト両面で追加コストをかけずに導入することが可能となり、検討する価値が十分にあります。

内部でWSUSを用意すればドメインに所属するクライアントをグループ分けし、Windows Updateが適用されるスケジュールを割り振ることで、再起動が行われる日程や時間帯のコントロールも可能になります。

2018年2月

※ 関連ページ 「当社ＩＴのお引越しサービスのご案内」