DataDomainをAWS上にたてる場合の構成のメモ 2023/12/07


DELL PowerProtect DD(DataDomain)には、オブジェクトストレージにデータを保存するような機能がある。

1つはAvamarと連動した場合に使用できる、Data Domain全体のバックアップをオブジェクトストレージに対して保存するというDataDomain CloudDR機能。

もう1つは、Data Domainにある、高速でコストが高いActive Tierにデータを保存して、一定日数経ってアクセスする可能性が少なくなったデータを遅くてコストが安いCold Tierに移動する、という階層化構造を利用するCloud Tier機能である。

Cloud Tier機能を使う場合、一度DataDomainに接続されているディスクに対してデータを保存し、一定日数(最小14日)経過後にオブジェクトストレージに転送される、という設定になる。

この2種類の方法だと、クラウド上だけにデータが保存されている、というわけではないので使いにくい。

いろいろ資料を調べると、AWS, Azure, GCP上に仮想的なDataDomain、DELL PowerProtect DD Virtual Edition(DDVE)が提供されていて、これらにおいては、オブジェクトストレージのみに対してデータを保存するという、Active Tier on Object Storage (ATOS) という機能があるようだ。

ローカル(オンプレ)のvSphere, Hyper-V上に対してDDVEも展開できるのだが、その場合はその機能はついていない。(これは評価版を入れて確認した)

Dell PowerProtect DDVE on Amazon Web Services 7.12 Installation and Administration Guide」の「初期設定手順」を確認すると、「File System」の「Active Tier」設定で、Storage Typeとして「Object Store」で設定している。

なので、DDVEをクラウド上に展開するときだけ、使えるんだと思うんだけど、認識はあってるんだろうか?

Data Domain: DDVE and ATOS Supported Configurations, Event Message: Unsupported virtual hardware configuration

Data Domain: Data Domain Virtual Edition(DDVE) which are Cloud deployed (ATOS), may run out of Local-Metadata Storage

AWS上に作成する場合、「APEX Protection Storage for AWS (DDVE)」(以前DDVEと呼ばれいたAPEX Protection Storageと注釈が入ってる)にはサンプル構成として以下のようなものが書かれている

ドキュメントをいろいろ眺めてみると

・インスタンスについて
保存領域のサイズによってインスタンス選択が変わり
2023年12月時点では M5.xlarge(16TB), M5.2xlarge(32TB), M5.4xlarge(96TB), M5.8xlarge(256TB) となっている。
なお、以前は M4シリーズだった模様

・インスタンスが動作するために必要なEBSについて
GP3のストレージが要求されている(以前はGP2)
root領域 250GB
NVRAM disk領域 10GB
data disk領域 1024GB(これ不要かも?)
metadata disk領域が最小2TB~26TB以上

metadata disk領域は、重複排除/圧縮状況により変化し、重複排除率が上がると使用容量も増え、残り容量が20%を切ると増設が必要となるので注意。
16TB構成時 1TB*2個
32TB構成時 1TB*4個
96TB構成時 1TB*10個
256TB構成時 2TB*13個

metadata用領域が足らなくなった場合の対処→「Data Domain: Data Domain Virtual Edition(DDVE) which are Cloud deployed (ATOS), may run out of Local-Metadata Storage

・このほかにデータを保存するオブジェクトストレージ AWS S3

・ATOS構成の場合、Cloud Tierは使用できない
いきなりクラウドに書いてるので、そこからさらにクラウドに移動させる、という機能は使えない(not support)

iSCSIストレージ上のvSphere仮想マシンのSANバックアップを仮想マシン上で実験する


vSphere仮想環境でFC-SANやiSCSI-SANの共有ディスク上に作ったVMFSデータストアがあり、そこにあるvSphere仮想マシンのバックアップを行う場合の手法はいくつかある。

・SAN
・HotAdd
・NBD/NBDSSL

ここらを解説してる資料があるかなーと探してみると

vSphere 5時代の「Virtual Disk Transport Methods」だと絵付きで解説されてるんですが、現状のVMware公式記述はVMware Virtual Disk Development Kit Programming Guide 8.0の「Virtual Disk Transport Methods」で一覧としてのページには絵はないが個別ページ(SAN Transport)には絵がある。

じゃあ、とバックアップソフト側を探すといろいろでてくる

