Azure Virtual Desktop バックアップ・リストア完全ガイド（A・C・D方式）について、WordPress記事形式で表示いたします。

---

Azure Virtual Desktop バックアップ・リストア完全ガイド

はじめに

本記事では、Azure Virtual Desktop（AVD）環境で実施している3つの主要なバックアップ方式について、具体的な手順を詳しく解説します。

• A. Azure Backup：セッションホストVMの定期バックアップ
• C. スナップショット方式：緊急時の即時バックアップ
• D. FSLogix プロファイルコンテナ：ユーザープロファイルデータの保護

---

A. Azure Backup（仮想マシンバックアップ）

概要

Azure Backupは、AVDセッションホストVMの定期的なバックアップを自動実行するマネージドサービスです。Recovery Services コンテナーを使用して、スケジュールベースのバックアップとポイントインタイム復旧を提供します。

特徴

• 自動スケジュール実行（4時間〜日次間隔）
• 最大99年の長期保持
• VM構成情報も含めた完全バックアップ
• ファイルレベルでの復旧も可能
• 地理的冗長性（GRS/LRS）

---

A-1. Azure Backupの設定手順

ステップ1：Recovery Services コンテナーの作成

手順：

1. Azure Portalにログイン
2. 検索バーで「Recovery Services コンテナー」を検索
3. 「+ 作成」をクリック
4. 以下の情報を入力：
   • サブスクリプション：対象のサブスクリプションを選択
   • リソースグループ：既存を選択または新規作成
   • コンテナー名：例）RSV-AVD-Backup-JapanEast
   • リージョン：AVDセッションホストと同じリージョンを選択
5. 「確認および作成」→「作成」をクリック

所要時間： 約2〜3分

ポイント：

• コンテナーは必ずバックアップ対象VMと同じリージョンに作成
• 命名規則を統一すると管理が容易

---

ステップ2：バックアップポリシーの作成

手順：

1. 作成したRecovery Services コンテナーを開く
2. 左メニューから「バックアップポリシー」を選択
3. 「+ 追加」をクリック
4. ポリシー設定：
   • ポリシータイプ：Azure Virtual Machine
   • ポリシーサブタイプを選択：

Standard ポリシー（標準）

バックアップ頻度：日次または週次
バックアップ時刻：例）午前2:00（業務時間外推奨）
即時復旧の保持期間：1〜5日
タイムゾーン：(UTC+09:00) 大阪、札幌、東京

保持期間設定：
- 日次バックアップ：7〜180日（例：30日）
- 週次バックアップ：4〜520週（例：12週）
- 月次バックアップ：6〜120ヶ月（例：12ヶ月）
- 年次バックアップ：1〜10年（例：3年）

Enhanced ポリシー（推奨）

バックアップ頻度：4時間、6時間、8時間、12時間から選択
例）12時間ごと（0:00と12:00）
即時復旧の保持期間：1〜30日（例：7日）
タイムゾーン：(UTC+09:00) 大阪、札幌、東京

保持期間設定：
- 毎時バックアップ：最大150日
- 日次バックアップ：最大9,999日
- 週次バックアップ：最大5,163週
- 月次バックアップ：最大1,188ヶ月
- 年次バックアップ：最大99年

5. ポリシー名を入力：例）AVD-Enhanced-12H-Policy
6. 「作成」をクリック

推奨設定（本番環境）：

ポリシーサブタイプ：Enhanced
バックアップ頻度：12時間ごと
即時復旧：7日間
日次保持：30日
週次保持：12週
月次保持：12ヶ月
年次保持：3年

---

ステップ3：セッションホストVMのバックアップ有効化

方法A：個別VM設定

手順：

1. Azure Portalでバックアップ対象のVMを開く
2. 左メニューから「バックアップ」を選択
3. 以下を設定：
   • Recovery Services コンテナー：ステップ1で作成したコンテナーを選択
   • バックアップポリシー：ステップ2で作成したポリシーを選択
4. 「バックアップの有効化」をクリック

所要時間： 約5分

---

方法B：一括設定（推奨）

手順：

1. Recovery Services コンテナーを開く
2. 左メニューから「バックアップ」を選択
3. 以下を設定：
   • バックアップの対象：Azure Virtual Machine
   • 仮想マシンの場所：セッションホストのリージョン
4. 「バックアップ」ボタンをクリック
5. バックアップポリシーを選択
6. 「仮想マシンの追加」をクリック
7. バックアップ対象のVMを複数選択： ☑ avd-sessionhost-01☑ avd-sessionhost-02☑ avd-sessionhost-03☑ avd-sessionhost-04
8. 「OK」をクリック
9. 「バックアップの有効化」をクリック

所要時間： 約10分（対象VM数による）

ポイント：

• ホストプール内の全セッションホストを一度に設定可能
• 同じポリシーを適用することで管理が容易

---

ステップ4：初回バックアップの実行確認

手順：

1. Recovery Services コンテナーを開く
2. 左メニューから「バックアップ項目」を選択
3. 「Azure Virtual Machine」をクリック
4. バックアップが有効化されたVMの一覧を確認
5. 各VMの「バックアップ状態」を確認：
   • 警告：初回バックアップ実行中
   • 正常：バックアップ完了

初回バックアップ所要時間：

• スナップショット作成：5〜15分
• Vaultへのデータ転送：1〜6時間（VM容量による）

---

ステップ5：手動バックアップの実行（オプション）

用途： 重要な変更作業前に追加のバックアップポイントを作成

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure Virtual Machine」を選択
3. 対象のVMをクリック
4. 「今すぐバックアップ」をクリック
5. 復旧ポイントの保持期間を指定：
   • デフォルト：ポリシーに従う
   • カスタム：1〜99年の範囲で指定
6. 「OK」をクリック

所要時間： 5〜15分（スナップショット作成）

---

A-2. Azure Backupからのリストア手順

リストアオプションの選択

Azure Backupでは3つのリストア方式があります：

オプション1：新しいVMの作成

• 完全に新しいVMとして復元
• 元のVMは影響を受けない
• 新しいVM名、IP、リソースIDが付与される

オプション2：ディスクの復元

• ディスクのみを復元
• 手動でVMに接続する必要がある
• カスタマイズが必要な場合に有用

オプション3：既存のVMの置換

• 既存VMのディスクを入れ替え
• VM名、IP、設定は維持
• ダウンタイムが最小

---

リストア手順：新しいVMの作成

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure Virtual Machine」を選択
3. リストア対象のVMをクリック
4. 「VMの復元」をクリック
5. 復元ポイントを選択： 復元ポイント一覧：├─ 2025/01/12 12:00:00 (スナップショット)├─ 2025/01/12 00:00:00 (スナップショット)├─ 2025/01/11 12:00:00 (コンテナー)└─ 2025/01/11 00:00:00 (コンテナー)
6. 「復元の構成」で以下を設定：

復元タイプ：仮想マシンの作成

VM設定：
- 仮想マシン名：avd-sessionhost-01-restored
- リソースグループ：既存を選択または新規作成
- 仮想ネットワーク：既存のAVD VNetを選択
- サブネット：SessionHost-Subnet を選択
- ストレージアカウント：診断用ストレージを選択

詳細オプション：
☑ 可用性セットを復元する（該当する場合）
☑ 拡張機能を復元する
☑ タグを復元する

7. 「確認および復元」をクリック
8. 設定を最終確認
9. 「復元」をクリック

所要時間： 15〜60分

---

リストア手順：既存のVMの置換

注意： この操作は既存VMのディスクを置き換えます。実行前に必ず確認してください。

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure Virtual Machine」を選択
3. リストア対象のVMをクリック
4. 「VMの復元」をクリック
5. 復元ポイントを選択
6. 「復元の構成」で以下を設定：

復元タイプ：ディスクの交換

設定：
- ステージングの場所：一時ストレージアカウントを選択
  （復元処理中に使用される一時領域）

7. 「確認および復元」をクリック
8. 警告メッセージを確認： 警告：この操作により、既存のディスクが置き換えられます。VMは自動的に再起動されます。
9. 「復元」をクリック

処理内容：

1. VMを停止
2. 古いディスクをデタッチ
3. 復元したディスクをアタッチ
4. VMを再起動

所要時間： 20〜40分

ダウンタイム： 約10〜20分

---

