VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その2

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その1 からの続き。

ESXi 7とvCenter 7上でWindows Server 2016仮想マシンを用意し、VMware Toolsをインストール済みとしていました。VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その1 に記載の通り、初期同期が完了しました。

移行の前に、「その他のオプション」見てみました。将来的には、Azure Arcへの登録もできますね。

続いて、仮想マシン移行を見ていきます。1.8.0プレビューでは、VMware Toolsのアンインストール、静的IPアドレスの移行がサポートされます。

全てのオプションを選択しました。いずれのオプションを選択しても、ローカル管理者権限のクレデンシャルが必要です。

事前チェックが開始。

事前チェックが完了。

差分同期の初期フェーズが完了して、。

静的IPアドレスの構成が完了しましたので、VMware Toolsのアンインストールが開始。

Mware Toolsのアンインストールが完了。

移行元仮想マシンの電源OFFされました。

合わせてvCenter側の状態を確認しました。

そうこうしているうちに移行が完了しました。

移行元の仮想マシンは、残っているので切り戻しが可能です。ただしVMware Toolsがアンインストール済みなので注意します。

では、オプションで指定したVMware Toolsのアンインストール、静的IPアドレスの構成がどうなったかを見ます。

仮想マシンコンソールより、OSにサインインしました。シャットダウンイベントの追跡ツールが表示されました。

IPアドレスの構成は移行できていました。

では、プロパティから確認したところ、DNSを残して消えました。

コミュニティメンバーに教えてもらったところ、静的IPアドレスの構成自体は下記のフォルダーにあります。

実際の設定情報は、JSONファイルに書かれています。

さてこの静的IPアドレス構成は、起動時にタスクスケジューラーで一度のみと聞きました。ため元で再起動してみましたが、すでに実行済みであり、静的IPアドレス構成は再反映されません。

この後、別の環境でリトライを繰り返したところ、移行前と移行後のNICに同じIPアドレスが付与されているからかもと考えています。移行前と移行後のNICに同じIPアドレスが付与されている旨のメッセージを別途キャプチャしたく考えています。

時間が前後しますが、VMware Toolsのアンインストールは確認済みです。

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その3 へ続く。

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その1

1.6.0 プレビューを試行していましたが、システム要件の通りだとうまく行かずにおりました。コミュニティのメンバーと会話したところ、結果的にはWACサーバーにHyper-Vの役割は不要だとわかりました。

これで再試行しようとしたところ、1.8.0 プレビューに上がりました。

Hyper-V側に仮想マシン名のフォルダーが自動作成されるようになりました。これは良い点です。固定IPアドレスの移行もサポートされるようになったとのこと。

ESXi 7とvCenter 7を用意してありましたので、そちらでWindows Server 2016仮想マシンを用意し、VMware Toolsをインストールしました。

まずは同期するところまでを見ていきます。

移行先サーバーのフォルダー指定は、1.6.0と変わらずです。

ここから状態ごとにメッセージが出ていきます。事前チェックの開始通知です。

事前チェック完了、初期同期の開始です。

前述した通り、移行先フォルダーに仮想マシン名のフォルダーが作成されました。1.6.0ではなかった機能です。

同期されている仮想ハードディスクもあります。

当方の環境では、16分ほどで初期同期が完了しました。固定の仮想ハードディスク127GBを使いました。

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その2 に続く。

Windows Server ＆ Cloud User Group Japan 第47回 勉強会セッション動画「Windows Admin Center 2410のPowerShell概要」

 

Azure Arc GatewayがGAしました。

Announcing the General Availability of Arc Gateway for Azure Local

ということなので、公式手順に則り、Azure Portalから作成し終えるところまでを本稿にまとめます。

Azure Local 用 Azure Arc ゲートウェイについて

にそってリソースを作成します。

Azure ArcのManagementから、Azure Arc gatewayをクリックし、新規に作成します。

サブスクリプション、リソースグループ、gateway名、Regionを設定します。サブスクリプション、リソースグループ、Regionは、デプロイ対象になるAzure Localと同じところを指定します。

タグで、標準でサポートするカスタムタグを1つ以上指定することになっているので、タグBillに対応する値を選択します。

作成します。

10分ほど待つと作成されました。

概要/OverviewにあるResource ID（下図の赤い箇所）をメモしておきます。Resource IDは、Azure Arcへの登録時に使用しますので。

