以下のURLは確認されていますでしょうか。

http://docs.citrix.com/ja-ja/receiver/windows/4-3/ica-securing-connections-v2/receiver-windows-configure-passthrough.html


また、シンクライアント側の設定の問題であれば、任意の1台で展開用のマスターを作成して再展開するという手も取れそうな気がしますが。

チャル様

ご教示頂いたURLを確認してみましたが、特に問題なさそうです。

また、Windows認証を求められた際、入力→アプリが開く→アプリを閉じる→ログオフする→PCシャットダウンする→PC起動すると、今度は認証を求められないこともあります。
(PCシャットダウンではなく再起動の場合は認証が求められます)
できたりできなかったりで全くわかりません。

任意の１台で展開用のマスターを作成することも可能なのですか。
そちらも確認してみます。

そうなってくると同じ端末からでもユーザで違いがあるか？といったような切り分けも必要かもしれません。

シンクライアントのマスター作成については購入されたベンダーなどへの確認は必要かと思いますが、USBで展開するような方法は何度かやった事はあります。

↓例えばhpの場合
http://h50146.www5.hp.com/lib/products/thinclient/pdf/hp_thinclient_doc00023.pdf

チャル様

お世話になります。

同じ端末から別ユーザでも確認してみます。

マスターを作成してUSBで展開する方法ですが、正常端末と対象端末が物理的に別な場所にあり、難しい状況です。
USBではなく、ファイルで展開もできるのでしょうか。
リモートデスクトップで接続してUSBリダイレクトして可能であればできるかもしれません。

機種がわかりませんが、USBを利用する場合USBブートが必要になると思いますので、USBリダイレクトでは更新できないかもしれません。

可能かわかりませんが遠隔地の方に手順書とUSBメモリを渡して作業をしていただくか、
更新サーバを利用したアップデートができる場合があるので、確認されては
いかがでしょうか。
例えば、hpならHP Device Managerというような方式があります。
http://jp.ext.hp.com/thin-clients/knowledgebase/

いずれにしてもこれらはシンクライアント端末側の設定が統一されていないということであれば有効ですが、原因が別であれば、効果はないかもしれません。

WIをロードバランスしてないかとか、ServiceサイトなのかWebサイトなのかとか
そもそもXenaDesktop/Appのバージョンが何かとか気になる

同じような経験は何度かあるけど大体RDP関連のグループポリシーだとか
Receiverがおかしい(中途半端な権限でインストールしたとか)だか
そんな理由だった気がするが詳細思い出せない

補足）サーバOSは、全てWindowsServer2012R2です。
多量印刷の失敗による事も考えましたが、B、C側でもより多く印刷していました。
現象発生のトリガーが判ればもう少し進展しそうです。

＞障害が発生しているモジュール名: ntdll.dll
落ちるexeに関わらずここにOS側のdllが記載されてたら
ダンプ解析しないとログじゃ分からないですよ。
メーカーに問い合わせをしてください。

ログの詳細はわかりませんが、以下のHotfixは適用済みでしょうか。
↓
ICATS750WX64019

その他
・怪しいプリンタドライバor不要なプリンタドライバの削除

ご回答ありがとうございます。
問い合わせ先は、Citrixかマイクロソフトかはたまたサーバメーカか検討つかず、
とりあえずHotfixを適用してみようと思います。

複数のFAT端末で同様の事象が発生しない限り調査はおそらく徒労です。

同様事象がおきないということは、概ねそのAT端末固有の問題なので、
現象が発生するしないの境界線がどこなるのか、
FAT端末側の怪しい設定/ソフトやらを変えたり戻したり
パフォーマンスモニタで監視するとかして徹底的に調査するしかないです。

とりあえずはReceiverを徹底的に綺麗にアンインストールして入れなおす、
より新しいバージョンを例外的にいれるなどして解決を祈るのもお勧めです。

また、この手の「根本的に動かない」とか「エラーがでる」とかとは異なる
パフォーマンスの類の問題はちゃんとCdf Traceをしてそのログを
Citrixのサポートに送ってヘルプを請わないと解決し難いと思いますよ。

S様

説明不足で申し訳ございません、お客様の複数FAT端末で発生しています。

