Azure Migrateの解体

移行が終わったら、Azure Migrateの移行元と移行先のアプライアンス、Azure Migrateプロジェクトは、不要になります。下記の公式資料を参照しています。

プロジェクトを作成して管理する - プロジェクトを削除する

ただアプライアンスの関連付け解除などあまり細かく書いてないようにも思います。こういうやり方もあるとご理解いただけると助かります。

※解体から時間がたっております。画像中の日時が本年2月ごろです。

今回の解体対象は、下記のプロジェクトです。

VMwareとAzure Localそれぞれにアプライアンスがあります。

エージェントレスでしたので、エージェントの登録は無です。

評価を削除しておくこととします。

VMware側アプライアンスを削除します。

Azure Local側アプライアンスを削除します。

Azure Local側アプライアンスのログインが外れたことを確認できました。

VMware側アプライアンスから、移行先のAzure Localアプライアンス資格情報を削除します。

VMware側アプライアンスから、エージェントレス用資格情報を削除します。今回はワークグループ用の資格情報のみが対象です。

Azureにログイン必要とあるのに、「ログイン中」になっていたので、画面をリロードして状況を確認します。

「ログイン中」から「構成中」に変わりました。

アプライアンスの関連付けをクリアできたと思いますので、Azure Migrateプロジェクトを削除します。

スクロールダウンして、Azure Migrateプロジェクト名を入力して削除を実行します。

確認ダイアログで、「削除」をクリックして続行します。

削除完了。

「最新の情報に更新」行うとプロジェクトがなくなりました。

リソースグループを削除しようとしましたが、エラー。

あちこちにロックオブジェクトがある確認しながら、あった場合は削除していきます。

最後の画像は、リソースグループの削除エラーが残っております。。。

リソースグループ内のオブジェクトを改めて削除します。

「削除」を入力して削除を実行します。

確認ダイアログで、「削除」をクリックして続行します。

削除中。

削除完了。

この後、リソースグループを削除しておきます。

VMware側アプライアンスをシャットダウン後、削除します。

確認ダイアログで、「削除」をクリックして続行します。

削除完了

Azure Local側アプライアンスをシャットダウン後、削除します。フェールオーバークラスターマネージャーからまず削除します。

画像を取り忘れましたが、Hyper-Vマネージャーから削除し、CSVからもディスクと仮想マシンフォルダーを削除すれば、終了ですね。

Windows Admin Center version 2511の新しいビルド 2.6.6.18

いろいろございまして、

Windows Admin Center version 2511 is now generally available!

を改めて見直しました。引用しますが、冒頭に下記の文言が追記されております。。。

April 9th, 2026: The Windows Admin Center installer has been updated to build number 2.6.6.18. This build includes an update to the Cluster manager extension that addresses a known issue and no other functionality changes. The HA deployment scripts and associated documentation have also been updated. 

known issureのリンクをクリックすると、

ボリューム ツールでの誤った削除

にアクセスできました。文面を引用します。

クラスター マネージャーのバージョンが 5.2.6 未満のWindows Admin Centerのインスタンスでは、ボリュームの削除操作で問題が発生する可能性があります。データ損失を防ぐには、クラスター マネージャー拡張機能をバージョン 5.2.6 に更新するか、バージョン 2511 ビルド 2.6.6.18 以降Windows Admin Center使用していることを確認します。 クラスター マネージャー拡張機能が更新されない限り、Windows Admin Centerでボリュームを削除しないでください。

ということです。。。Windows Admin Center 2511 ビルド 2.6.6.18に上げたほうが良いですね。

もう一つ、高可用性スクリプトが更新されたとのこと。これは別途試してみます（前回試したときにうまく動いていないので）。

OpenSSH for Windows Server 2025 その4 ローカルユーザーのパスワード認証

ADドメインユーザーではなく、ローカルユーザーを試してみます。

Windows Server および Windows 用の OpenSSH Server の構成 - AllowGroups、AllowUsers、DenyGroups、DenyUsers

