Horizon AgentとSQL Serverのセキュリティについて

今回は実際に客先で起きた事象とその解決方法をご紹介します。

一般的にVDIは、同じ業務を行う社員向けにいくつかのマスターイメージを作成した仮想マシンを大量に展開する形が非常に多いです。
しかし、業務によっては特定の人しか利用しないアプリケーションもあることから、それらは、カスタムのマスターを作成したり、そのアプリケーション利用者専用の仮想マシンを手動で作成し1対1で割り当てるケースなどもあります。
今回はこの後者である、特定のアプリケーション用の仮想マシンをメンテナンス中の遭遇した内容です。

こちらの環境では会計担当者が専用の会計アプリケーションを利用しており、会計専用のデスクトップを手動で作成し、専用の会計アプリケーションをインストールしていました。
（いわゆるスタンドアロンアプリケーションとして会計アプリケーションを利用）
導入当初は、Horiozon 6.2で運用しており問題なく動作していましたが、メンテナンスのタイミングで、Horiozn Agent7.4にアップグレードを行い、Windows Updateなどのメンテナンスを行った後、リリースを行ったら、会計アプリケーションからデーターベースに接続ができなくなり、アプリケーションが起動できなくなったという報告を受けました。

アプリケーションを起動すると「データーベースに接続できませんでした」とだけ表示され、ログは特に出力されません。

このアプリケーションは、クライアントが操作するアプリケーションの中にSQLServer 2012 Expressがインストールされており、ローカルホストでアプリケーションとデーターベースが通信をしているアプリケーションでした。

ただ、サービスを見てみると、SQLServerのインスタンスは正常起動しており、
SQLServer Management Studioからはきちんと接続でき、DBとしては正しく起動している状況でした。

こうなると、SQLServerのインスタンス名指定間違いや、DBとAPサーバー間のFirewallによる通信制御を考えてしまいますが、そもそもスタンドアロンでの運用ですし、インスタンス名も特に変更をしていません。

ためしに、Horizon Agentをアンインストールしたところ、アプリケーションは何事もなかったように起動しました。

さて、ここで考えられるのは、Horizon View Agentのインストールすることによって、何らかの影響が生じているということです。

長い前置きでしたが、実はHorizon Agentの新しいバージョン（Ver7以降）に関しては、低レベルの暗号化を無効にするレジストリーキーが記載されます。
それは、Horizon ClientとHorizon Agentの間でですよね？と思われがちですが、実はOSに影響を与える部分のレジストリも変更されます。

今回のSQLServer Express 2012は、TLS1.0が必要だったのですが、これがHorizon Agentによって無効化され、アプリケーションがデーターベースと接続できなくなったというのが原因でした。

では、解決方法をお知らせいたします。

レジストリで以下を変更します。

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥SCHANNEL¥Protocols¥TLS1.0¥Server

に、以下の値を作成します（すでにある場合は変更します）

Enabled ：1 (DWORD32Bit)

変更をWindowsを再起動すると、アプリケーションは正しくデーターベースと接続できるようになります。
※そのほか、SSL3.0などの制御もこのレジストリから行います。

やや古めなアプリケーションの場合、このようにHorizon Agentのセキュリティ回りの影響を受ける可能性がありますので、その場合このようなワークアラウンドで切り抜けるしかないですね。

もし、SQLServer系のアプリケーション利用で、Horizon Agentをバージョンアップした際にアプリケーションが動作しなくなった場合は、一度確認をしてみましょう。

参考
https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

Windows10のSysprep時注意点

世間では、Windows10も一般化し企業での導入も普及期に入りWin7からの移行のケースも増えてきたかと思います。
Windows10には、様々なエディションが有りアップデートプログラムの適用について、様々なパターンを選ぶことができるようになっています。

さて、Windows10で一般的なVLKイメージで展開する際に、まずゴールドイメージにWindows Updateを施した後に、Horizon View側で展開の設定を行うかと思います。
この際に、Sysprep経由での展開時に失敗することがあります。

実際に手動でWindows10のゴールドイメージにsysprepをかけようとしても、以下のようなエラーが出て正しくsysprep自体が動作しません。
 

