Windows の管理

ターミナル サービスを使用してアプリケーションを展開する

Greg Shields

 

概要:

  • RemoteApp のメリット
  • アプリケーションをユーザーに提供する
  • ターミナル サービスの実装を評価する
  • 優れたユーザー エクスペリエンスを保証する

目次

デスクトップから RemoteApp への移行
Web からアプリケーションを起動する
デスクトップからアプリケーションを起動する
ユーザー エクスペリエンス
パフォーマンスを予測できる RemoteApp
環境に合わせた構成

ターミナル サービスの詳細なインストール方法や使用方法については、インターネット上でも書籍でも多くの情報が提供されています。ただし、このような多くの情報源の中で、リモート アプリケーションを最も効果的にユーザーに提供するための方法に関する情報は大きく不足しています。必要なアプリケーション一式をホストするターミナル サーバーを環境内にすばやく展開するために、多大な労力を費やす必要はありませんが、ユーザーのニーズに合わせてこの作業を行うには、多少の配慮が必要です。

ターミナル サーバーを管理する場合は、管理対象のリモート アプリケーション インフラストラクチャを客観的に眺め、次の点を確認します。まず、アプリケーションをどのように展開しているか、2 番目に、リモート デスクトップと TS RemoteApp のどちらをユーザーに提供しているか、3 番目に、ユーザーがアプリケーションへのアクセスに使用しているのは、静的なリモート デスクトップ プロトコル (RDP) ファイル、Web ページ、デスクトップ ショートカットのいずれであるかを確認します。

そして 4 番目の確認事項は、ターミナル サービス アプリケーションのユーザー エクスペリエンスをどのように評価しているかです。Windows Server 2008 に実装されたターミナル サービスの機能強化によって、これらの重要な確認事項に対して驚くほど優れた回答が提示される可能性があります。

デスクトップから RemoteApp への移行

Windows Server 2008 では、サービスと機能が大幅に強化されたことによって、ターミナル サービスの管理作業が単純化されます。Windows Server 2008 で導入される新機能と変更点の一覧については、TechNet Magazine 2008 年 11 月号の記事「強化されたターミナル サービスを使用してプレゼンテーション層を仮想化する」を参照してください。この記事では、Joshua Schnoll が Windows Server 2008 への移行によって提供される新機能について説明しています。これらのうち、間違いなく最も重要な機能強化は、ターミナル サーバーを使用してデスクトップ全体ではなく個々のアプリケーションをユーザーに展開できるようになったことです。

TS RemoteApp と呼ばれるこれらの個々のアプリケーションは、ユーザーからは、ローカル デスクトップに直接インストールされているかのように見えます。RemoteApp をクリックして起動すると、そのアプリケーションのみがローカル コンピュータ上に表示されます。余分なタスク バーや 2 つのデスクトップは表示されないので、ローカル以外のシステムを操作していることを意識せずに済みます。実装とユーザーのニーズにもよりますが、TS RemoteApp は通常のローカル デスクトップ アプリケーションと同じように操作できるので、デスクトップ全体を展開するよりも便利です。

Windows Server 2008 では、TS RemoteApp マネージャ コンソールを使用することによって、新しい TS RemoteApp を簡単に作成できます。このコンソールは、[管理ツール] から起動します。[操作] ウィンドウの [RemoteApp プログラムの追加] をクリックすると、RemoteApp ウィザードが起動します。このウィザードは、既にサーバーにインストールされている可能性があるアプリケーションの一覧を、ターミナル サーバーの Windows Management Instrumentation (WMI) ストアに照会します。図 1 は、この一覧の例を示しています。

図 1 ターミナル サーバーにインストールされているアプリケーションが一覧表示される RemoteApp ウィザード

この一覧から、RemoteApp を作成するアプリケーションを選択して、[次へ] をクリックします。目的のアプリケーションが一覧内に含まれていない場合は、[参照] をクリックして、そのアプリケーションのプライマリ EXE ファイルを探します。通常は、アプリケーションの起動に使用される EXE ファイルが該当します。ウィザードの処理が完了すると、リモート アプリケーションを展開できるようになります。