を参照し、AllowUsersにローカルユーザーを追加しました（事前にローカルユーザーは作成済み）。sshdサービスも再起動します。

パスワード認証を試したところ、上手くいきました。

キーベース認証を試行していないことを思い出したので、別途確認します。

※何か権限設定を書き忘れているような気もするので、確認予定です。書き忘れがあれば別途追記します。

OpenSSH for Windows Server 2025 その3 キーベースの認証 ローカル管理者権限ありのADドメインユーザー

七転八倒のためGen AIを併用しながらという感じで試行錯誤した結果、タイトルの挙動故の設定が必要と理解しました。具体的には、下記の設定が必要でした。

Windows 用 OpenSSH でのキーベースの認証 - 管理ユーザー

通常ユーザーの公開キー配置場所である ホームディレクトリ\.ssh\id_ecdsa.pub ではなくて、$env:ProgramData\ssh\administrators_authorized_keys に置く必要がありました。加えて、set-contentでasciiにコード変換するとうまくいきました。コマンド例は下記のとおりです。

(Get-Content C:\Users\sashizaki\.ssh\id_ecdsa.pub) | Set-Content -Encoding ascii C:\ProgramData\ssh\administrators_authorized_keys

では、七転八倒をかいつまんでみていきます。基本的には、下記のドキュメントを参照しています。

Windows 用 OpenSSH でのキーベースの認証

まずは、ssh-keygenで秘密キーと公開キーのペアを作成します。

普通に、ホームディレクトリ\.ssh\id_ecdsa.pub に配置しました。これでキーベース認証が使えると思ったら間違いでして、

Windows Server および Windows 用の OpenSSH Server の構成 - OpenSSH 構成ファイル

に記載がある %programdata%\ssh\sshd_config ファイルから「PubkeyAuthentication yes」を有効化して、sshdサービスを再起動します。（後で気づいて対応しましたが、この時点でパスワード認証も有効化しておくてデバッグしやすい）

ユーザー指定を変えながらいくつかリトライしたもののsshコマンドからつながらず。

Gen AIの提案から、

(Get-Content C:\Users\sashizaki\.ssh\id_ecdsa.pub) | Set-Content -Encoding ascii C:\ProgramData\ssh\administrators_authorized_keys

と

icacls C:\ProgramData\ssh\administrators_authorized_keys /inheritance:r

icacls C:\ProgramData\ssh\administrators_authorized_keys /grant "Administrators:F"

icacls C:\ProgramData\ssh\administrators_authorized_keys /grant "SYSTEM:F"

を実行しsshdサービスを再起動しました。

ssh /vでデバッグ情報を出力させながら、再試行しました。結果、成功。

Network ATCのGlobal Cluster Overridesも出力してみる

Network ATCのSet-NetIntentによりOverridesを追加してみる

では、Global Cluster Overridesを出力していないことを思い出し、調べつつ生成AIからPowerShellコードを出力してもらいました。

# -----------------------------

# Dump Network ATC intents + Global overrides (Cluster + Proxy)

# -----------------------------

# インテント別Overrides（既存ロジックを最適化：Get-NetIntent呼び出しを1回に）

$intentNames = (Get-NetIntent).IntentName

foreach ($name in $intentNames) {

    $i = Get-NetIntent -Name $name

    "`n===== Intent: $($i.IntentName) / Type: $($i.IntentType) ====="

    "AdapterAdvancedParametersOverride:"; $i.AdapterAdvancedParametersOverride

    "RssConfigOverride:";                $i.RssConfigOverride

    "QosPolicyOverride:";                $i.QosPolicyOverride

    "SwitchConfigOverride:";             $i.SwitchConfigOverride

    "IPOverride:";                       $i.IPOverride

    "NetAdapterCommonProperties:";       $i.NetAdapterCommonProperties

}

# --- Global overrides を取得（globalintent相当） ---

$g = Get-NetIntent -GlobalOverrides | Where-Object IntentType -eq 'Global'

"`n===== Global Overrides (globalintent) ====="