その中でも、Veritas NetBackup「VMware のトランスポートモード: ベストプラクティスとトラブルシューティング」が分かりやすいかなぁ、と感じた。

SAN Transport

SAN Transportについて、何の変哲もないiSCSIストレージを、ESXiサーバとWindowsサーバの両方につなげただけでも使えるのかな、と検証してみようとした。

(上記画像はVMwareから転載)

まあ、実機の環境がなかったので、vSphere仮想マシンのWindowsサーバからiSCSI接続して構築してみたところ、commvaultの場合は「SAN access is only supported for physical machines.」というメッセージでバックアップさせてくれなかった。

Event Code: 91:248
Severity: Minor
Program: vsbkp
Description:
Unable to open the disks for virtual machine [仮想マシン名] for SAN access. SAN access is only supported for physical machines.

なにを設定すればごまかせるかな?と試行錯誤・・・とりあえず以下の設定で仮想マシンを作ってみたものの駄目だった。

CPU:ハードウェア仮想化 ハードウェアアシストによる仮想化をゲストOSに公開
IOMMU:IOMMUをゲストOSに公開
パフォーマンスカウント:仮想CPUパフォーマンスカウンタの有効化
SCSIコントローラ:LSI Logic SAS
ネットワークアダプタ:E1000e
ゲストOS:その他 その他(64ビット)
VMware-toolsインストールなし

結局のところ、普通に作ってから、[構成パラメータ]で「smbios.reflecthost」を「TRUE」とするだけで成功した。以下は実際に使った設定。

SCSIコントローラ:LSI Logic SAS
ネットワークアダプタ:E1000e
ゲストOS:Windows Windows Server 2016以降
VMware-toolsインストールあり
構成パラメータ: smbios.reflecthost 「TRUE」

どうやらBIOS stringにVMwareの文字列が入っているかどうかで判定していた模様。

今回はCommvaultバックアップでの事例だったけど、NetBackupなど他のバックアップソフトウェアでもvSphere環境へのアクセスはVDDK経由で行っているので、おそらく同じような制限がかかっているのではないかと想定している。

2023/11/22追記: NetBackup 8.1.1環境があったので試してみたら、こちらは偽装しなくてもそのまま動いた

ONTAP 9.6以前からONTAP 9.7以降にアップデートする際に容量の問題が発生する可能性


ONTAP 9.5P5シミュレータ環境をONTAP 9.7にアップデートした場合には問題なかったのに、運用中のONTAP 9.5P10環境をアップデートしようとしたところ、firmwareアップロードの段階で「THe request body must have content type multipart/form-data with a field named file」というエラーとなった。

確認すると、ONTAP 9.5P10, ONTAP9.6~ONTAP 9.6P6で発生するというえらくピンポイントな仕様問題だった。(System Manager ONTAP 9.7 image upload fails with multipart/form-data error)

ファイルをアップロードする領域が2GBと設定されているが、ONTAP 9.7では2GBでは足らなくなったためエラーになる、という問題だった。

webのアップロード用パラメータを2GBから4GBに変更することで対処できるとのことで実施した。

まず、diagモードに切り替えて現在の設定確認

netappcluster::> set diag

Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

netappcluster::*> system services web file-uploads config show
Node              Size
----------------- ------------
netappcluster-01  2GB
netappcluster-02  2GB
2 entries were displayed.

netappcluster::*>

次に変更を実施

netappcluster::*> system services web file-uploads config modify -node * -size 4GB

Warning: Files already uploaded or are being uploaded will be lost. Starting a
         file upload before the resize operation is finished will cause the
         uploaded file to be unavailable.
Do you want to continue? {y|n}: y
[Job 14002] Job is queued: Web File Upload Resize Node Job.
[Job 14003] Job is queued: Web File Upload Resize Node Job.
2 entries were modified.

netappcluster::*> 

すぐに反映されないので、上記で出力されたジョブIDのステータスを確認する。


netappcluster::*> job show -id 14002
                            Owning
Job ID Name                 Vserver    Node           State
------ -------------------- ---------- -------------- ----------
14002  Web File Upload Resize Node Job netappcluster netappcluster-01 Success
       Description: Web File Upload Resize Node Job

netappcluster::*> job show -id 14003
                            Owning
Job ID Name                 Vserver    Node           State
------ -------------------- ---------- -------------- ----------
14003  Web File Upload Resize Node Job netappcluster netappcluster-02 Success
       Description: Web File Upload Resize Node Job

