2021年9月19日日曜日

KB5005565 の不具合について

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

  • エラーコード「0x0000011b」でネットワーク上の共有プリンターから印刷ができなくなる不具合
  • Bluetooth機器が接続されない不具合
  • ローマ字/カナ入力モードが自動的に切り替わらない不具合
そのうち、2番目のBluetooth機器が接続されない不具合は私も確認しました。

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


そして、一番下の項目にあるように「Bluetooth が無効です」と表示されます。
これらを回避するには、下記のようにコントロールパネルからアンインストールをします。(下記の画像は、すでにアンインストールしてしまったので、別の更新プログラムになります)


ちなみに、デバイスマネージャーを開いても、Bluetooth のツリーが存在していないようでした。
(表示>非表示のデバイスの表示、をすれば見えるようにはなります)



そしてこの事象を治すのに、以外と時間がかかりました。
なぜならKB5005565 をアンインストールして再起動しても事象が解消していなかったからです。
私が利用している端末は、Win10 20H2 のデスクトップですが、色々調べてた結果、嘘のような話ですが、電源OFF 後に、電源コードを根本から抜いて、1分くらい経過したら、再度つないで起動することで、Bluetooth が使えるように戻ります。
本当にこれで治りました。ドライバの認識を初期化しているんじゃないかと思います。

2021年9月18日土曜日

2021年8月のSSU(KB5005260)について

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

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

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) をインストールしてください。
===========================

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

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

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

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

現時点でのベストプラクティスは、8月の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)
==========================

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

2021年5月1日土曜日

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 の項にある)、公開情報を見ると、すべて送信時の制約しか記載が無いため、恐らく違うなと考えていました。




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

2021年4月22日木曜日

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 を追加するやり方ですが、下記の過去記事にまとめてありますので、ご参照ください。


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

Windows Server 2016 でRC4 を無効化

Windows Server 2016 でRC4 を無効化する場合、以下の2つの方法があります。

レジストリ キー:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

値:SchUseStrongCrypto
値の種類:REG_DWORD
設定値:0x1

SchUseStrongCrypto については、下記の公開情報を参照するとよいでしょう。


================================
強力な暗号化の構成
強力な暗号化をサポートするように .NET Framework を構成します。 SchUseStrongCrypto レジストリ設定を DWORD:00000001 に設定します。 この値により、RC4 ストリーム暗号が無効になります。また、再起動が必要です。================================


もしくは、下記の レジストリを作成して設定することで、RC4 を無効化することができます。
既定では存在しないキー、値となりますので、存在しない場合は手動で作成してください。

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128

値の名前: Enabled
値の種類: REG_DWORD
設定値: 0x0

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128

値の名前: Enabled
値の種類: REG_DWORD
設定値: 0x0

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128

値の名前: Enabled
値の種類: REG_DWORD
設定値: 0x0

こちらはOS 再起動は不要です。

Windows Server 2016 でのTLS の設定について

Windows Server 2016 では、既定でTLS1.2 が有効となっております。
しかし、TLS1.1 や1.0 、そしてSSL3.0 まで利用できてしまいます。
そのため、下記のレジストリを設定することで、TLS1.2 以外の通信ができないように制御することが可能です。

TLS 1.0 の無効化
====================================================
以下のレジストリを作成して設定することで、TLS 1.0 を無効化することができます。
既定では存在しないキー、値となりますので、存在しない場合は手動で作成してください。

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server

値: Enabled
値の種類: REG_DWORD
設定値: 0x0

値: DisabledByDefault
値の種類: REG_DWORD
設定値: 0x1

TLS 1.1 の無効化
====================================================
以下のレジストリを作成して設定することで、TLS 1.1 を無効化することができます。
既定では存在しないキー、値となりますので、存在しない場合は手動で作成してください。

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server

値: Enabled
値の種類: REG_DWORD
設定値:       0x0

値: DisabledByDefault
値の種類: REG_DWORD
設定値:       0x1

SSL 3.0 の無効化
====================================================
以下のレジストリを作成して設定することで、SSL 3.0 を無効化することができます。
既定では存在しないキー、値となりますので、存在しない場合は手動で作成してください。

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client

レジストリ キー:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server

値: Enabled
値の種類: REG_DWORD
設定値:       0x0

値: DisabledByDefault
値の種類: REG_DWORD
設定値:       0x1


Enabled は OS で TLS 1.0、1.1 及びSSL 3.0 を有効/無効にするかを決めるレジストリです。
一方、DisabledByDefault はアプリケーションが明示的に TLS/SSL のバージョンを指定しない場合に、OS が自動的にそのバージョンの TLS/SSL 通信を行うかどうかを決定します。
"DisabledByDefault" を 0 に設定しますと、該当の TLS/SSL のバージョンが "既定で有効" になり、1 に設定しますと "既定で無効" になります。
しかしながら、"DisabledByDefault" がいずれの設定の場合でもアプリケーションが明示的に指定した場合には、指定されたバージョンの TLS/SSL 通信が行われます。
また、レジストリ キーとして上記の通り Client と Server の 2 つありますが、"Client" はクライアント側として動作するときの設定、"Server" はサーバー側として動作するときの設定となります。

より詳細な公開情報は下記にありますので、参照してみてください。



2021年4月17日土曜日

カタログ情報をDB から削除するコマンド

 WSUS に着信しない更新プログラムは、手動でインポートする必要があります。

インポートのやり方は管理コンソールの右側に[更新のインポート] という項目があるので、こちらをクリックしてカタログサイトからインポートを実施します。



初めてインポートする場合は、エラーがでてインポートできないかもしれませんので、その場合は、%SystemRoot%\system32\inetsrv にw3wp.exe.config ファイルを生成して、ファイルの内容に下記を追加して保存すれば、大体うまくインポートできるようになります。
---------------------------------
$wsus = Get-WSUSServer
$wsus.DeleteUpdate("XXXXXXXXXXXXX")
---------------------------------
※ "XXXXXXXXXXXXX" の部分につきましては UpdateID を入力します。

上記コマンドを実施して以下のエラーが発生する場合は、対象の更新プログラムが承認済みの状態だったりしますので、元の未承認の状態に戻すことで、事象が解消しますのでご確認ください。

===================================
PS C:\Users\administrator> $wsus.DeleteUpdate("628f5572-7e1a-4934-b864-3e6e24d3c758")
"1" 個の引数を指定して "DeleteUpdate" を呼び出し中に例外が発生しました: "spDeleteRevision: cannot delete revisionid: 11
3652 because it is still deployed to a Non DSS Target Group
spDeleteUpdate got error from spDeleteRevision
spDeleteUpdateByUpdateID got error from spDeleteUpdate"
発生場所 行:1 文字:1
+ $wsus.DeleteUpdate("628f5572-7e1a-4934-b864-3e6e24d3c758")
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : SqlException
===================================