先般、XenApp 7.6 がリリースされました。

6.5 時代の多くの機能が復活しており、個人的にはこれまでの 7.x リリースの中で最も”XenApp らしい”製品だと思っています。

XenDesktop の VDI も有力なソリューションですが、集約率や既存 UI(最近はモバイルも)との親和性といった点では XenApp に一日の長があり、用途に合わせた使い分けを考えていくのが最近では当たり前となっています。

これまでの 7.x リリースでは、IMA から FMA へのアーキテクチャ変更に伴ってやや XenDesktop 色が強く出ている側面がありましたが、7.6 ではそうした箇所もかなり改善され、適材適所のデスクトップ仮想化を実現する環境が整ってきたと言えるでしょう。

現場でどんどん採用が進んでいくことを期待したいところです。

■XenApp 対応を進める上での課題と「残留」アプリケーション

ところで、既存のアプリケーションの XenApp 対応を計画し実行する際には、用途や端末戦略にもよりますが、原則としてなるべく多くのアプリケーションを XenApp の公開アプリケーションとして配信することを目指すのが基本となります。

そうすることで、端末の種別やライフサイクルと切り離し、アプリケーション本来のライフサイクルを中心に投資を計画することができるようになるからです。また、アプリケーション更新に伴うクライアントソフトウェアやミドルウェアの配布運用を省力化する効果も期待できます。

ただ、よく知られているように、古いアプリケーションや内製アプリケーションの中には、XenApp と必ずしも親和性が高くないものがあります。RDS(旧ターミナルサービス)セッションではそもそも正常に動作しないものから、プログラムに多重起動チェックが含まれているもの、ユーザープロファイル以外の箇所に一時ファイルを直接書き出す仕様のものなど、実に様々なケースが存在し、我々コンサルタントが現場で頭を悩ませるところでもあります。最終的には、あれこれの手を駆使して稼働に持って行くのですが(AppDNA や実機検証を通じて、あらかじめリスク判別したり、結果を元にアプリケーション開発チームを巻き込んでおくことも大事な一手です)、中には DVD プレイヤーのように、リモートアプリケーションとして使用すると突出して帯域を必要とするアプリケーションや、仮想化に適さない特殊なデバイスを使用しているため、そもそも XenApp で配信しない方がよい、またはできないアプリケーションが存在します(このほか、利用ユーザー数が1~2名のアプリケーションや、TV 会議など、必ずしも XenApp 配信「する必要がない」アプリケーションもあります。まずは徹底したヒアリングと仕分けから入るのが、手戻りを避けるコツです)。

こうしたアプリケーションは、いわゆる「残留」組として、端末側に残していくことになるのですが、単純に残すだけではエンドユーザーの使用感に不都合が生じる場合があります。

ファットクライアントを中心に、一部のアプリケーションだけを XenApp 配信するユースケースであれば問題は少ないのですが、シンクライアントや、既存ファット PC のシンクライアント化を前提としたユースケースの場合は、「ローカル」アプリケーションと「リモート」アプリケーションを区別して別々の起動方法を使い分けるのか、という問題が生じます。先の例で言えば、DVD プレイヤーはスタートメニューから、その他のアプリケーションは Receiver の画面から選択する、ということになります。いかにも面倒であり、なるべくどちらかに統一したいというのがエンドユーザーおよび 運用担当者の本音でしょう。ただ、Windows 端末だけで全ての業務をこなしていた時代は変わりつつあり、タブレット等のモバイルデバイスや自宅の Macの存在を前提とすれば、Receiver を中心とした「企業アプリケーションストア」のインターフェイスの方が望ましいケースの方が今は多いと思います。

それでは、どうすれば「ローカル」と「リモート」を、ひとつの Receiver インターフェイスに統合することができるのでしょうか。

■Receiver  からのローカルアプリケーション起動

