2024年4月のセキュリティ更新プログラムで、既知の問題が2つ出ています。

おもにWindows Server 2022に影響ありますが、

2024 年 4 月 9 日 — KB5036909 (OS ビルド 20348.2402)

で、下記の通り既知の問題が2つ出ています。文面を引用します。

1. 2024 年 4 月のセキュリティ更新プログラムをインストールした後の NTLM トラフィックの問題
   ドメイン コントローラー (DC) に 2024 年 4 月のセキュリティ更新プログラム (KB5036909) をインストールすると、 NTLM 認証トラフィックが大幅に増加する可能性があります。 この問題は、環境内のプライマリ ドメイン コントローラーの割合が非常に少なく、NTLM トラフィックが多い組織に影響を与える可能性があります。
   次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します。
   影響を受けるプラットフォーム:
1. クライアント: なし
2. サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008
2. 2024 年 4 月のセキュリティ更新プログラムをインストールした後、VPN 接続が失敗する可能性があります
   Windows デバイスは、2024 年 4 月のセキュリティ更新プログラム (KB5036909) または 2024 年 4 月のセキュリティ以外のプレビュー更新プログラム をインストールした後、VPN 接続エラーに直面する可能性があります。
   次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します。
   影響を受けるプラットフォーム:
1. クライアント: Windows 11バージョン 23H2;Windows 11、バージョン 22H2、Windows 11、バージョン 21H2、Windows 10、バージョン 22H2、Windows 10、バージョン 21H2。
2. サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008。

いずれにしても、今後の定例なのか、定例外で対応が図られそうですね。

Azure Arcの画面にもESUが提供できる旨、表示されるようになりました。

Windows Server ＆ Cloud User Group Japan 第36回 勉強会　にて発表あった

拡張セキュリティ更新プログラム (ESU) のおさらい

にESUの提供形態として、Azure Arcが増えている旨、説明がありました。

それに関してAzure Arcの画面にもメッセージが出るようになっていたので、そちらを貼ります。

Hyper-VホストがサポートするHyper-V仮想マシンの構成バージョンと、Hyper-Vレプリカ

Hyper-VホストがサポートするHyper-V仮想マシン構成バージョンと、Hyper-Vレプリカの関係性を試してみたくなり、ちょっとやってみました。

結論から申し上げますと、「Hyper-VホストがサポートするHyper-V仮想マシンの構成バージョンでなければ、Hyper-Vレプリカは構成できない」です。当たり前ですよね。

今回試したのは、Windows Server 2022でのみサポートされるHyper-V仮想マシン構成バージョンである10のHyper-V仮想マシンをWindows Server 2019にHyper-Vレプリカできるか、です。上記に書いたとおり、「Hyper-Vレプリカは構成できない」が実際の挙動であり、長期サービス ホストでサポートされている VM の構成バージョン の記載とも一致します。

なんでこんな変なことを思いついたかというと、Hyper-Vレプリカを構成すると、レプリカ元のHyper-V仮想マシン構成バージョンで、レプリカ先に仮想マシンを作成するからです。仮想マシンの移行では、レプリカ元が最新バージョンでは無いHyper-Vホスト、レプリカ先が最新バージョンのHyper-Vホストで構成します。このパターンは、レプリカ先が最新バージョンのHyper-VホストでサポートするHyper-V仮想マシン構成バージョンならば、正しく機能しますね。では、この逆はどうなるのかを見てみようということです。結論はわかっちゃいるけど、実際に試してみたい興味が勝りました。

前置きはこれくらいとして、下記の2パターンを記載しておきます。手元の環境は、下記となっています。

• PET320がWindows Server 2022 Hyper-Vホスト
• ML110G7がWindows Server 2019 Hyper-Vホスト

Windows Server 2022でのみサポートされるHyper-V仮想マシン構成バージョンである10のHyper-V仮想マシンをWindows Server 2019にHyper-Vレプリカできるか

冒頭の結論通り、このパターンは構成できません。実際の流れを見てましょう。

Windows Server 2022でのみサポートされるHyper-V仮想マシン構成バージョンである10のHyper-V仮想マシンであることを確認しました。

Hyper-Vレプリカの構成要約です。

予想通り、構成できませんね。

Windows Server 2022に配置されているHyper-V仮想マシン構成バージョンである9のHyper-V仮想マシンをWindows Server 2019にHyper-Vレプリカできるか

