WSUSは、どの更新プログラムがWindows ServerCoreのインストールに実際に適切であるかを知るのに十分なほど賢くないようです。たとえば、WSUSはServer 2012 R2 Update(KB2919355
)しかし、失敗します(試してみましたが、成功する自信がありませんでした。)そして、WSUSは、このサーバーに必要な更新がまだ14あると考えています。それらのうちの4つはSilverlightです。
さて、CoreエディションにSilverlight(皮肉)が必要かどうか、また、8.1/2012 R2の最近の「アップデート」がCore(皮肉ではない)に必要かどうかはわかりませんが、表面的には不適切に見えます。
14以上の更新と1つ以上の失敗した更新が継続的に必要であるため、このサーバーを存続させたくありません。
これをどのように処理するかについての考えは? MSがCoreの更新を処理するためのより良い対応を行っていないことに少し驚いています。それは、MSが推進していることだからです。
更新
私はいくつかのことを学びました。
私の提案は:
これで始められるはずです。
サーバーコアのインストールにKB2919355を正常にインストールしました。
私の知る限り、1つのコンピューターグループの更新を拒否することはできません。承認することはできません。承認されていない更新は、失敗または必要として表示されます。
これが本当に気になる場合は、いくつかのオプションを利用できます。どれも簡単でも簡単でもありませんが、それだけの価値があると考える人もいます。
ビルドは、サーバーとワークステーション用に別々のWSUSサーバーを作成します。
インターフェイスの列を非表示にし、更新カテゴリを使用して、重要な更新がシステムに適用されていないかどうかを確認します。
問題のある更新を拒否し、ローカルで公開された更新として再導入します。元の更新とは異なる検出ロジックを提供します。これにより、環境に適した検出ロジックを作成できます。
警告:これには、SCCM/SCUP、またはLUPやWSUSPackagePublisherなどのサードパーティツールを使用するか、WSUS APIを学習して、更新を公開する独自の方法を開発する必要があります。これは、この方法で無効にしたい更新について、適切なインストールコマンドと検出方法を調査する必要があることも意味します。
追加の利点:これにより、奇妙な副作用をもたらす可能性のある更新のインストール方法を管理できるため、環境内のソフトウェアをより細かく制御できるようになります。また、この方法を使用すると、実際にはMicrosoft製品以上のものを管理できます。私はこれを使用して、1つの中規模企業のほぼすべてのユーザーアプリケーションに更新を提供しました。 WSUSで使用するサードパーティアプリケーションの更新プログラムを提供する会社もあります。たとえば、Adobeは、カタログを通じて少なくともAcrobat、Reader、およびFlashPlayerのアップデートを提供しています。
警告:これには、WSUSの内部動作を掘り下げるか、サードパーティのツール/スクリプト/ソリューションを使用して探しているものを提供する必要もあります。
追加の利点:これが提供する柔軟性はあなたを驚かせるかもしれません:レポートパッケージで提供されるものに妥協する代わりに、WSUSに尋ねる質問に答えるレポートを持つことができます。