2022年1月の帯域外リリース for Windows Server OS

１月にリリースされている累積的な更新プログラムについてですが、色々な問題が含まれている状況となっております。
また、１月以前にもいくつか問題を含んだ更新プログラムがリリースされており、中にはサーバーOS で勝手に再起動が動作してしまうような致命的なものが含まれていたりします。

そのため、こちらではどの更新プログラムで問題が混入し、どの更新プログラムでその問題が解消できるのかという内容をまとめてみましたので、ご参考にしてみてください。

※WSUS から配信したい場合はすべてWSUS に手動インポートする必要があります。

もし、WSUS Import がうまく行かない場合は、以下のリンク先をご確認ください。

Nautilus: WSUS でカタログからインポートできない場合の対処策 (dah8ra.blogspot.com)

該当 OS	原因となる更新プログラム	対策となる更新プログラム	解消される事象（代表的なもの）	公開情報
Windows Server 2019	KB5008218	KB5010196	リモート デスクトップを使用してサーバーにアクセスできない場合があります。 最終的に、サーバーが応答を停止する可能性があります。 さらに、黒い画面が表示され、サインインと一般的なパフォーマンスが低下する	https://support.microsoft.com/ja-jp/topic/2021-%E5%B9%B4-12-%E6%9C%88-14-%E6%97%A5-kb5008218-os-%E3%83%93%E3%83%AB%E3%83%89-17763-2366-0d9c500d-6e71-4cb4-99e2-416655622769
Windows Server 2019	KB5009557	KB5010791	Windows Server が予期せず再起動 / ベンダー ID を含む IP セキュリティ (IPSEC) 接続が失敗（VPN 接続不可）	https://support.microsoft.com/ja-jp/topic/january-18-2022-kb5010791-os-build-17763-2458-out-of-band-43697313-d8e0-4918-b6df-7f64d4d9a8cd
Windows Server 2016	KB5008207	KB5010195	リモート デスクトップを使用してサーバーにアクセスできない場合があります。 最終的に、サーバーが応答を停止する可能性があります。 さらに、黒い画面が表示され、サインインと一般的なパフォーマンスが低下する	https://support.microsoft.com/ja-jp/topic/2021-年-12-月-14-日-kb5008207-os-ビルド-14393-4825-35421e45-96b3-4585-9faa-02576d813e7a
Windows Server 2016	KB5009546	KB5010790	予期せず再起動 / ベンダー ID を含む IP セキュリティ (IPSEC) 接続が失敗（VPN 接続不可）	https://support.microsoft.com/ja-jp/topic/2022-%E5%B9%B4-1-%E6%9C%88-11-%E6%97%A5-kb5009546-os-%E3%83%93%E3%83%AB%E3%83%89-14393-4886-0c2cac57-13b6-42e6-b318-41ca32428f91
Windows Server 2012	KB5008285	KB5010215	Windows Server 2012が停止する可能性があります。 さらに、黒い画面、サインインの遅さ、または時間の一般的な遅さが発生して、最終的にサーバーが応答を停止	https://support.microsoft.com/ja-jp/topic/2021-年-12-月-14-日-kb5008285-セキュリティ専用更新プログラム-5c1ac43e-ddd4-48d9-a3af-68d03968080f
Windows Server 2012	KB5009595	KB5010794	サーバーが予期せず再起動	https://support.microsoft.com/ja-jp/topic/kb5010794-windows-8-1-%E3%81%8A%E3%82%88%E3%81%B3-r2-windows-server-2012%E3%81%AE%E5%B8%AF%E5%9F%9F%E5%A4%96%E6%9B%B4%E6%96%B0-2022-%E5%B9%B4-1-%E6%9C%88-17-%E6%97%A5-a92500fb-f227-400e-b70e-f7dd50386fd3
Windows Server 2012	KB5009619	KB5010797	Windows Server が予期せず再起動	https://support.microsoft.com/ja-jp/topic/kb5010797-windows-server-2012-2022-%E5%B9%B4-1-%E6%9C%88-17-%E6%97%A5-1f14f497-8404-404d-8d78-0c962c9e486d

Windows Server 2012R2 からWindows Server 2016、2019 へのインプレースアップグレードとWSUS の移行について

Windows Server 上でWSUS サーバー以外の機能を追加して運用している場合、そちらの機能を継続して運用するために、Windows Server のアップグレードが必要になる可能性があります。

その場合、WSUS の役割が追加されている場合、WSUS サーバーをインプレースアップグレードできるかどうかに焦点が当たることとなります。

結論としましては、インプレースアップグレードする場合は、WSUS の役割を一旦削除してからインプレースアップグレードを実施し、アップグレード後に再度WSUS の役割を追加することをお勧めします。

私が調べたところ、WSUS の役割を入れたままでインプレースアップグレードをすると、管理コンソールが開かなかったり、再度インストールしても、IIS にある「WSUS の管理」という項目が残っていると、インストール直後の後処理に失敗するとのことであったため、改めて新規にWSUS をセットアップしてデータベースを移行する方が、設定抜けに気づかないといったことがないと思いますので、おすすめです。

