Omnissa Horizon（旧 VMware Horizon）への移行と PowerCLI 自動化

はじめに

VMware Horizon は 2024 年に大きな転機を迎えました。Broadcom による VMware 買収後、End-User Computing（EUC）部門は 私募ファンド KKR に売却され、2024 年に Omnissa という独立企業として再出発 しました。これに伴い、製品名も VMware Horizon から Omnissa Horizon にリブランド されています。

特に Horizon 8 2412（2025 年 1 月リリース） では、UI 表示だけでなくインストールパス、レジストリキー、サービス名、PowerCLI モジュール、ADMX テンプレートなどがすべて Omnissa ブランドに変更されました。既存の VMware Horizon 環境からアップグレードする場合、自動化スクリプト・GPO・運用ツールが影響を受ける ため、変更点の把握が運用上の課題となっています。

本記事では、以下を整理します。

• VMware Horizon から Omnissa Horizon への変化（2024〜2025 年の業界動向）
• リブランドに伴う主要な変更点（パス、レジストリ、PowerCLI モジュール）
• Horizon 8 の基本構成（View Composer 廃止後）と構築手順
• PowerCLI（Omnissa.VimAutomation.HorizonView）を使った異常 VM 自動復旧スクリプト
• リブランド後の運用で押さえておきたい落とし穴

VMware Horizon から Omnissa Horizon へ

2024〜2025 年にかけて、VMware Horizon は会社・製品名・ライセンスのいずれも大きく変化しました。順を追って整理します。

経緯: Broadcom 買収から Omnissa 設立まで

• 2023 年: Broadcom が VMware を買収完了
• 2024 年 2 月: Broadcom が VMware の EUC 部門を KKR に売却すると発表
• 2024 年 4 月: EUC 部門が Omnissa として新ブランド発表
• 2025 年 1 月 28 日: Omnissa Horizon 2412 リリース（リブランディング完了版）
• 2025 年 3 月 28 日: Broadcom の Horizon 関連サポート終了（以降は Omnissa が直接サポートを提供）

参考: Omnissa Horizon Update – Virtualization Review
“VMware sold its End-User Computing (EUC) division to private equity firm KKR in 2023/2024. This led to the business being rebranded as Omnissa.”
（VMware は 2023〜2024 年にかけて EUC 部門を私募ファンドの KKR に売却し、これに伴い同事業は Omnissa にリブランドされました）
https://virtualizationreview.com/articles/2026/03/05/omnissa-horizon-update.aspx

製品名と所在地の変化

Horizon 8 のリリース履歴（2025 年以降）

Omnissa は引き続き Horizon 8 系列を 3 か月程度のサイクルでリリースしています。

長期安定性を重視する本番環境では ESB ブランチ（2312n 系列） の利用、新機能を取り入れたい環境では非 ESB の最新バージョン、という使い分けが基本となります。

参考: Omnissa Horizon 2412 – Rebranding! – ITQ
“In the 2412 release, the Omnissa rebranding was completed. All possible references to VMware Horizon were replaced by Omnissa branded references, not only in the UI, but also in folder structures, registry keys, APIs.”
（2412 リリースで Omnissa リブランドが完了しました。VMware Horizon のあらゆる参照が Omnissa ブランドに置き換えられ、それは UI だけでなくフォルダ構造、レジストリキー、API にも及びます）
https://itq.eu/knowledge/omnissa-horizon-2412-rebranding/

VMware Horizon 7 以前を運用している場合、Horizon 8 への移行に加えて Omnissa リブランドへの対応も同時に検討する必要があります。

リブランドに伴う主要な変更点

Horizon 8 2412 以降では、ファイルパス・レジストリキー・サービス名・PowerCLI モジュール がすべて Omnissa ブランドに変更されています。既存の自動化スクリプト・GPO・運用ツールに影響するため、移行前に把握しておきたいポイントを整理します。

ファイル・フォルダ構造の変更

絶対パス（フルパス）でファイルを参照する自動化スクリプトを使っている場合、これらの変更により 動作不能になる可能性 があるため、変更点を踏まえてスクリプトの見直しが必要です。