新しく作成した RemoteApp を右クリックしてプロパティを表示した後、いくつかのオプションを調整できます。名前、場所、アイコン、およびエイリアスに関する情報を変更できるだけでなく、コマンド ライン引数を入力することもできます。この機能は、起動時に一連の引数を渡さなければ正しく動作しないアプリケーションを展開する場合に役立ちますが、いくつかのアプリケーションと組み合わせて使用し、リモート コンテンツへのリンクを作成することもできます。

すぐには気が付かない場合が多いかもしれませんが、TS RemoteApp に移行することによって、ユーザーの画面上で、単にアプリケーションを提供するだけでなく、さまざまなメリットを提供できます。また、少し手を加えるだけで、RemoteApp を使用して、あらかじめ構成したコンテンツを自動的に起動することもできます。

たとえば、ユーザーにアプリケーションではなく特定のドキュメントを展開する必要があるとします。つまり、ユーザーが空の Microsoft Office Word または Microsoft Office Access アプリケーションに接続できる RemoteApp を作成するのではなく、特定の Word 文書や Access データベースに接続できるようにします。このような場合、アプリケーションのプライマリ EXE の名前に続いて、目的のドキュメントの名前を引数として入力すると、この動作を実現できます。したがって、\\fileServer\fileShare\CompanyPTO.accdb に格納されている Access 2007 ベースの有給休暇データベースに接続する場合は、"有給休暇データベース" という名前の新しい RemoteApp を作成し、ドキュメントの場所をコマンド ライン引数として入力します。この "有給休暇データベース" アプリケーションをダブルクリックして起動すると、正しいデータベースが既に読み込まれた状態の Access に自動的に接続されます。

このように、リモート コンテンツへの接続を作成することは、RemoteApp の便利な利用方法の 1 つです。ただし、どの RemoteApp への接続を作成する場合も、その RemoteApp の起動に使用するアイコンへのリンクをユーザーに提供する必要があります。以降のセクションでは、Windows Server 2008 のターミナル サービスを使用してリンクを提供する方法をいくつか紹介します。

Web からアプリケーションを起動する

新しい TS Web アクセスの役割サービスを使用すると、構成済みの Web ページ上でアプリケーションのショートカットをホストできます。この役割サービスは、環境内のターミナル サーバーと統合され、ユーザーがアプリケーションを 1 つの場所から見つけて起動できるページを提供します。図 2 は、この Web ページの例を示しています。

fig02.gif

図 2 展開済みの RemoteApp が表示された TS Web アクセスの Web ページ

このようなページを作成するには、TS Web アクセスの役割を既存の IIS サーバーにインストールし、この TS Web アクセス サーバーのコンピュータ アカウントをドメインの TS Web Access Computers グローバル グループに追加します。環境の規模が小さい場合は、既存の 1 台のターミナル サーバーに TS Web アクセスをインストールして、1 台のサーバーによるソリューションを構築できます。

RemoteApp をインストールしたら、TS RemoteApp マネージャで、構成済みの RemoteApp を右クリックし、[TS Web アクセスで表示する] をクリックして、TS Web アクセスを有効にします。バージョン 6.1 以降のリモート デスクトップ クライアントを使用している場合は、https://serverName/ts を参照すると、アプリケーションのショートカットの一覧を表示できます。表示されたショートカットの中から任意のショートカットをクリックすると、自動的に RemoteApp が起動します。

TS Web アクセスを使用すると、アプリケーションを見つけて起動するための使いやすいインターフェイスを簡単に提供できます。このツールは、特にアプリケーションやバージョンを定期的に変更する場合に役立ちます。この場合、必要な Web サイトの更新作業は、TS Web アクセス内に古いアプリケーションやバージョンへのリンクが表示されないようにし、新しいアプリケーションやバージョンのインストールが完了したら、それらのアプリケーションやバージョンへのリンクを表示することだけです。

ただし、このツールにはいくつかの制限があります。1 つは、ユーザーがアクセスできるアプリケーションを制限するためのメカニズムが組み込まれていないことです。ターミナル サーバー上に作成され、TS Web アクセス内で公開されている RemoteApp には、認証されたすべてのユーザーがアクセスできます。

2 つ目の問題は、ユーザーが通常アプリケーションを使用する方法と関係があります。アプリケーション (Word など) を起動するときに、アプリケーションのショートカットを実際にクリックすることがどれほどあるでしょうか。まずそれほど多くはないでしょう。通常は、既存の Word 文書をダブルクリックして、その文書があらかじめ読み込まれた状態で Word を起動すると思います。