リストア手順：ファイルレベルの回復

用途： VM全体ではなく、特定のファイルのみを復元したい場合

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure Virtual Machine」を選択
3. 対象のVMをクリック
4. 「ファイルの回復」をクリック
5. 復元ポイントを選択
6. 「実行可能ファイルのダウンロード」をクリック
7. スクリプトファイル（.exe または .py）をダウンロード
8. スクリプトを実行する環境で以下を実施：

Windows環境：

# ダウンロードしたスクリプトを実行
.\IaaSVMILRExec.exe

# パスワードを入力（Azure Portalに表示されています）
Enter password: ****************

# ディスクがマウントされます
Volume mounted to: E:\

マウント後の操作：

9. エクスプローラーでマウントされたドライブを開く
10. 必要なファイル/フォルダをコピー
11. コピー完了後、スクリプトを終了
12. Azure Portalで「ディスクのマウント解除」をクリック

制限事項：

• マウント後12時間で自動的にアンマウント
• 複数の復元ポイントを同時にマウント不可

---

リストア監視とトラブルシューティング

監視方法：

1. Recovery Services コンテナーを開く
2. 「バックアップジョブ」を選択
3. 進行中のリストアジョブを確認：

ジョブ表示例：
┌─────────────────────────────────────────┐
│ 復元 - avd-sessionhost-01               │
│ 状態：進行中                            │
│ 進行状況：45%                           │
│ 開始時刻：2025/01/12 14:30:00          │
│ 推定残り時間：15分                      │
└─────────────────────────────────────────┘

よくあるエラーと対処法：

エラー	原因	対処法
UserErrorVmProvisioningStateFailed	ターゲットVNetへのアクセス権限不足	Recovery Services コンテナーのマネージドIDに権限を付与
UserErrorDiskQuotaExceeded	ディスククォータ超過	サブスクリプションのクォータ増加を申請
UserErrorRestoreFailedDueToInsufficientPermissions	リソースグループへのアクセス権限不足	共同作成者ロールを付与

---

C. スナップショット方式

概要

スナップショット方式は、重要な変更作業前に即座にバックアップポイントを作成する補助的なバックアップ手段です。Azure Backupと比べて軽量で高速ですが、手動管理が必要です。

特徴

• 作成速度：数秒〜数分
• 即時復旧：スナップショットから直接ディスク作成
• 用途：パッチ適用前、アップグレード前などの一時的な保護
• 保持期間：手動管理（作業完了後に削除推奨）

スナップショットの種類

標準スナップショット

• フルスナップショット
• 初回バックアップとして使用

増分スナップショット（推奨）

• 変更分のみを保存
• コスト効率が良い
• 2回目以降のスナップショットで自動適用

---

C-1. 手動スナップショットの作成手順

ステップ1：単一ディスクのスナップショット作成

手順：

1. Azure Portalで対象のVMを開く
2. 左メニューから「ディスク」を選択
3. スナップショットを作成したいディスクをクリック： 例：- OSディスク：avd-sessionhost-01_OsDisk- データディスク：avd-sessionhost-01_DataDisk_01
4. ディスクの画面で「スナップショットの作成」をクリック
5. スナップショット設定：

基本情報：
- サブスクリプション：（自動入力）
- リソースグループ：VM と同じグループを選択
- スナップショット名：命名規則に従って入力
  例：snap-avd-sh01-os-20250112-pre-patch
- リージョン：（自動入力 - ソースディスクと同じ）

スナップショットタイプ：
◉ 増分（推奨）
○ 完全

ストレージタイプ：
◉ Standard HDD（コスト重視）
○ Premium SSD（パフォーマンス重視）

タグ：
- Purpose: Pre-Change-Backup
- CreatedDate: 2025-01-12
- DeleteAfter: 2025-01-15

6. 「確認および作成」をクリック
7. 「作成」をクリック

所要時間： 30秒〜2分

---

ステップ2：複数ディスクの一括スナップショット作成

注意： VMに複数のディスク（OS + データディスク）がある場合、整合性のため同時にスナップショットを作成する必要があります。

PowerShell を使用した方法：

# Azure にログイン
Connect-AzAccount

# 変数設定
$resourceGroupName = "RG-AVD-SessionHosts"
$vmName = "avd-sessionhost-01"
$snapshotPrefix = "snap-avd-sh01"
$timestamp = Get-Date -Format "yyyyMMdd-HHmm"

# VM情報を取得
$vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName

# OSディスクのスナップショット作成
$osDisk = Get-AzDisk -ResourceGroupName $resourceGroupName -DiskName $vm.StorageProfile.OsDisk.Name
$snapshotConfig = New-AzSnapshotConfig `
    -SourceUri $osDisk.Id `
    -Location $vm.Location `
    -CreateOption Copy `
    -Incremental

$snapshotName = "$snapshotPrefix-os-$timestamp"
New-AzSnapshot `
    -Snapshot $snapshotConfig `
    -SnapshotName $snapshotName `
    -ResourceGroupName $resourceGroupName

Write-Host "OSディスクのスナップショット作成完了: $snapshotName"

# データディスクのスナップショット作成
foreach ($dataDisk in $vm.StorageProfile.DataDisks) {
    $disk = Get-AzDisk -ResourceGroupName $resourceGroupName -DiskName $dataDisk.Name
    $snapshotConfig = New-AzSnapshotConfig `
        -SourceUri $disk.Id `
        -Location $vm.Location `
        -CreateOption Copy `
        -Incremental
    
    $snapshotName = "$snapshotPrefix-data$($dataDisk.Lun)-$timestamp"
    New-AzSnapshot `
        -Snapshot $snapshotConfig `
        -SnapshotName $snapshotName `
        -ResourceGroupName $resourceGroupName
    
    Write-Host "データディスクのスナップショット作成完了: $snapshotName"
}

Write-Host "すべてのスナップショット作成が完了しました"

実行方法：

1. Azure Cloud Shell（PowerShell）を開く
2. 上記スクリプトを貼り付け
3. 変数を環境に合わせて修正
4. 実行

---

ステップ3：スナップショットの確認

手順：

1. Azure Portalで「スナップショット」を検索
2. リソースグループでフィルタリング
3. 作成されたスナップショットを確認：

スナップショット一覧：
┌──────────────────────────────────────────────┐
│ 名前                              │ サイズ   │
├──────────────────────────────────────────────┤
│ snap-avd-sh01-os-20250112-pre-patch  │ 127GB │
│ snap-avd-sh01-data0-20250112-pre-patch│ 512GB │
│ 状態：成功                                   │
└──────────────────────────────────────────────┘

---

C-2. スナップショットからのリストア手順

リストア方法の選択

スナップショットからのリストアは2段階のプロセスです：

1. スナップショットからディスクを作成
2. 作成したディスクを使用してVMを構築

---

ステップ1：スナップショットからディスクを作成

手順：

1. Azure Portalで「スナップショット」を開く
2. リストア元のスナップショットを選択
3. 「ディスクの作成」をクリック
4. ディスク設定：

基本情報：
- サブスクリプション：（自動入力）
- リソースグループ：元のVMと同じグループ
- ディスク名：restored-avd-sh01-os-20250112
- リージョン：（自動入力）

可用性オプション：
- 可用性ゾーン：なし（元の構成に合わせる）

ソース：
- ソーススナップショット：（自動入力）

サイズ：
- サイズ変更が必要な場合は「サイズの変更」をクリック

パフォーマンス：
◉ Premium SSD（推奨 - AVD用）
○ Standard SSD
○ Standard HDD

暗号化：
- 暗号化タイプ：既定（プラットフォーム管理キー）

5. 「確認および作成」をクリック
6. 「作成」をクリック

所要時間： 5〜15分（ディスクサイズによる）

---

ステップ2：新しいVMの作成（新規VM作成の場合）

手順：

1. Azure Portalで「仮想マシン」→「作成」を選択
2. 基本情報を入力：

プロジェクトの詳細：
- サブスクリプション：対象のサブスクリプション
- リソースグループ：元のVMと同じグループ

インスタンスの詳細：
- 仮想マシン名：avd-sessionhost-01-restored
- リージョン：元のVMと同じリージョン
- 可用性オプション：可用性ゾーンなし
- イメージ：既存のディスクを使用（次のステップで設定）
- VMサイズ：元のVMと同じサイズを選択