Windows Server 2019 Hyper-VホストでサポートされるHyper-V仮想マシン構成バージョンである9のHyper-V仮想マシンは、Hyper-Vレプリカを構成できる仮定を見てみました。結論は、実際に構成できました。

Windows Server 2019でもサポートされるHyper-V仮想マシン構成バージョンである9のHyper-V仮想マシンであることを確認しました。

Hyper-Vレプリカの構成要約です。

Hyper-Vレプリカが構成でき、初期レプリカが実行されています。

Windows Server 2022 Hyper-V の仮想マシン構成バージョンから見る仮想マシンの移行パターン

Hyper-V の仮想マシンのバージョンをアップグレードする (Windows または Windows Server)

を見ていて、「仮想マシンの移行で段階を踏まないといけないところがまた出てきたな」と感じました。

Hyper-V の仮想マシンのバージョンをアップグレードする (Windows または Windows Server) から画像で引用します。各 Windows Server Hyper-V がサポートする仮想マシンの構成バージョンを赤枠でくくってみました。

Windows Server 2022 Hyper-Vがサポートする仮想マシンの構成バージョンは、最大が10.0で最小が8.0です。

Windows Server 2019 Hyper-Vがサポートする仮想マシンの構成バージョンは、最大が9.0で最小が5.0です。

Windows Server 2016 Hyper-Vがサポートする仮想マシンの構成バージョンは、最大が8.0で最小が5.0です。

Windows Server 2012 R2 Hyper-Vがサポートする仮想マシンの構成バージョンは、5.0です。

今の感じだと、移行元として Windows Server 2012 R2 Hyper-V が多いです。ですので、移行先は、Windows Server 2019 Hyper-V までが限界です。

そして移行元として Windows Server 2012 R2 Hyper-V から、Windows Server 2022 Hyper-V に直接移行することはできません。
つまり、移行元として Windows Server 2012 R2 Hyper-V → Windows Server 2016 Hyper-V or Windows Server 2019 Hyper-V → Windows Server 2022 Hyper-V という段階を踏む必要がありますねー

Remove-VMGroup で VMGroup が消せないときは、Remove-VMGroupMember で関連付けた仮想マシンを削除します。

 VMGroup なるものを知ったの巻。
※仮想マシンのバックアップなどで使われることがあるようです。

Remove-VMGroup で VMGroup が消せそうとしましたが、エラー。。。

Remove-VMGroup : 操作に失敗しました。

予期しないエラーが発生しました:　ライブラリ、ドライブまたはメディアプールはこの操作を実行するためには空でなければなりません。(0x800710D3)

上記のエラーコードで、調べてみました。

• vmgroup – PowerShell 中文博客
• [2016 Hyper-V] unable to snapshot / backup guest cluster - Add-VMGroupMembers not working

ぱっと解決策になる感じでは無いです。。。

ふと思ったのは、

• [2016 Hyper-V] unable to snapshot / backup guest cluster - Add-VMGroupMembers not working

に書いていある下記でした。

VMMembers      : {}

VMGroupMembers :

 エラーメッセージも、VMGroup に何か入っている的なものだったので、もしかしてメンバーを何とかして特定し、その関連付けを外せばよいのかなと。
docs.microsoft.com の Remove-VMGroup のコマンドレットページを眺めていたら、

Remove-VMGroupMember

なるものが！
幸いにして仮想マシン名は、判明したので、Remove-VMGroupMember の Examples を使って、一台ずつ仮想マシンを VMGroup のメンバーから外しました。

その後、Remove-VMGroup で VMGroupを無事に削除できましたよ。
VMGroup の関連付けが空になっていないと、Remove-VMGroup で VMGroup を消すことができないのですね。勉強になりました。
※仕組みを考えるとある意味当たり前の話ですね。。。

Hyper-V のチェックポイントが消せないと思ったら、SCDPM のバックアップがからんでいた

※手っ取り早く解決したい方は、本記事の一番下までスクロールしてください！

Hyper-V マネージャーを見ていたら、身に覚えのないチェックポイントがあるのを発見。

見ての通り、チェックポイントが削除できません。このチェックポイントは、SCDPM サーバーがバックアップ時にとっているものだと容易に推測できました。

なんだこれと思い、SCDPM サーバー側でバックアップ対象から外してみたけど、チェックポイントは消えない。

調べてみると、
You can't delete a recovery checkpoint for a virtual machine in Data Protection Manager
Data Protection Manager で仮想マシンのリカバリのチェックポイントを削除することはできません。

なるサポート情報を発見しました。