レジストリキーの変更

レジストリキーが変更されたことに伴い、ADMX テンプレートも刷新されています。既存の GPO は新しい ADMX で作り直す必要 があります。Omnissa の公式ドキュメントでは、新しい ADMX を導入してから GPO を再構成し、すべてのコンポーネントが 2412 以降にアップグレード完了した後に旧 GPO を削除する手順が案内されています。

サービス名の変更

Windows サービス一覧に表示される名称も変更されています。

サービス監視ツール（Zabbix、Nagios など）でサービス名を直接指定している場合、監視設定の更新が必要となります。

PowerCLI モジュールの変更（最重要）

PowerCLI による Horizon の自動化に関わる最重要の変更点です。Omnissa Horizon に対応するためには、新しい PowerCLI モジュール を利用する必要があります。

参考: Horizon PowerShell Module – Omnissa Developer Portal
“The Omnissa Horizon Powershell module (Omnissa.VimAutomation.HorizonView) can be used to Connect and Disconnect to the View API Service to assist with automating Horizon activities via Powershell.”
（Omnissa Horizon PowerShell モジュール（Omnissa.VimAutomation.HorizonView）は、PowerShell による Horizon 操作の自動化のために、View API サービスへの接続・切断を行えます）
https://developer.omnissa.com/horizon-powercli/

注意点として、新しい VMware.PowerCLI（13.3 以降）からは VMware.VimAutomation.HorizonView モジュールが削除 されています。VMware.PowerCLI のオフラインインストーラからも HorizonView モジュールが取り除かれており、Horizon の操作には Omnissa の新モジュールを利用することが前提となります。

vCenter 操作用の VMware.PowerCLI 自体は引き続き有効なため、Horizon と vCenter の両方を扱うスクリプトでは 「VMware.PowerCLI（vCenter 用）+ Omnissa.VimAutomation.HorizonView（Horizon 用）」 という組み合わせになります。

Horizon 8 の構成シンプル化（View Composer の廃止）

Horizon 7 から Horizon 8 への移行で最もインパクトが大きいのが 「View Composer の廃止」と「インスタントクローンの標準化」 です。Omnissa Horizon でもこの構成が継承されています。

View Composer の廃止

Horizon 7 までは、ストレージ容量を節約できる「リンククローン方式」を利用するために、以下のコンポーネントが必要でした。

• View Composer サーバ（専用の Windows Server）
• 専用データベース（SQL Server 等）

これらは構築の手間と運用上の障害切り分けの複雑さを生む要因でもありました。Horizon 8（2006 以降）ではリンククローン機能自体が廃止 され、より高速な「インスタントクローン」が標準機能になっています。

インスタントクローンの仕組みやリンククローンとの詳細な違いについては、関連記事『Horizon 8 インスタントクローンとリンククローンの違いと移行の落とし穴』も参考にしてください。

Connection Server と vCenter の直接連携

View Composer が廃止されたことで、Connection Server が vCenter と直接連携してクローン展開を行う構成に簡素化されました。これにより構築工数とトラブル時の切り分け対象が減り、運用負荷の低減につながっています。

Omnissa Horizon 環境構築手順

構成がシンプルになったことで、構築手順自体は Horizon 7 時代と比べて大幅に簡略化されています。Omnissa Horizon でも以下の流れは共通です。

必要なコンポーネント

Omnissa Horizon 環境を構築するために必要なサーバは以下のとおりです。

• vSphere 基盤: ESXi ホスト、vCenter Server（vCSA）
• 認証基盤: Active Directory ドメインコントローラ
• 管理サーバ: Connection Server（Windows Server。事前にドメイン参加させておく）

Horizon 7 時代に必要だった「View Composer サーバ」と「専用 SQL データベース」は不要になっています。

Connection Server のインストール

Omnissa Customer Connect から Connection Server のインストーラ（Omnissa-Horizon-Connection-Server-xxxx.exe ※従来は VMware-Horizon-Connection-Server-xxxx.exe）をダウンロードして実行します。ウィザードに沿って進める中で、重要な分岐点は次の 1 つです。