残念ながら、TS Web アクセスではこのような方法でアプリケーションを起動することはできません。ドキュメントをダブルクリックして、それに関連付けられているアプリケーションを起動するユーザーにとって、TS Web アクセスは適切なソリューションとして認められない可能性があります。でも安心してください。次のセクションでは、このような場合にさらに適した方法を紹介します。

デスクトップからアプリケーションを起動する

ターミナル サービスでは、ユーザーがドキュメントをダブルクリックしてアプリケーションを起動できるように、リモート アプリケーションへのリンクをデスクトップに "インストール" する機能が提供されます。実際にどのような処理が行われるかというと、RemoteApp の RDP ファイルが Windows インストーラ パッケージ (MSI ファイル) 内にラップされます。この MSI ファイルが、環境内のデスクトップにインストールされます。

また、この MSI をインストールすると、デスクトップ上のファイル拡張子の関連付けが変更され、ファイルをダブルクリックしたときに、そのファイルに関連付けられたターミナル サーバー上の RemoteApp が起動するようになります。図 3 は、Word の RemoteApp がインストールされたときに、クライアント システム上のファイル拡張子の関連付けが変更されるようすを示しています。この状態で、通常の Word の拡張子を持つファイルをダブルクリックすると、リモート デスクトップ接続を経由して Word が起動します。

fig03.gif

図 3 リモート デスクトップ接続を起動するように変更されたファイル拡張子の関連付け

既存の RemoteApp を基に Windows インストーラ パッケージを作成するには、まず TS RemoteApp マネージャを参照します。目的の RemoteApp を右クリックし、[Windows インストーラ パッケージの作成] をクリックします。既定では、作成されたすべての Windows インストーラ パッケージは C:\Program Files\Packaged Programs に格納されますが、このパッケージの作成先は RemoteApp ウィザードから変更できます。また、このウィザードでは、RemoteApp をホストするサーバーの名前と使用するポート、サーバー認証、証明書の設定、および TS ゲートウェイの設定も構成できます。

図 4 は、デスクトップにインストールされたアプリケーションがどこに配置されるかに関する設定を示しています。図からわかるように、デスクトップ上にショートカットを作成することも、[スタート] メニューのフォルダ内にショートカットを作成することもできます。この画面に表示される最も重要なオプションは、一番下にあるチェック ボックスです。これは、クライアントの設定を上書きするかどうかを指定するチェック ボックスで、このチェック ボックスをオンにすると、RemoteApp のファイル拡張子の関連付けがローカル デスクトップからターミナル サーバーに変更されます。ユーザーがドキュメントをダブルクリックして、TS によってホストされているアプリケーションを起動できるようにする場合は、このチェック ボックスをオンにする必要があります。[次へ] をクリックし、[完了] をクリックしてウィザードを終了します。

図 4 Windows インストーラ パッケージの作成時に変更できる、クライアントのファイル拡張子の関連付け

当然のことながら、デスクトップへのインストールを使用してアプリケーションへの接続を提供するメリットは、ユーザーの操作を変更する必要がないことです。アプリケーションがインストールされると、ユーザーは通常どおり、ドキュメントをダブルクリックしてアプリケーションを起動できるようになります。

ただし、この方法には、デスクトップの管理作業が増加するという欠点もあります。この方法で RemoteApp を使用する場合、その RemoteApp へのアクセスを必要とするすべてのデスクトップに RemoteApp をインストールする必要があります。この処理は、グループ ポリシー ソフトウェア インストール (この後すぐに説明します) を使用すると単純化されますが、それでも余分な管理作業が発生します。また、アプリケーションを変更する場合、おそらく各デスクトップにインストールされている RemoteApp の更新も必要になります。

Windows インストーラ パッケージの作成が完了すれば、グループ ポリシー ソフトウェア インストールを使用してこのパッケージをインストールする処理の構成は難しくありません。まず、グループ ポリシーからアクセスできるファイル共有を作成します。ターミナル サーバーが 1 台の環境では、このファイル共有の場所として、既定の場所である、ターミナル サーバー上の C:\Program Files\Packaged Programs フォルダが適している場合があります。必ずこのフォルダと共有に適切な権限を割り当て、グループ ポリシーの処理中にクライアントがこの共有にアクセスできるようにしてください。次に新しいグループ ポリシー オブジェクト (GPO) を作成し、"コンピュータの構成\ポリシー\ソフトウェアの設定\ソフトウェアのインストール" を参照します。[ソフトウェアのインストール] を右クリックし、[新規] をポイントして、[パッケージ] をクリックします。表示されたダイアログ ボックスで、RemoteApp 用に作成した MSI ファイルを選択します。展開方法を選択するよう求められたら、[Advanced] (詳細) をクリックします。