＞また、この手の「根本的に動かない」とか「エラーがでる」とかとは異なる
＞パフォーマンスの類の問題はちゃんとCdf Traceをしてそのログを
＞Citrixのサポートに送ってヘルプを請わないと解決し難いと思いますよ。
ありがとうございます。
既にCitrix社に問合せをしているのですが、こちらからもCDF Traceログ解析などの提案をしてみます。

Citrix社にCase問い合わせしてるならここのBBSよりそちらを信用されて
そちらに集中された方がよろしいかとは思いますが
一般論としてこの手の状況を切り分けるには、
とにかく現象が再現する条件を切り詰めていくことが重要です。

RDPでは発生せず、ICA(=Receiver)を使って発生するのであれば、
ごく自然に考えればICAのプロトコルかReceiverが何かしらの
要素で疎外されていると考えてよいです。

Citrix社によりCDF Traceなどが解析されればそれだけで結構辺りが付きそうですが
個人で努力するのであれば、
・Receiverを綺麗に再インストール/Verupする
・WireSharkなどをFAT端末に仕込んで、ネットワーク周りを監視する
・同様にパフォーマンスモニタを仕込んで、パフォーマンスを周りを監視する
・徹底的にFAT端末のサービスや常駐タスクを止めて、
　現象が発生しなくなるようなら、影響ありそうなサービス/タスクを探る
辺りが結局無難な切り分けです。

ICAセッションの設定はXenAppポリシーとセッション ホストの構成のICA-TCPとADのADMテンプレにあった気がします。
優先順位は知らないけども。

Keep-Aliveのポリシーはすんなり動いたのをあまり見たことがない（率直）

コンピューターポリシーなので、Keep-Aliveのポリシーが効いているかは
コンソールでログオンしてレジストリの値を見ればわかります。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix
の
IcaEnableKeepAliveとICAKeepAliveIntervalですかね。
ここが1と180とかになってないならそもそもCitrixポリシーが効いて|当たってないので
そっち方面を攻めることになります。
まずそちらご確認ください。

Reppa氏の仰るようにリモートデスクトップ側のポリシーや
RDセッションホストにも同様に設定があります。
通常はCitrixポリシー側が勝つようですが、6.5+Windows10は非サポートな組み合わせ
だと思うのであまり信用せず、そちらで何か設定されていないか
念のためご確認ください。

レジストリ的には当たってるようであればそうですねぇ。
セッションアイドルタイマーに関する記述がありませんがデフォルトですか？
ネットワーク切断後にセッションはアイドル状態になるので、
もしこのタイマーが有効でかつ設定秒数が短いと、
そっち側の制御で切断されている可能性があります。

Citrixのセッションアイドルタイマーポリシーは、XenApp(RDSサーバー)には効かないので
↓のURLとか参考にして、ローカルポリシーやらで設定されてないか確認してみてください。
https://technet.microsoft.com/ja-jp/library/cc754272(v=ws.11).aspx
もしくは、メモ帳起動後にしばらく放置(アイドルに)して、自動的に切断されないか
確認してみてください。念のため。

セッションアイドルタイマーに関してはグループポリシーのリモートデスクトップセッションの設定も合わせて行っております。
セッションアイドルタイマー
→有効
セッションアイドルタイマーの間隔
→120分
切断セッションタイマー
→有効
切断セッションタイマーの間隔
360分

取り急ぎレジストリの値を調べました
IcaEnableKeepAlive 0
IcaKeepAliveInterval 60

AppCenterにて設定変更後、対象XenAppサーバーを再起動しても上記レジストリ値に変化はないです、ためしに手動で以下の設定に変更して、同じくメモ帳を起動し、ネットワーク切断したところ
IcaEnableKeepAlive 1
IcaKeepAliveInterval 180

セッションの状態がアクティブの状態が60秒と伸びましたが、180秒とはなりませんでした。
XenApp6.5でkeepAliveはまともにうごかないのでしょうか？

ポリシー適用しても当該レジストリが書き変わらないのは明らかにおかしいので
ポリシーの設定の仕方とかはよく見直してください。
適用対象の指定の仕方とか。ほかのポリシーで上書きされてないかとか。

