コグノスケ

Windows Updateが0x80070643エラーで失敗し続ける

最近、家で使っているWindows 10 22H2にてWindows UpdateのKB5034441という更新のインストールにずっと失敗していて、毎回0x80070643というエラーが出ます。しばらく無視していましたが鬱陶しいので対策することにしました。

MicrosoftのサイトにあるKB5028997（KB5028997: WinRE更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順）によると、回復パーティションのサイズを250MB増やしなさいとのこと。

やたら手順が多く面倒なので、より簡単そうなKB5034957（KB5034957: CVE-2024-20666 のセキュリティの脆弱性に対処するために、展開されたデバイスの WinRE パーティションを更新する）を試しました。

KB5034957の説明によれば、

• スクリプトをPatchWinREScript_2004plus.ps1という名前で保存
• Update用の*.cabファイル（※）をダウンロード
• PowerShellから実行

だけで良いはずです。

（※）カタログ（Microsoft Updateカタログ）から2024-01 Dynamic Update for Windows 10 Version 22H2 for x64-based Systems (KB5034232)を探します。

実行したけどだめだった

やってみると下記のエラーで怒られますので、設定を変えなければいけないようです。

PS C:\users\katsuhiro\desktop> .\PatchWinREScript_2004plus.ps1

.\PatchWinREScript_2004plus.ps1 : このシステムではスクリプトの実行が無効になっているため、ファイル C:\users\katsuhiro\d
esktop\PatchWinREScript_2004plus.ps1 を読み込むことができません。詳細については、「about_Execution_Policies」(https://g
o.microsoft.com/fwlink/?LinkID=135170) を参照してください。
発生場所 行:1 文字:1
+ .\PatchWinREScript_2004plus.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : セキュリティ エラー: (: ) []、PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

エラーメッセージが示すリンク先（実行ポリシーについて - PowerShell | Microsoft Learn）を見ると、この問題を解決するには管理者権限で実行したPowerShellにて、Set-ExecutionPolicyで設定を変えなされとのこと。なるほど……？とりあえず現在の設定のRestrictedより制限を1つ緩めたRemoteSignedにしました。

PS C:\users\katsuhiro\desktop> Set-ExecutionPolicy RemoteSigned

実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies
のヘルプ トピック (https://go.microsoft.com/fwlink/?LinkID=135170)
で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "N"): y

PS C:\users\katsuhiro\desktop> Get-ExecutionPolicy

RemoteSigned

スクリプトを実行すると色々ログが出たあとに、Delete mount direcotryと出ました。成功したのかな？ちなみにもう1回実行しようとすると、前にもやっただろ？と言われて動作しません。良くできておりますね。

PS C:\users\katsuhiro\desktop> .\PatchWinREScript_2004plus.ps1

コマンド パイプライン位置 1 のコマンドレット PatchWinREScript_2004plus.ps1
次のパラメーターに値を指定してください:
(ヘルプを表示するには、「!?」と入力してください。)
packagePath: windows10.0-kb5034232-x86_3f9ddcafa903e4dd499193a851ecacbe79d842b3.cab
01/25/2024 03:36:11 - This script was previously run successfully

これで万事解決と言いたいところですが、更新KB5034441のインストールは未だに成功しません。ええー、だめじゃん……！

手動でパーティションを拡大

同じエラーが出ているということは、まだ回復パーティションのサイズが足りないのでしょうか？とはいえ先程使ったPowerShellスクリプトをもう1回実行しても、2回目は何もしません。

スクリプト改造するのもダルいので、観念して手動で回復パーティションのサイズを拡大したところ、あっさりWindows Updateが成功しました。パーティションサイズの拡大の手順は、先ほども挙げたKB5028997（KB5028997: WinRE更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順）の通りです。

KB503441インストール成功

Windows Updateが変なエラーで止まらなくなって、嬉しいは嬉しいですけど、回復パーティションはサイズが増え803MBになってしまいました。1GB近くも何を保存しているんでしょうね？？

USB Type-C充電器の置き換え

USB Type-Cの充電器を3つほど購入しましたので、メモを残しておきます。

