みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
最近注目を集めているMicrosoftのHCIソリューション「Microsoft Azure Local」ですが、ハードウェアアプライアンスを購入する前に「ちょっと試してみたい」「使い勝手を確認してみたい」というニーズが多いのではないかと思います。
MicrosoftではHyper-V上にネスト環境上でAzure Localを展開する手順を公開しており、こちらの手順に沿って展開することで機能評価を問題なく行うことができます。Microsoft公式の構成と手順なので、何か問題があればAzureサポートにサポート依頼を行うこともできます（サポートしていただいたこともあります）。
こちらの手順で使用するハイパーバイザーは、当然のことながらHyper-Vになります。
なぜAzure Localが注目を集めているのか？ という話になると、昨今の仮想化界隈を賑わせている事情もあるかと思います。となると、多くの場合現在利用中のハイパーバイザーはVMware vSphereではないでしょうか。
新規でハードウェアを調達してHyper-Vを導入するのもなかなかハードルが高い……、Hyper-Vの知見者がいない……、ということで、VMware vSphere環境でAzure Localを展開してみたいと思います。
- 1：最初に注意事項と免責事項
- 2：用語として
- 3：展開環境
- 4：VMware vSphere側の設定
- 5：仮想マシンへAzure Stack HCI OSを展開する
- 6：Azure Stack HCI OS展開後の作業
- 7：Azure Portalからのデプロイ
- 8：原因究明
- 9：エラー対策（イレギュラー処理）
- 10：そののちのエラーと対策
- 11：そして展開
- 12：最後に
1：最初に注意事項と免責事項
前述の通り、Hyper-Vのネスト環境上でのAzure Local展開は公式手順も掲載されているのでMicrosoftのサポート構成となりますが、本記事で取り扱っているVMware vSphereのネスト環境上でのAzure Localは、Microsoftの非サポート環境となります。
同環境上で発生した問題については、Microsoftのサポートを受けられませんので注意してください。
また、同環境上で発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。
本記事では、Azure Localそのもののデプロイ方法などはMicrosoftのドキュメントを参照していただく形にしています。ある程度デプロイに慣れている方を想定していますこと、ご了承ください。
本記事で確認したAzStackHci.EnvironmentCheckerは、本記事執筆時点で最新版のバージョン1.2100.2850.619です。バージョンアップが行われた場合は対策が無効になる可能性もあります。ご了承ください。
2：用語として
Azure Localは、以前はAzure Stack HCIと呼ばれていました。
Azure LocalはMicrosoftが提供するハイパーコンバージドインフラストラクチャー（HCI）のソリューションの総称です。
Azure Localを構成するハードウェア上で実行されるOSは、従来のWindows Serverではなく、Azure Stack HCI OSとなります。
また、Azure LocalはMicrosoft Azureのサービスとして提供されているため、Microsoft Azureのリソースプロバイダーや各種サービスの中にも当然のことながら登場します。
これらの一部にはAzure Stack HCIの名前が残っており、Azure LocalとAzure Stack HCIが混在する形となっていますが、同じものを指していると思っていただいて問題ないです。
紛らわしいですが、OS名やコマンドレットなど正確を期するために、このあたりはご了解いただければと思います。
3：展開環境
VMware vSphere上で2台の仮想マシンを作成し、その仮想マシンにAzure Stack HCI OSをインストールしてクラスターを構築します。
仮想マシン観点での構成概要は図1のとおりです。
こちらの構成図は、以降の説明の中でも引用させていただきますので、覚えておいていただければと思います。
なお、仮想マシンに接続する仮想ディスクやネットワークアダプターは、Azure Localのハードウェア仕様に則っていれば任意です。
こちらの環境を展開するソフトウェアは以下の通りです。
- ハイパーバイザー：VMware vSphere 8.0U2
- 仮想マシンのOS：Azure Stack HCI OSは最新版のAzure Local 12.2504
上記以外にもActive Directoryドメインコントローラー（DNS含む）やvCenterが必要になります。
vCenterは後述するTPMのために必須となっています。ESXiホストだけでは構築不可です。残念。
必要なActive Directory環境などは、以下のドキュメントを参照してください。
なお、Azure Local側から見た展開構成は、ネットワークアダプターを4つ接続して、完全非集中型ネットワークでかつストレージ用のネットワークが2面ある構成です。
マネジメントや仮想マシン用のネットワークでVLAN構成をしたくないけどもネットワークは分けたい、という場合によく使われる構成ですね。
余談ですが、ダウンロードしたAzure Stack HCI OSのファイル名（AzureLocal24H2.26100.1742.LCM.12.2504.0.3142.x64.en-us.iso）を見ると、執筆時点では「24H2」の文字があり、古い言い方ですと「23H2から24H2へ移行している」ということを窺い知ることができます（24H2、23H2という呼び方は、Azure Localへのブランド変更の際に消えてしまった模様です。わかりやすい言い方だったのでちょっと残念）。
執筆時点では2504は「11.2504」と「12.2504」の2つのバージョンが混在することになり、今回のようなISOイメージからの新規インストールはすべて「12.2504」になります。「11.2504」は既存環境のアップグレードですね。
また、Azure Local 12.2504はドライバー周りがWindows Server 2025と互換性のあるものを要求している点も、興味深い点の1つです。
4：VMware vSphere側の設定
Azure Localを展開するうえで、VMware vSphere側で設定しなければならないことがいくつかありますので、簡単に解説します。
こちらには一般的なネスト構成の設定も含まれていますので、お分かりになる方はさらっと目を通すレベルでOKかと思います。
4-1：仮想スイッチの設定
図1の構成では、仮想スイッチを2つ作っています。
1つは物理ネットワークに接続するための仮想スイッチです。図1でいうところの「VM vSwitch」です。
このVM vSwitchには、図1における仮想マシンのオレンジのネットワークアダプター（管理用ネットワーク接続用）と青いネットワークアダプター（仮想マシン接続用）の2つが接続されます。
オレンジのネットワークアダプターは管理用なので、ホストOSへのRDP接続先やインターネットへの通信の送信元になります。青いネットワークアダプターがAzure Local上の作成されるワークロード（仮想マシン）が接続するAzure Local内の仮想スイッチのアップリンクですね。
この2つのネットワークアダプターは、Azure Localの仮想スイッチのアップリンクとして使用されます。そのため、複数のMACアドレスでの通信が行われるので、セキュリティポリシーを緩和する必要があります。
図2が仮想スイッチ「VM vSwitch」の設定画面となっていますが、セキュリティポリシーとして「無差別モードを許可」「偽装転送を許可」「MAC変更を許可」の3つのポリシーを、既定値の「いいえ」から「はい」に変更しています。
図1で示した仮想スイッチの2つ目が「Cluster vSwitch」です。
こちらはAzure Localのノード間通信を行うネットワーク専用となっています。
ご存じの通りAzure Localはハイパーコンバージド構成なので、ストレージの同期通信が必要だったり、クラスターノード間での仮想マシンの移動（ライブマイグレーション）を行うための通信があったりと、クラスターノード間の通信が頻発します。
これらの通信は仮想マシンベースの通信ではなく、Azure Localの各ノードが行うため、「VM vSwitch」のようなセキュリティーポリシーを緩和する必要はありません。
しかしながら、Azure Localの仕様として図1の緑のネットワークアダプターは「VLANタグをOSが付与してパケットを送出する」ため、今回のようなネスト構成ですとゲストOSがVLANタグを付与する「ゲストVLAN」を許可する必要があります。
Azure Localでは通常VLAN711-VLAN718を使用するため、それらのタグVLANの疎通許可をする必要があり、「Cluster vSwitch」ではVLAN4095を設定するか、もしくはVLAN711からVLAN718をトランクする必要があります。今回はVLAN4095を設定して、全VLANをトランクします（図3）。
4-2：仮想マシンの構成（CPU構成）
仮想スイッチを用意したら、次は仮想マシンを作成します。
ハードディスクはAzure Localの仕様に従った構成であれば問題ないですが、仮想マシン作成する際のポイントとしては、CPUの設定は外せないポイントになります。
図4は仮想マシンを作成する際の画面になりますが、ゲストOSのバージョンは「Windows Server 2025」とし、その直下の「Windows仮想化ベースのセキュリティの有効化」のチェックをオンにして仮想マシンを作成します。
これにより、ネスト構成を実装するうえで必要なCPUの設定が実施されます。
具体的には図5のように「ハードウェアアシストによる仮想化をゲストOSに公開」にチェックが入った状態で仮想マシンが作成されます。
この機能が有効になっていないと、仮想マシンで仮想化技術が使用できないため、Azure LocalやWindows ServerではHyper-Vが有効化できません。こちらはネスト構成においては必須の設定になります。
4-3：仮想マシンの構成（ネットワークアダプター構成）
「4-1：仮想スイッチの設定」でも説明した通り、Azure LocalではネットワークアダプターでVLANタグが付与されるため、仮想マシンのネットワークアダプターは、ネットワークアダプターでVLAN設定が可能なものを設定する必要があります。
そのため仮想マシン作成の際には、ネットワークアダプターはVMXNET3を指定してください。
本構成では図1のCluster Portに接続する緑のネットワークアダプターは必ずVMXNET3を選択してください。
なお、図1の仮想マシンのオレンジのネットワークアダプター（管理用ネットワーク接続用）と青いネットワークアダプター（仮想マシン接続用）の2つも、VMXNET3を使用することをお勧めします。
4-4：トラステッドプラットフォームモジュール（TPM）
Azure LocalではTPM2.0が必須であるため、仮想マシンにTPMをアタッチする必要があります。
仮想マシンに対してTPMを提供するためには、vCenter Serverでキープロバイダを設定する必要があります。
vCenter ClientでvCenter Serverを選択し、「構成」→「キープロバイダ」を選択、右ウィンドウで「追加」をクリック、「ネイティブキープロバイダの追加」をクリックします。
「ネイティブキープロバイダの追加」にて、名前を入力して「キープロバイダーの追加」をクリックします。
「キープロバイダをTPMで保護されているESXiホストでのみ使用（推奨）」のチェックボックスは、ESXiホストに物理TPMがあるかどうかでオン／オフを設定してください。
本記事の環境ではオフにして構成しています（オンだと仮想マシンにTPMが設定できませんでした）。
図7では「1つ以上のネイティブキープロバイダがすでに構成されています」というメッセージが出ていますが、環境依存なので無視してください。
キープロバイダを追加しただけでは、仮想マシンにTPMを提供できません。
作成したキープロバイダのバックアップを取って、初めてアクティブになります。そのため、新規で作成したキープロバイダのステータスは図8のように「バックアップされていません」となっています。
図8のように、バックアップ対象のキープロバイダを選択し、下の「キー管理サーバ」ウィンドウの「バックアップ」ボタンをクリックして、キープロバイダのバックアップを取得します。
図9のウィンドウが表示されますので、「キープロバイダのバックアップ」をクリックします。
「ネイティブキープロバイダデータをパスワードで保護（推奨）」のチェックは任意です。
バックアップを実行すると拡張子「p12」のファイルがダウンロードされます。PKCS#12形式の証明書ファイルになりますので、大切に保管してください。
バックアップが完了するとキープロバイダがアクティブに変更され、仮想マシンにTPMがアタッチ可能になります。仮想マシンの設定を編集し、「新規デバイスの追加」から「Trusted Platform Module（TPM）」を選択して、仮想マシンにアタッチします。
5：仮想マシンへAzure Stack HCI OSを展開する
Azure Stack HCI OSのISOイメージをマウントして仮想マシンを起動することで、Azure Stack HCI OSをインストールできます。
ここは特に問題になるようなところはありませんが、Azure Stack HCI OSは現在英語版のみの提供となっています。言語パック等をインストールせずに、英語版のまま使用します。
以前はローカライズ版が提供されていましたが、ローカライズBugの問題もありこのような形になっているようです。
OSインストール後、VMware Toolsをインストールします。vCenterからVMware Toolsのイメージをマウントしたのち、Sconfigの15番の「Exit to command line (PowerShell)」を選択し、コマンドプロンプトからISOイメージ上のSetup64.exeを実行します。
「Setup64.exeを実行してもなにも変わらない！」と思われた場合、インストールウィンドウがコマンドプロンプトのウィンドウに隠れている場合がほとんどなので、ウィンドウを動かしてみてください。後ろからひょっこりVMware Toolsのインストールウィンドウが顔を出すはずです。
VMware Toolsをインストールして再起動した後、ネットワーク設定やホスト名の変更などを実施しますが、on ESXi構成特有の設定はありません。Azure Localのドキュメントに従ってAzure Arc接続まで実施します。
on ESXi構成特有の設定ではないのですが、ここでの注意点が時刻設定です。
上記のデプロイドキュメント中でもw32tmによる時刻同期設定が記述されていますが、別のドキュメントでタイムゾーンやフォーマットによってデプロイが失敗することがあると示唆されています。
したがって、タイムゾーンはUTCを選択し、フォーマットはUS標記であることを確認してください。
時刻設定をSConfigから実施する場合は、9番の「Date and time」から実施できます。
時刻のフォーマットは9番の「Date and time」を実行後、設定画面の「Change calender setting」から確認可能です。
6：Azure Stack HCI OS展開後の作業
ここからはon ESXi構成特有の作業になります。これを行わないと、デプロイ作業中にエラーが発生します。
6-1：VMXNET3のVLAN ID設定
Azure Localではクラスター間通信のためにVLANを使用します。これは物理構成でもネスト構成でも同様で、Azure Stack HCI OS上でクラスター間通信に使用するネットワークアダプターでVLANタグを設定してタグVLANで通信します。
物理ネットワークアダプターでVLAN IDを設定するのか、仮想ネットワークアダプターでVLAN IDを設定するのかは、ネットワークアダプターの構成次第のところもあります。この辺りは、「NetworkATC」と呼ばれるのAzure Stack HCI OSもしくはWindows Server 2025の機能によって実現しているのですが、NetworkATCについては別の機会に触れたいと思います。
翻って、本記事の図1のようなネスト構成でかつ完全非集中型構成では、クラスター間通信用のネットワークアダプター（図1の緑のネットワークアダプター）であるVMXNET3ネットワークアダプターでVLAN IDの設定が必要になります。
設定自体はデプロイ作業中に自動的に行われる（具体的に言うとNetworkATCの機能で設定される）ので問題はないのですが、VMXNET3のVLAN IDの既定値は「Null」であり、Azure Localのデプロイスクリプトで期待されている「0」が入っていないため、スクリプトがエラー終了します。
これを回避するために、あらかじめPowerShellコマンドレットである「Set-NetworkAdapterAdvancedPropaty」コマンドレットを使用して、プロパティ値「VLAN ID」の値に「0」をセットします。
「Set-NetworkAdapterAdvancedPropaty」コマンドレットの実行前後に、「Get-NetworkAdapterAdvancedPropaty」コマンドレットを使用して確認していますが、「Null（-）」が「0」に変更されていることがわかります。
ここまでくれば、後はAzure Portalからのデプロイ作業となります。
7：Azure Portalからのデプロイ
Azure Portalからのデプロイも、基本的にはMicrosoftのドキュメントの通りです。
かつてAzure Local 23H2と呼ばれていたバージョンのAzure Local からの変更点は、拡張機能がAzure Arc接続の後処理として実施されていたものが、明示的にインストールを指示するように変更された点でしょうか。
かつてはAzure Arcをインストール／接続した後に10分から20分程度の待機時間が必要でした。これは拡張機能のインストールが裏で行われていたためで、インストール完了しているのかがわかりにくかったは事実です（別画面で確認する必要があった）。そのあたりを考慮した変更なのではないかと思っています。
と思ったら、ホストを追加したらいきなり拡張機能のインストールが自動実行されるパターンが1回だけありました。この辺りは臨機応変な対応が必要のようです。
これ以降は、基本的にはいままでのAzure Localのデプロイと変わるところはありません。
さて、設定が終わって、検証タスクが実行され、それが終われば実際のデプロイプロセスが実行されると思いますが、ここでエラーが発生します。
※エラーが発生したからといって、この画面を更新したりしないでください。現状維持です！
エラーが発生した個所は「Hardware Check」で、エラーメッセージは「ECCメモリではない」という感じのようです。
Azure Localの仕様を見る限りでは、最低32GBのECCメモリが必須となっています。
しかしながら、同じドキュメントに「メモリと ECC の要件を満たさない場合は、 仮想デプロイを選択します。」と、ネスト構成にするようにもアドバイスがあります。
Hyper-Vのネスト構成であればOKだけれども、VMware vSphereのネスト構成ではNGとなると、展開プロセスでどのように「展開されている環境はネスト環境である」ということを判断しているかを調べる必要がありますね。
8：原因究明
ということで、この問題をクリアするためには、Azure Localのデプロイの仕組みを理解する必要があります。
Azure Localのデプロイは、Microsoftが用意したPowerShellモジュールやスクリプト、定義ファイルをインターネットからダウンロードし、PowerShellスクリプトをローカルで実行することでデプロイを行っています。
定義ファイル等はC:\NugetStoreにダウンロードされ、PowerShellモジュールはC:¥Program Files¥WindowsPowerShellにダウンロードされます。
PowerShellのモジュールはPowerShell Galleryでも参照できるようになっていますので、解析をする場合はPowerShell Gallaryを参照したほうが良いかと思います。
今回引っかかったのは、環境チェックの部分なので、PowerShellモジュールはこの辺のものを使用しているようです。
今回はハードウェア周りのチェックで引っかかっているのでハードウェア周りをチェックしているモジュールを探すと、「AzStackHciHardware.psd1」というモジュールがあります。中を確認すると、「Test-AzStackHciHardware」というファンクションがあります。
なるほど、
(Get-WmiObject -Class Win32_ComputerSystem).Model
を実行して、戻り値が「Virtual Machine」であれば仮想環境と判断し、いくつかのテストしか実行しないようにしているようです。
Win32_ComputerSystem WMIクラスは、Windows を実行しているコンピューターシステムの情報を取得することができ、参加しているドメイン名やコンピューター名、製造元メーカーなどを取得可能なWMIクラスになっています。
Modelの値には製造元がコンピューターに提供する製品名が入り、読み取り専用の値のようですね。では、VMware vSphere環境の仮想マシンが、この値をどう返しているのかを実機で確認します。
図19の通り「VMware 20,1」と入っているので、仮想マシンとは判断されずに物理コンピューターと同じチェック基準が適用されていますね。
ちなみにHyper-V仮想マシンは、ご想像の通り「Virtual Machine」と返されています（図20）。
VMware仮想マシンのこの値を「Virtual Machine」と書き換えられれば仮想マシンと判断されるのですが、残念ながらGet-WmiObjectのModelは読み取り専用なので書き換え不可です。
続いてハードウェアチェックそのものを実施しているファンクションを探します。
どうも「AzStackHci.Hardware.Helpers.psm1」にファンクションが集中しているようです。
上から機能を追いかけていくと、ありました。「Test-MemoryProperties」です。
追いかけていくと、「Win32_PhysicalMemory」を読み取って、TotalWidthとDataWidthを比較して、値がDataWidthよりもTotalWidthのほうが大きければECCメモリ、と判断しているようです。
本当？ ということでWin32_PhysicalMemory WMIクラスを確認します。
TotalWidthを確認すると、「 エラー修正ビットがない場合、このプロパティの値は DataWidth プロパティに指定されているものと一致する必要があります。」との記述があり、なるほど、DataWidth とTotalWidthの値が異なればECCメモリと判断OKですね。
実際、ECCメモリを搭載している物理環境でWin32_PhysicalMemory WMIクラスを取得すると、確かにTotalWidthが72になっています。
対して仮想マシンではTotalWidthは64となっており、non-ECCメモリであると判断されてしまいます。
ということは、TotalWidthが64でもOKという判断式に変えてしまえば環境チェックは通りますね。
ちなみに、Hyper-V環境だとどうなのか、というと、図23のように両値ともNullになっています。Hyper-V仮想マシンでは厳密にメモリ幅まで確認できないようです。
9：エラー対策（イレギュラー処理）
ということで、環境チェックがエラーで中断している状態のAzure Localホストにコンソール接続し、コマンドプロンプトでnotepad.exeを実行します。
メモ帳が起動します。メモ帳は使えるんですね。
メモ帳の「File」メニューから「Open」を選択し、以下のファイルを開きます。
C:\Program Files\WindowsPowerShell\Modules\AzStackHci.EnvironmentChecker\AzStackHciHardware\AzStackHci.Hardware.Helpers.psd1
ファイルが存在しない場合は、別のAzure Localホストにあるはずなので、ファイルを探してください。
AzStackHci.Hardware.Helpers.psm1の407行目に移動すると、以下のような行があります。
if ($this.TotalWidth -gt $this.DataWidth)
これを以下のように書き換えます。
if ($this.TotalWidth -ge $this.DataWidth)
演算子を「より大きい（gt）」を「以上（ge）」にすることでECCチェックをnon-ECCでも通るようにする、という感じです。
ファイルを上書き保存し、Azure Portalの画面から再試行ボタンをクリックします。
これでECCエラーは解消され、最後までチェッカーが実行されるはずです。
もしかすると、ハードウェアチェックでTPM周りのエラーが発生するかもしれません。
この問題は、仮想マシン展開あるあるの1つで、TPMの証明書が作成日からすくなくとも1日経過しているかを確認し、経過していなければエラーを出力する、というものになります。
したがって、TPM付きの仮想マシンを作成して日付が変わっていれば、本問題は発生しません。万が一発生してしまい、かつ急ぎで作成しなければならない場合は、ECCメモリの対策を行ったとき同様、PowerShellモジュールを修正します。
AzStackHci.Hardware.Helpers.psm1の1252行目に移動すると、以下のような行があります。
$currentCert = $sinceIssued.Days -gt 0 -and $untilExpired.Days -gt 0
これを以下のように書き換えます。
$currentCert = $sinceIssued.Days -ge 0 -and $untilExpired.Days -gt 0
ECCメモリ対策同様、演算子を「より大きい（gt）」を「以上（ge）」にすることこの問題はクリアできます。ファイルを上書き保存し、Azure Portalの画面から再試行ボタンをクリックして、再試行してください。
10：そののちのエラーと対策
この次のNetworkチェックでエラーが発生した場合、以下の問題が考えられます。
- ストレージネットワークでのVLAN設定不可
- ストレージネットワークでのVLAN通信不可
- ストレージネットワークでのRDMA確認不可
1については、VMXNET3固有の「既定値がNullである」問題であることがほとんどなので、「6-1：VMXNET3のVLAN ID設定」の項を参照して、VLANIDをセットする作業を行ってください。まれに仮想ネットワークアダプターとしてE1000を接続してしまい、ゲストVLANが設定できない、というオチもあるので、VMXNET3であることも併せてご確認ください。
2については、「4：VMware vSphere側の設定」の節で説明した通り、ストレージネットワークではゲストVLANが設定され、VLAN711からVLAN718を使用して通信が実施されます。ESXiホストの仮想スイッチは仮想マシンのタグVLAN通信を許容するよう、ポートグループの設定を行う必要があります。本構成ではポートグループでVLAN4095を指定しています。「4-1：仮想スイッチの設定」を参照して、設定を確認してください。
3については、Azure Localの展開設定の際にRDMAをdisableにするのを忘れてた、というものです。本記事では説明を割愛していますが、Azure Localのネットワーク設定時に、必ずネットワーク設定を開いてRDMAをdisableにしてください。
ここまでくれば、事前チェックは問題なく完了するはずです。
なにかしらのエラーが発生した場合には、エラーメッセージを読んでいただければ、基本的には解決可能なレベルまで細かくエラー内容を提示してくれているはずです。
11：そして展開
展開が開始されれば、完了まで待つだけです。
インターネットの帯域が細いとか、実はプロキシーが必要だった、等、環境面で問題がある場合を除き、すんなりと展開は完了するはずですが、結構時間がかかります。
本記事を執筆した環境では、3時間超で完了しました。
ですので、Azure Portalで適当なタイミングで「最新の情報に更新」ボタンで情報更新を行い、進捗を確認しながら気長に待つ必要があります。コンソール接続をしておいて、PowerShellの実行状況を確認するのも一つの手ですね。展開スクリプトがエラーで落ちた場合には、スクリプト実行画面がプロンプトに戻っているはずです。
12：最後に
デプロイが完了すれば、ハイパーバイザーにかかわらず、Azure Localの機能評価は可能となります。
ネスト構成なので性能評価は難しいかと思いますが、Azure Localがどういう動きをして、Azureとどう協調して動くのかは確認いただくことが可能かと思います。
繰り返しになりますが、VMwareのネスト構成でのAzure Localの展開は非サポート構成です。エラー等でAzureサポートに問い合わせても、一切サポートは行っていただけません。サポートが必要な場合には、Hyper-V環境でのデプロイも検討してください。
では、よいAzure Localライフを！
書いた人：後藤 諭史（Satoshi GOTO）
ソリューションアーキテクト部所属。
専門はWindows Server Hyper-VやAzure LocalといったMicrosoft仮想化技術。Microsoft SDN（Hyper-V Network Virtualization）などのWindows Server ネットワーク技術も。
Microsoft オンプレ技術以外にも、エンタープライズネットワークとかMicrosoft Azureとか、運用とか。
ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。
Microsoft MVP for Cloud and Datacenter Management（2012-2026）
Microsoft MVP for Microsoft Azure（2024-2026）
