WSUS 管理コンソールから、[サーバー名]>[オプション]>[製品と分類] より、[製品] タブで、「Microsoft Edge」を、[分類] タブで「更新」を選択して同期をすると、Chrominium Edge の更新プログラムが同期できる。
どの製品、分類を選択してよいかがわからない場合は、下記のMicrosoft のカタログサイトを確認すればわかる。
対象の更新プログラムで検索をすると、「製品」列と「分類」列があるので、これが上記で設定したものと同じものを選択すれば、検索した対象の更新プログラムが同期できます。
現時点で９月の累積更新プログラムである、KB5005565 を適用することで発生する事象については、下記３点があるようです。
現在、恐らく一番多く利用されているエンドユーザー向け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 を利用したいと思い、セットアップをしました。
セットアップ自体はとても簡単で、Route53 でドメイン取得しておけば、MX レコードとかを自動で追加してくれるし、DKIM も勝手に設定してくれるので、これからメールサーバーを導入される小規模事業を始める方にはとてもオススメです。
こちらのサービスを導入しようとセットアップしたところ、メールの送信はすぐにできたのですが、メールの受信ができずに困りました。
gmail からメールを送信しても、MAILER-DAMON からメールが送れませんとのメールが迷惑メールボックスに届きます。
ほとんどの人はこのような事象には遭遇しないようで、同様の事象が発生している人も、WorkMail で作成したUser を一度Disable にしてからEnable にすると治った、という投稿もありましたが、そんなにうまくは行きません。
調査を進めたところ原因は、過去に作成したメール受信のルールセットの優先順位が、今回作成したWorkMail のルールよりも上に存在していたことにより、このルールセットが邪魔してメール受信ができていませんでした。
事象解消のための具体的な手順としては、Amazon SES のコンソールを開き、下記のEmail Receiving > Rule Sets から、View Active Rule を開きます。
具体的な原因は、下記のRule name のm-8 から始まる名前のものが他のルールよりも下にあるので、これを一番上の状態（下記の画像の状態）にします。
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
===================================
下記のリンクから、Japan Microsoft Endpoint Manager Support Team のブログにいけます。
日本マイクロソフト サポート情報 (cssjpn.github.io)
今までのフォーラムの情報もアーカイブとして残っていますが、いつ削除されるかわからないので、保存しておきたい情報はスクショしておきましょう。
ちなみにブログのリンクは以下。
Japan Microsoft Endpoint Manager Support Blog (jpmem.github.io)
MECM/SCCM では、BranchCache とPeerCache の設定を両方有効にすることが可能です。
その場合、どちらの機能を利用してコンテンツをダウンロードするの？という疑問が湧いてきます。
これは結論から言うと、通常の環境であれば、PeerCache が有効になるケースがほとんどとなります。
理由としては、BranchCache は配布ポイントからダウンロードされる場合に有効となりますが、コンテンツのダウンロードソースの優先順位はPeerCache ソースの方が優先順位が高いため、PeerCache が有効になります。
ただ、PeerCache ソースがダウンしているような状況であれば、配布ポイントからのコンテンツダウンロードが動作するため、その場合はBranchCache が利用される動作となります。
コンテンツのダウンロードソースの優先順位は下記の公開情報に情報がありますので、確認してみてください。
MECM では、ピアキャッシュという機能があります。
簡単にいうと、ピアキャッシュソースというコンテンツを持つクライアント端末に対して、他のコンテンツを持たないクライアントが、ピアキャッシュソースからコンテンツをダウンロードする、というもので、配布ポイントからのダウンロードをしない動作となります。
クライアントのピア キャッシュ - Configuration Manager | Microsoft Docs
この中で、MECM の管理コンソールの下記のチェックを有効にした場合に、上記の公開情報にある一部ダウンロードという機能が有効になります。
WSUS から配信できない更新プログラムを手動でインポートしたが、これを消したいということがあるかと思います。
その場合、下記のコマンドをPowerShell から実行すればカタログ情報から削除できます。
- サンプル コマンド
--------------------------------
$wsus = Get-WSUSServer
$wsus.DeleteUpdate("13b5a526-7f85-4546-adde-95ced26276e5")
--------------------------------
※ "13b5a526-7f85-4546-adde-95ced26276e5" の部分は UpdateID を入力します。
UpdateID を確認する場合、カタログサイトの対象の更新プログラムを選択した時に表示されるURL 情報を確認するとよいでしょう。