$g | Format-List ProxyOverride, ClusterOverride, ResourceContentVersion, IntentName, Scope, IntentType, InstanceId, ObjectVersion

# -----------------------------

# 1) Global Cluster Overrides (New-NetIntentGlobalClusterOverrides 相当)

# -----------------------------

$clusterProps = @(

  'EnableNetworkNaming',

  'EnableLiveMigrationNetworkSelection',

  'EnableVirtualMachineMigrationPerformanceSelection',

  'VirtualMachineMigrationPerformanceOption',

  'MaximumVirtualMachineMigrations',

  'MaximumSMBMigrationBandwidthInGbps'

)

"`n===== Global Cluster Overrides (ClusterOverride) ====="

$g.ClusterOverride | Select-Object $clusterProps | Format-List

# -----------------------------

# 2) Global Proxy Overrides (New-NetIntentGlobalProxyOverrides 相当)

#    -ProxyServer / -ProxyBypass / -AutoDetect / -AutoConfigUrl

# -----------------------------

$proxyPropCandidates = @(

  'ProxyServer',     # New-NetIntentGlobalProxyOverrides -ProxyServer

  'ProxyBypass',     # New-NetIntentGlobalProxyOverrides -ProxyBypass

  'AutoDetect',      # New-NetIntentGlobalProxyOverrides -AutoDetect

  'AutoConfigUrl'    # New-NetIntentGlobalProxyOverrides -AutoConfigUrl

)

"`n===== Global Proxy Overrides (ProxyOverride) ====="

# ProxyOverride は環境によりプロパティ名が揺れる可能性があるため、

# 「存在するプロパティだけ」出すようにしています。

if ($null -eq $g.ProxyOverride) {

    Write-Warning "ProxyOverride が null です（未設定/既定の可能性）。"

} else {

    $existing = $proxyPropCandidates | Where-Object { $g.ProxyOverride.PSObject.Properties.Name -contains $_ }

    if ($existing.Count -eq 0) {

        # 期待の名前で取れない場合は全出力して原因特定

        Write-Warning "ProxyOverride に期待プロパティ($($proxyPropCandidates -join ', '))が見つかりません。全プロパティを表示します。"

        $g.ProxyOverride | Format-List *

    } else {

        $g.ProxyOverride | Select-Object $existing | Format-List

    }

}

これをNestedなWindows Server 2025 S2D上で実行しました。NetDirect=RDMAとSR-IOVは無効化が確認できました。

Global Cluster Overridesは、特段設定してないので何も出てきませんが、項目としては大丈夫です。

なお物理サーバーで値が出ているのは確認済みです。

OpenSSH for Windows Server 2025 その2 GPOによるサービスの制御

OpenSSHをホストごとに個別設定するのは手がかかりますので、グループポリシー（GPO）で制御します。

グループ ポリシーを使用して OpenSSH を管理する方法

に則り、設定します。

グループポリシーの管理を起動します。

GPOを作成します。

グループポリシーを編集しましょう。左側のナビゲーションウィンドウで、[コンピューターの構成]、[ポリシー]、[Windowsの構成]、[セキュリティの構成] 、[システムサービス] の順で選択します。その中にある[OpenSSH SSH Server] をダブルクリックします。

[このポリシーの設定を定義する]をチェックするとサービスの起動を制御できます。

[セキュリティの編集]をクリックすると、既定値の確認、編集が可能です。

では、サービスのスタートアップモードを無効化。gpupdate /forceでGPOを反映しました。止まりましたね。

サービスのスタートアップモードを手動に変更。gpupdate /forceでGPOを反映しました。

明示的に起動していないので、サービスは停止したままです。

サービスの管理でもスタートアップの種類は[手動]であることが確認できます。

スタートアップの種類を[自動]に変更します。

gpupdate /forceでGPOを反映しました。サービスの起動を確認できます。

サービスの管理でもスタートアップの種類は[自動]であり、サービスは実行中であることが確認できます。

次回は、キーベースの認証をみていきます。調べている限り、クセがあるので注意しなければなりませんので、その辺りも解説予定です。