• インスタンスのタイプ: 「Horizon スタンダードサーバー（Horizon Standard Server）」 を選択

これで vCenter と連携し、インスタントクローンを展開する準備が整います。

マスターイメージ（Windows 10/11）の作成

仮想デスクトップの「原本」となるマスター VM を作成します。Windows 10/11 をインストール後、Horizon Agent を導入します。インストール時の機能選択で押さえておきたいポイントは以下です。

• Horizon Instant Clone Agent: 選択することを推奨
• Horizon View Composer Agent: 選択しない（Horizon 8 では項目自体が表示されないケースが多い）

導入完了後、デプロイの基準点となる スナップショット を取得しておきます。

KMS サーバが無いラボ環境での回避策

検証環境やホームラボなど、KMS（ライセンス認証）サーバを用意していない環境でインスタントクローンを展開すると、以下のエラーが発生してデプロイに失敗するケースがあります。

view composer agent initialization error (16): Failed to activate software license

ライセンス認証をスキップして展開するための回避策として、マスター OS 側で以下のレジストリ値を設定し、その状態でスナップショットを取得する方法があります。

ただし、Horizon 2412 以降では レジストリキーが Omnissa パスに移行している可能性 があります。最新環境で動作しない場合は、Omnissa Customer Connect / Knowledge Base の最新情報を参照することをおすすめします。

この設定はあくまで検証用の暫定的な回避策です。本番環境では適切なライセンス認証を実施することをおすすめします。

PowerCLI 環境セットアップ（Omnissa 対応版）

数百〜数千台規模の VDI を運用する場合、GUI（Horizon Console）での操作には限界があります。PowerCLI を導入することで、運用の自動化・効率化 が可能になります。

Omnissa Horizon 環境では、vCenter 操作用に VMware.PowerCLI、Horizon 操作用に Omnissa.VimAutomation.HorizonView および Omnissa.Horizon.Helper を組み合わせて利用します。

# 管理者権限の PowerShell で実行
Install-Module -Name VMware.PowerCLI -Scope AllUsers

# Omnissa Horizon View モジュールのインポート
Import-Module Omnissa.VimAutomation.HorizonView

# Helper モジュールのインポート（高度な操作で使用）
Import-Module Omnissa.Horizon.Helper

# モジュールの動作確認
Get-Command -Module Omnissa.VimAutomation.HorizonView
Get-Command -Module Omnissa.Horizon.Helper

Connect-HVServer -Server <Connection Server の FQDN> `
                 -User <管理者ユーザー> `
                 -Password <パスワード> `
                 -Domain <ドメイン名>

自己署名証明書環境での接続エラー対処

検証環境などで自己署名証明書を使用している場合、接続時に以下のエラーが発生することがあります。

Connect-HVServer : 機関 'xxx' との SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした。

接続前に以下のコマンドを実行することで、証明書検証を無視する設定を入れられます。

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

本番環境では適切な証明書を導入し、検証無視は使用しないことをおすすめします。

【実践】PowerCLI で異常な VM を自動復旧する

VDI を運用していると、「使用中ではないのに接続できない VM」「エージェントが無応答の VM」が一定の頻度で発生します。これらを毎日手動で探して再起動するのは運用負荷が高いため、PowerCLI を使って異常状態の VM を自動的に検出・再起動する 仕組みを整えておくと有効です。

スクリプトの処理ロジック

スクリプト本体（Omnissa 対応版）

#-------------------------------------------------------------------------
# 環境変数（実環境に合わせて書き換え）
#-------------------------------------------------------------------------
# Connection Server 情報
$cs         = 'cs01.example.com'        # FQDN
$csUser     = 'Administrator'           # 管理ユーザー
$csPassword = 'YourPassword!'           # パスワード
$csDomain   = 'example.com'             # ドメイン

# vCenter Server 情報
$vc         = 'vc01.example.com'        # FQDN
$vcUser     = 'administrator@vsphere.local'
$vcPassword = 'YourPassword!'

# 対象とする異常ステータス一覧
$targetStates = @(
    'PROVISIONING_ERROR',            # 展開エラー
    'ERROR',                         # エラー
    'AGENT_UNREACHABLE',             # エージェント応答なし
    'AGENT_ERR_STARTUP_IN_PROGRESS', # 起動処理中のままスタック
    'AGENT_ERR_DISABLED',            # 無効化エラー
    'AGENT_ERR_INVALID_IP',          # IP 取得エラー
    'UNKNOWN'                        # 不明
)

#-------------------------------------------------------------------------
# 処理本体
#-------------------------------------------------------------------------
# モジュールのインポート（Omnissa 対応版）
Import-Module Omnissa.VimAutomation.HorizonView
Import-Module Omnissa.Horizon.Helper
Import-Module VMware.VimAutomation.Core

# 1. Connection Server に接続
Write-Host "Connecting to Omnissa Horizon Connection Server..." -ForegroundColor Cyan
$hvServer = Connect-HVServer -Server $cs `
                             -User $csUser `
                             -Password $csPassword `
                             -Domain $csDomain

