• Azure Private Endpoint を使った際に名前解決がうまくいかない「あるある」パターン 7 選
• 各パターンの事象・原因・解決策を具体的に整理
• nslookup / Resolve-DnsName などの確認コマンド例付き
• Hub-Spoke 構成やオンプレミス接続時に特にハマりやすいポイントを重点解説

はじめに

Azure Private Endpoint を使うと、Azure PaaS サービスへの通信を VNet 内のプライベート IP 経由に閉じることができます。

ただし、Private Endpoint を作成しただけでは十分ではありません。DNS の名前解決が正しく Private IP を返すように構成する必要があります。

そこで重要になるのが Azure Private DNS Zone です。Private DNS Zone にレコードを用意し、対象の VNet にリンクすることで、VNet 内の VM や各種サービスが Private Endpoint の Private IP を名前解決できるようになります。

仕組み自体はシンプルですが、実務では「名前解決できない」「なぜかパブリック IP に解決される」「オンプレミスからだけつながらない」といったトラブルがよく発生します。

本記事では、特によくある 7 つのパターンを取り上げ、事象、原因、解決策の順で整理します。

パターン 1: Private DNS Zone を VNet にリンクし忘れて名前解決できない

事象

Private Endpoint を作成し、Private DNS Zone にも A レコードが登録されているのに、VM から nslookup するとパブリック IP が返ってくる。

> nslookup myaccount.blob.core.windows.net
Non-authoritative answer:
Name:    blob.xxxx.store.core.windows.net
Address:  20.xx.xx.xx   ← パブリック IP

原因

Private DNS Zone を作成しただけでは、VNet 内のリソースはそのゾーンを参照しません。Private DNS Zone の「仮想ネットワーク リンク」が未設定のため、VNet の DNS 解決に Private DNS Zone が使われていない状態です。

解決策

Azure Portal で Private DNS Zone の [仮想ネットワーク リンク] を開き、対象の VNet をリンクします。

