ログオンが遅くなる/遅いという類の現象/不具合はXenApp/XenDesktopでは
あるあるのよくありすぎる話なので
漠然と事例を求めたところであまり有意義ではないでしょう。

取りあえず一般論しか言えませんが、

1．こちらの内容を手を抜かずにご確認ください。
http://support.citrix.com/article/CTX101705

2．特定のタイミングから現象が出ているならそのタイミングで何をしたのか
些細なことでも見逃さずに確認をしてください

3．クライアント側の接続ソフトウェア(Receiverですか？)でのログを確認してください
ログを取っていて見ることができればもう少し詳細にどのタイミングで
詰まっているかが分かるはずです

同様にログオンされる側のXenAppサーバーの方にも参考になるログが沢山あります。
原因が全く分からないにしても、正常に動作しているサーバーでは発生していない
エラーや警告などは何かしらあるのではないですか？
そちらをキーにお調べになると良いでしょう。

連投すいません。具体的なご質問事項を記載しておりませんでした。

・NetScaler上でシングルサインオンを設定しているにも関わらず、
　StoreFrontのログオン画面が表示されてしまう原因として、
　何が考えられるのでしょうか。

・「ログオンの有効期限が切れました。続行するには、もう一度ログオン
　してください。」というメッセージ表示を回避し、StoreFrontに
　ログオンするためには、どのような設定が必要なのでしょうか。

再びの連投すいません。また、長文すいません。

色々と調査を進めたところ、状況が以下の通り変わりました。

　①NetScalerにドメインのユーザー名とパスワードを入力し「ログオン」をクリック
　②StoreFrontのログオン画面が表示
　③ログオンをクリック
　④「要求を完了できません。」というメッセージが表示

さらに、StoreFrontサーバのイベントログにて、上記④を実施したタイミングで
以下エラーイベントが出力されることを確認しました。

ログの名前：Citrix Delivery Services
ソース：Citrix Authentication Service
イベントID：3
レベル：エラー
説明：

[NetScaler Gateway URL]/CitrixAuthService/AuthService.asmx の AG Web Service で以下のエラーが発生しました。このエンドポイントは、2016/04/27 11:22:14 まで無視されます。
Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=3.5.0.0, Culture=neutral, PublicKeyToken=null
[NetScaler Gateway URL]/CitrixAuthService/AuthService.asmx の NetScaler Gateway 認証サービスへの通信でエラーが発生しました。認証サービスが実行されていることを確認してください。
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain)

System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
基礎になる接続が閉じられました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした
場所 System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
場所 System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.AGAuthService.AuthenticationServiceSoap.GetAccessInformation(String sessionId, String username, String domain)
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)

System.Security.Authentication.AuthenticationException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
検証プロシージャによると、リモート証明書は無効です。
場所 System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
場所 System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
場所 System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
場所 System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
場所 System.Net.ConnectStream.WriteHeaders(Boolean async)

NetScalerの方は切り分けのハードル高いので一旦無視しますが
StoreFrontの方でひとまず「認証」とか「ストア」とか「Receiver for Web」とか
「NetScaler Gateway」の設定を色々再確認してください。

以下サンプル。

・「認証」で認証方式「NSGからのパススルー」を有効にしていますか
・「ストア」でリモートアクセスを有効にしていますか
・同様に、適切な方式・アプライアンスが指定されていますか
・「Receiver for Web」で認証方式「NetScaler Gateway からのパススルー」を
　有効にしていますか
・「NetScaler Gateway」で、NSGのURLやサブネットIPアドレスや
　コールバックURLが適切に設定されていますか
・同様に、SSLを使っているならSTAの設定は適切に設定されていますか

辺り。

Sさん、ご連絡が遅くなりましたが、ご回答ありがとうございました。
以下の通り「NetScaler Gateway」の設定を色々と確認しましたが、
事象の解決には至りませんでした。