ここで、1 つの選択肢が提示されます。RemoteApp のインストール処理は非常に簡潔で、C:\Program Files\RemotePackages フォルダにインストールされるのは RDP ファイルとアイコンぐらいです。このため、[管理の対象でなくなったときは、このアプリケーションをアンインストールする] チェック ボックスをオンにしておくとよいでしょう。このチェック ボックスをオンにすると、GPO が削除されたか、この GPO が適用されない新しい OU にコンピュータが移動されたときに、RemoteApp が自動的にコンピュータから削除されます。このオプションを有効にすると、コンピュータとアプリケーションが管理対象であるかどうかを基準に RemoteApp が削除されるので、非常に便利です。

ユーザー エクスペリエンス

上記の方法を使用してアプリケーションを展開できることは非常に便利ですが、ターミナル サービスの管理作業には、アプリケーションの作成と展開以外にも重要な作業が含まれます。それは、実装がユーザーのニーズを満たすようにすることです。アプリケーションの配布について考えるときは、どのような場合でも、ユーザー エクスペリエンスの質を測るための主観的なパフォーマンス評価指標を検討する必要があります。確固たる評価指標を使用して、展開したターミナル サービスの有効性を数値化することは困難ですが、成功を判断する指標として、ユーザーの総合的な満足度を評価する必要があります。

たとえば、特にユーザーが同じサーバー上のリソースを共有している場合、ユーザーの管理が非常に面倒に感じられることがあります。ターミナル サービスでは、複数のユーザーが 1 台のサーバーにアクセスして、そのサーバーにインストールされているアプリケーションを共有します。多数のユーザーを少数のサーバーにまとめることができれば、管理するアプリケーションの数が少なくなるので、より簡単にアプリケーションを管理できます。管理するアプリケーションの数が少なければ、修正プログラムを適用する手間もかからず、より制御が行き届いた環境になり、管理項目も減少します。

このような形でユーザーを集約する場合、ターミナル サーバーの管理者はシステムの "子守り" をする必要があります。ターミナル サーバー ファームを適切に管理するには、システム上でユーザーが行う操作を観察し、積極的に変更を加える必要があります。たとえば、再構成やロックダウンなどの変更を実装し、あるユーザーの不適切な操作が他のユーザーの操作に影響を与えないようにします。

効果的なターミナル サーバーの管理の例としては、パフォーマンス警告を構成して、プロセッサの使用率が急激に上昇して非常に高い数値になり、そこから下降しない場合に通知を受けるようにすることが挙げられます。多くの場合、このような動作は、あるプロセスがプロセッサ使用率の急激な上昇を招いたか、あるユーザーが共有システム上で過剰にリソースを消費する操作を行ったことを示します。原因のプロセスを突き止めて強制終了しても、それは問題解決の第一歩にしかなりません。原因のプロセスがこのように動作した理由を解明することが、長期的に見た問題の解決策と言えます。

このような場合、リモート アプリケーションのパフォーマンスが、ローカル デスクトップ上のアプリケーションと少なくとも同等であることが基準になります。補足記事「ターミナル サービスの主要なパフォーマンス カウンタ」では、ターミナル サービス環境の制御に役立つパフォーマンス モニタのカウンタを紹介します。

パフォーマンスを予測できる RemoteApp

RemoteApp の実体はターミナル サービス セッションで、セッションの画面サイズは、起動するアプリケーションの画面サイズと等しくなります。したがって、セッション画面がアプリケーション画面よりも大きくなることはないので、リモート アプリケーションがローカル アプリケーションであるかのように表示されます。