今回は、Windows Server 2019 Hyper-V を使っているため、Windows Server 2012 R2に対する修正プログラムでは、解消しません。

ということで、

You can't delete a recovery checkpoint for a virtual machine in Data Protection Manager
Data Protection Manager で仮想マシンのリカバリのチェックポイントを削除することはできません。

に記載されている、Hyper-V マネージャーの「ディスクの編集」を用いてチェックポイントを削除することにします。実際には、
Manually Merge .avhd to .vhd in Hyper-V

を参照しながら進めます。

（すべての仮想ハードディスクを処理しなければいけないですが）とりあえず最初の仮想ハードディスクを選択します。

ん、マージがない。。。最適化で進めてみる。

最適化で、差分ディスクが消えるわけないか。。。さてさてとなると、PowerShell を使うしかない。
Merge-VHD
Merge differencing disks (AVHD/AVHDX) to boot Hyper-V machine after restoring to files from Hyper-V datasource
Merge AVHDX Hyper-V Checkpoints

を参考にします。

Merge-VHD -Path .\127GB_A77CEB9C-4253-42E8-8C6A-525E53E809CD.avhdx -DestinationPath .\127GB.vhdx

という感じ。

AVHDXファイルは、消えました。が、.mrt とか .rct は残っているな。

Hyper-V マネージャーの表示は消えてない。。。

しょうがないので、手動で親ディスクを再マウントしてみます。

手動で、差分ディスクを親ディスクにマージしているので、ここは強行します。
（当該仮想マシンには、仮想ハードディスクがあと５個あるのでそちらも併せて対応します）

まだ、Hyper-V マネージャーの表示は消えてない。。。

Removing Backup Checkpoint in Hyper-V That Has No Delete Option
を参考に、チェックポイントの削除を試みます。

差分ディスクを先に消したほうが、失敗。。。

差分ディスクを消していなかったほうは、問題なく完了。ということで、こちらが正しいやり方ですね！

うまくスナップショットが消えていない仮想マシンは、

謎のスナップショット
を参考にして、新しスナップショットを作成し、それをエクスポートする形で対応してみます。

エクスポートが終わったので、元の仮想マシンを削除します。

仮想マシンフォルダーも削除しておきます。

エクスポートした仮想マシンをもとのフォルダーに戻します。
（ちなみに、RAIDなHDDから、RAIDなSSDへ戻します）

仮想マシンをインポートします。

完全に治りました！

結論
SCDPM のバックアップがらみで、Hyper-V のチェックポイントが消せないと思ったら、

 Get-VMSnapshot -ComputerName pet320 -VMName g2ws2019s2d01| Remove-VMSnapshot

的な削除がお勧めです。

Azure Site Recovery で SCVMM を使った セカンダリサイトへのレプリケーションが、約３年後に廃止されるので

Azure Site Recovery の 一部オプションが今後段階的に廃止されます。
で記載した通り、Azure Site Recovery で SCVMM を使った セカンダリサイトへのレプリケーションが2023年3月1日に廃止されます。

Azure Site Recovery で SCVMM を使った セカンダリサイトへのレプリケーション
については、管理部分をAzure Site Recovery に置いているものであり、レプリケーション自体は、Hyper-V レプリカを使用しています。
アーキテクチャ - セカンダリ サイトへの Hyper-V のレプリケーション
に記載されている概念図を見ていただけると理解しやすいです！

Azure Site Recovery に管理部分があるので、DR構成を一括で行えていたわけです。
では、この部分が2023年3月1日に廃止されるということは、レプリケーション自体は、Hyper-V レプリカを使用し続けるということになります。
Azure Site Recovery を使用したカスタマー マネージド サイト間での (VMM による) ディザスター リカバリーの廃止
に記載の代替オプション2を今後計画していく必要があるということです。
代替オプションの文面を下記に引用します。

オプション 2:サイト間レプリケーションを、基本的な Hyper-Hyper-V レプリカ ソリューションを使用して続行することを選択します。ただし、Azure portal で Azure Site Recovery を使用して DR 構成を管理することはできません。

※ちなみに、代替オプション1は、Hyper-V から Azure にレプリケーションする方法です。

2020/03/14時点の画面で確認しておきます。（言うまでもないですが、Azure は継続的に改良されるため、2023年3月1日に同じ画面になっているかは不明です）

レプリケーションアイテムをクリックし、[レプリケーションの無効化]をクリックします。