・「認証」で認証方式「NSGからのパススルー」を有効にしていますか
　→有効にしています
・「ストア」でリモートアクセスを有効にしていますか
　→有効にしています
・同様に、適切な方式・アプライアンスが指定されていますか
　→「VPNトンネルなし」方式で適切なアプライアンスをしています。
・「Receiver for Web」で認証方式「NetScaler Gateway からのパススルー」を
　有効にしていますか
　→有効にしています
・「NetScaler Gateway」で、NSGのURLやサブネットIPアドレスや
　コールバックURLが適切に設定されていますか
　→サブネットIPはNetScalerがStoreFrontサーバと通信するためのIPを、
　 コールバックURLはNetScaler Gateway URLを指定しています。
・同様に、SSLを使っているならSTAの設定は適切に設定されていますか
　→STAはStoreFrontサーバを指定しています。

なるほど。

現象を単純に見ますと、NSGからSFに対して認証情報が
パススルーする処理がコケてるように見えるわけです。
レス内容を拝見する限り、StoreFront側での設定は概ね適切なようですし
NSG側で何か設定が間違っている/不足しているのだと思います。

で、前レスでも書いたんですが、私はNSGについてはそこまで詳しくなくてですね。
エラー見る限りAuthenticationかCertification Authorityという単語周りな
気はするのですが、これ以上のアドバイスはちょっと難しいです。

可能なら正式なヘルプサポートを受けるなどご検討ください。

NetScakerを利用する場合の認証には2通りあります。
1つはNetScalerの認証画面よりログインしてアプリケーションを利用する方法と、NetScalerの認証画面
ではなくStoreFront側の認証画面で認証した後アプリケーションを利用する方法の2通りあります。
NetScalerの認証画面を利用する場合、ADサーバとLDAPによる認証が必要となり、SNIPよりtcp:389
の通信等が発生します。
エラー発生フローを見る限り、NetScalerにLDAPの設定がされていないように見受けられるのですが、
こちらの設定は大丈夫でしょうか。
NetScalerの認証画面を利用せずに直接StoreFrontでの認証を利用する場合にはLDAPの設定は必要なく
代わりに次の設定が必要です。
1.Virtual ServersのVIPで「Enable Authentication」を無効化
2.StoreFrontでStoreWebの認証設定で「NetScaler Gatewayからのパススルー」を無効化
3.C:\inetpub\wwwroot\Citrix\Store\web.configをメモ帳で開き編集する。
　<resourcesGateways requireTokenConsistency="true">
　を
　<resourcesGateways requireTokenConsistency="false">
　に変更。
　
NetScaler Gatewayとして利用する場合ですが、色々と癖があるので設定が少しややこしいかと。

しげっちさん、コメントありがとうございます。

今回は「NetScalerの認証画面よりログインしてアプリケーションを利用する方法」を
利用したいと考えております。アドバイスいただいたLDAP連携の件ですが、
実はすでに設定済みです。NetScalerのns.logを確認するにLDAP連携関連の
エラーは見当たらないため、設定としては問題ないように思えます。

追加情報となりますが、私の方で調査を進めた結果、StoreFront側で設定する
「コールバックURL」を設定しない（空欄にする）ことでNetScaler経由の
StoreFrontログオンが成功することを確認しました。ただし、社内アクセスと
社外アクセスで適用するCitrixポリシーを分けたいという要件があるため、
「コールバックURL」の指定は必須という認識です。

というのも、上記要件は「SmartAccess」により実現可能と考えており、
「SmartAccess」を利用するためには「コールバックURL」の指定が
必要という認識があります。

上記の考察は間違っておりますでしょうか。また、「SmartAccess」を
利用しない場合、別の方法で上記要件を満たすことは可能でしょうか。

NetScaler経由で制限する場合にはSmartAccessで設定する必要があります（SNIPでも制限できそうですが）。

コールバックURLを登録する場合、2点注意が必要です。

コールバックURLに登録するFQDNですが、NetScalerに割り当てているVIPのIPアドレスを解決する必要が
ありますが、こちらの名前解決はHosts等で既に実施済みでしょうか。
あと、サーバ証明書をプライベート認証局より発行している場合、ルート証明書をStoreFrontサーバに
登録する必要があります。