# 2. vCenter Server に接続
Write-Host "Connecting to vCenter Server..." -ForegroundColor Cyan
Connect-VIServer -Server $vc -User $vcUser -Password $vcPassword

# 3. 異常 VM の検索と再起動
if ($hvServer) {
    foreach ($state in $targetStates) {
        # 対象ステータスの VM を取得
        $ProblemVMs = Get-HVMachineSummary -State $state

        foreach ($ProblemVM in $ProblemVMs) {
            $vmName = $ProblemVM.Base.Name
            Write-Host "異常な VM を検出: $vmName ($state)" -ForegroundColor Red

            # vCenter 経由で再起動を実行
            $VM = Get-VM -Name $vmName -ErrorAction SilentlyContinue
            if ($VM) {
                Write-Host " -> 再起動コマンドを送信中..." -ForegroundColor Yellow
                Restart-VMGuest -VM $VM -Confirm:$false
            } else {
                Write-Host " -> vCenter 上で VM が見つかりませんでした。スキップします" -ForegroundColor DarkYellow
            }
        }
    }

    # 切断処理
    Disconnect-HVServer -Server $cs -Confirm:$false
    Disconnect-VIServer -Server $vc -Confirm:$false
    Write-Host "処理が完了しました。" -ForegroundColor Green
} else {
    Write-Error "Connection Server への接続に失敗しました。"
}

VMware.Hv.Helper を使っていた既存スクリプトの移行

VMware Horizon 時代に作成した既存スクリプトを Omnissa Horizon 環境に移行する場合、Import-Module 部分の書き換え が主な対応となります。

# 旧（VMware Horizon 時代）
Import-Module VMware.VimAutomation.HorizonView
Import-Module VMware.Hv.Helper

# 新（Omnissa Horizon 2412 〜）
Import-Module Omnissa.VimAutomation.HorizonView
Import-Module Omnissa.Horizon.Helper

コマンドレット名（Connect-HVServer、Get-HVMachineSummary など）は互換性が保たれているため、モジュール名の書き換えだけで動作するスクリプトが多い のが実情です。ただし、絶対パスでの参照や、レジストリ操作・サービス名指定を含むスクリプトは別途確認が必要です。

定期実行による運用効率化

このスクリプトを Windows のタスクスケジューラに登録して定期実行することで、管理者が気付く前に異常 VM を検出・対処できます。実行頻度は環境のサイズによりますが、15 分〜1 時間に 1 回 程度が目安となります。

VDI 運用では、HA フェイルオーバ時のリソース逼迫やバルーニング発生もパフォーマンス低下要因になります。リソース管理の挙動については、関連記事『VMware メモリバルーニングとは｜仕組みと esxtop での確認手順』も参考にしてください。

移行・運用上の落とし穴と注意点

VMware Horizon から Omnissa Horizon への移行、または既存環境を 2412 以降にアップグレードする際に押さえておきたい注意点を整理します。