[レプリケーションを無効にして削除]が通常のやり方です。今回はこちらで実施しません。このやり方は、仮想マシンのレプリケーション(Hyper-Vレプリカ)を削除してから、レプリケーションアイテムを削除するという方法だからです。


[削除]を選択します。
こちらは、仮想マシンのレプリケーション(Hyper-Vレプリカ)を削除しないで、レプリケーションアイテムを削除する方法です。これにより、レプリケーションアイテムは削除されますが、仮想マシンのレプリケーション(Hyper-Vレプリカ)は残ります。
本来の目的は、警告アイコンにも書かれている通り、ソースの環境に接続できない場合に用いるオプションですね。

[OK]を押すと、削除が開始します。

削除されました。


Hyper-Vレプリカが残っていることを確認できました！


この移行作業は、レプリケーションアイテムごとに、作業します。つまり、レプリケーションアイテムが多いと、結構な手間になると思います。
移行パスとしては、少々面倒ではありますが、これまでのレプリケーションポリシーをそのまま使い続けるという点では、メリットがありますね。

BMR 実施後、Windows Server Backup が起動しないことがあるらしい

こんなエントリーを見つけました。
Windows Server バックアップで BMR リストア実行後、Windows Server バックアップが起動しない事象について

事象自体は、「Windows Server 2012 以降の OS」との記載があるとおり、Windows Server 2016とかでも発生するようですね。
カタログの再構築（削除、再起動）で解消するようなので、頭の片隅に置いておくと良さそうですー

Windows Server 2012 R2 Hyper-V と Windows Server 2019 Hyper-V 間での Hyper-V レプリケーション

色々調べたのですが、ドキュメントが見当たらなかったので試しました。

Windows Server 2012 R2 Hyper-V と Windows Server 2019 Hyper-V で各々 Hyper-V レプリカの設定を行います。
Windows Server 2012 R2 Hyper-V で仮想マシンを作成、今回は Windows Server 2012 R2 をインストールします。

仮想マシンでレプリケーションを有効にした結果は、下記の通りで、うまくいっています。
フェールオーバーして、素の OS としては問題なさそうな感じ。
※情報が見当たらないので、公式にサポートされるものかはわかりません。Your own risk ということです。上手くいかなくても当記事が責任を持つことはありません。

Windows Server 2012 R2 Hyper-V での Hyper-V レプリカ状況


Windows Server 2019 Hyper-V での Hyper-V レプリカ状況

Netjoin 4097 1316

物理機に入っていたドメインコントローラーを降格したものの、クリーンアップが不十分であった件。

ドメインコントローラーを降格しましたが、情報が残っていたので下記の対応を実施。

• ntdsutilでクリーンアップを実行
• DNSから該当ホストの情報を根こそぎ削除
• サイトとサービスから、該当ホストの情報を削除

だけど、相変わらずドメイン参加できない。


本記事のタイトルで調べてみました。

Windows Server 2012 Standard - Domain Join Failed
にコンピューターアカウントも削除せよとあったので、削除。ちなみに画面取り損ねたのですが、ドメインコントローラーとしてコンピューターアカウントが存在してました。。。これが直接の原因ですね。
※同じコンピューターアカウントを使う予定で削除していなかったのが、良くなかった。

Windows Server な仮想マシンで NIC の MAC Address 設定を切り替えてみる

Azure Site Recovery というか、Hyper-V レプリカの絡みで挙動確認、備忘録として残します。

CentOS の挙動確認したので、Windows Server だとどうなるの？　というエビデンスが必要になった次第。
※ CentOS の挙動確認 も、備忘録として残しておきたいところ。。。

結論としては、同じ NIC （いわゆる"イーサネット n"）のままで IP アドレス情報を維持しています。ただ、MAC Address はちゃんと変わってました。

第1世代仮想マシン Windows Server 2012 R2
動的から静的に変更した画面キャプチャーです。



NIC 、IP アドレスは変わらず。


静的から動的に変更した画面キャプチャーです。


NIC 、IP アドレスは変わらず。


第2世代仮想マシン Windows Server 2012 R2
動的から静的に変更した画面キャプチャーです。



NIC 、IP アドレスは変わらず。


静的から動的に変更した画面キャプチャーです。


NIC 、IP アドレスは変わらず。


第2世代仮想マシン Windows Server 2016
動的から静的に変更した画面キャプチャーです。



「NIC 、IP アドレスは変わらず」の画面撮り忘れ。。。
まあ、ここは同じ MAC Addressだからということで。

静的から動的に変更した画面キャプチャーです。


NIC 、IP アドレスは変わらず。