サーバのログに一部証明書関係のエラーが出ているのでこの2点を確認してください。
SmartAccessですが、ポリシーで指定するファーム名やアクセス条件に「*」以外を利用して細かく制限
する場合には別途ライセンスが必要になった記憶があります。

しげっちさん、返信が遅くなり申し訳ありません。

しげっちさんからのご回答を元に色々と検証を進めたところ、サーバ証明書の箇所でエラーが
発生していたらしく、再度サーバ証明書をNetScalerにバインドし直したところ、
今回の要件を満たす動作を確認しました。しげっちさん、Sさん、ご支援ありがとうございました。

そのような指定はできないと思います。（サーバ指定できるのはStoreFrontまで）
私は、公開するアプリケーション名を「○○○（サーバ１で起動）」のようにして、そのサーバ１だけでアプリケーションを公開することで、事実上サーバ指定と同じ効果を得ています。
もちろん、この場合、負荷分散／冗長化の構成にはなりませんが…。

7.6ではアプリケーションの公開はデリバリーグループ単位で行います。

おっしゃるようなことをしたければ、アプリケーションサーバを
それぞれ異なるデリバリーグループに所属させ、
それぞれのデリバリーグループでアプリケーションを
公開することがシンプルな方法です。

ご回答ありがとうございます。
dai様 >
> 私は、公開するアプリケーション名を「○○○（サーバ１で起動）」のようにして、そのサーバ１だけでアプリケーションを公開することで、事実上サーバ指定と同じ効果を得ています。

上記回答頂きましたが、アプリケーション名を変更しただけで、サーバ２では上記アプリケーションが起動されないのは何故でしょうか。

S様 >
　デリバリグループを分けて試してみます。

以上、宜しくお願いします。

お使いの製品のバージョンを明記してください。

同じPCに対し、異なるユーザー名でログオンして動作が変わるのであれば、
おおむね、そのユーザーがログオンした際に適用される個別設定
いわゆるユーザプロファイル内に、アプリケーション起動を阻害する原因があります。

普段とは異なるPCに、問題が出ているユーザーアカウントでログオンして
現象が発生するか確認するなど、どうすれば解決する（現象がでない）のかの試行を
「これは関係ないだろう」などと思い込みで除外したりせずに
いろいろなパターンでやってください。急がば回れです。

Could not find specified Citrix XenApp server.
というメッセージは、指定されたXenAppサーバーとの通信に失敗しているということです
このため、ネットワーク周りが比較的怪しいといえます。

WindowsFirewallなどが有効になっていないか、
有効ならば必要なポートやネットワークに対する疎通をブロックしていないか
確認してください。

起動中に切れて、エラーメッセージは出ないのですか？
各サーバ及びクライアントにイベントログへのエラー記録なども合わせて、状況を整理して書いた方がいいですね。

XMLの通信をHTTPSで構成していれば問題なく接続できますが、HTTPで構成している場合には
TrustRequestsSentToTheXmlServicePortの値をTrueに必要があります。
こちらの設定はTrueになっていますか？
ちなみにALLOWADDSTOREとALLOWSAVEPWDはどちらも「A」でしょうか。

test

ハイパーバイザー上のVDAにローカルログオンできるか確認した方がいいと思います。
ログオン処理に失敗してるのか、ログオン処理は続いているが起動の途中でクライアント側のDesktop Viewerが落ちているのか(DDCから見たらセッションは残っているのか等)、
貰った情報じゃちょっとわからないです。

ちょっと聞いたことがない事例なのですが、NLB経由ではなくStoreFrontのURLへ直接
アクセスした場合に結果は変わりますか？

また、シンクライアントと管理サーバの接続経路にFWやUTMなどが設置されているようであれば、必要なポートがすべて開放されているかどうかを確認されたほうが良いかなと思います。