3. 「ディスク」タブに移動
4. OSディスク設定：

OSディスクのオプション：
- OSディスクタイプ：既存のマネージドディスクを接続
- マネージドディスクの選択：
  → ステップ1で作成したディスクを選択

5. データディスクがある場合：
   • 「新しいディスクの接続」をクリック
   • 「既存のディスク」を選択
   • 復元したデータディスクを選択
6. 「ネットワーク」タブに移動：

ネットワークインターフェイス：
- 仮想ネットワーク：元のVMと同じVNet
- サブネット：SessionHost-Subnet
- パブリックIP：なし（AVDでは通常不要）
- NICネットワークセキュリティグループ：基本
- パブリック受信ポート：なし

7. 「管理」タブで設定確認：

監視：
☑ ブート診断を有効にする
☑ ゲストOSの診断を有効にする（オプション）

ID：
- システム割り当てマネージドID：元の構成に合わせる

8. 「タグ」タブでタグを追加（元のVMと同じタグ推奨）
9. 「確認および作成」→「作成」をクリック

所要時間： 10〜20分

---

ステップ3：既存VMのディスク交換（既存VM修復の場合）

手順：

1. Azure Portalで対象のVMを開く
2. VMを停止：
   • 「停止」をクリック
   • 停止完了を待つ（約3〜5分）
3. 「ディスク」メニューを開く
4. OSディスクの交換：
   • 「OSディスクの交換」をクリック
   • ステップ1で作成したディスクを選択
   • 「OK」をクリック
5. データディスクの交換（該当する場合）：
   • 古いデータディスクを「デタッチ」
   • 「データディスクの追加」をクリック
   • 復元したデータディスクを選択
   • LUN番号を元の構成と同じに設定
6. VMを起動：
   • 「開始」をクリック
   • 起動完了を待つ（約3〜5分）
7. VM接続確認：
   • RDP接続またはAVDクライアントで接続
   • 正常に動作することを確認

ダウンタイム： 約10〜15分

---

ステップ4：リストア後の確認作業

チェックリスト：

□ VMが正常に起動している
□ ネットワーク接続が正常
□ AVDホストプールに登録されている
□ ユーザーがログインできる
□ FSLogixプロファイルが正常にマウントされる
□ アプリケーションが正常に動作する
□ 必要な拡張機能がインストールされている
□ ドメイン参加状態が正常

AVD固有の確認：

1. Azure Portalで「Azure Virtual Desktop」を開く
2. 対象のホストプールを選択
3. 「セッションホスト」タブを確認
4. 復元したVMのステータスを確認： ステータス：使用可能セッション数：接続可能

---

スナップショットの削除（作業完了後）

重要： 不要なスナップショットは削除してコストを削減

手順：

1. Azure Portalで「スナップショット」を開く
2. 削除対象のスナップショットを選択
3. 「削除」をクリック
4. 確認メッセージで「はい」をクリック

一括削除（PowerShell）：

# 特定のタグを持つスナップショットを削除
$resourceGroupName = "RG-AVD-SessionHosts"
$tagName = "DeleteAfter"
$today = Get-Date

# スナップショット一覧を取得
$snapshots = Get-AzSnapshot -ResourceGroupName $resourceGroupName | 
    Where-Object { $_.Tags.Keys -contains $tagName }