落とし穴 1: 自動化スクリプトが動かなくなる

最も影響が大きいのが、既存の自動化スクリプトの破損 です。以下のパターンに該当するスクリプトは事前に修正が必要です。

落とし穴 2: GPO（ADMX）テンプレートの再作成が必要

レジストリパスが変更されたため、既存の GPO は新しいレジストリキーを参照していない状態 になります。Omnissa の公式手順に沿って以下を実施することが推奨されています。

1. アップグレード前に、新しい Omnissa ADMX テンプレート を中央ストアに導入
2. 新しい GPO を作成し、必要な設定を再適用
3. すべてのコンポーネント（Connection Server / Agent / Client）が 2412 以降にアップグレード完了したことを確認
4. 旧 GPO を削除

過渡期は新旧 GPO を並行運用する形になるため、GPO の優先順位設定 と 適用範囲（OU）の管理 に注意が必要です。

落とし穴 3: ライセンスモジュール（OLM）への移行

Horizon 8 2503 以降では Omnissa License Module（OLM） への移行が進んでおり、有効な Omnissa キーが無い環境は制限モード（Restricted Mode）に入る ようになっています。

参考: Omnissa Horizon Update – Virtualization Review
“Releases such as Horizon 8 2503 and 2506 transitioned away from VMware/Broadcom license modules to the Omnissa License Module (OLM). After upgrading, deployments without valid Omnissa keys enter a restricted mode until compliant keys are applied.”
（Horizon 8 2503 / 2506 では VMware/Broadcom ライセンスモジュールから Omnissa License Module（OLM）に移行されました。アップグレード後、有効な Omnissa キーが無いデプロイは適合キーが適用されるまで制限モードに入ります）
https://virtualizationreview.com/articles/2026/03/05/omnissa-horizon-update.aspx

アップグレード前に Omnissa Customer Connect で有効なライセンスキーを取得・確認 しておくことをおすすめします。

落とし穴 4: サポート提供元の変化

2025 年 3 月 28 日以降、Broadcom からの Horizon 関連サポートは終了 しています。サポートを受けるためには以下のいずれかが必要です。

• Omnissa との直接サポート契約（サブスクリプションベース）
• サードパーティサポート の利用
• 既存の永続ライセンス で利用継続（公式サポートなし）

Horizon 環境のリプレースや延命の判断にあたっては、サポート体制の変化も考慮事項として組み込む必要があります。

落とし穴 5: ESB ブランチと非 ESB の選択

Omnissa Horizon は ESB（Extended Service Branch） と 非 ESB の 2 系統でリリースされています。

リブランド完了の 2412 は 非 ESB であるため、本番環境で長期安定性を求める場合は、後継の ESB ブランチがリリースされるまで 2312n に留まる選択肢もあります。アップグレード計画時にはブランチ選定も併せて検討します。

まとめ

本記事では、VMware Horizon から Omnissa Horizon への変化と、リブランド後の構築・運用ポイント、PowerCLI による自動化までを整理しました。

• 2024 年に EUC 部門が KKR に売却され、2025 年 1 月の Horizon 8 2412 で VMware Horizon → Omnissa Horizon のリブランドが完了
• インストールパス（C:\Program Files\Omnissa\Horizon）、レジストリ（HKLM\Software\Omnissa\Horizon）、サービス名（Omnissa Horizon ...）が一斉に変更
• PowerCLI モジュールは VMware.VimAutomation.HorizonView から Omnissa.VimAutomation.HorizonView へ変更（コマンドレット名は互換性維持）
• 構成は Horizon 8 系列を継承し、View Composer 廃止 / インスタントクローン標準化 で構築工数とトラブルポイントが減少
• 既存の自動化スクリプト・GPO・サービス監視は 絶対パスとサービス名の参照箇所を確認 して書き換える必要がある
• Horizon 8 2503 以降は Omnissa License Module（OLM） への移行が進み、有効な Omnissa キーが必要
• 本番環境では ESB ブランチ（2312n 系）の利用 を選択肢として検討する

以上、最後までお読みいただきありがとうございました。