netappcluster::*>

「Success」が含まれていれば変更が完了している。(変更途中は Running )

ただ、変更が終わったあとの設定表記は4GBとならずに「0B」となるが、これで正常とのこと

netappcluster::*> system services web file-uploads config show
Node              Size
----------------- ------------
netappcluster-01  0B
netappcluster-02  0B
2 entries were displayed.

netappcluster::*>

KBには「system node systemshell -node * -command df -h /mroot/etc/upload」を実行して /mroot/etc/upload に割り当てられた容量を確認する、という記載がある。

ここで使っているsystemshellコマンドは最近のONTAP OSでは標準で使えない状態に変更されているため「Error: command failed: Error: Account currently locked. Contact the storage administrator to unlock it.」というエラーとなる場合がある。その場合は、ロックを解除する必要がある。手順については「NetApp ONTAPから他サーバに気軽にsshできる穴がふさがれてしまった」を参考のこと

で、ONTAP 9.13.1ぐらいになってくると状況によっては4GBより必要な可能性もあるようで、最近になって「System Manager fails to upload ONTAP image due to insufficient space」というKBが追加されていた。こちらは7GBに変更するとあるが、2023年11月時点ではこの問題が発生する状況が未公開となっているため、4GBのままで良さそうである。

CVE-2022-38023適用後 NetAppがActive Directoryに参加できない


いままでも「SMB2 Enabled for DC Connections設定に起因する接続できない問題」というのがあったが、先日話題になった「Active Directoryサーバのセキュリティ強化アップデート(CVE-2022-38023)に伴うONTAPファイルサーバへの影響」で、2023年7月以降のActive Directory環境ではONTAP をCIFSに新規作成しようとした場合にエラーがでる、という問題が出ていた。

Is AES Encryption Enabled設定」と「AES session key enabled for NetLogon channel設定」の2つの設定を変更する必要がある。

前者はONTAP 9.12.1から初期値変更、後者はONTAP 9.10.1から初期値変更となっているので、最近導入している場合は問題が発生しないのだが、以前のバージョンからアップデートしているような環境の場合は以前の値のままとなっているため注意が必要となっている。

その1: Is AES Encryption Enabled 設定

以前からONTAPを使っていてアップデートしているような環境では、SMB内部接続での暗号化形式でAESを使わない、という設定になっているせいで、下記の様なエラーとなる。

netapp9101::> vserver cifs create -vserver svm3 -cifs-server svm3 -domain adosakana.local

In order to create an Active Directory machine account for the CIFS server, you must supply the name and password of a Windows account with
sufficient privileges to add computers to the "CN=Computers" container within the "ADOSAKANA.LOCAL" domain.

Enter the user name: administrator

Enter the password:

Error: Machine account creation procedure failed
  [    47] Loaded the preliminary configuration.
  [   130] Created a machine account in the domain
  [   130] SID to name translations of Domain Users and Admins
           completed successfully
  [   131] Successfully connected to ip 172.17.44.49, port 88 using
           TCP
  [   142] Successfully connected to ip 172.17.44.49, port 464 using
           TCP
  [   233] Kerberos password set for 'SVM3$@ADOSAKANA.LOCAL' succeeded
  [   233] Set initial account password
  [   244] Successfully connected to ip 172.17.44.49, port 445 using
           TCP
  [   276] Successfully connected to ip 172.17.44.49, port 88 using
           TCP
  [   311] Successfully authenticated with DC
           adserver.adosakana.local
  [   324] Unable to connect to NetLogon service on
           adserver.adosakana.local (Error:
           RESULT_ERROR_GENERAL_FAILURE)
**[   324] FAILURE: Unable to make a connection
**         (NetLogon:ADOSAKANA.LOCAL), result: 3
  [   324] Unable to make a NetLogon connection to
           adserver.adosakana.local using the new machine account
  [   346] Deleted existing account
           'CN=SVM3,CN=Computers,DC=adosakana,DC=local'

Error: command failed: Failed to create the Active Directory machine account "SVM3". Reason: general failure.

netapp9101::>

この問題はマニュアルの「Enable or disable AES encryption for Kerberos-based communication」に記載されているように「is-aes-encryption-enabled」設定をtrueに変更することで解決する。

