Horizon 7 では、自社で現在使用しているアプリケーション プロビジョニングのテクニックをそのまま使い続けながら、Mirage も使用できます。ただし、サーバの CPU 使用率およびストレージ I/O の管理と、ユーザーにアプリケーションのインストールを許可するかどうかの決定という 2 つの考慮事項が加わります。
アプリケーションをほぼ同時刻に多数のリモート デスクトップにプッシュすると、CPU 使用率とストレージ I/O が大きく急上昇することがあります。このピーク ワークロードは、デスクトップのパフォーマンスに顕著な影響を及ぼす場合があります。ベスト プラクティスとしては、アプリケーションの更新がピーク時以外に実行されるようにスケジュールし、可能であれば各デスクトップの更新時刻をずらします。また、ストレージ ソリューションがそのようなワークロードをサポートできるように設計されていることを確認する必要があります。
会社がユーザーにアプリケーションのインストールを許可している場合は、現在のポリシーを継続できますが、デスクトップの更新や再構成などの View Composer の機能は活用できません。View Composer では、アプリケーションが仮想化されていないか、あるいはユーザーのプロファイルまたはデータ設定に含まれている場合、そのアプリケーションは View Composer の更新、再構成、または再分散操作が実行されるたびに破棄されます。多くの場合、インストールされるアプリケーションをこのように厳格に制御できることは、利点となります。View Composer デスクトップは既知の優れた構成とほぼ同じに保たれるため、サポートが容易です。
ユーザーの企業が、View Composer を使用してアプリケーションをプロビジョニングする代わりに、独自のアプリケーションをインストールし、リモート デスクトップの有効期間内にこれらのアプリケーションを保持する必要がある場合は、インスタント クローンを App Volumes と一緒に使用できます。または、完全クローン専用デスクトップを作成し、ユーザーがアプリケーションをインストールできるようにしてから、Mirage を使用して、ユーザーがインストールしたアプリケーションを上書きせずにデスクトップの管理と更新を行う方法もあります。