では、どのようにしてWSUS の移行を実行するかというと、WSUS のデータベースをでタッチ後、バックアップして、インプレースアップグレードしたら、WSUS のデータベースをリストアするという流れになります。

具体的な手順は2012R2 での移行手順となっていますが、下記のURL の2.3, 2.4 を参考に実施すれば移行可能と思いますので、困った場合は下記を参照してみてください。

2.3. WSUS データベースをバックアップする
2.4. WSUS データベースのバックアップを移行先サーバーで復元する

WSUS 3.0 SP2 から Windows Server 2012 R2 WSUS への移行手順 その 1 (WID -> WID の場合) | Microsoft Docs

WSUS 3.0 SP2 から Windows Server 2012 R2 WSUS への移行手順 その 2 (SQL -> SQL の場合) | Microsoft Docs

 

Chrominium Edge の更新プログラムをWSUS サーバーに同期させる手順

 WSUS 管理コンソールから、[サーバー名]>[オプション]>[製品と分類] より、[製品] タブで、「Microsoft Edge」を、[分類] タブで「更新」を選択して同期をすると、Chrominium Edge の更新プログラムが同期できる。

どの製品、分類を選択してよいかがわからない場合は、下記のMicrosoft のカタログサイトを確認すればわかる。

Microsoft Update カタログ

対象の更新プログラムで検索をすると、「製品」列と「分類」列があるので、これが上記で設定したものと同じものを選択すれば、検索した対象の更新プログラムが同期できます。

KB5005565 の不具合について

現時点で９月の累積更新プログラムである、KB5005565 を適用することで発生する事象については、下記３点があるようです。

• エラーコード「0x0000011b」でネットワーク上の共有プリンターから印刷ができなくなる不具合
• Bluetooth機器が接続されない不具合
• ローマ字/カナ入力モードが自動的に切り替わらない不具合
  

そのうち、２番目のBluetooth機器が接続されない不具合は私も確認しました。

事象としては、下記の赤丸の場所にBluetooth を有効にするスイッチが表示されません。

そして、一番下の項目にあるように「Bluetooth が無効です」と表示されます。

これらを回避するには、下記のようにコントロールパネルからアンインストールをします。（下記の画像は、すでにアンインストールしてしまったので、別の更新プログラムになります）

ちなみに、デバイスマネージャーを開いても、Bluetooth のツリーが存在していないようでした。

（表示＞非表示のデバイスの表示、をすれば見えるようにはなります）

そしてこの事象を治すのに、以外と時間がかかりました。

なぜならKB5005565 をアンインストールして再起動しても事象が解消していなかったからです。

私が利用している端末は、Win10 20H2 のデスクトップですが、色々調べてた結果、嘘のような話ですが、電源OFF 後に、電源コードを根本から抜いて、１分くらい経過したら、再度つないで起動することで、Bluetooth が使えるように戻ります。

本当にこれで治りました。ドライバの認識を初期化しているんじゃないかと思います。

2021年8月のSSU（KB5005260）について

 現在、恐らく一番多く利用されているエンドユーザー向けWindows10 のバージョンである、2004, 20H2, そして21H1 ですが、こちらの累積更新プログラムを適用するために必要なサービススタック更新プログラムについての備忘録になります。

まず、６月、７月の累積更新プログラムについてですが、こちらは５月の累積の更新プログラムが前提条件となっています。

2021 年 6 月 8 日 — KB5003637 (OS ビルド 19041.1052、19042.1052、および 19043.1052) (microsoft.com)

2021 年 7 月 13 日 — KB5004237 (OS ビルド 19041.1110、19042.1110、および 19043.1110) (microsoft.com)

抜粋：
===========================
最新の累積的な更新プログラムをインストールする前に、2021 年 5 月 11 日の更新プログラム(KB5003173)をインストールします。
===========================

しかしながら、今までは最新のSSU が適用されていれば、最新の累積更新プログラムは適用ができていました。

2021 年 5 月 11 日 — KB5003173 (OS ビルド 19041.985、19042.985、および 19043.985) (microsoft.com)

抜粋：
===========================
この LCU をインストールする前に、最後のスタンドアロン SSU (KB4598481) をインストールしてください。
===========================

しかし、５月の累積更新プログラムに同梱されているSSU がないと、６月、７月の累積更新プログラムが適用できなくなってしまったため、６、７月の累積を適用したい場合は、５月の累積の適用がMUST となってしまいました。

しかしながら、運用の手法として、置き換えられた更新プログラムは、WSUS サーバーにて拒否済みにし、しっかりメンテナンスしている環境である場合、６月の累積が５月の累積を置き換えるので、５月の累積が拒否済みとなり、６月の前提条件の５月が適用されない状況となってしまうことが発生しているようです。

つまり、６月、７月の累積を適用したい場合は、５月や６月の置き換えられる累積更新プログラムを拒否済みにせず、配信し続ける必要があります。

ただ、こちらの事象は、８月の最新のサービススタック更新プログラム（KB5005260）を適用することで、すべて解決できます。