Proxyサーバーの準備がないため、一旦ここで確認を区切ります。

Windows Server ＆ Cloud User Group Japan 第47回 勉強会資料「Windows Admin Center 2410のPowerShell概要」

Windows Admin Center 2410のPowerShell概要_PowerShell Overview for Windows Admin Center 2410 by @sshzk

アジェンダは下記の通りです。

PowerShellコマンドレットの比較概要
構成管理関連コマンドレット
接続管理関連コマンドレット
拡張関連コマンドレット
管理関連コマンドレット
移行関連コマンドレット
PowerShellTools関連コマンドレット
まとめ
参考情報
---
Comparison of PowerShell cmdlets
Configuration Management Cmdlets
Connection Management Cmdlets
Extensibility Cmdlets
Management Cmdlets
Migration Cmdlets
PowerShell Tools Cmdlets
Summary
Reference Information

Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた その2

Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた

でマイクロソフトの公式資料である

仮想 Azure ローカル システムをデプロイする

を使ってNested Hyper-Vとして仮想マシンでAzure Localのデプロイを試しています。

デプロイ前の最終バリデーションで、エラーになりました。

こちらは、同僚に聞いてみたところ、 WSMan:\localhost\Client\TrustedHostsは、何も設定していないとのこと。改めてお手製スクリプトから、WSMan:\localhost\Client\TrustedHosts へ設定をはずしてみました。

結果、久しぶりにAzure Localのデプロイに成功しました。

今後もデプロイを通じて確認を進めていけそうです。

Nested Hyper-Vを使う公式のAzure Local仮想マシンデプロイ手法を使ってみた

仮想 Azure ローカル システムをデプロイする

を見つけました。

こちらをベースにお手製のスクリプトを改良しました。加えて、再認識しましたが、ゲストOSのタイムゾーンはPST/PDTのままだなと（統合サービスとの時間同期を無効化、w32tmによるタイムサービスとの同期を行った上で、ゲストOSのクロックをPST/PDTに手動で合わせた）。

2508のデプロイにおいて、Extensionは、インストールされたものから触らない。下手に手動アップグレードすると、BasicのValidateに失敗するという気づきを得ました。

ということで、本稿作成時点でのExtensionsは、下記のままで進めました。

デプロイ前の最終的なValidateは、TrustedHostsの指定方法がよろしくないような。*だとダメなのかな。。。また調べ直さないと。

引き続き調べるとして、22H2依頼のデプロイを成功させたいものですね。

Active DirectoryでBitLocker回復パスワードを表示する

BitLocker回復パスワードをActive Directoryに保存できますね。Azure Localのノードで使われるBitLocker回復パスワードも同様に保存できます。

Azure Localのノードではないのですが、本稿ではWindows 11でBitLockerを有効化し、BitLocker回復パスワードをActive Directoryに保存した結果を閲覧してみます。

Windows 11でBitLockerを有効化

設定から、BitLockerドライブ暗号化を開きます。この例では、暗号化されていません。ここから暗号化を有効化します。

UACにて管理者権限を取得します。

回復キーはファイルに保存しました。

BitLockerをアクティブ化します。

有効化できました。

Active DirectoryドメインコントローラーにBitLocker回復パスワードビューアーをインストール

サーバーマネージャーから役割と機能の追加をクリックして、ウィザードを起動します。

「役割ベースまたは機能ベースのインストール」をクリックして、「次へ」をクリックします。

指定されたサーバーのまま、「次へ」をクリックします。

サーバーの役割はそのままにして、「次へ」をクリックします。

機能で、「リモートサーバー管理ツール」→「機能管理ツール」の順で展開します。

「BitLocker回復パスワードビューアー」をクリックして、「次へ」をクリックします。

「インストール」をクリックします。

しばらく待つとインストールが完了しました。

BitLocker回復パスワードをActive Directoryに保存

グループポリシーは未構成のまま試してみることとしました。

manage-bde.exeのオプションを確認します。

manage-bde.exe -statusで状態を見ておきます。

ファイルに保存した回復キーを確認しました。

リトライした結果、manage-bde.exeよりBitLocker回復パスワードをActive Directoryに保存しました。回復キーのIDは、そのまま指定できません。下図の通り、'{回復キーのID}'という形式で囲っておく必要がありました。

該当のコンピューターアカウントにて、BitLocker回復タブをクリックしたところ、回復キーのID、回復パスワードが表示されました。