netapp9101::> vserver cifs security modify -vserver svm3 -is-aes-encryption-enabled true
netapp9101::> vserver cifs security show -fields is-aes-encryption-enabled
vserver is-aes-encryption-enabled
------- -------------------------
Cluster -
Snapmirror-WAN
        -
netapp9101
        -
netapp9101-01
        -
svm0    true
svm2    false
svm3    true
7 entries were displayed.

netapp9101::>

その2: AES session key enabled for NetLogon channel 設定

上記を設定しても、下記の様なエラーとなった。

netapp9101::> vserver cifs create -vserver svm3 -cifs-server svm3 -domain vm2.adosakana.local

In order to create an Active Directory machine account for the CIFS server, you must supply the name and password of
a Windows account with sufficient privileges to add computers to the "CN=Computers" container within the
"ADOSAKANA.LOCAL" domain.

Enter the user name: administrator

Enter the password:

Error: Machine account creation procedure failed
  [    43] Loaded the preliminary configuration.
  [   133] Created a machine account in the domain
  [   133] SID to name translations of Domain Users and Admins
           completed successfully
  [   134] Successfully connected to ip 172.17.44.49, port 88 using
           TCP
  [   144] Successfully connected to ip 172.17.44.49, port 464 using
           TCP
  [   226] Kerberos password set for 'SVM3$@ADOSAKANA.LOCAL' succeeded
  [   226] Set initial account password
  [   253] Successfully connected to ip 172.17.44.49, port 445 using
           TCP
  [   284] Successfully connected to ip 172.17.44.49, port 88 using
           TCP
  [   316] Successfully authenticated with DC
           adserver.adosakana.local
  [   323] Encountered NT error (NT_STATUS_PENDING) for SMB command
           Read
  [   327] Unable to connect to NetLogon service on
           adserver.adosakana.local (Error:
           RESULT_ERROR_GENERAL_FAILURE)
**[   327] FAILURE: Unable to make a connection
**         (NetLogon:ADOSAKANA.LOCAL), result: 3
  [   327] Unable to make a NetLogon connection to
           adserver.adosakana.local using the new machine account
  [   344] Deleted existing account
           'CN=SVM3,CN=Computers,DC=ADOSAKANA,DC=local'

Error: command failed: Failed to create the Active Directory machine account "SVM3". Reason: general failure.

netapp9101::>

この状況となった環境のActive Directoryサーバはsambaで作成しているため /usr/local/samba/var/log.samba を確認してみると下記のエラーがでていた。

[2023/10/20 14:48:22.301935,  0] ../../source4/rpc_server/netlogon/dcerpc_netlogon.c:281(dcesrv_netr_ServerAuthenticate3_check_downgrade)
  CVE-2022-38023: client_account[SVM3$] computer_name[SVM3] schannel_type[2] client_negotiate_flags[0x741ff] real_account[SVM3$] NT_STATUS_DOWNGRADE_DETECTED reject_des[0] reject_md5[1]
[2023/10/20 14:48:22.302215,  0] ../../source4/rpc_server/netlogon/dcerpc_netlogon.c:291(dcesrv_netr_ServerAuthenticate3_check_downgrade)
  CVE-2022-38023: Check if option 'server reject md5 schannel:SVM3$ = no' might be needed for a legacy client.
[2023/10/20 14:48:22.304539,  0] ../../source4/rpc_server/netlogon/dcerpc_netlogon.c:281(dcesrv_netr_ServerAuthenticate3_check_downgrade)
  CVE-2022-38023: client_account[SVM3$] computer_name[SVM3] schannel_type[2] client_negotiate_flags[0x701ff] real_account[SVM3$] NT_STATUS_DOWNGRADE_DETECTED reject_des[1] reject_md5[1]
[2023/10/20 14:48:22.304600,  0] ../../source4/rpc_server/netlogon/dcerpc_netlogon.c:291(dcesrv_netr_ServerAuthenticate3_check_downgrade)
  CVE-2022-38023: Check if option 'server reject md5 schannel:SVM3$ = no' might be needed for a legacy client.
[2023/10/20 14:48:22.304638,  0] ../../source4/rpc_server/netlogon/dcerpc_netlogon.c:298(dcesrv_netr_ServerAuthenticate3_check_downgrade)
  CVE-2022-38023: Check if option 'allow nt4 crypto:SVM3$ = yes' might be needed for a legacy client.