現時点でのベストプラクティスは、８月のSSU を適用して最新の累積更新プログラムを適用することです。

SSU:
==========================
KB5005260: Windows 10 Version 2004、20H2、および 21H1 のサービス スタック更新プログラム: 2021 年 8 月 11 日 (microsoft.com)
==========================

累積更新プログラム：
==========================
2021 年 8 月 10 日 — KB5005033 (OS ビルド 19041.1165、19042.1165、および 19043.1165) (microsoft.com)

2021 年 9 月 14 日 — KB5005565 (OS ビルド 19041.1237、19042.1237、および 19043.1237) (microsoft.com)
==========================

８月のSSU を適用することで、６月、７月の累積更新プログラムも適用が可能となりますが、最新の累積更新プログラムではないため、やはり、最新の累積更新プログラムを適用していく方が運用としては望ましいと思います。

AWS のWorkMail で受信ができずにハマった話

 AWS のサービスである、WorkMail を利用したいと思い、セットアップをしました。

セットアップ自体はとても簡単で、Route53 でドメイン取得しておけば、MX レコードとかを自動で追加してくれるし、DKIM も勝手に設定してくれるので、これからメールサーバーを導入される小規模事業を始める方にはとてもオススメです。

こちらのサービスを導入しようとセットアップしたところ、メールの送信はすぐにできたのですが、メールの受信ができずに困りました。

gmail からメールを送信しても、MAILER-DAMON からメールが送れませんとのメールが迷惑メールボックスに届きます。

ほとんどの人はこのような事象には遭遇しないようで、同様の事象が発生している人も、WorkMail で作成したUser を一度Disable にしてからEnable にすると治った、という投稿もありましたが、そんなにうまくは行きません。

調査を進めたところ原因は、過去に作成したメール受信のルールセットの優先順位が、今回作成したWorkMail のルールよりも上に存在していたことにより、このルールセットが邪魔してメール受信ができていませんでした。

事象解消のための具体的な手順としては、Amazon SES のコンソールを開き、下記のEmail Receiving > Rule Sets から、View Active Rule を開きます。

具体的な原因は、下記のRule name のm-8 から始まる名前のものが他のルールよりも下にあるので、これを一番上の状態（下記の画像の状態）にします。

やり方は、対象のRule name をクリックして、編集画面を開いたら、下記の画像にある通り、Enabled になっていることを確認して、Run after rule で<Beginning> を選択してSave Rule ボタンを押して設定を保存することで、m-8 のRule の優先順位が一番高くなるので、この状態に修正すればメールが受信できるようになります。

この事象は、過去にメール受信の設定を自分で組んでいた場合に発生するため、新規にAWS を利用したり、過去にAmazon SES を利用したことがない人であれば遭遇しない事象となります。

最初は、Amazon SES がsandbox の状態だったので、これをproduction access にしなければいけないのかとも思ったのですが（Amazon の公式資料に、そのようなことを想像させる一文がGetting started receiving email の項にある）、公開情報を見ると、すべて送信時の制約しか記載が無いため、恐らく違うなと考えていました。

Step 2: Verify your domain - Amazon Simple Email Service Classic

以外と半日ハマってしましましたので、皆様はハマらないように参考にしていただけると幸いです。

WSUS でカタログからインポートできない場合の対処策

WSUS サーバーに着信しない更新プログラムというのが存在するのですが、これをWSUS サーバー経由でクライアントに配信、展開したい場合は、カタログサイトからインポートをする必要があります。

上記の「更新のインポート」からインポートしたいKB 番号の更新プログラムを選択して、下記のインポートのボタンを押します。

しかし、構築したての何も設定を変更していないWSUS サーバーだと、下記のように失敗してしまいます。

よくある回避策として、w3wp.exe.config を利用したやり方がありますが、こちらは.NET Framework に、OS 側で設定されている暗号化方式を参照してね、という設定をすることになるのですが、SchUseStrongCrypto のレジストリを追加したやり方の場合、.NET Framework に、強力な暗号化を構成してね、という設定となり、現時点ではTLS1.2 を利用するように構成されることになります。

ただ、.NET Framework に強力な暗号化を構成するように指定したとしても、OS 側の設定も結局のところ参照することにはなるので、OS側でTLS1.2 が無効になっていたら通信できないはずです。（現時点でTLS1.2 を無効にする人はいないと思いますが。。。）

また、TLS1.2 が使えない場合は、TLS1.1, 1.0 というようにバージョンを下げてリトライしますが、これを無効化する場合は、下記の過去記事を参照ください。

Nautilus: Windows Server 2016 でのTLS の設定について (dah8ra.blogspot.com)

ということで、SchUseStrongCrypto を追加するやり方ですが、下記の過去記事にまとめてありますので、ご参照ください。

Nautilus: Windows Server 2016 でRC4 を無効化 (dah8ra.blogspot.com)

また、公開情報としても下記に情報がありますので、こちらもご参照いただくとよいかと思います。

トラブルシューティング Windows Server Update Services (WSUS) の同期とインポートの問題 - Configuration Manager | Microsoft Docs