で、いまさらですが、ICA Keep-Aliveタイムアウトで指定する秒数は、
Keep-Aliveのパケットをサーバーが送信する「間隔」を定めるものです。
このKeep-Aliveパケットの送信は、ユーザーセッションが確立した後、
定期的に行われます。
「ネットワークが切断した後の○○秒後に送信」とかではないです。

何が言いたいかというと、どれだけ長大な間隔を指定したとしても、
NW切断が発生した直後にその送信間隔が来てしまえばそのタイミングで
セッションは切断状態になる、ということです。

この間隔を長くすればするほど、切断後のセッションアクティブ維持時間を
「確率的に伸ばすことができる」ということではありますが、
このKeep-Alive機能で「NW切断後確実に180秒間アクティブ状態をキープする」
ことは困難です。

この辺り、誤解されている気がしたので念のためご確認ください。

ご指摘の通り、KeepAliveの動作について誤解しておりました。
ご説明ありがとうございました。

ポリシー適用にてレジストリ値が書き換わらない件については再確認するとして、
KeepAliaveを設定するメリットが見えなくなりました。

当方の想定として、ネットワーク切断後、KeepAlive設定時間とReceiver再接続時間を合わせておけばその間はネットワーク復旧時に公開アプリも自動復旧すると想定しておりましたが
よくよく考えてみるとKeepAliveを設定しなくてもクライアントの自動再接続を設定していれば想定した同様の動作が可能ということが判明しました。

そもそもkeepAliveはどのような要件で必要になるのか、ご存ぞの方教えていただけますか？

最近の環境ではKeep Aliveの機能が必要になることはほぼありません（きっぱり）
（実際、Citrixのデフォルトではこの機能は無効になってるでしょう？）

なぜなら、おっしゃるようにクライアントの自動再接続が機能している限り、
ネットワークが切断され、セッションが切断されても、
セッションがログオフされず残留している限り、さらっと問題なく切断セッションに
再接続できるからです。

同様に、アイドル状態で放置してもセッションが切断/ログオフされないように
設計するのであればKeep Aliveの設定は通常は必要ありません。

何かしらの理由で自動再接続機能が働かなかったり使いたくない場合、
セッションアイドルタイマーを設定しているのにアイドルでも
切断状態にしたくない場合、なんだか知らないけどセッションが速攻で
切断状態になるのを防ぎたい、などなど謎の要件がある場合に、
使用することがあるかもしれない、ぐらいですかね。
私は本番環境で実装したことはない。

結果、セッション維持にKeep-Aliveは使わないことにしました。

Keep-Aliveについての情報、大変助かりました。
機能の説明及び考察について、大変勉強、参考になりました。

ありがとうございました。

解決案ではなく恐縮ですが、OpenGLAcceleratorは導入してないけれど
同じようなGRDI K2構成(ドライバーも362.56だなぁ)で特段のことをしなくても
3DCADはスイスイ動いたので他の所に原因を求めても良いのではないかなぁと思いはします。
ボトルネックが実際にGPUにあるのかとかも是非お確かめください。

ご回答有難う御座います。

中規模程度のアセンブリであれば問題なく動くのですが、
大規模アセンブリになると重くカクカクしてます。

GRID K2 と同等の性能とされているQuadro K5000搭載のワークステーションに比べ格段に遅いです。

ご教授頂いたGPU以外の可能性も引き続き探ってみたいと思います。

XenDesktopでGRID K2を利用する場合、OpenGLAcceleratorを利用する
必要はなかったかと。これはXenApp(サーバOS用)で利用する機能だったと
記憶しています。

vGPUで利用する場合、設定するプロファイルによりパフォーマンスが
異なるのですが、この点は確認されましたでしょうか。
vGPUではなくパススルーで利用しても改善されないでしょうか？

3D CADのアプリケーションにもよるのですが、GRID K2をvGPU1で利用すると
NVIDIAのCUDAは利用できません。(M60の上位ではできるみたいですが)

パススルーやvGPUを利用するにはHDX 3D Pro を利用してVDAを導入する
のですが、HDX 3D Proを有効にするとDCRは利用できません。
XenD側のポリシーも合わせて見直されたはいかがでしょうか。