# PowerShell でリンクを作成する例
New-AzPrivateDnsVirtualNetworkLink `
  -ResourceGroupName "rg-network" `
  -ZoneName "privatelink.blob.core.windows.net" `
  -Name "link-to-vnet-spoke01" `
  -VirtualNetworkId "/subscriptions/<sub-id>/resourceGroups/rg-network/providers/Microsoft.Network/virtualNetworks/vnet-spoke01" `
  -EnableRegistration $false

リンク作成後、再度名前解決を確認します。

> nslookup myaccount.blob.core.windows.net
Name:    myaccount.privatelink.blob.core.windows.net
Address:  10.0.1.4   ← Private IP

ポイント

• -EnableRegistration は $false にしてください。$true にすると VM のホスト名を Private DNS Zone に自動登録する機能が有効になりますが、PaaS の Private Endpoint の名前解決では通常不要です。
• 1 つの Private DNS Zone に対して複数の VNet をリンクできます。

パターン 2: オンプレミスや他 VNet から Private Endpoint の名前解決ができない

事象

Private Endpoint を配置した VNet 内の VM からは名前解決できるが、VPN/ExpressRoute 経由のオンプレミスや、ピアリングしている別の VNet からは名前解決できない。

原因

Azure Private DNS Zone は、基本的に リンクされた VNet 内 でのみ有効です。オンプレミスの DNS サーバーは Azure Private DNS Zone を直接参照できません。

そのため、オンプレミスのクライアントはパブリック DNS を引いてしまい、結果としてパブリック IP が返ります。

解決策

DNS フォワーダー（条件付きフォワーダー） を構成し、privatelink.*.core.windows.net などのクエリを Azure 側へ転送できるようにします。

方法 A: Azure DNS Private Resolver を使う（推奨）

Azure DNS Private Resolver を Hub VNet にデプロイし、インバウンドエンドポイントの IP をオンプレミス DNS サーバーの条件付きフォワーダー先に設定します。

オンプレ DNS サーバー
  → 条件付きフォワーダー: privatelink.blob.core.windows.net → 10.0.0.4 (DNS Private Resolver のインバウンド IP)
    → Azure DNS (168.63.129.16)
      → Private DNS Zone の A レコード → Private IP

方法 B: Azure VM 上に DNS フォワーダーを構成する

Hub VNet 上の VM に DNS サーバー（Windows DNS や Unbound など）を構成し、168.63.129.16 への条件付きフォワーダーを設定します。オンプレミスの DNS サーバーからはこの VM の IP にフォワードします。

ポイント

• Azure DNS Private Resolver は VM 不要のマネージドサービスなので、新規構築では方法 A を推奨します。
• オンプレミス側のフォワーダー設定では、privatelink を含む FQDN のゾーンを対象にしてください。

パターン 3: Private DNS Zone のゾーン名を間違えている

事象

Private DNS Zone を作成し、VNet リンクも設定しているが、名前解決が Private IP にならない。

原因

Azure サービスごとに Private DNS Zone のゾーン名が異なります。間違ったゾーン名で作成すると、DNS クエリがそのゾーンにマッチしないため、パブリック DNS にフォールバックします。

よくある間違いの例

解決策

Microsoft Learn の公式ドキュメント Azure プライベート エンドポイントの DNS 構成 に、サービスごとの正しいゾーン名一覧が掲載されています。必ずこのドキュメントを参照してください。

ポイント

• 特に Azure Monitor 関連 は、利用する機能に応じて privatelink.oms.opinsights.azure.com、privatelink.ods.opinsights.azure.com、privatelink.agentsvc.azure-automation.net、privatelink.monitor.azure.com、privatelink.blob.core.windows.net など複数のゾーンが必要になりやすく、漏れやすいです。
• Private Endpoint 作成時の 自動 DNS 統合（後述のパターン 7）を使えば、正しいゾーン名で自動作成されるため、ゾーン名の間違いを防げます。

パターン 4: パブリック DNS が優先されて Private IP に解決されない

事象

VNet 内の VM から名前解決しても、Private IP ではなくパブリック IP が返ってくる。Private DNS Zone のリンクは設定済み。

原因

VNet または VM の DNS 設定がカスタム DNS サーバーを指している 場合、Azure 既定の DNS（168.63.129.16）は使われません。

そのカスタム DNS サーバーが privatelink.* のクエリを適切に処理できていないと、Private DNS Zone が参照されず、パブリック DNS にフォールバックしてしまいます。

確認方法

# VM の DNS 設定を確認
Get-DnsClientServerAddress -InterfaceAlias "Ethernet"

# VNet の DNS 設定を Azure CLI で確認
az network vnet show --name vnet-spoke01 --resource-group rg-network --query "dhcpOptions.dnsServers"

解決策

カスタム DNS サーバー（例: Hub VNet 上の DC や DNS サーバー）に、privatelink.* ゾーンの条件付きフォワーダーを 168.63.129.16 宛に設定してください。

Windows DNS サーバーの場合:

# 条件付きフォワーダーの追加例
Add-DnsServerConditionalForwarderZone `
  -Name "privatelink.blob.core.windows.net" `
  -MasterServers 168.63.129.16

ポイント

• 168.63.129.16 は Azure のワイヤサーバーで、Azure VM 内からのみ到達可能です。オンプレミスの DNS サーバーから直接フォワードすることはできません（パターン 2 参照）。
• VNet の DNS 設定を「既定（Azure 提供）」に戻すと解消するケースもありますが、Active Directory 環境ではカスタム DNS が必要なことが多いため、条件付きフォワーダーで対応するのが現実的です。

パターン 5: Hub-Spoke 構成で Private DNS Zone のリンク先 VNet を間違える

事象

Hub-Spoke 構成で、Spoke VNet 上の VM から Private Endpoint の名前解決ができない。Hub VNet 上の VM からは名前解決できる。

原因

Private DNS Zone の仮想ネットワーク リンクが Hub VNet のみに設定されており、Spoke VNet にリンクされていないケースです。

Hub-Spoke 構成では、DNS の設計パターンによって対応が異なります。

解決策

パターン A: Spoke VNet が Azure 既定 DNS を使っている場合

Spoke VNet にも Private DNS Zone の仮想ネットワーク リンクを追加します。

# Spoke VNet へのリンク追加
New-AzPrivateDnsVirtualNetworkLink `
  -ResourceGroupName "rg-network" `
  -ZoneName "privatelink.blob.core.windows.net" `
  -Name "link-to-vnet-spoke01" `
  -VirtualNetworkId "/subscriptions/<sub-id>/resourceGroups/rg-network/providers/Microsoft.Network/virtualNetworks/vnet-spoke01"

パターン B: Spoke VNet のカスタム DNS が Hub の DNS サーバーを指している場合

Hub VNet のリンクのみで OK ですが、Hub 上の DNS サーバー（またはDNS Private Resolver）が 168.63.129.16 に条件付きフォワードしている必要があります。

Spoke VM → Hub DNS サーバー → 168.63.129.16 → Private DNS Zone → Private IP

この設計では、Hub 側に DNS を集約し、Spoke が常に Hub の DNS を利用する 前提であれば、実装上は Private DNS Zone を Hub VNet のみにリンクして名前解決できるケースがあります。ただし、Microsoft Learn では、名前解決が必要な VNet をそれぞれ Private DNS Zone にリンクする構成が基本です。中央集約型 DNS 設計を採る場合は、この前提を明示して設計してください。

ポイント

• Hub-Spoke が多数ある環境では、パターン B の中央集約型 DNS 設計は管理しやすい一方で、Spoke が Hub DNS を必ず利用することを前提に設計・運用する必要があります。
• Azure DNS Private Resolver を Hub に配置し、Spoke VNet の DNS 設定でその IP を利用する構成は、実務でも採用しやすいパターンです。

パターン 6: DNS は解決できるのにアプリから接続できない

事象

nslookup や Resolve-DnsName では Private IP が正しく返ってくるのに、アプリケーション（Web アプリ、SDK など）から Private Endpoint 経由で接続できない。

# DNS は正しく解決できている
Resolve-DnsName myaccount.blob.core.windows.net
# → 10.0.1.4 (Private IP) ✓

# しかし接続するとタイムアウトする
Test-NetConnection -ComputerName myaccount.blob.core.windows.net -Port 443
# → TcpTestSucceeded : False

原因（複数の可能性）

原因 A: NSG / ファイアウォールでブロックされている

Private Endpoint のサブネットに関連付けられた NSG や、Azure Firewall / NVA がトラフィックをブロックしている場合があります。

# Private Endpoint への疎通確認
Test-NetConnection -ComputerName 10.0.1.4 -Port 443

原因 B: プロキシ設定

アプリケーションや OS にプロキシが設定されていると、DNS 解決はローカルで行われても、実際の HTTP 通信がプロキシ経由になり、プロキシサーバー側でパブリック IP に解決されてしまうことがあります。

# プロキシ設定の確認
netsh winhttp show proxy

# 環境変数の確認
$env:HTTP_PROXY
$env:HTTPS_PROXY

原因 C: Split-brain DNS

nslookup はシステムの DNS キャッシュやホストファイルを無視して直接 DNS サーバーに問い合わせます。一方、アプリケーションは OS の名前解決を使います。hosts ファイルや DNS クライアントキャッシュに古いエントリが残っていると、アプリだけ異なる IP に解決される場合があります。

# DNS キャッシュの確認
Get-DnsClientCache | Where-Object { $_.Entry -like "*myaccount*" }

# hosts ファイルの確認
Get-Content C:\Windows\System32\drivers\etc\hosts | Select-String "myaccount"

# DNS キャッシュのクリア
Clear-DnsClientCache

ポイント

• nslookup の結果だけで「DNS は問題ない」と判断しないことが重要です。Resolve-DnsName、dig、アプリケーション実行時の挙動を合わせて確認し、どこで結果が変わるのかを切り分けましょう。
• プロキシが原因の場合は、Private Endpoint の FQDN をプロキシのバイパスリストに追加します。

パターン 7: 自動 DNS 統合を使わず A レコードが登録されていない

事象

Private Endpoint を作成したが、Private DNS Zone に A レコードが存在せず、名前解決が Private IP にならない。

原因

Azure Portal で Private Endpoint を作成する際、「プライベート DNS ゾーンとの統合」 オプションがあります。このオプションを「いいえ」にした場合、または ARM テンプレート / Terraform / Bicep で privateDnsZoneGroups を構成しなかった場合、A レコードは自動登録されません。

解決策

方法 A: Private DNS Zone Group を後から追加する（推奨）

# Private DNS Zone Group の作成
$zone = Get-AzPrivateDnsZone -ResourceGroupName "rg-network" -Name "privatelink.blob.core.windows.net"

$config = New-AzPrivateDnsZoneConfig `
  -Name "privatelink-blob-core-windows-net" `
  -PrivateDnsZoneId $zone.ResourceId

New-AzPrivateDnsZoneGroup `
  -ResourceGroupName "rg-app" `
  -PrivateEndpointName "pe-storage01" `
  -Name "default" `
  -PrivateDnsZoneConfig $config

Private DNS Zone Group を構成すると、A レコードが自動的に作成・管理されます。Private Endpoint の IP が変わった場合も自動更新されるため、この方法を強く推奨します。

方法 B: 手動で A レコードを追加する

# 手動で A レコードを登録する例
New-AzPrivateDnsRecordSet `
  -ResourceGroupName "rg-network" `
  -ZoneName "privatelink.blob.core.windows.net" `
  -Name "myaccount" `
  -RecordType A `
  -Ttl 3600 `
  -PrivateDnsRecords (New-AzPrivateDnsRecordConfig -IPv4Address "10.0.1.4")

ポイント

• 手動登録の場合、Private Endpoint を再作成して IP が変わるとレコードの更新を忘れるリスクがあります。必ず Private DNS Zone Group を使いましょう。
• Bicep / Terraform で IaC 管理している場合は、必ず privateDnsZoneGroups（Bicep）または azurerm_private_dns_zone_group（Terraform）をテンプレートに含めてください。

トラブルシューティングに使えるコマンド集

以下は、Private Link + DNS のトラブルシューティング時に役立つコマンドをまとめたものです。

DNS の名前解決確認

# Windows - Resolve-DnsName（OS のリゾルバーを使用。推奨）
Resolve-DnsName myaccount.blob.core.windows.net

# Windows - nslookup（直接 DNS サーバーに問い合わせ）
nslookup myaccount.blob.core.windows.net

# Linux - dig（詳細な DNS 応答を確認）
dig myaccount.blob.core.windows.net

# Linux - host
host myaccount.blob.core.windows.net

CNAME チェーンの確認

Private Endpoint が正しく構成されている場合、privatelink を含む CNAME が返ります。

Resolve-DnsName myaccount.blob.core.windows.net -Type CNAME
# → myaccount.blob.core.windows.net → myaccount.privatelink.blob.core.windows.net

privatelink の CNAME が返らない場合、Private Endpoint の作成自体に問題がある可能性があります。

ネットワーク疎通確認

# TCP 接続テスト
Test-NetConnection -ComputerName myaccount.blob.core.windows.net -Port 443

# Linux
curl -v https://myaccount.blob.core.windows.net
nc -zv myaccount.blob.core.windows.net 443

DNS キャッシュの管理

# Windows - キャッシュ確認
Get-DnsClientCache | Where-Object { $_.Entry -like "*privatelink*" }

# Windows - キャッシュクリア
Clear-DnsClientCache

# Linux - systemd-resolved のキャッシュクリア
sudo systemd-resolve --flush-caches

Private DNS Zone の状態確認 (Azure CLI)

# Private DNS Zone のレコード一覧
az network private-dns record-set list \
  --resource-group rg-network \
  --zone-name privatelink.blob.core.windows.net \
  --output table

# 仮想ネットワーク リンクの一覧
az network private-dns link vnet list \
  --resource-group rg-network \
  --zone-name privatelink.blob.core.windows.net \
  --output table

# Private Endpoint の DNS 構成確認
az network private-endpoint dns-zone-group list \
  --resource-group rg-app \
  --endpoint-name pe-storage01 \
  --output table

まとめ

Private Link + Private DNS Zone のトラブルの多くは、「DNS の名前解決が Private IP を返さない」 という点に集約されます。切り分けの基本は以下のフローです。

1. Resolve-DnsName で FQDN を引いて、Private IP が返るか？
   • 返らない場合は、DNS 構成の問題を疑います（パターン 1〜5, 7）。
   • 返る場合は、ネットワークまたはアプリ側の問題を疑います（パターン 6）。
2. CNAME チェーンに privatelink が含まれるか？
   • 含まれない場合は、Private Endpoint の構成自体を確認します。
   • 含まれる場合は、Private DNS Zone 側の問題を確認します。
3. どこから名前解決しているか？
   • VNet 内なら、Private DNS Zone のリンクとレコードを確認します。
   • オンプレミスや他 VNet なら、DNS フォワーダーの構成を確認します。

この順番で見ていくと、どこで名前解決が崩れているのかをかなり効率よく切り分けられます。

参考リンク

• Azure プライベート エンドポイントの DNS 構成
• Azure Private Link とは
• Azure DNS Private Resolver とは
• プライベート エンドポイントの DNS の問題のトラブルシューティング
• 仮想ネットワーク リンクを使用した Azure プライベート DNS ゾーン
• Hub-spoke ネットワーク トポロジにおけるプライベート エンドポイントの DNS 解決

• ASR のフェールオーバーは拡張機能の移行をサポートしていない
• AMA でログ取得している場合、フェールオーバー後はログが取得されなくなってしまう
• AMA の DCR を活用して、VM の再登録などを復旧計画に入れてしまうことを忘れずに

ASR の制限事項

Azure Site Recovery の制限事項の 1 つとして、「拡張機能は再インストールしてください」というものがあります。

Azure リージョン間での Azure VM ディザスター リカバリーに関するサポート マトリックス

そもそも拡張機能は公式サイトから引用すると以下のようなもので、「Azure VM に様々な機能を提供する軽量なアプリケーション」です。

拡張機能は、Azure 仮想マシン (VMs)でのデプロイ後の構成と自動化を提供する小さなアプリケーションです。 Azure プラットフォームでは、VM の構成、監視、セキュリティ、およびユーティリティのアプリケーションを対象とする多くの拡張機能をホストします。

Azure 仮想マシンの拡張機能とその機能

代表的な拡張機能として Azure VM でログを取得する Azure Monitor Agent （AMA）がありますが、ASR でフェールオーバーした後は制限事項にある通り、拡張機能を再インストールしない限り、AMA を利用してログを取得することができません。

拡張機能を再インストールする

ここでは AMA を例にして実際に ASR を使ってフェールオーバーした VM に対して AMA を再インストールする流れを見てみます。

VM をデプロイし、AMA でログを取得した場合、VM の拡張機能はこのようになっています。（AMA 以外の拡張機能も含まれています、AMA は AzureMonitorWindowsAgent です）

対象の VM をフェールオーバーした後、改めて VM の拡張機能を確認してみると、サポートされていないためすべてなくなっています。 （対象の VM 名が一緒なのでわかりにくいですが）

一応コマンドで確認すると…

 Type                : Microsoft.Azure.Monitor.AzureMonitorWindowsAgent
    TypeHandlerVersion  : 1.20.0.0
    Status              :
      Code              : ProvisioningState/Unresponsive
      Level             : Warning
      DisplayStatus     : Unresponsive
      Message           : Handler Microsoft.Azure.Monitor.AzureMonitorWindowsAgent of version 1.20.0.0 is unresponsive. Last
heartbeat: 10/6/2023 5:50:06 AM

「Unresponsive」と書かれていて、AMA の反応がないことがわかります。 この場合、AMA でログ取得するデータ収集ルールにおいても、フェールオーバーを行った VM を選択できません。 ですので、一度 AMA 拡張機能をアンインストールする必要があります。

コマンド

Remove-AzVMExtension -Name AzureMonitorWindowsAgent -ResourceGroupName <resource-group-name> -VMName <virtual-machine-name>

結果

Virtual machine extension removal operation
This cmdlet will remove the specified virtual machine extension. Do you want to continue?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): Y
RequestId IsSuccessStatusCode StatusCode ReasonPhrase
                         True  NoContent No Content

削除をしてあげることで、データ収集ルールで VM を選択できるようになっているので追加してあげます。 （下記のスクリーンショットにはないのですが、AMA 拡張機能削除前は対象の VM は選べない状態となっています）

これでログが無事取得できるようになりました。

ただ、この方法だと人力すぎますよね。

復旧計画で AMA 再インストールを自動化する

ASR では復旧計画というものがあり、DR 発動時に行う作業を1つの流れにまとめることが可能です。

例えば、復旧する順番として「DB サーバーを先に起動した後に Web サーバーを起動する」といった流れのように、 FO 時に起動の順番を決定することができるのが、復旧計画です。 この復旧計画を活用し、 ASR 発動後に AMA を再インストールするという流れにしてあげることで、自動で AMA が再インストールされてログが取れるようになります。

Automation でフェールオーバー対象の VM の拡張機能を再インストールしてしまう

復旧計画では、Azure Automation のスクリプトを利用することが可能です。 流れとしては以下のような流れになるでしょう。

1. FO が開始され、別リージョンで VM が起動する
2. 別リージョンの VM から AMA をアンインストールするコマンドを実行する -> Automation で実行
3. AMA をインストールするコマンドが実行される
4. データ収集ルール（DCR）に VM を再関連付けする

以下は、Azure Automation の Runbook で使用できる AMA のインストールスクリプトの一例です。

param(
    [Parameter(Mandatory=$true)]
    [string]$vmName,
    
    [Parameter(Mandatory=$true)]
    [string]$resourceGroupName,
    
    [Parameter(Mandatory=$true)]
    [string]$location,
    
    [Parameter(Mandatory=$true)]
    [string]$dcrId
)

# Azure に接続（Managed Identity を使用）
Connect-AzAccount -Identity

# 既存の AMA 拡張機能を削除（エラーハンドリング付き）
try {
    Write-Output "Removing existing AMA extension from VM: $vmName"
    Remove-AzVMExtension -Name "AzureMonitorWindowsAgent" -ResourceGroupName $resourceGroupName -VMName $vmName -Force
    Write-Output "AMA extension removed successfully"
} catch {
    Write-Output "Failed to remove AMA extension or extension not found: $($_.Exception.Message)"
}

# AMA 拡張機能をインストール
try {
    Write-Output "Installing AMA extension on VM: $vmName"
    Set-AzVMExtension -ResourceGroupName $resourceGroupName -VMName $vmName -Name "AzureMonitorWindowsAgent" -Publisher "Microsoft.Azure.Monitor" -Type "AzureMonitorWindowsAgent" -TypeHandlerVersion "1.0" -Location $location
    Write-Output "AMA extension installed successfully"
} catch {
    Write-Error "Failed to install AMA extension: $($_.Exception.Message)"
    throw
}

# データ収集ルールとの関連付け
try {
    Write-Output "Associating VM with Data Collection Rule: $dcrId"
    $vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName
    $associationName = "vm-$vmName-dcr-association"
    New-AzDataCollectionRuleAssociation -ResourceUri $vm.Id -AssociationName $associationName -DataCollectionRuleId $dcrId
    Write-Output "DCR association completed successfully"
} catch {
    Write-Error "Failed to associate VM with DCR: $($_.Exception.Message)"
    throw
}

Write-Output "AMA reinstallation and DCR association completed for VM: $vmName"

復旧計画での実装手順

1. Azure Automation アカウントの準備
   • Automation アカウントを作成
   • 必要な PowerShell モジュール（Az.Accounts、Az.Monitor など）をインポート
   • システム割り当て Managed Identity を有効化し、適切な権限を付与
2. Runbook の作成
   • 上記のスクリプトを Runbook として作成
   • パラメータを適切に設定
3. 復旧計画への組み込み
   • ASR の復旧計画でグループを作成
   • フェールオーバー後のアクションとして Automation Runbook を追加
   • 必要なパラメータ（VM名、リソースグループ、DCR ID など）を設定

注意事項

Linux VM の場合

Linux VM の場合は拡張機能の名前が異なるため、以下のように修正が必要です。

# Linux の場合
Remove-AzVMExtension -Name "AzureMonitorLinuxAgent" -ResourceGroupName $resourceGroupName -VMName $vmName -Force
Set-AzVMExtension -ResourceGroupName $resourceGroupName -VMName $vmName -Name "AzureMonitorLinuxAgent" -Publisher "Microsoft.Azure.Monitor" -Type "AzureMonitorLinuxAgent" -TypeHandlerVersion "1.0" -Location $location

複数の拡張機能がある場合

AMA 以外にも拡張機能を利用している場合は、それらも同様に再インストールが必要です。例えば：

• Dependency Agent
• カスタム拡張機能

これらも同様の手順で復旧計画に組み込むことができます。

まとめ

ASR を利用する際は、拡張機能の制限事項を理解し、事前に復旧計画に組み込んでおくことが重要です。特に監視やセキュリティに関わる拡張機能は、DR 発動後も継続して動作させる必要があるため、自動化しておくことをお勧めします。

復旧計画と Azure Automation を活用することで、手動での作業を減らし、確実な復旧を実現することができます。定期的な DR テストの際に、拡張機能の動作確認も含めて実施することを忘れずに行いましょう。

• Logic Apps は既定でワークフローは順番で実行される
• 分岐をさせる方法をまとめました

分岐方法のいくつか

Logic Apps を利用してワークフローを実行させる場合、通常であれば順に沿って実行されます。

ただし、条件を付けて「特定の曜日の場合は実行させない」などといったことを実施したいことはあると思います。

その場合にどのような方法があるかをまとめました。

以下のような方法があります。

• Conditional
• Switch
• Branches
• Loop
• Scopes

Conditional

まずは Conditional、条件です。 その名の通り、条件に合致すればxxxする、合致しなければ△△△する、といった条件分岐です。

下記の例は「注文金額が10万円以上なら承認処理を呼び出す、10万円未満なら即時処理」です。

"actions": {
  "CheckAmount": {
    "type": "If",
    "expression": {
      "greaterOrEquals": [
        "@int(body('GetOrder')?['amount'])",
        100000
      ]
    },
    "actions": {
      "CallApproval": {
        "type": "ApiConnection",
        "inputs": {
          "host": {
            /* 承認API接続情報 */
          }
        }
      }
    },
    "else": {
      "actions": {
        "AutoApprove": {
          "type": "Compose",
          "inputs": "自動承認"
        }
      }
    }
  }
}

• typeにIfを指定
• expressionで真偽を判定
• actionsにTrue時の処理、elseにFalse時の処理を記述

Switch

スイッチです。条件式に合致するかどうかを複数パターンに振り分けます。 下記の例はケースごとに新規通知・確認通知・その他通知をさせるような処理をしています。

"actions": {
  "OrderStatusSwitch": {
    "type": "Switch",
    "expression": "@body('GetOrder')?['status']",
    "cases": {
      "New": {
        "actions": {
          "NotifyNew": {
            /* 新規通知処理 */
          }
        }
      },
      "Confirmed": {
        "actions": {
          "NotifyConfirmed": {
            /* 確認通知処理 */
          }
        }
      }
    },
    "default": {
      "actions": {
        "NotifyUnknown": {
          /* その他通知処理 */
        }
      }
    }
  }
}

• casesでキーごとに処理を定義
• defaultでどのケースにも該当しない値をハンドリング

Branches

いわゆるパラレル処理、処理を並列で走らせ、処理の高速化や非同期実行を実現させます。 下記の例は、メール送信とログ記録を同時に行わせています。

"actions": {
  "SendEmail": {
    "type": "Compose",
    "inputs": "メール送信",
    "runAfter": {
      "PreviousAction": ["Succeeded"]
    }
  },
  "LogApi": {
    "type": "Http",
    "inputs": {
      /* ログ記録API */
    },
    "runAfter": {
      "PreviousAction": ["Succeeded"]
    }
  }
}

• Logic Apps には「Parallel」タイプは存在しない
• 同じ runAfter の依存先を指定することで、複数アクションが並列実行される
• 上記の例では SendEmail と LogApi が PreviousAction の後に同時に実行される

Loop

繰り返し処理です。Loop は For each と Until の 2 種類があります。

For each

配列内にある要素を処理します。 parallel で同時実行数を調整できます。 下記の例の場合は 5 回繰り返します。

"actions": {
  "ForEachItem": {
    "type": "Foreach",
    "foreach": "@body('GetList')",
    "actions": {
      "ProcessItem": {
        "type": "Compose",
        "inputs": "@item()"
      }
    },
    "runtimeConfiguration": {
      "concurrency": {
        "repetitions": 5
      }
    }
  }
}

• foreachで対象の配列を指定
• runtimeConfiguration.concurrency.repetitionsで同時実行数を設定

Until

条件が満たされるまで繰り返します。無限ループを防ぐためにも limit や timeout を設定するといいでしょう。

"actions": {
  "UntilLoop": {
    "type": "Until",
    "expression": {
      "equals": [
        "@variables('done')",
        true
      ]
    },
    "actions": {
      "CheckStatus": {
        /* ステータス確認処理 */
      },
      "Delay": {
        "type": "Wait",
        "inputs": {
          "interval": {
            "count": 10,
            "unit": "Second"
          }
        }
      }
    },
    "limit": {
      "count": 20,
      "timeout": "PT5M"
    }
  }
}

• limitで最大試行回数
• timeoutで全体の実行上限時間

Scopes

複数アクションをまとめて、成功・失敗時の後続処理を一括で設定します。

"actions": {
  "TryScope": {
    "type": "Scope",
    "actions": {
      "StepA": { /* 処理A */ },
      "StepB": { /* 処理B */ }
    }
  },
  "CatchScope": {
    "type": "Scope",
    "runAfter": { "TryScope": ["Failed"] },
    "actions": {
      "LogError": { /* エラーログ記録 */ },
      "NotifyAdmin": { /* 管理者通知 */ }
    }
  },
  "FinallyScope": {
    "type": "Scope",
    "runAfter": {
      "TryScope": ["Succeeded"],
      "CatchScope": ["Succeeded"]
    },
    "actions": {
      "Cleanup": { /* 後始末処理 */ }
    }
  }
}

• Scopeを3つ用意してTry/Catch/Finally構成を実現
• runAfterで実行条件をまとめて指定

まとめ

改めて、それぞれの分岐方法の紹介です。

• Conditional：Ifタイプでシンプルに2択分岐
• Switch：複数ケースの振り分けに最適
• Branches：Parallelで並列実行を実現
• Loop：Foreach／Untilでバッチや条件付き繰り返し
• Scopes：Scope＋RunAfterでTry/Catch/Finallyを実装

ワークフローで適切な分岐を選択することで、拡張性の高い設計が可能となります。

• Application Gateway では AFD や TM で可能な「トラフィックの重みづけでの負荷分散」ができない
• 作りこみで「疑似」重みづけをやってみる

AFD と TM でもいいんだけど

トラフィックの負荷分散で重みづけができるサービスは、Azure Front Door や Traffic Manager になります。 この 2 つのサービスはグローバルサービスになるので、特定のリージョンに依存せず、パブリックに公開されるサービスになります。

こうなると、もしパブリックに公開させたくない要件のあるシステムの場合は利用できないため、 AFD や TM は残念ながら利用できません。

L7 トラフィックの負荷分散を行うことが出来る Azure のサービスは Application Gateway になりますが、AppGW は重みづけをつけたトラフィックのルーティングができません。

今回は、Application Gateway を利用して疑似的にトラフィックの重みづけをする方法を考えてみます。

思いついた方法 2 つ

パッと思いつく方法はこんな形でしょうか。

• VM 2 台のうち、VM2 をシャットダウンしておいて、VM1 側に障害があった際に立ち上げる

• AppGW で VM2 にもルーティングされるように設定しておき、普段は VM2 にルーティングされないように NSG をつけておいて、VM1 障害時に VM2 の NSG を外す

両方とも不可能ではなさそうです。 VM1 側で障害を検知したら、VM2 を立ち上げる or VM2 NIC に付随の NSG を外すだけで OK ですからね。 ただし、VM2 を立ち上げるのと NSG を外す動作だと、NSG を外すほうが時間的にはかからないので、今回は後者の方法をとってみたいと思います。

NSG を外す

では、VM1 側に障害があった際に、VM2 の NSG を外して VM2 側にルーティングする方法を考えていきます。 今回の場合は 2 台なので、アラート発報の契機としては、AppGW の正常なホストの数でよさそうです。

AppGW では、メトリックとして正常なホスト数（Healthy Host Count）というのを取得していて、その正常なホストがなくなったときに VM2 についている NSG を外すようにします。

ちなみに正常「ではない」ホスト数に関しては Unhealthy Host Count というメトリックになります。

上記の画像だと、2 台の正常なホストがいて、とあるタイミングで 1 台に異常があって正常なホストが 1 に減っています。

今回のやりたいことだと、2台構成の Active-Standby だと、正常なホスト数が1台で、それ以下になった場合はアラートが発生して VM2 が動作する流れになります。

アラート発生時に NSG を外すには、アラートのアクションとして Automation を利用して、アラート発生時に Automation が作動して NSG を外す流れです。

サンプルとしてはこのような形でしょうか

$AzureContext = Connect-AzAccount -Identity

## Place the network interface configuration into a variable. ##
$nic = Get-AzNetworkInterface -Name <nicname> -ResourceGroupName <RGname>

## Remove the NSG to the NIC configuration. ##
$nic.NetworkSecurityGroup = $null

## Save the configuration to the network interface. ##
$nic | Set-AzNetworkInterface

NSG を外す NIC を指定し、その値を NULL とする = NSG を外すという方法です。 なので、あくまで NIC につけている NSG は、AppGW からのルーティングされない設定だけ追加（AppGW からの HTTP,HTTPS を受け付けない）しておき、その他セキュリティとして必要な NSG はサブネットの NSG で設定するようにしておきます。

デメリット

大きなデメリットとしては、どうしても振り分けに時間がかかってしまうところでしょうか。

何度か試していたところ、 Healthy Host Count が減ったことを検知して、正常な VM 側の NSG を外すまである程度バラつきはありますが 5 分～7,8 分かかるといったところでしょうか。

また、今回の例で出している VM1 が正常に戻った場合のオペレーションも考える必要があります。

例えば VM1 が正常に戻った場合、 VM1 側に AppGW からの通信が急に流れることになります。これが問題なければ OK ですが、例えば VM1 側で受け付けるべきポートは空いてるけどサービスが立ち上がってないなどがある場合は VM1 側への通信がエラーとなるので、サービスとして通信を受け入れる準備が出来てから通信を流したいですよね。

その場合は例えば VM1 に AppGW からの通信をブロックする NSG をつけるなど対策を考える必要があります。

どうしても標準でない機能を無理くり実装することによってダウンタイムが出るなど考慮点は増えてしまうので、なるべく標準機能だけで実装していきたいですね。

• Update Manager はパッチ更新管理に便利なサービスです
• パッチ適用のタイミングは様々なパターンがあるので注意

Azure Update Manager

Windows, Linux 双方とも大事な運用項目の1つとして挙げられるパッチ適用ですが、 Azure では Azure Update Manager（AUM）というサービスを利用して、「どの VM にどのパッチが適用されていないか」などを確認することが可能です。

AUM では、Resource Graph を用いて、VM や Arc 対応サーバーにある拡張機能からパッチの適用状況を引っ張ってきます。

こちらから図を引用しています。：Azure Update Manager について

パッチ適用状態の確認はオンデマンド/定期的に実行され、さらにパッチ適用もオンデマンド/定期的に実行可能です。

このうち、 パッチを適用する定期的なタイミング が様々存在しているので、そちらをまとめたいと思います。

パッチ適用タイミングの色々

大きく分けて 4 つあります。

Customer Managed Schedules

その名の通り、ユーザー側で「いつパッチを適用していいか」というタイミングを決めて、そのタイミングでパッチを適用するという方法です。

追加方法は簡単で、AUM 概要から「スケジュールの更新」から設定します。

リソースとして作成していきます。

• メンテナンススコープは「ゲスト(Azure VM、Arc 対応 VM/サーバー)にする
• 「再起動の設定」で、パッチ適用時に再起動してしまっていいか
• 「スケジュール」で、いつから/メンテナンスする期間/期間を決定

次にどの VM を対象のスケジュールでパッチを当てるかを設定します。

動的スコープを利用することで、今後増えるだろう VM も抜け漏れなく Update Manager でパッチ適用管理が可能になります。

リソースの種類（VM, Arc 対応）やどのリージョンに所属する VM なのかなどを決めましょう。

静的に割り当てる場合は、動的スコープはスルーして、次の「リソース」タブでどの VM かを全て決めます。

次に、どのパッチを適用するかを決定します。 KB ID からも決めることが可能です。

こういった形で、決められたスケジュールで決められた範囲のパッチを自動で適用できるようになります。

Azure マネージド

こちらを利用すると、以下に従って Azure 側が必要なパッチを適用します。

• [重大] または [セキュリティ] に分類されているパッチは、自動的にダウンロードされ、VM に適用されます。
• パッチは、IaaS VM のピーク外の時間帯 (VM のタイムゾーン) に適用されます。
• VMSS Flex の場合、パッチはすべての時間に適用されます。
• パッチ オーケストレーションが Azure によって管理され、可用性優先の原則に従ってパッチが適用されます。
• プラットフォーム正常性シグナルによって特定された仮想マシンの正常性は、パッチ適用の失敗を検出するために監視されます。
• アプリケーションの正常性はアプリケーション正常性拡張機能を使って監視できます。
• すべての VM サイズで機能します。

こちらからの引用です。 Azure VM での VM ゲストの自動パッチ適用

その中で「可用性優先の原則」と記載がありますが、パッチ適用によって可用性が下がらないように担保するようにパッチ適用するよ、というものです。 以下のような原則があります。（あくまで一部ですがわかりやすいものを記載）

• geo ペアリージョン（東日本と西日本みたいなペア）同時に更新しない
• 異なる AZ にある VM が同時に更新されない
• 共通の AS 内にある VM が同時に更新されない

また、Azure マネージドの場合はパッチオーケストレーションモードが AutomaticByPlatform である必要があります。

パッチオーケストレーションモードの確認方法

Windows 自動更新/イメージの既定値

こちらは非常に簡単で、OS 側の設定に任せる、という設定です。

• Windows 自動更新： Windows OS のみ
• イメージの既定値： Linux OS のみ

先ほどのパッチオーケストレーションモードの確認コマンドで確認した際には、以下のように出力されます。

• Windows 自動更新： AutomaticByOS
• イメージの既定値： ImageDefault

このパッチオーケストレーションモードは、特に他のモード設定をしていない場合に使用されます。

手動更新

こちらは、Windows OS のみ対応しており、自動更新を無効にします。このモードは、自身でパッチを適用したり、WSUS など別の管理サービスを利用する際に使います。

パッチオーケストレーションモードは、 Manual です。

パッチオーケストレーションモードの確認方法

仮想マシン作成時の「管理」タブにある「ゲスト OS の更新プログラム」で選択可能です。こちらの場合は Azure マネージドが設定されています。（Azure-orchestrated using Automatic guest patching）

また、以下のコマンドによって、対象 VM のパッチオーケストレーションモードを確認することが可能です。

 az vm get-instance-view --resource-group <rgname> --name <vmname>

Customer Managed Schedule の注意点

Customer Managed Schedule でのスケジュールでの適用は便利ですが、スケジュールを外したときに、 VM の自動パッチ適用（Azure-orchestrated）によって、 意図しないタイミングで パッチが適用されてしまう可能性があります。

これを回避するために、 ByPassPlatformSafetyChecksOnUserSchedule という設定があります。 この設定が true になっている場合、スケジュールが設定されていない場合、自動でパッチ適用されることがなくなりますので、これはぜひ設定しておきましょう。転ばぬ先の杖というやつですね。

パッチオーケストレーションを確認しておきましょう。

まとめ

Azure Update Manger を利用することで、パッチ管理が Azure Portal 上で可能になります。 ただ、 WSUS のように「WSUS 自体がパッチをダウンロードし、それをクライアントにばら撒く」ようなことはせずに、あくまでパッチの適用状況の確認と、パッチを適用する場合は VM がインターネット経由で取得しにいくという点には注意です。

• Azure のホストメトリックではディスク使用量/率は取得できない
• ディスク使用量はカスタムメトリックか Log Analytics にログとして送って取得しよう

VM のディスク使用量

ディスクの IOPS や Read/Write といったディスクのパフォーマンスについては取得できるのですが、ディスク使用量は現状 VM のホストメトリックからは取得することができません。

ちなみに Azure 基盤側から VM のディスクの使用量まで取れないことに起因しています。

監視としてディスクの使用量が少なくなったなどは実施することは多いと思いますので、取得するようにしていきましょう。

VM ディスクのパフォーマンスをどう考えたらいいのか？については以下が非常に参考になります。 Azure VM のディスクパフォーマンス状況の確認方法について

2024/4現在、ディスクの使用量（空き容量）を取得するには、ゲスト VM 側の情報を取得する必要があります。

カスタムメトリックを利用する

Azure 基盤側からみたメトリックではなく、ゲスト OS 側で取得できる「カスタムメトリック」を利用することで、ディスクの使用量を取得することが可能です。 別記事でカスタムメトリックを取得する方法を記載していますので、こちらを参考にしてカスタムメトリックを取得してください。

Azure VM のゲスト OS 上のパフォーマンスカウンターを気軽に取ってみる

Linux の場合は、「disk/used_percent」などで取得するといいでしょう。

Windows の場合は使用率ではなく、使用量なので「Free Space」を取得するといいかと。 （こちらの例では_totalで取得しており、全ディスクの空き容量を取得してしまっているので、それぞれのディスクを分けて取得したい場合は C,D,E など分けてカスタムメトリックを取得する必要があります）

Log Analytics を利用する

もう1つの方法は Log Analytics に対してパフォーマンスカウンターなどのメトリックを飛ばし、Log Analytics からクエリを抽出する方法です。 カスタムメトリックを取得する方法と同じように、DCR を利用することでパフォーマンスカウンターを Log Analytics にデータを送信することが可能です。

Azure VM のゲスト OS 上のパフォーマンスカウンターを気軽に取ってみる

ゲスト OS のパフォーマンスデータを Log Analytics に送信できたら、このような形でクエリを打ちこんでみましょう

# Linux の場合
Perf
 | where CounterName == "% Used Space"
 | where InstanceName == "/"
 | where Computer == "<VM Name>"
# Windows の場合
Perf
| where Computer == "<VM Name>"
| where CounterName == "% Free Space"

ディスクの使用量が取得できるはずです。

アラートを設定したい場合

Log Analytics の場合

CounterValue で使用率が 80% を超えたら、などになると思いますので、

CounterValue >= 80

といったものを追加してあげて、アラートを設定してあげるといいでしょう。

カスタムメトリックの場合

特に考えることなく、対象のカスタムメトリックからアラートを作成してあげましょう。

• データ収集ルールを使えば簡単に Azure VM 上のゲストメトリックが取得可能
• メトリックを Log Analytics Workspace に入れるまでもないときに活用

カスタムメトリックの取得

Azure VM では、仮想マシンの基盤から VM のメトリックを自動で取得してくれます。

ただ、あくまで基盤のメトリックなので VM 内部のメトリックは取得できません。カスタムメトリックを利用することで、ゲスト OS のメトリック（例えば Windows のパフォーマンスカウンター）を取得し、メトリックスエクスプローラーで確認が可能となります。

昔はもうちょっと面倒だったなーという記憶があるのですが、 Azure Monitor Agent がリリースされてデータ収集ルール（DCR）が使える現状では、 DCR を活用すれば簡単に取得することが可能です。

AMA を利用したカスタムメトリクスはプレビュー機能です。なお、2024年8月のドキュメント更新により、この機能は一般提供（GA）されないことが公式に発表されています。今後は Azure Monitor ワークスペースでの Prometheus メトリックや OpenTelemetry を使用した収集が推奨されています。詳細は Azure Monitor のカスタム メトリック (プレビュー) を参照してください。

DCR からゲスト OS のメトリックを取得する

Azure Monitor の DCR を活用することで、DCR で設定した収集するデータ、データを収集する VM、送信先を簡単に管理することが可能です。

どのデータを取得するか

どの VM から設定したデータを取得するか

データソースについては、デフォルトではベーシックなものが選ばれています。

カスタムにすることで、細かく取得が可能になります。

パフォーマンスカウンターは _total しかデフォルトでとれないので各プロセスのカウンターを取得する

カスタムで取得できるのは基本的にそれぞれのパフォーマンスで「_total」や「*」といった、全プロセスなどを足し合わせたものを取得するので、 例えば特定プロセスの CPU 使用率を取得したい場合はパフォーマンスカウンターを追加してあげる必要があります。

\Process(プロセス名)\ % Processor Time

取得したいプロセス名を全部いれる必要があるので手間ではありますが。。。

設定してあげることで、VM のメトリック名前空間に「仮想マシンのゲスト」が追加され、そこから DCR で設定したパフォーマンスカウンターのメトリックを確認することが可能です。

こちらの例では、Azure の拡張機能である Network Watcher Agent のスレッド数を取得しています。

Appendix

Azure Monitor のカスタム メトリック (プレビュー)

2024年8月追記: 上記公式ドキュメントにて「カスタム メトリックの送信」機能が一般提供されないことが明記されました。代替手段として以下が推奨されています。

• Azure Monitor ワークスペースでの Prometheus メトリック収集
• OpenTelemetry を使用したメトリック収集

• ANF を SMB 接続する際にいきなりエラーになります
• Microsoft Entra Domain Services の設定を行うユーザーにも注意

Architecture

アーキテクチャはこのような構成図になります。

ANF のテナントと Entra Domain Services のテナントを分けていますが、深い意味はありません。 簡単に解説するとこのようなアーキテクチャです。

• オンプレミスを模倣した左側の PC は、オンプレ AD に所属
• クライアント PC は SMB プロトコルで Entra DS に参加している ANF をマウント
• オンプレミス AD は Entra ID Connect 経由で Entra ID に同期
• Entra ID に同期されたユーザーは Entra Domain Services に同期される

それぞれのサービスについては以下リンクを参照してください。

Microsoft Entra Domain Services

Azure NetApp Files

ハマったこと

Entra Domain Service は簡単にいうと「マネージドの Active Directory Domain Services」ですが、 マネージドなので ADDS とは異なる部分があります。 エンタープライズ管理者の特権がない、スキーマの拡張機能がないなど ADDS とは違う部分があるので、利用方法には注意が必要です。

比較についてはこちらをご確認ください。

セルフマネージド Active Directory Domain Services、Microsoft Entra ID、マネージド Microsoft Entra Domain Services を比較する

ANF を SMB で利用したい場合には、ANF を ADDS に所属する必要があります。

Azure NetApp Files の Active Directory 接続の作成と管理

その AD 接続を行った際に、Entra Domain Services ならではのハマったことがあったので、そちらを下記にいくつか記載します。

Entra Domain Service の ADDS/DNS を見たい場合は AAD DC Administrators に所属しているユーザーでログイン

そもそも ANF をマウントする前に、Entra Domain Services の ADDS/DNS 機能を設定するには、Azure ポータルなどからは出来ず、別途 Entra Domain Services に接続できる VM などを構築する必要があります。

その際、対象の VM にログインするユーザーは AAD DC Administrators に所属している必要があります。

Entra ID でユーザーを作成してあげるか、ADDS で同期されてきた Entra ID に出来たユーザーに対して、 AAD DC Administrators に所属させてあげましょう。

対象のユーザーで VM に対してログインし、 VM に ADDS のツールや DNS のツールをインストールして設定してあげましょう。 ちなみに DNS ツールを利用する際は、Entra ID に割り当てられた IP アドレスではなく、FQDN を利用しないといけないことに注意です。

PTR レコードを Entra DS 環境の DNS に入れる

ADDS 接続を作成し、SMB ボリュームを作成する際、以下のエラーが発生しました。

>Failed to create the Active Directory machine account \"SMB-ANF-VOL. Reason: LDAP Error: Local error occurred Details: Error: Machine account creation procedure failed. [nnn] Loaded the preliminary configuration. [nnn] Successfully connected to ip 10.x.x.x, port 88 using TCP [nnn] Successfully connected to ip 10.x.x.x, port 389 using [nnn] Entry for host-address: 10.x.x.x not found in the current source: FILES. Ignoring and trying next available source [nnn] Source: DNS unavailable. Entry for host-address:10.x.x.x found in any of the available sources\n*[nnn] FAILURE: Unable to SASL bind to LDAP server using GSSAPI: local error [nnn] Additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address) [nnn] Unable to connect to LDAP (Active Directory) service on contoso.com (Error: Local error) [nnn] Unable to make a connection (LDAP (Active Directory):contosa.com, result: 7643.

これは、ANF を AD 接続する際は、 PTR レコードが必要なために発生するエラーです。 あくまで検証環境なので、ADDS 環境はユーザーを作成したりするぐらいで、あまりいじっていなかったのが1つ原因かもしれません。 このエラーが発生した際は、 Entra Domain Services の DNS に AD サーバーの PTR レコードを登録してあげましょう。

OU の指定が AADDC Computers

AD 接続設定時、「組織単位のパス」を入れます。 これは ANF 自体をどの OU に所属させるかという設定になります。 特に値を設定しない場合は CN=Computers を利用しますが、 Entra DS の場合は OU=AADDC Computers である必要があります。

エラーとしてはこんな感じに出てしまいます。

{
 "code": "DeploymentFailed",
 "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",
 "details": [
  {
   "code": "InternalServerError",
   "message": "Error when creating - Failed to create the Active Directory machine account \"SMBTESTAD-D9A2\". Reason: SecD Error: ou not found Details: Error: Machine account creation procedure failed\n [ 561] Loaded the preliminary configuration.\n [ 665] Successfully connected to ip 10.x.x.x, port 88 using TCP\n [ 1039] Successfully connected to ip 10.x.x.x, port 389 using TCP\n**[ 1147] FAILURE: Specifed OU 'OU=AADDC Com' does not exist in\n** contoso.com\n. "
  }
 ]
}

AES 暗号化がされていない

Entra DS では、Kerberos RC4 暗号化が利用できますが、既定では無効化されています。 特に設定をしていない場合、ANF の AD 接続時にAES 暗号化にチェックを入れておく必要があります。 以下のようなエラーが発生します。

Failed to create the Active Directory machine account \"SMB-ANF-VOL\". Reason: Kerberos Error: KDC has no support for encryption type Details: Error: Machine account creation procedure failed [nnn]Loaded the preliminary configuration. [nnn]Successfully connected to ip 10.x.x.x, port 88 using TCP [nnn]FAILURE: Could not authenticate as 'contosa.com': KDC has no support for encryption type (KRB5KDC_ERR_ETYPE_NOSUPP)

まとめ

今まで紹介したことが特に設定していない Entra DS に対して ANF の AD 接続を行う際にハマったことです。

上記に関しては、 ANF 側で AD 接続を行ったときには出ないエラーで、ボリューム作成時に SMB プロトコルで接続する設定を入れたときに発生するエラーなので、すぐには気付かず、 ボリューム作成時に「あれ？？」となるエラーになります。 なので、事前に上記のようなエラーとなりそうなものに対処してからボリューム接続に臨みましょう。

Appendix

Azure NetApp Files のボリュームに関するエラーをトラブルシューティングする

• 同じ Virtual WAN 内の仮想ハブは暗黙で Peering が張られて、お互いの仮想ハブに接続されているネットワークは相互に通信が可能
• 仮想ハブについては VNet を接続できるが、違う仮想ハブであれば同じ IP Range の VNet を接続できる
• 接続できてしまうが、対象の VNet 同士は通信できないので注意
• 同一仮想ハブ内であれば IP Range が被っていると接続できないとエラーが出るのに。。。

Virtual WAN

Virtual WAN を活用することで、様々な場所から Azure への接続を 1 つの Hub にまとめることができます。 以下のようなものを、1 つの Virtual WAN にまとめてしまい、相互に接続することが出来るサービスです。

• S2S VPN
• P2S VPN
• ExpressRoute
• VNet

公式ドキュメントからの抜粋ですが、以下のような形になります。

大規模に様々な接続形態がある場合に使用されることが多い Virtual WAN ですが、 その中心にいるものが仮想ハブと言われるものです。

複数の仮想ハブ

仮想ハブは同一リージョン内に複数作成することも可能で、仮想ハブ同士は特に設定を意識することなくピアリングされ推移的な接続がなされます。

ですので、オンプレミス - 仮想ハブA - 仮想ハブB - VNet C といった接続を設定なしで通信してくれるようになります。

VNet の追加は非常に簡単で、Virtual WAN の設定より「接続の追加」から VNet を追加するだけです。

VNet を追加すると、 VNet 側には自動で VNet Peering が追加されます。

もちろん 同じ仮想ハブ内で複数の VNet やオンプレミスのネットワークを接続する際、 VNet の IP Range が被っているとエラーがでます。

VWAN で仮想ハブが複数存在する場合の IP Range には注意

そりゃそうですが、VNet 同士の IP Range が重複している場合、お互いに通信できることはできません。 IP Range は管理されていることが多いので、重複が発生することはほぼないと思います。 しかし、例えば Virtual WAN はとある部署が管理していて、そこに接続するためのシステムが別部署で管理している場合に　IP Range が被ってしまうことが起こり得てしまうでしょう。

そんな時に何も考えずに 仮想ハブに VNet を繋いでいくと、こんな構成が取れてしまいます。

この場合、仮想ハブ A と仮想ハブ B に同じ 10.1.0.0/16 の IP Range を持つ VNet C と VNet D がありますが、 2 つの VNet 間はもちろん通信できません。

テストしてみると、VNet C と VNet D 以外の VNet （例えば 192.168.0.0/16）以外は通信可能なので、 なんでもかんでもとりあえずえいやで繋いでしまう構成はよくないってことがわかりますね。

Appendix

Azure VWAN のテストをしたい場合は以下のテンプレートを使うのがいいでしょう。

Azure Virtual WAN (vWAN) Multi-Hub Deployment