幸い、XenApp/XenDesktop 7.x のアクセスコンポーネント(Citrix StoreFront。Citrix Receiver と協働して認証と UI を提供します)には、端末ローカルのアプリケーションを、Receiver の画面から起動する機能が用意されています。

これにより、エンドユーザーはそのアプリケーションがローカルなのかリモートなのかを特に意識することなく起動することができます。端末を起動した後、エンドユーザーは Receiver の画面にアクセスしさえすれば、必要な全てのアプリケーションにアクセスできるようになるわけです。運用担当者にとっても、ユーザーの使い方が画一化されているぶん混乱が少なくなり、ユーザーコールを減らすメリットを期待できます。

ローカルアプリアクセスを使用した Receiver インターフェイスのイメージ

 図1:Receiver 上でのローカル/リモートアプリケーションの一元アクセス

この機能の設定方法は、比較的単純です。XenApp の公開アプリケーションには [説明] という設定項目がありますが、ここに、以下の文字列を含めることで設定します。

  • KEYWORDS: prefer=<(ローカルアプリの)ショートカット名にマッチする文字列>

これだけです。

公開アプリケーションをエンドユーザーがサブスクリプション(利用登録)する際、指定した文字列にマッチしたショートカットが端末側に既に存在するかどうかが判定され、存在する場合には、StoreFront は XenApp 公開アプリケーションへのショートカットを作成せず、端末側のローカルアプリケーションを優先して起動するようになります。このためユーザーは、そのアプリケーションがローカルであるかリモートであるかを意識せずに、一貫性のあるインターフェイスで利用できるようになります。なお、細かい設定方法や設定例については、eDocs に詳しい記載がありますのでこちらもご参照下さい。

このようにいたって簡単かつ便利な機能ですが、現場の実装ではいくつかの留意点があります。以下にいくつか代表的な例を列挙します。

・全角半角の違いに注意する(特にスペースやアルファベット、数字など)。

・ショートカットは公開アプリケーションの購読前にあらかじめ存在していなくてはならない。

・ショートカットを後から作った場合は、公開アプリケーションを購読し直すことで更新できる。

・prefer=の”p”は小文字のみ認識される。

・公開アプリケーションの実行パスはダミーで構わない。

・使用する XenApp のバージョンは問わない(XenApp 5、6.5、7.x いずれにも適用することができる)。

■ユーザー目線で設計する

ユーザーエクスペリエンスを最適化するために XenApp / XenDesktop 7.x で新たに実装された機能は、他にもいくつかあります。共有デスクトップ/ VDI の画面内に端末ローカルのアプリケーションを統合して表示する機能や、組織の必須アプリケーションを自動的に配信し、誤って削除されないようにする機能などです(前者は Platinum Edition、後者は全エディションで利用できます)。

これらの機能を活用することで、XenApp はより便利に、よりユーザーに受け入れられるシンクライアント/モバイルソリューションとなっていきます。

XenApp はエンドユーザーが日々接する、文字通りのユーザーインターフェイスを提供するソリューションです。ユーザーは業務をストレスなく効率的に進める上で、アーキテクトが想像する以上にディテールにこだわります。従って、設計段階においても、ユーザーエクスペリエンスのディテールに注意を払い、しかるべき対応を考えることは重要なポイントとなります。本稿の内容が、そうしたユーザー目線での設計アプローチの一助となれば幸いです。

XenApp とその関連技術は、製品として積み上げられてきた歴史が長い分、カバーされる範囲も非常に広く、オンラインマニュアル(eDocs)やナレッジベースだけで最適解を見つけることが難しくなってきています。このローカルアプリアクセスのように、機能自体は eDocs で比較的網羅されていても、使いどころがわかりづらかったり、実装にあたって落とし穴があったりする例も少なくありません。

馬は馬方、ということで、アセスメント/設計サービスや教育サービスを要所で活用しつつ、プロジェクト効率の「最適化」を狙うことも、併せてご検討いただければと思います。