ただし、マイクロソフトによる RemoteApp の実装で提供される機能は、上記の説明から想像される機能よりもはるかに優れています。RemoteApp を展開する場合とデスクトップ全体を展開する場合では、起動と操作に必要なリソースが異なります。リモート デスクトップを起動するには、explorer.exe のインスタンスを作成してデスクトップ シェルを操作する必要があります。また、explorer.exe と共に起動するように構成されたすべてのプロセスも必要です。これには、システム トレイ アプリケーションやヘルパ アプリケーションなど、標準のデスクトップに必要なすべてのサービスとプロセスが含まれます。

対照的に、RemoteApp を起動するために、explorer.exe のシェル全体や、すべてのアドオンは必要ありません。実は RemoteApp では、explorer.exe の代わりに、rdpshell.exe と rdpinit.exe という 2 つのプロセスが使用されます。これらは不要な機能が取り除かれたプロセスで、RemoteApp を起動するための代替シェルおよびシェル ログオン アプリケーションとして機能します。

図 5 は、ターミナル サーバーのリソース使用状況を示す簡単な例です。この例では、2 人のユーザーが電卓アプリケーションに接続し、このアプリケーションを起動します。User1 はデスクトップ全体のセッションにログインし、User2 は事前に作成した calc.exe の RemoteApp インスタンスに接続します。calc RemoteApp を起動するために実行する必要があるプロセスのリソース使用量は User2 の方が高くなっていますが、これらのプロセスによって使用されるメモリの量の合計は、User1 の explorer シェルによって使用されるメモリの量の合計よりも少なくなっています (図 6 参照)。

fig05.gif

図 5 デスクトップと RemoteApp との間のリソース使用量の違いを示すタスク マネージャ

図 6 メモリ使用量の例
実行されるプロセス User1 – デスクトップ全体 User2 – RemoteApp
Explorer.exe 7,064 KB n/a
Tasking.exe 1,792 KB 1,704 KB
Dwm.exe 588 KB 516 KB
Rdpclip.exe 1,032 KB 908 KB
Calc.exe 648 KB 716 KB
Rdpinit.exe n/a 860 KB
Rdpshell.exe n/a 828 KB
合計 11,124 KB 5,532 KB

このように RAM の使用量を減少させることは、パフォーマンスの向上を図るうえでの 1 つの考慮事項に過ぎません。ユーザーの操作がプロセッサの使用率に与える影響も考慮する必要があります。デスクトップ全体を展開すると、ユーザーはターミナル サーバーにインストールされているどのアプリケーションでも実行できるようになります。

システムが適切にロックダウンされていなければ、ターミナル サービスを利用して Word 文書にデータを書き込む、消費リソースの少ないユーザーが、より多くのリソースを必要とする別の強力なアプリケーションを起動してリソースを大量に消費するユーザーに変わってしまう可能性があります。ユーザーの操作を予測できなければ、ユーザー 1 人あたりに必要なリソースを計画することは難しくなります。また、ターミナル サーバーの管理も複雑になり、それによって 1 人のユーザーの操作が他のユーザーの操作に影響を与える可能性も高くなります。

この予測不能性を示す例としては、おそらく Internet Explorer が最適でしょう。通常、Windows Server の各インスタンスにインストールされる Internet Explorer は、あまり多くのリソースを使用することなく実行できます。ただし、さまざまなプラグインを必要とする、適切にコーディングされていない Web サイトを表示するために Internet Explorer を使用すると、Internet Explorer によって消費されるリソースの量は劇的に増加します。ユーザーがデスクトップ セッションの実行中に、Internet Explorer を予期しない形で不適切に実行することによって、知らず知らずのうちにターミナル サーバー上の利用可能なリソースを大量に消費した場合、他のユーザーのパフォーマンスが低下する可能性があります。

デスクトップ全体を展開した場合と比較すると、RemoteApp の構造は、リソース使用量を予測しやすいと言えます。RemoteApp を起動したユーザーは、起動したアプリケーションと、そのアプリケーションから起動した他のアプリケーションのみを操作できます。したがって、パフォーマンスという観点では、ユーザーの操作をより正確に予測できる傾向があります。

環境に合わせた構成

この記事の最終的な目標は、リモート アプリケーションをユーザーに展開するときに使用できる方法を紹介することです。Windows Server 2008 で提供されるターミナル サービスの新機能によって、複数の方法でアプリケーションへのリモート接続を実現できるようになります。デスクトップと Web のどちらでアプリケーションをホストするか、およびデスクトップ全体と RemoteApp のどちらを展開するかを考慮して、各環境に適した構成を決定してください。