もしやkerneberosではなくNTLMで接続されてたりする?と lm-compatibility-level をkrb に設定しても同じ結果となった。

netapp9101::> vserver cifs security modify -vserver svm3 -lm-compatibility-level krb

netapp9101::> vserver cifs security show -fields lm-compatibility-level
vserver lm-compatibility-level
------- ----------------------
Cluster -
Snapmirror-WAN -
netapp9101 -
netapp9101-01 -
svm0    lm-ntlm-ntlmv2-krb
svm2    lm-ntlm-ntlmv2-krb
svm3    krb
7 entries were displayed.

netapp9101::>

さらに調べると「Configure Active Directory domain controller access overview」に、Netlogon にAESを使いたい場合は「aes-enabled-for-netlogon-channel」をtrueに設定する、と書いてあった

netapp9101::> vserver cifs security show -fields aes-enabled-for-netlogon-channel
vserver aes-enabled-for-netlogon-channel
------- --------------------------------
Cluster -
Snapmirror-WAN -
netapp9101 -
netapp9101-01 -
svm0    false
svm2    false
svm3    false
7 entries were displayed.

netapp9101::> vserver cifs security modify -vserver svm3 -aes-enabled-for-netlogon-channel true

netapp9101::> vserver cifs security show -fields aes-enabled-for-netlogon-channel
vserver aes-enabled-for-netlogon-channel
------- --------------------------------
Cluster -
Snapmirror-WAN -
netapp9101 -
netapp9101-01 -
svm0    false
svm2    false
svm3    true
7 entries were displayed.

netapp9101::>

設定変更後に再実行したところ、Active Directory参加に成功した。

netapp9101::> vserver cifs create -vserver svm3 -cifs-server svm3 -domain adosakana.local

In order to create an Active Directory machine account for the CIFS server, you must supply the name and password of
a Windows account with sufficient privileges to add computers to the "CN=Computers" container within the
"ADOSAKANA.LOCAL" domain.

Enter the user name: administrator

Enter the password:

Notice: SMB1 protocol version is obsolete and considered insecure. Therefore it is deprecated and disabled on this
CIFS server. Support for SMB1 might be removed in a future release. If required, use the (privilege: advanced)
"vserver cifs options modify -vserver svm3 -smb1-enabled true" to enable it.

netapp9101::>

↑のSMB1を有効にするかどうか、というところについては、複合機の出力先として指定されている、とか、LinuxサーバからCIFSでマウントしている、とか、Windowsワークグループからアクセスしている、という場合には有効にする、というような形となる。

Windows Server 2012R2に .Net Framework 3.5が追加できない場合の解決方法


実験するためWindows Server 2012R2を新規インストールして、まずはWindows Updateを全部適用してから、いろいろ設定していこう!と行ってみたところ思わぬところで問題が発生した。

結論を先に書いておくと「.NET Framework 3.5, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8 のセキュリティおよび品質ロールアップ」がインストールされていることが原因であるため

・Windows Updateを実施する前に追加すれば問題は発生しない
・Windows Update完了後に問題が発生した場合は「.NET Framework 3.5, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8 のセキュリティおよび品質ロールアップ」をアンインストールする

のどちらかを行うことで、インストールに成功するようになった。

ただ、.NET Frameworkのパッチの内部的な仕組みに気がつかないとアンインストールできないので、原因が知られていない、という状態でした。

問題の検証

Windows Updateが一通り終わったあとで、今回の実験対象のソフトウェアは.NET Framework 3.5が必要だな、と追加しようとしたらエラーとなった。

「代替ソースパスを指定」からDVD内のsources\sxs\を指定

で、エラー

このとき、イベントログのWindowsログの「Setup」に「パッケージ Microsoft .NET Framework 3.0の更新 NetFx3 を有効にできませんでした。 状態 0x800f0906。」と出ている

「0x800f0906」で調べると「.NET Framework 3.5 の展開エラーと解決手順」が出てくるが、コレではなかった。

[MS14-046] Windows 8.1 および Windows Server 2012 R2 用の .NET Framework 3.5 のセキュリティ更新プログラムについて (2014 年 8 月 12 日)」に以下の記載がある

