Windows Server ＆ Cloud User Group Japan 第53回 勉強会セッション資料「Azure Site Recovery for Azure Local」

Azure Site Recovery for Azure Local by @sshzk

Azure Site Recovery for Azure Local その1

Windows Server ＆ Cloud User Group Japan 第53回 勉強会の担当セッションについて、内容の一部を先んじて書きます。本稿で考えを整理してからセッション資料をまとめるという意図もあります。あとタイトルでは、その1と書きましたが、その2以降があるかはまだ考えておりませんw

本題に移ります。

システム要件としてはRecovery Serviceコンテナー/Recovery Service Valutが必要なのは、いうまでもないです。加えて他のシステム要件を見る上で、レプリケーションジョブの作成がとてもわかりやすいです。レプリケーションジョブのウィザードを一部ご紹介しながら説明します。

まず移行先の環境として、Azureを指定します。その際、Azure仮想ネットワーク/VNetを必要であることがわかりますね。

先に進めるとストレージアカウントが必要でした。

ということで、確認の一助になれば幸いです。

Azure Local 2609のデプロイウィザードで、ノードの追加が失敗しています。

Azure Local 2609のデプロイウィザードで、ノードの追加が失敗していまして。

英語版でも試したのですが、同様です。

Webブラウザを変えてみましたが、事象は変わらず…

先週は問題なくできていたのだが？！

Azure Local 2609 deployment with Active Directory

Azure Local 2609において、Active Directoryを使う場合も比較のためにデプロイしました。

それで9/26にはなくて、9/27になって既報である「2609公開後のドキュメント更新」、「システム レベルのシークレットの自動バックアップ （プレビュー）」の正しい有効化方法」のとおりシークレットをバックアップする設定が増えていました。

ということで、キーコンテナー（Azure Key Vault）を追加設定してます。

やはりバリデーションは、Nested Hyper-Vの場合でも30分かからずにおわっています。

この改良はありがたいです。

Active Directoryを使う場合のデプロイは、下記のパラメーターで行いました。

デプロイは、2時間48分ほどで完了しました。ADレスの場合より多少早かったです、当方の環境では。

Azure Local 2609 deployment local identity with key vault

Azure Local 2609を用いて、deployment local identity with key vaultを試行します。変わらずNested Hyper-Vです。

以前は１時間かかっていたように記憶しています。しかしバリデーションがNested Hyper-Vで、30分ぐらいで終わるようになっていました。

下記の設定でデプロイしております。

デプロイ完了です。2時間56分ほどかかりました。

Windows Admin Center 2610 Public Previewから、Virtualization Modeをインストールしたら拡張が見えた

Windows Admin Center 2610 Public Previewがリリースされました。

でもお伝えした通り、Administration ModeとVirtualization Modeが同じインストーラーに同梱されています。

このうちVirtualization Modeをいれてみたところ、拡張がメニューに増えていました。

GA版でどういう扱いになるのかまだ不明ですが、気づきとして書いておきます。

Azure Local 2609をデプロイしようと、Azure Arcの登録方法でつまづく

 Azure Local 2609で、ADレスのAzure LocalをデプロイしようとNested Hyper-VでAzure Local仮想マシンを2台作成しました。

Azure Arcの登録をしようと

Register Azure Local with Azure Arc without using Arc gateway

をみたところ、やり方が変わってました（というかパラメーターが増えてる）。。。「Last updated on 09/05/2026」ですね。

 $Tenant、$Subscription、$RG、$Regionといった変数のくだりは、変更ないです。

まず変数として下記の行が増えていましたので、上記URLより引用します。

#Optional: Define the Azure Resource Manager access token.
# Required only if you want to use token-based authentication instead of device code authentication.
$armTokenResponse = Get-AzAccessToken
# Convert token to string for use in initialization
# Required because Get-AzAccessToken returns SecureString
$ArmAccessToken = [System.Net.NetworkCredential]::new("", $armTokenResponse.Token).Password    
# Define the target Azure Local solution version that the node must update to after registering with Azure Arc.
# Example: "12.2602.1002.10"
$TargetSolutionVersion = "<solution-version>"

さんざんリトライした挙句、$armTokenResponseと$ArmAccessTokenは、オプションだと気づきました。すなわち$armTokenResponseのコメントにオプションだと書いてあるのに気付くのが遅かったです。オプションなのに、実行すると下記のメッセージが出続けます。

あと、自分がやっていたNested Hyper-V VMに対してのInvoke-Commandではうまくいかない様子。具体的には、

Invoke-AzStackHciArcInitialization @params

の部分でデバイス認証すら出ず、エラーになっていました。

しようがないので、リモートデスクトップ接続経由でコマンドを流しました。結果、デバイス認証が使えるようになりました。

しかし今度は、TargetSolutionVersionが正しくないと。

生成AIと相談して、TargetSolutionVersionは使わないでお試ししてみます。具体的には、$paramsの要素から、$TargetSolutionVersionをコメントアウトしています。

Invoke-AzStackHciArcInitialization @params　を再実行。

改めてデバイス認証が出ましたので、認証を通します。

今回は、TargetSolutionVersion無でブートストラップが、無事に成功。

登録が完了したかは、下記のコードで確認ということです。

$status = Get-ArcBootstrapStatus

$status.Response.Status

確認結果は、2ノード分として下記のとおりです。

Azure Portal上からも問題ないことを確認しました。