• Anker A2663113（Nano II 65W、USBポート: Cx1）
• Anker A2667N11（PowerPort III 3-Port 65W、USBポート: Cx2 + Ax1）
• ELECOM MPA-ACCP4465BK（USB Power Delivery 65W キューブAC充電器、USBポート: Cx2 + Ax1）

Anker Nano IIはLenovo ThinkPad E480のACアダプターを置き換えるために買いました。ThinkPad E480付属のACアダプタはやや大きいため、Nano IIのようなコンパクトな充電器はありがたいです。

Anker PowerPort IIIはスマホやタブレットの充電に長らく使ってきたAUKEY PA-Y12（72W Charging Station、USBポート: Cx1 + Ax2）の置き換えです。出力は負けますがコンパクトでありがたい限りです。時代の進化を感じます。

AUKEY Charging Stationに比べると、Anker PowerPort IIIはType-Aポートが-1でType-Cポートが+1です。以前ならType-Aポートが多い方が嬉しかったのですが、最近は我が家もType-Cでの充電に対応した機器が多くなって、AでもCでもどっちでも問題なくなりました。

ELECOMキューブ充電器は旅行で持っていく用に買いました。3ポートあるのにコンパクトでとても良いです。

ただ1点気になるのは、Type-CポートとType-Aポートの抜き差しを繰り返すとまれに充電制御がおかしくなる？現象です。Type-CポートのUSB-PD出力が5Vに張り付いてしまい、他のポートを空けても戻らなくなることがありました。コンセントから外して再度電源を投入すると直ります。何か条件があるのかな？

自分のドメインとGmailとDNSのSPFレコード

目次: 自宅サーバー

Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース（Gmailユーザへメールが届かなくなる？Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説！ - NRIセキュア ブログ）を思い出しました。

自分のドメインからGmailにメールを送ることはほとんどないですが、全く送れないのも困りそうです。試しにGmailに自分のドメインのメールアドレスからメールを送ったところエラーが返ってきました。もうポリシーが変更されているのでしょうか？

とりあえずDNSの設定を変更してSPF（RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1）レコードを追加します。送信元がメールサーバーのIPと一致しなければ、全部受信拒否してOKという強気の設定にしました（バリュードメインの設定パネル用の書式で書いています）。

txt @ v=spf1 ip4:219.94.129.142 -all

設定後しばらく待って（少なくともDNSのTTLに指定した秒数以上）からGmailにメールを送ったところ正しく届いていました。良かった良かった。

設定の意味がわからないときは

SPFレコードの設定を解説してくれているブログ（送信ドメインを認証するためのSPFレコードに詳しくなろう - SendGridブログ）が参考になりました。

活きた設定例を見たいときはプロバイダ各社のSPFレコードを見ると良いと思います。SPFはTXTレコードの一種なので、TXTレコードをDNSに問い合わせます。

$ dig wakwak.com TXT
（略）

;; QUESTION SECTION:
;wakwak.com.                    IN      TXT

;; ANSWER SECTION:
wakwak.com.             86400   IN      TXT     "v=spf1 ip4:211.9.226.0/25 ip4:211.9.226.128/26 ip4:211.9.227.0/25 ip4:211.9.227.160/27 ip4:211.9.230.0/23 ip4:211.132.128.0/23 ip4:211.132.130.160/28 ip4:211.132.130.132/31 ip4:211.132.130.208/31 ip4:219.103.130.0/24 ip4:219.103.131.128/26 ~all"

;; AUTHORITY SECTION:
wakwak.com.             73658   IN      NS      ns2.wakwak.com.
wakwak.com.             73658   IN      NS      ns1.wakwak.com.

;; ADDITIONAL SECTION:
ns1.wakwak.com.         37518   IN      A       211.9.226.37
ns2.wakwak.com.         37518   IN      A       211.9.226.101

理由はわからないですが、プロバイダのSPFレコードを見るとディレクティブ（レコードの最後の部分）に~allを使っていることが多いです。

今回はkatsuster.netのSPFレコードのディレクティブを-all（ルールに合致しなければ全部受信拒否）にしましたが、世の中のプロバイダ同様に~all（ルールに合致しなくても受信拒否しない）でも良いのかもしれません。