Microsoft .NET Framework 3.5 用のセキュリティ更新プログラム 2966828 (マイクロソフト セキュリティ情報 MS14-046 に記載されています) をインストールした後、[Windows の機能] で Microsoft .NET Framework 3.5 のオプションの機能を初めて有効にしようとしたときに、機能がインストールされないことがあります。Microsoft .NET Framework 3.5 の機能を追加する前にインストールを “段階的に実行” した場合にこのエラーが発生することがあります。
この問題を解決するには、更新プログラム 3005628 をインストールします。
この問題を回避する方法の詳細については、以下のサポート技術情報番号をクリックしてください。
3002547Windows 8、Windows Server 2012、Windows 8.1、または Windows Server 2012 R2 でセキュリティ更新プログラム 2966827 または 2966828 をインストールした後に Microsoft .NET Framework 3.5 のオプションの Windows 機能を有効化できないことがある

更新プログラム 3005628「Windows 8、Windows 8.1、Windows Server 2012、および Windows Server 2012 R2 上の .NET Framework 3.5 の更新プログラム」の説明を読むと、原因としては、.NET Framework 3.5がインストールされていないのに、.NET Framework 3.5に関する更新プログラムがインストールされていることが原因である模様。

しかし、2023年9月現在では更新プログラム3005628 を適用してみたが効力はなかった。

更新履歴をみると「.NET Framework 3.5, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8 のセキュリティおよび品質ロールアップ」がある。

しかし、インストールされた更新プログラムを確認すると、.NET Framework関連のパッチがないのでインストールできないように見える。

ただ、調べたところwusaコマンドを使うとアンインストールできそうな感じだったので「wusa /uninstall /kb:5030184」でアンインストールを試みたが「インストールされていない」と表示される。

2023 年 9 月 12 日 – Windows Server 2012 R2 用 .NET Framework 3.5、4.6.2、4.7、4.7.1、4.7.2、4.8 のセキュリティおよび品質ロールアップ (KB5030184)」を確認すると、実はこの更新プログラム「Windows Server 2012 R2 用 .NET Framework 3.5 のセキュリティおよび品質ロールアップについて (KB5029915)」「Windows Server 2012 R2 用 .NET Framework 4.6.2、4.7、4.7.1、4.7.2 のセキュリティおよび品質ロールアップについて (KB5029916)」「Windows Server 2012 R2 用 .NET Framework 4.8 のセキュリティおよび品質ロールアップについて (KB5029917)」の3本だてらしい。

更新履歴上にこの3つは載ってないけど、試してみるかと「wusa /uninstall /kb:5029915」を実行すると、アンインストールに成功した。

おや?と思って、先ほどのインストールされた更新プログラム画像を再確認するとKB5029915がいた・・・

なるほど・・・「更新履歴」と「インストールされた更新プログラム」とで表示されるKB番号が別なのか・・・

で・・・これで大丈夫かな?と、.Net 3.5追加を試してみたらエラーになった。

もう一度更新一覧を確認しなおすともう1つ「.NET Framework 3.5, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8 のセキュリティおよび品質ロールアップ」があった

そちらは「2023 年 8 月 8 日 – Windows Server 2012 R2 用 .NET Framework 3.5、4.6.2、4.7、4.7.1、4.7.2、4.8 のセキュリティおよび品質ロールアップ (KB5029653)」で、「Windows Server 2012 R2 用 .NET Framework 3.5 のセキュリティおよび品質ロールアップについて (KB5028970)」「Windows Server 2012 R2 用 .NET Framework 4.6.2、4.7、4.7.1、4.7.2 のセキュリティおよび品質ロールアップについて (KB5028962)」「Windows Server 2012 R2 用 .NET Framework 4.8 のセキュリティおよび品質ロールアップについて (KB5028957)」なので、「wusa /uninstall /kb:5028970」でアンインストールを実行。

もしくは「インストールされた更新プログラム」から「Microsoft Windows (KB5028970)の更新プログラム」を右クリックして「アンインストール」でも大丈夫です。

役割と機能の追加から「.NET Framework 3.5」を実施してみたところ、今度は成功した。

この状態で新しくインストールされる更新プログラムを確認したところ、.NET 3.5専用のものの他に、先ほど.NET 3.5用のみアンインストールしたKB5030184もインストールされること、ということが確認出来た。

で、実際に適用したあとに、履歴一覧を確認するとKB5030184 が2回適用されていることが確認できた。