大体、ClianUpUtilityが正しく実行されていれば直るケースなんですが
あのツールも結構色々動作が怪しいのでねぇ。
インストールしたユーザーでやれとか管理者権限でやれとか
ツール実行した後にレジストリとかファイルが消えてるか手動で確認しろとか。

当エラーについてはレジストリのこれを直せってのが↓に載ってるので
これもお試しください。
http://support.citrix.com/article/CTX132875

あとこちらも。
http://support.citrix.com/article/CTX131788

バージョンが違うから該当しないとか仰らずレジストリ修正はお試しください。

Sさん

回答ありがとうございます。
人から教えてもらって、アンインストールしたあとこのレジストリを消し、再度インストールしてみたらうまくいきました。

[HKEY_LOCAL_MACHINE\Software\Policies\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Logon\Local Credentials]
・EnableSSOnThruICAFile
・SSOnUserSetting
・LegacyLocalUserNameAndPassword
・SSOnCredentialType
・UseLocalUserAndPassword
[HKEY_LOCAL_MACHINE\Software\Policies\Citrix\ICA Client\SSON]
・Enable

どのナレッジに書いていたのかは聞けてないんですけども、
これの「LegacyLocalUserNameAndPassword」が悪さしてたらしいです。
とりあえず解決できたので報告です。
＃CleanUpUtility で消してくれればいいのに・・・

デリバリーグループの設定になると思います。

以下を参考に「AllowRestart」の値をFalesに変更していただければ再起動が
非表示になるかと思います。

コマンドの詳細については画面キャプチャ内に記載されているので、
参考にしてください。

https://www.citrix.com/blogs/2014/05/12/storefront-power-management-desktop-restart/

チァル様
ご指南ありがとうございます。

デリバリーコントローラのWindows PowerShellにて
asnp citrix*でSDKを追加してから
Set-BrokerAccessPolicyRule -Name "XXXX_AG" -AllowRestart $false
を入れてみましたら
できました。ありがとうございました。

お役に立って良かったです。

チャル様

ご教授ください。

"XXXX_AG"とはなんの名称を指すのでしょうか。

横ですが、デリバリーグループ名です

Set-BrokerAccessPolicyRule -Name デリバリーグループ名 -AllowRestart $false

という構文になります。

S様

ご教授頂き、ありがとうございます。
試してみます！！

上記の補足ですが、FP3にてWindows10に対応したため、
Windows10の仮想デスクトップを使うことが目的です。

DDC7.6.300 + SF2.6は利用可能な構成とされていますし、
実際表面上は問題なく動きはします。

ただし、LTSRに準拠しておらず、推奨される構成ではないため、
将来的にCitrixのヘルプサポートを受けられなくなることが想定されます。
例えば、SF2.6 + クライアント(Receiver)側ブラウザがIE11　という組み合わせは
非サポートです。（多分Edgeもダメ）

何か問題があった場合、Citrixは「3.0.1を使ってください」と言ってきます。
そういった運用上のリスクも勘案した上で、SFのバージョンをどうするか判断してください。
http://docs.citrix.com/ja-ja/xenapp-and-xendesktop/7-6/xad-whats-new/long-term-service-release.html


なお、StoreFront3.0.1にはReceiver for Webサイトについて、クラシック表示機能があります。
2.x系からアップデートする場合を想定した機能なので、
この機能を有効にすると、2.X時代のUIで使えるので(完全に一致では無いかもしれない)
Receiver for Webサイトの外観が変わる事を問題視しているのであれば
そちらもご参考されると良いでしょう。
https://docs.citrix.com/ja-ja/storefront/3/manage-citrix-receiver-for-web-site/sf-receiver.html

ご回答ありがとうございます！！！
とてもわかりやすくて助かりました。
URLの情報も参考に検討させていただきます。

>社内のPCで「gpupdate /force」コマンドをそれぞれ実施したところ
Citrixと関係ない話に見えますが大丈夫ですか？

gpupdate の結果が知りたいのならgpresultを実行してください。
出力された内容をみれば、望んだポリシーが適用されているかどうかは確認ができます。
https://msdn.microsoft.com/ja-jp/library/cc756960%28v=ws.10%29.aspx

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

・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さん、ご支援ありがとうございました。