あとはStoreFrontのバージョンを最新のバージョンへアップグレードしてみるなどが
対応として考えられます。

> Xen1、Xen2、Xen3：配信サーバ－(DeliveryControllerを3台で冗長化）
→DBサーバはどのような構成でしょうか。

XenAppサーバが「登録済み」になってなく「未登録」のままでは？

未登録だと、アイコンが表示されますが起動できないというようなメッセージが出力されると思います。sigさんの指摘の通り、DBの冗長化を行っているのであれば設定する際に注意しないと同じようなことが起こるかもしれません。サイトの作成前にミラーを組むかPowerShellを実行しないとうまくいかないと思いますよ。

XenAppのインストールで「Virtual Delivery Agent for Windows Server OS」をXenAppサーバにインストールされましたか？

また、設定時に「サーバーマシンへの接続を有効にする」を選択しないと上手く起動しないことがあります。

同様の現象になりました。試しに、ストアフロント上でDelivery Controllerの管理から、トランスポートの種類をHTTPSからHTTPに、ポートを443から80に変更することでアプリケーションが表示されるようになりました。
これによる影響については確認中です。

ストア名は変えられますが、CitrixまでのURLは固定なので無理ですね。

StoreFrontについては詳しくないないですが、WebInterfaceでは設定で変えられましたね。
サポートされるか謎ですけど、特別なことしないと変更できないみたいです。

http://support.citrix.com/article/CTX133903

ご回答ありがとうございます。

そうなんですよ、WebInterfaceでは設定で変更できてたんですよ。
だからStorefrontもできるのかと思っていました。

通りすがりさんも同じように変更しようとしたことがあるのでしょうか？

IISへ任意の名前でアプリケーションを追加すれば/Citrix/StoreWeb以外のパスでも
利用できます。
最近構築した環境で/WebApp/で接続できるようにしています。

追記でwindowsログイン画面が表示される場合は、公開アプリが表示されている上部に下記エラーメッセージが表示されています。

[再接続可能になっているにも関わらず、一部のリソースに再接続できません。セッション中にこのメッセージが通常は表示されない場合は、システム管理者に連絡してください。 ]

上記エラーメッセージが表示される条件は何でしょうか？

お世話になっております。
どうしても原因が判らず改善が出来ないため、対処方法をもしご存じの方がいらっしゃれば
ご教示いただきたく書き込みをさせていただきます。

・状況
　公開アプリケーション起動後言語バーの全体が黒くなり動かず固定されてしまう。
　クライアント言語バーは問題無し、Xen環境のみ上記状況となる

・環境
　サーバ：WinServer2008R2standard　SP1
　クライアント：Win7Professional SP1
　XenApp6.5Enterprise
　Receiver4.3

元々はATOKが設定されていましたが、ATOKをアンインストールしMicrosoftIME
のみにしても状況は変わりませんでした。

以上、何卒よろしくお願い致します。

匿名希望さんの現象と似た状態がありました。
公開アプリケーションが複数あって、そのうちの１つが終了しきっていなかったのが原因でした。
管理コンソールで対象ユーザのセッションが残っていて、リセットして解消しました。

ここまで確認したこと。

WebInterfaceのサイト構築の際、認証ポイントの設定で、WebInterface又はAccessGatewayの
選択で、AccessGatewayにして手続きを行うと、ログオンの際にアクセス権が無いと言われる。
しかし、WebInterfaceで手続きを行うとワンタイムパスワード設定でWebInterface画面で
アカウントを入力しなくても、ログオンボタンを押すだけで貸与アプリケーションが表示
される。

解決しなければならない事項は、AccessGatewayの認証ポイントで、アクセス権がないという
事象をクリアにすることなのか。
そもそも、それはしなくてWebInterfaceの認証ポイントで進めていくのか解らなくなって
しまいました。

どなたかご教示をお願い致します。

とりあえず、成功。

STA URLの記述が間違っていたことが原因でした。
WebInterfaceのサーバー(トラスト内)にSTAが無かったことも。

以上でした。