実際に、C:\Windows\System32\Sysprep\Panther\setupact.logを見ると以下のようなエラーが出ています。

2017-04-02 16:25:16, Error SYSPRP Package Microsoft.MicrosoftSolitaireCollection_3.9.5100.0_x64__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
2017-04-02 16:25:16, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.
2017-04-02 16:25:16, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
2017-04-02 16:25:16, Error [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralizeValidate' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2
2017-04-02 16:25:16, Error SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2
2017-04-02 16:25:16, Error SYSPRP RunPlatformActions:Failed while validating SysprepSession actions; dwRet = 0x3cf2
2017-04-02 16:25:16, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2
2017-04-02 16:25:16, Error [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep generalize internal providers; hr = 0x80073cf2

さて、これはWindows Updateによりストアアプリの変更がおこなわれてしまうことによる弊害のようです。

実際には以下の情報が参考になります。

(参考)Windows 10 (バージョン 1511) における Sysprep 実行時の注意点
https://blogs.technet.microsoft.com/askcorejp/2015/12/20/windows-10-1511-sysprep/

こちらの中で紹介があるとおり、グループポリシーの変更行うことで対応が可能なようです。
私が検証する限り、1611ビルドのWindow10 Proのメディアに対して、Windows Update後に以下の対応を行ってもsysprepは成功しましたので、誤ってWindows Updateをかけてしまった後でもマスターの再作成は不要だと思います。


では回避法の手順を、おさらいしておきましょう。
※グループポリシーといえども、今回はClientOSのマスターであるためドメインに参加する前と考え、AD側での適用ではなく、クライアントOS本体のポリシー（ローカルコンピューターポリシー）を変更します。

1.まずは、該当のWindows10 Clientからファイル名を指定して実行をクリックします。

2.実行アプリケーションに「gpedit.msc」を入れて起動します。

3. [ローカルコンピューターポリシー]→[Windows コンポーネント]→[クラウド コンテンツ]の順にツリーを奨めていきます。

4.「Microsoft コンシューマー エクスペリエンスを無効にする」をダブルクリックします。

5.オプション選択画面が表示されますので、「有効」を選択し、OKをクリックします。

6.パラメーターが有効になっていることを確認し、ローカルグループポリシーエディタを終了します。

7.最後にコマンドプロンプトから「gpupdate」を実行し、ポリシーを反映させます。

これで、完了です。
この後は、sysprepを実行すると、正常に処理が完了します。

Horizon Viewのマスターとして利用する際に、Quickprepではなく、Sysprepを利用する場合は、あらかじめこの作業を行っておきましょう。

ゼロクライアントからHorizon Viewに接続できなくなった

Horizon View 6.2.2から採用された「TLS1.0」のデフォルト無効化。
これが、Tera1チップを搭載したゼロクライアントでは、どうやら問題になるようで、私の利用する環境では、以下のような画面が出てゼロクライアントからVDIの環境にログインできなくなりました。

「セッションネゴシエーションに失敗しました。ゼロクライアントはホストのセッションネゴシエーションの暗号設定と互換性がない可能性があります。」とのこと。

TLS1.2等で接続をしてくれればよいのですが、どうやらTLS1.0で接続をしているようでそれが仇になっているようです。

さて、この場合の対策ですが、Connection Serverにレジストリで「TLS1.0」を許可することで対応可能です。（TLS1.0を許可することが事態はセキュリティを低くすることになるので、お勧めではありません）LANなど閉じられた環境下で引き続きTera1のゼロクラを利用したい場合はこの手法を使うことで回避できます。

キーの場所：HKLM\Software\Teradici\SecurityGateway
キー名称: SSLProtocol
型: REG_SZ
値: tls1.2:tls1.1:tls1.0

値に、「tls1.0」が入っているのがポイントです。

これで、tera1チップを積んだゼロクライアントでも、接続可能になります。

（参考）Configuring security protocols on components to connect the View Client with desktops (2130798)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2130798

Horizon Viewで、AD証明書認証局から証明書をもらう方法

最近、インターネットの無害化などで、Horizon Viewを検討されるユーザーさんが増えているようです。Horizon Viewを利用すれば、VDIももちろんですが、RDSHを利用した低コストなインターネットブラウザーの配布も可能になります。もちろん、管理も楽になり、セキュリティリスクもHorizon Viewを導入することで大幅に低減します。

さて、Viewを利用するためにまず1番最初に必要なのは「Connection Server」ですね。別名Manager Serverなどとも呼ばれることがあります。
（Connection Serverの前にADやvSphere基盤は必要ですが・・・）

View Administeratorにログインすると、各サーバーのステータスが表示されますが、デフォルトですと接続サーバー（Connection Serverのことですね）が赤くなっており、証明書が公的機関のものではないと怒られています。

 
大規模やお堅い企業でセキュリティを意識される場合は、公的機関から証明書を取得して入れるのがベストであると思いますが、小規模な環境等では自社の証明局を利用するか、そのままオレオレ証明書のまま突っ走るかという話になるかと思います。

ただ、最近のHoriozon Clientでは、デフォルトですと公的機関証明書（認証局情報を持っていないいわゆるオレオレ証明書）での接続を行うと、「証明機関が無効または不正です。」と、なんとも冷たいエラーメッセージが出てしまいます。

この場合、Horizon Clientのオプションを変更することで、接続可能になります。
右上のメニューから「SSLを構成」を選択します。

ここで、「サーバーID証明書を検証しない」を選択し、OKをクリックします。

これで、解決はできますが、まあ、公的証明機関とは言わずとも、自社の認証局からの証明書でも入れて解決する方が、このオプションをユーザーごとに都度入れるよりもかっこよいですし、手間も省けますね。

View Connection Serverに、証明書を組み入れるのは少々手間がかかりますので、今回はAD上にWindowsの証明書サーバーがある前提で、楽に証明書の入れ込みを行う方法をお伝えしたいと思います。


まずは、あらかじめActiveDirectory内に証明書サーバーを構築しておいてください。

まずは、View Connection Serverがインストールされたサーバーにログインし、「ファイル名を指定して実行」をクリックします。
実行プログラムで「mmc.exe」を入力し、Enterキーを押します。

MMCコンソールを開いたら「ファイル」→「スナップインの追加と削除」をクリックします。

利用できるスナップインの項目を一番下までスクロールし「証明書」を選択し「追加」をクリックします。

スナップインで管理する証明書：で、「コンピューターアカウント」を選択します。

現在View Connection Serverで操作をしていますので、コンピューターの選択は、「炉k－刈るコンピューター」を選択し、完了をクリックします。

これで、スナップインの登録が完了しました。「完了」をクリックします。

コンソールルートの証明書から「個人」→「証明書」を選択し、現在View Connection Serverで利用されている証明書が存在していることを確認します。

Viewで利用されているかどうかを確認するためには、確認したい証明書を右クリックし「プロパティ」を開き、「フレンドリー名」が「vdm」が記載されているものになります。
※証明書をダブルクリックしても、プロパティは開きません。必ず右クリックからプロパティを引きましょう。

証明書のフォルダを右クリックし「すべてのタスク」→「新しい証明書の要求」をクリックします。

 開始する前のウィザードが表示されますので「次へ」をクリックします。

今回は既存のADに存在する証明書サーバーを利用しますので、そのまま「次へ」をクリックします。

WebサーバーというポリシーはWindowsデフォルトで存在するテンプレートになりますのでこちらを選択し、「この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください」という文字をクリックします。

いろいろな項目がありますが、無理にすべての情報を入れる必要はありません。
最低限、「共通名」（Common Name)の記述が必要です。
例えば、ユーザーから「viewcon.labo.local」というドメイン名でView Connection Serverにアクセスされる場合は、そのまま「viewcon.labo.local」と入力します。
共通名には、外部からアクセスされるFQDNを記入します。
共通名を入れるだけでも証明書としては一応発行可能ですが、必要に応じて、国や地域名、組織名などは入れておいた方がよいかと思います。

次に、「拡張機能」タブを選択します。
選択後、「キー使用法」を選択し、「CRL証明、データの暗号化、暗号解読のみ、暗号化のみ、キーの承諾、キー証明書の署名」を選択し、「追加＞」をクリックします。

さらに、下にスクロールし「基本制限」の項から「この拡張機能を有効にする」、「重要な機能制限拡張機能として登録する」、対象アルゴリズムの項から「この拡張機能を有効にする」にチェックを入れます。

次に「秘密キー」タブをクリックし、「秘密キーをエクスポート可能にする」、「秘密キーのアーカイブを許可する」をチェックを入れ、最後にOKをクリックします。

正常に値が反映される黄色の！で、表示されていた「この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください」というメッセージが消えていることを確認します。

これで、発行は完了です。「完了」をクリックします。

さて、これで新しい証明書が発行されましたが、これをViewで利用できるようにします。
まずView Connection Serverインストール時に自動的に発行された、デフォルトの証明書のフレンドリー名を変更します。
尚、インストール時に発行された証明書は、発行者がコンピューター名のFQDNと同じになっていますので、それで判断が可能です。

フレンドリー名がvdmになっているので、これを違う名前に変えて「OK」をクリックします。

次に、先ほど発行した証明書を同じように右クリックし「プロパティ」を開きます。

こちらのフレンドリー名を「vdm」にし、OKをクリックします。

 

これで、作業は完了です。MMCコンソールを閉じて、Viewのサービスを再起動します。

サービス再起動後、View Administratorの画面にログインし、アイコンが緑になっていれば証明書の問題はクリアーになります。

VMwareからは、コマンドラインで証明書を要求する方法がKBとして出ていますが、この方法であれば、マウス操作だけで簡単に証明書を組み込むことができます。

検証環境であってもオールグリーンがお好きな方は、是非やってみてください。

Horizon View 6.2.2 リリース

2016年になり、Horizonシリーズもメインバージョンが上がるのかなと思っていましたが、先にHorizon View 6.2.2がリリースされました。
今回のリリースは機能追加ではなく、バグフィックスがメインのようです。

早速リリースノートを見てみましょう。

このリリースの Horizon 6 の新機能

VMware Horizon View 6.2.2 はメンテナンス リリースです。 前のリリースのいくつかの既知の問題が解決されています。

と記載がありますとおり、まずはメンテナンスリリースであることが記載されています。

解決された問題

• ユーザーがセキュリティ サーバを介して接続している場合、ユーザーの PCoIP セッションの応答時間が低速になる場合があります。
• リモート アプリケーションに対するプリンタのマッピングが断続的に失敗します。

さてこの2点ですが、結構クリティカルな問題です。
2つめの、RDSHの公開アプリケーション時にプリンターマッピングがなされないという症状は、私も経験をしたことがあります。（同じホストとクライアントでも、RDSH公開デスクトップだったらプリンターマッピングが成功する）

小さなバグフィックスのようにも見えますが、RDSHを利用時には結構はまりどころな問題です。特にプリンターマッピングやセッション応答までに時間がかかるとなると、ネットワークまわりなどもかなり疑うことになりますので、導入時にはバージョンの確認を先にすることをお勧めします。

（参考）
VMware Horizon 6 バージョン 6.2.2 リリース ノート

VMwareの考える仮想化の世界

さて、今回はちょっと概念的なお話をしたいと思います。
VMwareでは、「One Cloud Any Application , Any Device」という言葉を掲げています。
1つのクラウドで、すべてのアプリケーションに対応、すべてのデバイスに対応するという意味です。
この1つのクラウドというのは、なにもvSphereやvCloud Airの事だけを挿しているわけではありません。

先日のvForumでも発表されましたが、vCloud AirやAWS等を、L2で接続してしまう技術（NSXによるクラウド対応）が発表されました。
つまり、様々なクラウドサービスをVMwareのテクノロジーで1つのクラウドとして扱うことができるというのがその意味です。

さて、このOne Cloud , Any Application , Any Deviceを実現するために、VMwareとしては、「Software Defined Data Center」というメッセージを出しています。
Software Defined Data Center、これが通称「SDDC」と呼ばれている無いようようになります。

SDDCを構成する上で、VMwareが定めているカテゴリー（構成要素）は、以下のようになります。

1. サーバー仮想化
2. クライアント仮想化
3. アプリケーション仮想化
4. ネットワーク仮想化
5. ストレージ仮想化
6. 仮想化の管理

この6つの要素になります。
この6つの構成要素にVMwareのどの製品が入るかを見ていきましょう

サーバー仮想化

• vSphereシリーズ
• vCloud Air
• vCloud Suite

クライアント仮想化

• Horizonシリーズ
• AirWatch

アプリケーション仮想化

• ThinApp
• App Volumes

ネットワーク仮想化

• NSX

ストレージ仮想化

• VSAN

マネージメント

• vRealize Suite

これらは、SDDCを構成する上で非常に重要な製品で有り、VMware社の柱の製品でもありますね。

是非「One Cloud Any Application , Any Device」と「Software Defined Data Center」は、覚えておいていただきたいキーワードです。

vSphere6Update1環境下で、Horizon Viewのリンククローンのプールでリコンポーズができない

さて、vSphere6 Update1を利用為た環境下で、Horizon Viewのリンククローンデスクトップのリコンポーズ（ReCompose）ができない症状が出るようです。

確認をしてみると、ちゃんとKBが出ていました。

（参考）KB:2133018

Linked Clone pool creation and recompositon fails with VMware Horizon View 6.1.x and older releases (2133018)

さて、こちらを確認すると、

• Creating and recomposing linked clone desktops fails on VMware Horizon View 6.1.x and all older releases after upgrading to vSphere 6.0 Update 1
• The Linked Clone desktop appears to be created on vCenter, but is deleted soon after vCenter complains about either "disposable" or "internal" .vmdk files this desktop

と記載があります。

まず、組み合わせとして、Horizon Viewが6.1.1以下及び、ESXi 6.0Update1の組み合わせの環境で生じるようです。
また、ディスポーザルディスク等が作成後、削除されタスクが不正終了するようです。

さてこの問題ですが、

This issue occurs when older versions of Horizon View Composer prior to VMware Horizon 6.2 require SSL v3 to communicate with VMware ESXi hosts and SSL v3 is disabled starting with VMware ESXi 6.0 Update 1 hosts. 

と記載があり、ESXi6で、SSLv3が無効になっているために起きる症状のようです。


解決方法ですが、「Horizon View 6.2」にアップグレードしてくださいが答えとなりますが、SSLv3を有効にする方法もKBとして紹介されています。

（参考）KB:2121021

Enabling support for SSLv3 in ESXi (2121021) 

セキュリティ的にも、SSLv3を有効にするよりは、Viewを6.2にバージョンアップすることをお勧めしますが...。

「View Composerに接続できません」を解決する

Horizon View 6.2が出たことですので、vCenter Server 6.0 Update 1との組み合わせで環境を構築し、ComposerをView Administratorで登録しようとしたところ、
「View Composerに接続できません」というエラーが出て先に進めない事象に遭遇しましたので、その解決法をご紹介したいと思います。

さて、環境は以下の通りです。

Windows版のvCenter ServerとSQLServerの構成に、View Composerをインストールした環境です。

この環境の場合、View Administratorでの設定は、vCenter ServerとComposerが同様の環境に入っていますので、設定は以下の画面で設定することが想定されます。

しかし、これが間違いの元のようです。

ポイントはADの設定です。
まず、vCenter Serverのインストールする仮想マシンがドメインに参加していなければそもそもですが、仮にドメイン参加をしていても、vCenter Serverを認証に利用する設定をしていなければ、このオプションは選択しても、エラーが出てしまいます。

ということで、vCenter Serverでアイデンティティソースとして追加すればそれで、解決するのですが、ADの認証はvCenter Serverで使いたくない場合はどうすればよいでしょうか？

※vCenter ServerでAD認証する設定は、vSphere6 アップデート情報(3)　vCenter Server Appliance 6でAictive Directory認証を利用する をご参考ください。

ここで、ポイントです。
View Administratorの根本に、vCenter ServerもComposerもAD認証で行うことが前提で、「View ComposerをvCenter Serverと一緒にインストール」のオプションが存在しています。この場合、vCenter Serverの登録で入力した認証情報を使って、Composerも認証しようとします。

vCenter Serverは、現行vCenter ServerのSSO機能で認証することがデフォルトになっておりますが、ComposerはWindowsのアカウントでした認証することができません。

ということで、解決法は、ｖCenter Serverの登録には、vCenter Serverで利用するSSOのアカウント（デフォルトは、administrator@vsphere.local）を入力します。

では、Composerはどのオプションで選択するかというと、「スタンドアロン View Composer Server」を選択します。ここで、vCenter Serverが参加しているADドメインの認証情報を入力します。
もちろんサーバーアドレスは、ComposerとvCentre Serverが同居していますので、vCenter ServerのIPアドレスを入力します。

View Composerは、vCenter ServerのSSO認証をサポートしていないため、ここはADのアカウントを入力します。

これで、無事に登録ができるはずです。
vCenter Server 5.5からは、vCenter ServerのSSOアカウントが有効でADアカウントの利用は別途vCenter Serverへ設定を行わないと、利用できませんのでこのような問題が発生してしまっているようですね。（Viewのこの設定に対する考え方が若干古いのかもしれません）

これで、万事解決です。

※vCenter Serverの認証でAD認証を利用為たい場合は、
vSphere6 アップデート情報(3)　vCenter Server Appliance 6でAictive Directory認証を利用する 

をご参考ください。

Horizon Viewで「プロビジョニング中にエラーが発生しました：View Composer Fault: VC operation exceeded the task timeout limit of 60 mins set by View Composer」

Horizon Viewの検証を行っていたら、

なメッセージが表示されて、正しく仮想デスクトップがプロビジョニングされない症状に出くわいました。検証環境のストレージがしょぼいので、時間がかかってタイムアウトしているようです。

調べているとコンポーザーのタイムアウト値に影響している模様。
こういうときは、KBを確認してみましょう。

Provisioning View desktops fail with the error: View Composer Fault: VC operation exceeded the task timeout limit set by View Composer (2030047)

これを確認することで。タイムアウト値を伸ばすことができるようです。

では具体的な手順を確認しましょう。

1.VMware View Composer サービスを停止します。. 詳細はKB1003895を確認しましょう。

2.Composerインストールフォルダを開きます。
　デフォルトですと、「C:\Program Files (x86)\VMware\VMware View Composer\」になります。


3.SviWebService.exe.configのバックアップを取得したのち、メモ帳で「SviWebService.exe.config」を開きます。

<VirtualCenter PropertyCollectorTimeout="60" />を見つけます。
<VirtualCenter PropertyCollectorTimeout="60" VcTaskTimeout="120" />

と、VcTaskTimeout="120"を追加します。（KBでは、90になっていますが、時間は適宜環境に合わせて変更しましょう）

4.もし、PropertyCollectorTimeoutが見つからない場合は、VcTaskTimeoutを検索してそのまま値を変更します。

ちなみに、単位は「分」となります。

5.ファイルを保存し、VMware View Composer サービスを起動します。
起動の詳細操作に関しては、KB1003895を確認しましょう。

これだけで、完了です。
プロビジョニングに時間がかかる場合には、抑えておきたい設定方法です。

Horizon View Administratorに残ったゴミな仮想マシン情報やプールを消す

Horizon Viewを利用して、仮想マシンを自動デプロイした上で、vCenter Server経由で直接仮想マシンを消したり、前回の投稿で行ったように、View Administratorに登録する際に、間違って同じマシンが何台も登録されてしまい、画面から消せなくなったことはありませんか？

今回はそういった、不整合になったデーターを消す方法をお教えします。

1.まずは、View Administratorのマシンにログインします。

2. コントロールパネル→管理ツール→ADSIエディタを開きます。

3.画面内の「ADSIエディタ」を右クリックし、接続をクリックします。

4. 識別名または名前付けコンテストを選択または入力するを選択し、

dc=vdi,dc=vmware,dc=int

を入力します。
続けて、ドメインまたはサーバーを選択または入力するを選択し、

localhost:389

と入力します。
名前は、好きな名称で結構です。

全部入力したら、OKをクリックします。

5.ツリーを展開して、必要な情報を探します。

OU=Server Group　は、デスクトッププールの情報
OU=Servers は、各仮想マシンの情報
OU=Appliactionsは、RDSH公開アプリケーション

が格納されています。

オブジェクトが多いとちょっと大変ですが、中を見ながら必要ないものはDeleteキーで削除することで、View Administratorの画面から不要なオブジェクトが消えます！