foreach ($snapshot in $snapshots) {
    $deleteDate = [DateTime]::Parse($snapshot.Tags[$tagName])
    
    if ($today -ge $deleteDate) {
        Write-Host "削除中: $($snapshot.Name)"
        Remove-AzSnapshot `
            -ResourceGroupName $resourceGroupName `
            -SnapshotName $snapshot.Name `
            -Force
        Write-Host "削除完了: $($snapshot.Name)"
    }
}

---

D. FSLogix プロファイルコンテナの保護

概要

FSLogixプロファイルコンテナは、ユーザープロファイル（デスクトップ設定、アプリケーション設定、ドキュメントなど）を集中管理するための仕組みです。セッションホストVMとは独立して保護する必要があります。

FSLogixの構成

ユーザーログイン
    ↓
FSLogixエージェント
    ↓
プロファイルコンテナ（VHD/VHDX）をマウント
    ↓
Azure Files または Azure NetApp Files

ストレージの種類：

• Azure Files：標準的な選択肢、コスト効率が良い
• Azure NetApp Files：高パフォーマンスが必要な場合

---

D-1. Azure Files バックアップの設定手順

ステップ1：現在のFSLogix構成の確認

手順：

1. AVDセッションホストにRDP接続
2. レジストリエディタ（regedit）を開く
3. 以下のパスに移動： HKLM\SOFTWARE\FSLogix\Profiles
4. 重要な設定値を確認： VHDLocations: \\storageaccount.file.core.windows.net\fslogix-profiles Enabled: 1
5. Azure Portalで対応するストレージアカウントとファイル共有を確認

---

ステップ2：Recovery Services コンテナーの準備

注意： Azure Files バックアップは、VM バックアップと同じRecovery Services コンテナーを使用可能ですが、別途作成することも可能です。

既存コンテナーを使用する場合：

• A. Azure Backupで作成済みのコンテナーをそのまま使用

新規作成する場合：

1. 「Recovery Services コンテナー」を作成
2. 名前例：RSV-AVD-FSLogix-JapanEast
3. FSLogixストレージと同じリージョンに作成

---

ステップ3：Azure Files バックアップポリシーの作成

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップポリシー」を選択
3. 「+ 追加」をクリック
4. ポリシータイプ：Azure ファイル共有を選択
5. ポリシー設定：

バックアップスケジュール：
- バックアップ頻度：日次（推奨）
- バックアップ時刻：午前 3:00（ユーザーログイン少ない時間）
- タイムゾーン：(UTC+09:00) 大阪、札幌、東京

保持期間：
- 日次バックアップ：30日（推奨：VMより長く）
- 週次バックアップ：12週
- 月次バックアップ：12ヶ月
- 年次バックアップ：5年（コンプライアンス要件に応じて）

6. ポリシー名：FSLogix-Profiles-Daily-Policy
7. 「作成」をクリック

推奨設定（本番環境）：

日次：30日
週次：12週
月次：12ヶ月
年次：5年

※ VMバックアップより長い保持期間を設定することで、
  VMを削除してもユーザープロファイルは保護される

---

ステップ4：ファイル共有バックアップの有効化

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ」を選択
3. 以下を設定：
   • バックアップの対象：Azure ファイル共有
   • ストレージアカウント：FSLogix プロファイルが保存されているストレージアカウントを選択
4. 「選択」をクリック
5. バックアップ対象のファイル共有を選択： ☑ fslogix-profiles ☑ fslogix-odfc（Office Containerを使用している場合）
6. バックアップポリシーを選択：
   • ステップ3で作成した FSLogix-Profiles-Daily-Policy を選択
7. 「バックアップの有効化」をクリック

所要時間： 約5分

---

ステップ5：初回バックアップの実行と確認

手動実行：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure ファイル共有」を選択
3. 対象のファイル共有をクリック
4. 「今すぐバックアップ」をクリック
5. 保持期間を指定（デフォルト：ポリシーに従う）
6. 「OK」をクリック

バックアップ確認：

1. 「バックアップジョブ」タブを開く
2. ジョブステータスを確認： ジョブ名：fslogix-profiles のバックアップ状態：完了期間：約15〜45分（データ量による）

---

D-2. FSLogix プロファイルのリストア手順

リストアシナリオ

FSLogixプロファイルのリストアが必要になる状況：

1. 個別ユーザープロファイルの破損
   • 特定ユーザーのプロファイルのみ復元
2. ファイル共有全体の障害
   • ファイル共有全体を復元
3. 誤削除からの回復
   • 削除されたプロファイルコンテナを復元

---

リストア方法1：個別プロファイルコンテナの復元

用途： 特定ユーザーのプロファイルのみを復元したい場合

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure ファイル共有」を選択
3. 対象のファイル共有（fslogix-profiles）をクリック
4. 「ファイルの回復」をクリック
5. 復元ポイントを選択： 復元ポイント一覧： ├─ 2025/01/12 03:00:00（今朝のバックアップ） ├─ 2025/01/11 03:00:00（昨日のバックアップ） ├─ 2025/01/10 03:00:00 └─ 2025/01/09 03:00:00
6. 回復の設定：

回復場所：
◉ 元の場所
○ 別の場所

元の場所を選択した場合：
- ファイルが既存する場合：
  ◉ スキップ（既存ファイルを保持）
  ○ 置換（バックアップからの復元を優先）

回復するアイテム：
- 「ファイルの参照」をクリック
- ユーザーのプロファイルコンテナを選択：
  例：Profile_user01.vhdx

7. 「復元」をクリック

所要時間： 5〜30分（ファイルサイズによる）

---

リストア方法2：ファイル共有全体の復元

用途： ファイル共有全体が破損または削除された場合

手順：

1. Recovery Services コンテナーを開く
2. 「バックアップ項目」→「Azure ファイル共有」を選択
3. 対象のファイル共有をクリック
4. 「ファイル共有の復元」をクリック
5. 復元ポイントを選択
6. 復元場所の設定：

復元場所：
◉ 元の場所（既存の共有に復元）
○ 別の場所（新しいファイル共有に復元）

元の場所を選択した場合の動作：
- ファイル共有全体が復元ポイントの状態に戻る
- 復元後に作成されたファイルは失われる

別の場所を選択した場合：
- ストレージアカウント：同じまたは別のストレージアカウント
- ファイル共有名：新しい名前を指定
  例：fslogix-profiles-restored

7. 「復元」をクリック

所要時間： 30分〜数時間（データ量による）

---

リストア方法3：Azure Files スナップショットからの復元

注意： Azure Files は自動的にスナップショットを作成します（Azure Backupが有効な場合）

手順：

1. Azure Portalでストレージアカウントを開く
2. 「ファイル共有」を選択
3. 対象のファイル共有（fslogix-profiles）をクリック
4. 「スナップショット」タブを開く
5. 利用可能なスナップショット一覧を確認： スナップショット一覧： ├─ 2025/01/12 03:00:15 ├─ 2025/01/11 03:00:10 ├─ 2025/01/10 03:00:08 └─ 2025/01/09 03:00:12
6. 復元したいスナップショットをクリック
7. スナップショット内のファイルを参照
8. 復元方法を選択：

方法A：個別ファイルのダウンロード

1. 対象ファイルを選択（例：Profile_user01.vhdx）
2. 「ダウンロード」をクリック
3. ダウンロード後、手動で元の場所にアップロード

方法B：ファイル共有全体の復元

1. スナップショット画面で「復元」をクリック
2. 復元オプション：
   ◉ 元のファイル共有を上書き
   ○ 新しいファイル共有に復元
3. 「OK」をクリック

所要時間： 数分〜30分

---

ステップ：リストア後の確認作業

ユーザープロファイルの動作確認：

1. 対象ユーザーでAVDにログイン
2. プロファイルが正常にマウントされることを確認： C:\Users\<username> が正常にアクセス可能
3. イベントビューアーで確認： アプリケーションとサービスログ → Microsoft → FSLogix → Profiles → Operational 確認項目： - イベントID 2：プロファイルの接続成功 - エラーがないこと
4. ユーザー設定が復元されていることを確認：
   • デスクトップアイコン
   • アプリケーション設定
   • ブラウザのブックマーク
   • Officeの設定

---

D-3. FSLogix Cloud Cache による冗長化（高度な設定）

概要

Cloud Cacheは、複数のストレージロケーションにプロファイルコンテナを同時に書き込むFSLogixの機能です。ディザスタリカバリに有効ですが、設定が複雑です。

構成例

プライマリリージョン（東日本）：
- ストレージアカウント：stfslogixjpe.file.core.windows.net
- ファイル共有：fslogix-profiles

セカンダリリージョン（西日本）：
- ストレージアカウント：stfslogixjpw.file.core.windows.net
- ファイル共有：fslogix-profiles

---

Cloud Cache の設定手順

注意： Cloud Cacheは既存のプロファイルコンテナ構成と互換性がありません。新規展開または移行作業が必要です。

ステップ1：セカンダリストレージの準備

1. セカンダリリージョンでストレージアカウントを作成
2. ファイル共有を作成（プライマリと同じ名前推奨）
3. Active Directory認証を設定（プライマリと同じ構成）

---

ステップ2：レジストリ設定の変更

セッションホストの以下のレジストリキーを変更：

キー：HKLM\SOFTWARE\FSLogix\Profiles

既存の設定を無効化：
VHDLocations を削除または無効化

Cloud Cache設定を追加：
新しい値：
名前：CCDLocations
種類：REG_SZ（複数文字列）
データ：
type=smb,connectionString=\\stfslogixjpe.file.core.windows.net\fslogix-profiles;type=smb,connectionString=\\stfslogixjpw.file.core.windows.net\fslogix-profiles

その他の設定：
ClearCacheOnLogoff: 0

設定の説明：

• 複数のストレージロケーションをセミコロン（;）で区切る
• 最初に記載したストレージが優先される
• 自動フェイルオーバーが有効

---

ステップ3：動作確認

1. ユーザーでログイン
2. Cloud Cacheが有効か確認： C:\ProgramData\FSLogix\Cache このフォルダにキャッシュファイルが作成される
3. 両方のストレージロケーションにプロファイルが作成されることを確認：
   • プライマリストレージを確認
   • セカンダリストレージを確認
   • 両方に同じプロファイルコンテナが存在すること

---

バックアップ・リストア運用のベストプラクティス

定期的な確認作業

週次確認（推奨）

□ Azure Backupジョブの成功率確認
  - Recovery Services コンテナー → バックアップジョブ
  - 成功率が95%以上を維持

□ スナップショットの棚卸し
  - 不要なスナップショットの削除
  - タグベースの自動削除スクリプト実行

□ FSLogixバックアップジョブの確認
  - ファイル共有バックアップの成功確認

---

月次確認（推奨）

□ リストアテストの実施
  - 非本番環境でリストアテスト
  - 手順書の更新

□ 保持期間の見直し
  - コンプライアンス要件の確認
  - ストレージコストの最適化

□ バックアップポリシーの見直し
  - RPO/RTO目標の達成状況確認

---

四半期確認（推奨）

□ 完全なDRテストの実施
  - セッションホストの完全リストア
  - FSLogixプロファイルの復元
  - ユーザー受け入れテスト

□ ドキュメントの更新
  - 手順書の改訂
  - 連絡先リストの更新
  - エスカレーションパスの確認

---

バックアップ監視とアラート設定

Azure Monitorでのアラート設定：

1. Recovery Services コンテナーを開く
2. 「アラート」→「新しいアラートルール」を選択
3. アラート条件を設定：

アラート1：バックアップジョブ失敗
- シグナル：バックアップジョブの状態
- 条件：失敗
- アクション：メール通知

アラート2：バックアップ未実行
- シグナル：バックアップジョブの頻度
- 条件：24時間バックアップなし
- アクション：メール通知

アラート3：復旧ポイントの有効期限
- シグナル：復旧ポイントの数
- 条件：閾値を下回る
- アクション：メール通知

---

コスト最適化

バックアップコスト削減のヒント：

1. 保持期間の最適化
   • 必要最小限の保持期間を設定
   • 日次・週次・月次のバランスを検討
2. スナップショットの適切な削除
   • タグベースの自動削除を実装
   • 作業完了後3日以内に削除
3. 増分バックアップの活用
   • Standard ポリシーよりEnhancedポリシー
   • 増分スナップショットの使用
4. ストレージ層の選択
   • 即時復旧が必要な期間のみPremium
   • 長期保持はStandard HDD

---

トラブルシューティングガイド

問題1：バックアップジョブが失敗する

症状：

• バックアップジョブが「失敗」ステータス
• エラーコード：UserErrorVmProvisioningStateFailed

原因：

• Recovery Services コンテナーのマネージドIDに権限不足

対処法：

1. Recovery Services コンテナーを開く
2. 「ID」→「システム割り当てマネージド ID」を有効化
3. 対象VMのリソースグループに「仮想マシン共同作成者」ロールを付与
4. バックアップを再試行

---

問題2：FSLogixプロファイルがマウントされない

症状：

• ユーザーログイン時にエラー
• 一時プロファイルでログイン

確認項目：

1. ストレージアカウントへのネットワーク接続確認
   Test-NetConnection stfslogixjpe.file.core.windows.net -Port 445

2. ファイル共有のアクセス権限確認
   - ストレージアカウント → アクセス制御（IAM）
   - 「Storage File Data SMB Share Contributor」ロール確認

3. FSLogixサービスの状態確認
   Get-Service frxsvc, frxdrv, frxccds

4. イベントログ確認
   Event Viewer → FSLogix → Profiles → Operational

---

問題3：リストア後にVMが起動しない

症状：

• リストア完了後、VMが起動しない
• エラー：OSディスクの読み込みエラー

対処法：

1. ディスクの整合性確認
   - スナップショット作成時にVMが実行中だった可能性
   - アプリケーション整合性スナップショットを使用

2. 別の復旧ポイントからリストア
   - より古い復旧ポイントを試す

3. ディスクのみ復元して調査
   - ディスクを別のVMにアタッチ
   - ログファイルを確認

---

まとめ

バックアップ戦略の全体像

┌─────────────────────────────────────────────┐
│         AVD バックアップ全体構成            │
├─────────────────────────────────────────────┤
│                                             │
│ レイヤー1：セッションホストVM               │
│  ├─ A. Azure Backup (Enhanced)             │
│  │   └─ 12時間間隔、30日保持               │
│  └─ C. スナップショット（補助）             │
│      └─ 変更作業前の即時バックアップ       │
│                                             │
│ レイヤー2：ユーザープロファイル             │
│  └─ D. FSLogix (Azure Files Backup)        │
│      └─ 日次バックアップ、長期保持          │
│                                             │
│ レイヤー3：ディザスタリカバリ（オプション） │
│  └─ B. Azure Site Recovery                 │
│      └─ リージョン間レプリケーション        │
│                                             │
└─────────────────────────────────────────────┘

各方式の使い分け

シナリオ	推奨方式	理由
日常的な保護	A. Azure Backup (Enhanced)	自動化、長期保持、完全復旧
パッチ適用前	C. スナップショット	即座の作成とロールバック
ユーザーデータ保護	D. FSLogix Backup	VM独立、長期保持
リージョン障害対策	B. Azure Site Recovery	自動フェイルオーバー

RPO/RTO目標

推奨設定：

セッションホストVM：
- RPO：12時間（Enhanced policy）
- RTO：1時間（スナップショットから復旧）

ユーザープロファイル：
- RPO：24時間（日次バックアップ）
- RTO：30分（Azure Files スナップショット）

ディザスタリカバリ：
- RPO：15分（ASR）
- RTO：2時間（フェイルオーバー）

---

次のステップ

1. 現環境の確認
   • 現在のバックアップ設定を棚卸し
   • この記事の内容と比較
2. ギャップ分析
   • 不足している保護を特定
   • 優先順位をつけて実装
3. テスト実施
   • 非本番環境でリストアテスト
   • 手順を検証・改善
4. 運用開始
   • 監視・アラートを設定
   • 定期確認スケジュールを確立

---

本記事に関する質問やフィードバックは、コメント欄またはサポートチームまでお問い合わせください。

---

以上が、WordPress記事形式でのAzure Virtual Desktop バックアップ・リストア完全ガイドです。この内容は実際のWordPress投稿として使用できる形式になっています。

AVD インプレースアップデート完全自動化手順について、WordPress記事形式で表示いたします。

---

Azure Virtual Desktop セッションホスト 完全自動アップデート運用ガイド

はじめに

本記事では、Azure Update Managerを使用して、Azure Virtual Desktop（AVD）セッションホストのWindowsアップデートを完全自動で実施する方法を解説します。

本記事で実現できること

• スケジュールに基づいた自動Windows Update実行
• ローリングアップデート（段階的適用）の自動制御
• ドレインモードの自動管理
• 再起動の自動実行
• 更新状況の自動監視
• 完全無人運用

自動化の全体フロー

毎月第2火曜日 午前3:00（自動トリガー）
    ↓
更新プログラムの評価（自動）
    ↓
対象VMを25%ずつグループ化（自動）
    ↓
グループ1（25%）
├─ ドレインモード有効化（自動）
├─ アクティブセッション待機（自動）
├─ Windows Update実行（自動）
├─ 再起動（自動）
├─ 正常性確認（自動）
└─ ドレインモード解除（自動）
    ↓
グループ2（25%）
├─ （同上）
    ↓
グループ3（25%）
├─ （同上）
    ↓
グループ4（25%）
├─ （同上）
    ↓
完了通知メール送信（自動）

---

前提条件

必要な権限

• Azure サブスクリプション：共同作成者以上
• AVD環境：ホストプールとセッションホストが構成済み
• Recovery Services コンテナー：バックアップが設定済み（推奨）

対応OSバージョン

• Windows 10 Enterprise マルチセッション
• Windows 11 Enterprise マルチセッション
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

必要なAzure拡張機能

Azure Update Managerは以下の拡張機能を自動でインストールします：

• Windows: Azure VM Extension for Update Management
• 監視エージェント: Azure Monitor Agent（オプション）

---

ステップ1：Azure Update Manager の有効化

1-1. Azure Update Manager へのアクセス

手順：

1. Azure Portalにログイン
2. 検索バーで「Update Manager」を検索
3. 「Azure Update Manager」を選択

初回アクセス時の画面：

┌─────────────────────────────────────────┐
│ Azure Update Manager                    │
├─────────────────────────────────────────┤
│                                         │
│ 仮想マシンの更新プログラムを             │
│ 一元管理します                          │
│                                         │
│ [開始する]                              │
└─────────────────────────────────────────┘

---

1-2. 対象リソースの確認

手順：

1. Azure Update Manager画面で「マシン」タブを選択
2. AVDセッションホストVMが表示されることを確認

表示例：

┌──────────────────────────────────────────────────┐
│ マシン一覧                                       │
├──────────────────────────────────────────────────┤
│ 名前                  │ 状態    │ 保留中の更新  │
├──────────────────────────────────────────────────┤
│ avd-sessionhost-01   │ 実行中  │ 15            │
│ avd-sessionhost-02   │ 実行中  │ 15            │
│ avd-sessionhost-03   │ 実行中  │ 15            │
│ avd-sessionhost-04   │ 実行中  │ 15            │
└──────────────────────────────────────────────────┘

---

1-3. 定期評価の有効化

定期評価を有効にすると、自動的に利用可能な更新プログラムをチェックします。

手順：

1. Azure Update Manager画面で「設定」→「定期評価」を選択
2. 以下を設定：

定期評価の設定：
◉ 有効

評価頻度：
◉ 24時間ごと（推奨）
○ カスタム

対象スコープ：
- サブスクリプション：対象のサブスクリプション
- リソースグループ：AVDセッションホストのRG
- タグフィルター（オプション）：
  例）Environment: Production

3. 「保存」をクリック

効果：

• 毎日自動的に利用可能な更新プログラムを評価
• Azure Portalで常に最新の更新状況を確認可能

---

ステップ2：メンテナンス構成の作成

メンテナンス構成は、いつ、どのように更新を適用するかを定義します。

2-1. メンテナンス構成の新規作成

手順：

1. Azure Update Manager画面で「メンテナンス構成」を選択
2. 「+ メンテナンス構成の作成」をクリック
3. 基本情報を入力：

基本：
- サブスクリプション：対象のサブスクリプション
- リソースグループ：AVD管理用RG（例：RG-AVD-Management）
- 構成名：AVD-SessionHost-Monthly-Patching
- リージョン：AVDセッションホストと同じリージョン
- メンテナンススコープ：
  ◉ ゲスト（VM内部の更新）

4. 「次へ：スケジュール」をクリック

---

2-2. スケジュールの設定

推奨設定（本番環境）：

スケジュール設定：

開始日時：
- 日付：2025年1月14日（次回のパッチ火曜日）
- 時刻：03:00（午前3時）
- タイムゾーン：(UTC+09:00) 大阪、札幌、東京

繰り返し：
◉ 月単位

繰り返し間隔：
- 1ヶ月ごと

曜日：
☑ 火曜日

週：
◉ 第2週

メンテナンス期間：
- 4時間（推奨）
  ※ 大規模環境では6〜8時間に設定

再起動の設定：
◉ 必要に応じて再起動
○ 常に再起動
○ 再起動しない

設定の意味：

• 毎月第2火曜日の午前3時に自動実行（Microsoft Patch Tuesdayの翌日）
• 4時間以内に完了するよう制御
• 必要な場合のみ再起動

---

2-3. 更新プログラムの選択

手順：

1. 「次へ：更新プログラム」をクリック
2. 以下を設定：

更新プログラムの分類：
☑ 重要な更新プログラム
☑ セキュリティ更新プログラム
☑ 更新プログラムのロールアップ
☑ Feature Pack
☑ Service Pack
☑ 定義の更新
☑ ツール
☑ 更新プログラム

除外する更新プログラム（KB番号）：
- 空欄（通常は除外なし）
  ※ 問題のある更新がある場合のみ指定
  例：KB5034441

更新プログラムの含有：
- カスタム（オプション）
  特定のKB番号のみ適用したい場合に使用

推奨： すべての更新プログラムを適用（除外なし）

---

2-4. 動的スコープの設定（重要）

動的スコープを使用すると、タグやリソースグループで対象VMを自動識別できます。

手順：

1. 「次へ：マシン」をクリック
2. 「+ 動的スコープの追加」をクリック
3. 以下を設定：

動的スコープの設定：

スコープ名：
- AVD-SessionHosts-Production

フィルター条件：
◉ リソースグループ
  └─ RG-AVD-SessionHosts

または

◉ タグ
  └─ タグ名：Environment
  └─ タグ値：Production
  
  および
  
  └─ タグ名：Role
  └─ タグ値：SessionHost

4. 「追加」をクリック

メリット：

• 新しいセッションホストを追加しても自動的に対象に含まれる
• 手動でVM一覧を更新する必要なし

---

2-5. ゲスト設定（AVD固有の設定）

手順：

1. 「次へ：ゲスト」をクリック
2. 以下を設定：

前後のタスク（プレ/ポストスクリプト）：
- 設定しない（標準）

または（高度な設定）：

プレタスク（更新前に実行）：
- Azure Automation Runbook
- スクリプト名：Pre-Patching-Backup
  内容：スナップショット自動作成

ポストタスク（更新後に実行）：
- Azure Automation Runbook  
- スクリプト名：Post-Patching-Validation
  内容：動作確認・通知送信

初期設定では「設定しない」でOK

---

2-6. 確認と作成

手順：

1. 「次へ：確認および作成」をクリック
2. 設定内容を最終確認：

確認項目：
□ スケジュール：毎月第2火曜日 03:00
□ 更新分類：すべて選択済み
□ 対象VM：動的スコープで自動識別
□ 再起動設定：必要に応じて再起動

3. 「作成」をクリック

所要時間： 約2〜3分

---

ステップ3：ローリングアップデートの設定

ローリングアップデート（段階的適用）を有効にすることで、全VMを一度に更新せず、グループ単位で順次更新します。

3-1. オーケストレーション設定

手順：

1. 作成したメンテナンス構成を開く
2. 「動的スコープ」タブを選択
3. 作成済みの動的スコープ（AVD-SessionHosts-Production）をクリック
4. 「オーケストレーション」セクションで以下を設定：

オーケストレーション設定：

バッチ処理：
◉ 有効

バッチサイズ：
- 25%（推奨）

並行処理：
- 同時に処理するVM数：
  ◉ パーセンテージ：25%
  ○ 固定数：指定なし

バッチ間の待機時間：
- 30分（推奨）
  ※ 前のバッチが完了してから次のバッチまでの待機時間

更新順序：
◉ リソース名順
○ ランダム

設定の意味：

4台構成の場合：
┌─────────────────────────────────┐
│ バッチ1（25% = 1台）            │
│ → avd-sessionhost-01           │
│    更新完了                     │
│    30分待機                     │
├─────────────────────────────────┤
│ バッチ2（25% = 1台）            │
│ → avd-sessionhost-02           │
│    更新完了                     │
│    30分待機                     │
├─────────────────────────────────┤
│ バッチ3（25% = 1台）            │
│ → avd-sessionhost-03           │
│    更新完了                     │
│    30分待機                     │
├─────────────────────────────────┤
│ バッチ4（25% = 1台）            │
│ → avd-sessionhost-04           │
│    更新完了                     │
└─────────────────────────────────┘

---

3-2. AVD統合（ドレインモード自動制御）

重要： Azure Update ManagerはAVDと統合されており、ドレインモードを自動制御できます。

設定手順：

1. メンテナンス構成で「AVD統合」セクションを確認
2. 以下を設定：

AVD統合設定：

ドレインモードの自動管理：
◉ 有効

更新前の動作：
☑ ドレインモードを有効化
☑ アクティブセッションが0になるまで待機
  └─ 最大待機時間：60分

更新後の動作：
☑ 正常性確認（AVDエージェント応答確認）
☑ ドレインモードを自動解除

効果：

自動的に以下が実行される：
1. 更新前：ドレインモード有効化
2. セッション0になるまで待機（最大60分）
3. Windows Update実行
4. 再起動
5. AVDエージェント正常性確認
6. ドレインモード解除

注意： AVD統合機能は2024年後半に追加された比較的新しい機能です。表示されない場合は次のステップ3-3の代替方法を使用してください。

---

3-3. 代替方法：Azure Automation Runbookによる制御

AVD統合機能が利用できない場合、Azure Automation Runbookで同等の機能を実装できます。

概要：

プレタスク（更新前）Runbook：
1. 対象VMのドレインモード有効化
2. アクティブセッション監視
3. セッション0確認後、処理続行

ポストタスク（更新後）Runbook：
1. AVDエージェント正常性確認
2. ドレインモード解除
3. 管理者に通知メール送信

PowerShellスクリプト例（プレタスク）：

<#
.SYNOPSIS
    AVD更新前処理：ドレインモード有効化とセッション待機
#>

param(
    [Parameter(Mandatory=$true)]
    [string]$VMName,
    
    [Parameter(Mandatory=$true)]
    [string]$ResourceGroupName,
    
    [Parameter(Mandatory=$false)]
    [int]$MaxWaitMinutes = 60
)

# Azure接続（マネージドIDを使用）
Connect-AzAccount -Identity

# ホストプール情報の取得
$hostPool = Get-AzWvdHostPool | Where-Object {
    $sessionHosts = Get-AzWvdSessionHost -HostPoolName $_.Name -ResourceGroupName $_.ResourceGroupName
    $sessionHosts.Name -contains "$VMName"
}

if (-not $hostPool) {
    Write-Error "ホストプールが見つかりません: $VMName"
    exit 1
}

# セッションホスト情報の取得
$sessionHost = Get-AzWvdSessionHost `
    -HostPoolName $hostPool.Name `
    -ResourceGroupName $hostPool.ResourceGroupName `
    -Name $VMName

Write-Output "ドレインモードを有効化: $VMName"

# ドレインモード有効化
Update-AzWvdSessionHost `
    -HostPoolName $hostPool.Name `
    -ResourceGroupName $hostPool.ResourceGroupName `
    -Name $sessionHost.Name `
    -AllowNewSession:$false

# アクティブセッション待機
$startTime = Get-Date
$maxWaitTime = $startTime.AddMinutes($MaxWaitMinutes)

Write-Output "アクティブセッションの終了を待機中..."

while ((Get-Date) -lt $maxWaitTime) {
    $currentSessionHost = Get-AzWvdSessionHost `
        -HostPoolName $hostPool.Name `
        -ResourceGroupName $hostPool.ResourceGroupName `
        -Name $sessionHost.Name
    
    $activeSessions = $currentSessionHost.Session
    
    Write-Output "現在のアクティブセッション数: $activeSessions"
    
    if ($activeSessions -eq 0) {
        Write-Output "すべてのセッションが終了しました"
        exit 0
    }
    
    Start-Sleep -Seconds 60
}

Write-Warning "タイムアウト: $MaxWaitMinutes 分経過しましたが、まだアクティブセッションがあります"
Write-Output "現在のセッション数: $activeSessions"

# タイムアウト時の動作を選択
# オプション1：処理を続行（推奨しない）
# exit 0

# オプション2：処理を中断（推奨）
exit 1

PowerShellスクリプト例（ポストタスク）：

<#
.SYNOPSIS
    AVD更新後処理：正常性確認とドレインモード解除
#>

param(
    [Parameter(Mandatory=$true)]
    [string]$VMName,
    
    [Parameter(Mandatory=$true)]
    [string]$ResourceGroupName,
    
    [Parameter(Mandatory=$false)]
    [string]$NotificationEmail = ""
)

# Azure接続
Connect-AzAccount -Identity

# ホストプール情報の取得
$hostPool = Get-AzWvdHostPool | Where-Object {
    $sessionHosts = Get-AzWvdSessionHost -HostPoolName $_.Name -ResourceGroupName $_.ResourceGroupName
    $sessionHosts.Name -contains "$VMName"
}

# セッションホスト情報の取得
$sessionHost = Get-AzWvdSessionHost `
    -HostPoolName $hostPool.Name `
    -ResourceGroupName $hostPool.ResourceGroupName `
    -Name $VMName

Write-Output "正常性確認開始: $VMName"

# AVDエージェントステータス確認
$maxRetries = 10
$retryCount = 0
$isHealthy = $false

while ($retryCount -lt $maxRetries) {
    $currentSessionHost = Get-AzWvdSessionHost `
        -HostPoolName $hostPool.Name `
        -ResourceGroupName $hostPool.ResourceGroupName `
        -Name $sessionHost.Name
    
    $status = $currentSessionHost.Status
    
    Write-Output "ステータス: $status (試行 $($retryCount + 1)/$maxRetries)"
    
    if ($status -eq "Available") {
        $isHealthy = $true
        break
    }
    
    $retryCount++
    Start-Sleep -Seconds 30
}

if (-not $isHealthy) {
    Write-Error "正常性確認失敗: $VMName はAvailable状態になりませんでした"
    
    # 通知メール送信（オプション）
    if ($NotificationEmail) {
        # Send-MailMessage またはLogic Apps連携
    }
    
    exit 1
}

Write-Output "正常性確認成功: $VMName"

# ドレインモード解除
Write-Output "ドレインモードを解除: $VMName"

Update-AzWvdSessionHost `
    -HostPoolName $hostPool.Name `
    -ResourceGroupName $hostPool.ResourceGroupName `
    -Name $sessionHost.Name `
    -AllowNewSession:$true

Write-Output "ドレインモード解除完了: $VMName"

# 成功通知（オプション）
if ($NotificationEmail) {
    $subject = "AVD更新完了: $VMName"
    $body = @"
セッションホスト $VMName の更新が正常に完了しました。

ホストプール: $($hostPool.Name)
ステータス: Available
ドレインモード: 解除済み
完了時刻: $(Get-Date -Format "yyyy/MM/dd HH:mm:ss")
"@
    
    # Send-MailMessage または Logic Apps 連携で通知
}

exit 0

---

3-4. Azure Automation アカウントの設定

手順：

1. Azure Portalで「Automation アカウント」を検索
2. 「+ 作成」をクリック
3. 以下を設定：

基本情報：
- サブスクリプション：対象のサブスクリプション
- リソースグループ：RG-AVD-Management
- 名前：AA-AVD-UpdateManagement
- リージョン：AVDと同じリージョン

詳細設定：
- マネージドID：
  ☑ システム割り当てマネージドID

4. 「作成」をクリック

---

3-5. Runbookのインポート

手順：

1. 作成したAutomation アカウントを開く
2. 「Runbook」を選択
3. 「+ Runbookの作成」をクリック

プレタスクRunbook：

名前：AVD-PrePatching-DrainMode
Runbookの種類：PowerShell
ランタイムバージョン：7.2
説明：更新前にドレインモードを有効化し、セッション終了を待機

上記のプレタスクスクリプトを貼り付けて「公開」

ポストタスクRunbook：

名前：AVD-PostPatching-Validation
Runbookの種類：PowerShell
ランタイムバージョン：7.2
説明：更新後に正常性を確認し、ドレインモードを解除

上記のポストタスクスクリプトを貼り付けて「公開」

---

3-6. マネージドIDへの権限付与

手順：

1. Automation アカウントの「ID」を選択
2. 「Azure ロールの割り当て」をクリック
3. 「+ ロールの割り当ての追加」をクリック
4. 以下を設定：

スコープ：リソースグループ
リソースグループ：RG-AVD-SessionHosts
ロール：Desktop Virtualization Session Host Operator

（追加）
スコープ：リソースグループ
リソースグループ：RG-AVD-SessionHosts
ロール：仮想マシン共同作成者

5. 「保存」をクリック

---

3-7. メンテナンス構成へのRunbook紐付け

手順：

1. Azure Update Managerで作成したメンテナンス構成を開く
2. 「設定」→「プレ/ポストタスク」を選択
3. 以下を設定：

プレタスク（更新前）：
- Automation アカウント：AA-AVD-UpdateManagement
- Runbook：AVD-PrePatching-DrainMode
- パラメーター：
  VMName: (自動設定)
  ResourceGroupName: (自動設定)
  MaxWaitMinutes: 60

ポストタスク（更新後）：
- Automation アカウント：AA-AVD-UpdateManagement
- Runbook：AVD-PostPatching-Validation
- パラメーター：
  VMName: (自動設定)
  ResourceGroupName: (自動設定)
  NotificationEmail: admin@example.com

4. 「保存」をクリック

---

ステップ4：通知とアラートの設定

4-1. Azure Monitor アラートの設定

手順：

1. Azure Portalで「モニター」を検索
2. 「アラート」→「+ アラートルールの作成」を選択
3. スコープ選択：

リソース：
- Azure Update Manager
または
- 各セッションホストVM

4. 条件設定：

アラート1：更新失敗時
- シグナル：更新プログラムのインストール失敗
- しきい値：1回以上
- 評価期間：5分

アラート2：更新完了時
- シグナル：メンテナンス実行完了
- しきい値：すべて
- 評価期間：実行終了時

5. アクショングループ設定：

アクショングループ名：AG-AVD-Update-Notifications

通知：
- 通知タイプ：メール/SMS/プッシュ/音声
- 名前：管理者通知
- メールアドレス：admin@example.com

6. 「作成」をクリック

---

4-2. Logic Apps による高度な通知（オプション）

より詳細な通知が必要な場合、Logic Appsを使用できます。

通知内容の例：

件名：[AVD] 月次パッチ適用完了 - 2025年1月

本文：
Azure Virtual Desktop 月次パッチ適用が完了しました。

実行日時：2025年1月14日 03:00 ～ 06:30
対象ホストプール：HP-AVD-Production

結果サマリー：
- 成功：4台
- 失敗：0台
- スキップ：0台

詳細：
┌────────────────────────────────────┐
│ avd-sessionhost-01                │
│ - 適用：15個の更新プログラム       │
│ - 再起動：あり                     │
│ - 完了時刻：03:45                  │
│ - ステータス：✅ Available         │
├────────────────────────────────────┤
│ avd-sessionhost-02                │
│ - 適用：15個の更新プログラム       │
│ - 再起動：あり                     │
│ - 完了時刻：04:45                  │
│ - ステータス：✅ Available         │
├────────────────────────────────────┤
（以下同様）
└────────────────────────────────────┘

詳細はAzure Portalで確認してください：
https://portal.azure.com/#view/Microsoft_Azure_...

---

ステップ5：初回実行とテスト

5-1. テスト実行（推奨）

本番環境での自動実行前に、テスト環境または1台のVMでテスト実行することを推奨します。

手順：

1. Azure Update Managerを開く
2. 「ワンタイム更新」を選択
3. 以下を設定：

対象マシン：
☑ avd-sessionhost-01（テスト用1台のみ）

更新プログラム：
☑ すべて選択

再起動オプション：
◉ 必要に応じて再起動

メンテナンス期間：
- 2時間

4. 「今すぐインストール」をクリック

監視：

Azure Update Manager
→ 更新履歴
→ 実行中のジョブを確認

確認項目：
□ ドレインモードが自動で有効化されたか
□ Windows Updateが正常に実行されたか
□ 再起動が完了したか
□ AVDエージェントが「Available」になったか
□ ドレインモードが自動で解除されたか

所要時間： 30分〜1時間

---

5-2. スケジュール実行の確認

手順：

1. メンテナンス構成を開く
2. 「スケジュールされた実行」タブを選択
3. 次回実行予定を確認：

次回実行予定：
日時：2025年2月11日（火）03:00
対象：動的スコープ（4台のVM）
状態：スケジュール済み

---

ステップ6：運用監視

6-1. 更新状況の確認

リアルタイム監視：

Azure Update Manager
→ 概要ダッシュボード

表示内容：
┌─────────────────────────────────────┐
│ 更新プログラムの状態                 │
├─────────────────────────────────────┤
│ 最新：2台                           │
│ 保留中の重要な更新：0台              │
│ 保留中のセキュリティ更新：0台        │
│ 保留中のその他の更新：2台            │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│ 最近の更新履歴                       │
├─────────────────────────────────────┤
│ 2025/01/14 03:00 - 成功（4台）      │
│ 2024/12/10 03:00 - 成功（4台）      │
│ 2024/11/12 03:00 - 成功（4台）      │
└─────────────────────────────────────┘

---

6-2. 詳細ログの確認

手順：

1. Azure Update Manager→「更新履歴」を選択
2. 対象の実行を選択
3. 詳細情報を確認：

実行詳細：
┌─────────────────────────────────────┐
│ 実行ID：xxxxxxxx-xxxx-xxxx-xxxx      │
│ 開始時刻：2025/01/14 03:00:00       │
│ 終了時刻：2025/01/14 06:30:00       │
│ 期間：3時間30分                      │
│ ステータス：成功                     │
├─────────────────────────────────────┤
│ マシン別の詳細：                     │
│                                     │
│ avd-sessionhost-01                  │
│ ├─ バッチ：1                        │
│ ├─ 開始：03:00                      │
│ ├─ 終了：03:45                      │
│ ├─ 適用した更新：15個               │
│ ├─ 再起動：あり                     │
│ └─ ステータス：✅ 成功              │
│                                     │
│ avd-sessionhost-02                  │
│ ├─ バッチ：2                        │
│ ├─ 開始：04:15                      │
│ ├─ 終了：05:00                      │
│ （以下同様）                         │
└─────────────────────────────────────┘

---

6-3. コンプライアンスレポート

Update Compliance の使用：

Update Complianceを有効にすると、より詳細なレポートが取得できます。

設定手順：

1. Azure Portalで「Log Analytics ワークスペース」を作成
2. Update Complianceソリューションを追加
3. Azure Update Managerと統合
4. レポートを確認：

コンプライアンスダッシュボード：
┌─────────────────────────────────────┐
│ 更新プログラムコンプライアンス       │
├─────────────────────────────────────┤
│ 準拠：100% (4/4台)                  │
│ 非準拠：0% (0/4台)                  │
│                                     │
│ セキュリティ更新の適用率：100%       │
│ 重要な更新の適用率：100%             │
│ その他の更新の適用率：95%            │
│                                     │
│ 平均更新遅延：2日                    │
│ 最終更新日：2025/01/14              │
└─────────────────────────────────────┘

---

トラブルシューティング

問題1：更新が失敗する

症状：

エラー：更新プログラムのインストールに失敗しました
エラーコード：0x80070002

原因と対処：

原因	対処法
ディスク容量不足	Cドライブの空き容量を確保（最低20GB推奨）
Windows Updateサービス停止	VMにRDPしてサービスを再起動
ネットワーク接続問題	NSG設定を確認（Windows Update URLへのアクセス許可）
競合する更新	除外リストに問題のあるKB番号を追加

---

問題2：ドレインモードが解除されない

症状：

更新完了後もドレインモードが有効なまま
ユーザーが接続できない

対処法：

手動でドレインモード解除：

# PowerShell
Update-AzWvdSessionHost `
    -HostPoolName "HP-AVD-Production" `
    -ResourceGroupName "RG-AVD-SessionHosts" `
    -Name "avd-sessionhost-01" `
    -AllowNewSession:$true

または

Azure Portal
→ Azure Virtual Desktop
→ ホストプール
→ セッションホスト
→ 対象VMを選択
→ 「ドレインモードをオフにする」

根本原因の調査：

Automation アカウント
→ Runbook
→ AVD-PostPatching-Validation
→ ジョブ履歴
→ エラーログを確認

---

問題3：再起動後にVMが起動しない

症状：

更新後の再起動で VM が停止状態のまま
Azure Portal: ステータス「停止済み」

対処法：

ステップ1：強制再起動

Azure Portal
→ 仮想マシン
→ 対象VM
→ 「再起動」（それでもダメなら「停止」→「開始」）

ステップ2：それでもダメならロールバック

Recovery Services コンテナー
→ バックアップ項目
→ 対象VM
→ 「ディスクの交換」
→ 最新の復旧ポイントを選択

ステップ3：事前に作成したスナップショットから復元

スナップショット
→ 更新前に作成したスナップショットを選択
→ 「ディスクの作成」
→ VMのディスクを交換

---

問題4：タイムアウトエラー

症状：

エラー：メンテナンス期間（4時間）を超過しました
一部のVMが更新未完了

対処法：

メンテナンス期間を延長：

メンテナンス構成
→ スケジュール
→ メンテナンス期間：6時間または8時間に変更

バッチサイズを調整：

現在：25%（4台なら1台ずつ）
変更：50%（4台なら2台ずつ）

※ ただし、負荷に注意

---

ベストプラクティス

1. 事前バックアップは必須

自動バックアップ設定：
- Azure Backup（日次）
- スナップショット（更新前自動作成）

推奨：
Automation Runbook（プレタスク）で
更新前に自動スナップショット作成を実装

---

2. テスト環境での事前検証

本番環境適用の1週間前：
テスト環境で同じ更新プログラムを適用
↓
動作確認
↓
問題があれば除外リストに追加
↓
本番環境適用

---

3. ユーザー通知

更新予定日の3日前：
ユーザーに通知メール送信

内容：
- 更新日時
- 影響範囲（短時間の接続不可の可能性）
- 緊急連絡先

---

4. 段階的ロールアウト

フェーズ1：非本番環境（1週間前）
フェーズ2：本番環境25%（Patch Tuesday翌日）
フェーズ3：問題なければ残り75%（翌週）

---

5. 監視とログ保管

保管すべきログ：
□ 更新履歴（Azure Update Manager）
□ Runbook実行ログ（Automation アカウント）
□ AVDエージェントログ
□ Windows Updateログ

保管期間：最低90日（監査要件に応じて）

---

コスト試算

Azure Update Manager のコスト

基本：

Azure Update Manager 自体は無料
※ 2024年時点

関連コスト：

1. Azure Automation
   - Runbook実行：$0.002/分
   - 月間想定：約$5〜10

2. Log Analytics（オプション）
   - データ取り込み：$2.76/GB
   - 月間想定：約$10〜20

3. ストレージ（スナップショット）
   - 増分スナップショット：約$0.05/GB/月
   - 月間想定（4台分）：約$20〜40

合計：月額 約$35〜70

---

まとめ

完全自動化で実現できること

✅ 完全無人運用

• 毎月自動的にWindows Update実行
• ドレインモード自動制御
• 段階的ロールアウト
• 自動再起動
• 正常性確認

✅ 安全性の向上

• ローリングアップデート（25%ずつ）
• 事前バックアップ
• 自動ロールバック（オプション）
• リアルタイム監視

✅ 運用負荷の削減

• 手作業不要
• 深夜作業不要
• 一貫性のある運用

✅ コンプライアンス対応

• 更新履歴の自動記録
• レポート自動生成
• 監査証跡の保管

---

初期設定チェックリスト

□ Azure Update Manager 有効化
□ 定期評価の有効化
□ メンテナンス構成作成
  □ スケジュール設定
  □ 更新プログラム分類選択
  □ 動的スコープ設定
  □ オーケストレーション設定（25%ずつ）
□ AVD統合設定
  □ ドレインモード自動制御
  または
  □ Automation Runbook作成・設定
□ 通知・アラート設定
□ テスト実行
□ 本番スケジュール確定

---

次のステップ

1. テスト環境で検証
   • 1台のVMでワンタイム更新実行
   • 動作確認
2. 本番環境に展開
   • メンテナンス構成を本番環境に適用
   • 次回のPatch Tuesday（第2火曜日）を待つ
3. 継続的改善
   • 更新履歴のレビュー
   • 問題があれば設定調整
   • ユーザーフィードバック収集

---

これで完全自動のローリングアップデート運用が実現できます！

何か不明点や追加で知りたいことがあれば、お気軽にお尋ねください。