ターミナル サービスの主要なパフォーマンス カウンタ

通常、ユーザー エクスペリエンスを評価する場合、主観的な方法として、評価指標の他に個人レベルの意見収集などが使用されますが、役立つパフォーマンス カウンタもいくつか提供されています。これらを使用して、ユーザーの満足度に影響を与えるターミナル サーバーのパフォーマンスを計測できます。ターミナル サーバー上で、以下のカウンタの値を計測することを検討してください。

Memory\Available MBytes このカウンタの値が非常に小さい場合、ターミナル サーバー上のプロセスによって、利用可能な物理メモリのほとんどが消費されています。この値が小さいことは、必ずしも状態の悪さを示しているわけではありませんが、Threads カウンタと Pages/Sec カウンタの値が大きく、このカウンタの値が小さい場合は、ターミナル サーバーにアクセスしているユーザーの数と、ユーザーが行っている操作の数が多すぎることが考えられます。

Memory\Pages/Sec これは、メモリとディスクとの間で発生する読み取りと書き込みの頻度に関するカウンタです。このカウンタの値が大きく、Available Mbytes の値が小さい場合、サーバーへの負荷を処理するためのメモリが不足していて、その結果、ユーザーのパフォーマンスが低下している可能性があります。

Processor\% Processor Time このカウンタは事実上、生産的な処理によるプロセッサの使用率を示します。特にマルチプロセッサ システムでは、ハングしたプロセッサや、使用率が急激に上昇したプロセッサを確認できるので、このカウンタに十分な注意を払う必要があります。

System\Threads サーバーによって実行されるプロセスは、それぞれ複数のスレッドで構成されます。Threads カウンタは、システム上のすべてのプロセスを構成するスレッドの合計を示す整数値です。多くのユーザーがターミナル サーバー上のシステム リソースを同時に使用するので、ターミナル サーバー上で実行されるスレッドとプロセスの数は多くなる傾向があります。このカウンタの値が増加した場合、多くの操作がサーバー上で同時に実行されていることが考えられます。通常は、スレッドの数が多いと、コンテキスト スイッチの数も増加します。これは、サーバーが各プロセスの要求を処理しようとするからです。

System\Context Switches/Sec コンテキスト スイッチは、プロセッサが処理するスレッドが切り替わるたびに発生します。コンテキスト スイッチが発生するたびに、わずかながらオーバーヘッドも発生するので、スレッドの数が多いだけでなくこのカウンタの値も大きい場合は、同時にアクセスしているユーザーの数と、ユーザーが行っている操作の数が多すぎる可能性があります。

System\Processor Queue Length プロセッサが負荷を処理しきれない場合、それらの要求はキューに格納されます。このキューの状態を示すカウンタが Processor Queue Length です。このカウンタの値が大きい場合、サーバー上のプロセッサに対する要求の数が多すぎることが考えられます。この場合、ユーザー エクスペリエンスにも影響が及ぼされる可能性があります。

Terminal Services\Active Sessions および Terminal Services\Total Sessions この 2 つのカウンタの値から、リソース使用率をターミナル サーバー上で作業しているユーザーの数と照らし合わせて評価できます。Active Sessions は、現在セッションを確立しているユーザーの数を示し、Total Sessions はアイドル状態のユーザーや切断されているユーザーも含むセッション ユーザーの数を示します。この 2 つのカウンタを合わせて監視することによって、サーバーが過負荷になることなく処理できるユーザーの数を特定できます。サーバーが過負荷になると、ユーザーのパフォーマンスは低下します。

カウンタの実際の値は、ハードウェア構成、インストールされているアプリケーション、およびシステム上のユーザーの数と種類によって異なります。したがって、ここで目安として具体的な値を提示すると、誤解を招く可能性があります。各環境で、評価指標の値 (数や時間) が通常の運用時と大幅に異なる場合に、その値を記録して変化のパターンを特定し、ユーザーのパフォーマンスが低下している可能性があるかどうかを判断するときの目安にしてください。

Greg Shields (MVP) は、Concentrated Technology の共同創設者であり、IT の専門家です。最新の著書には、『Windows Server 2008: What's New/What's Changed』(SAPIEN Press) があります。彼の連絡先については、www.ConcentratedTech.com を参照してください。