DDCは登録されていないVDAには振らないと思うので、
StoreFrontの前にnetscalerとかロードバランサーを置いてラウンドロビンで振るとかじゃ駄目ですか？

>双方のDeliveryControllerに双方のVDAを登録することは出来ないので、
の意味が分かりません。
もしかして、2台のDeliveryController(以下 DDC)は
それぞれ別ファームとして、それぞれがSQL DBを持つ
独立した環境2つを構成しようとしていますか？

それなら分からんでもないのですが、VDAへの接続をロードバランスするためだけに、
なんでそんな面倒な構成にするんや……って感じです。

「VDAへのアクセスをアクセスロードバランスしたい」という要件だけを
そのまま読み取ると、構成は著しくシンプルに
以下の構成でよいことになります。

・1台目
StoreFront(SF)、DDC(+SQL DB)、VDA、ライセンスサーバ

・2台目
VDA

この構成で、1台目と2台目を同じデリバリーグループに登録して余計なことをしなければ
ユーザーはSFにアクセスした後、DDCがロードバランスして1台目か2台目に
接続仲介されるので、要件を満たします。


実際には「どちらの物理サーバーがダウンしても使える状態にしたい」って要件
なんじゃないですか？

もしそうなら、全く同じ構成のオールインワンサーバーを1台ずつそれぞれ別ファームとして構成し、
Reppa氏が仰るようにSFの手前にロードバランサ―を置けば一応、要件は満たされます。

が、ロードバランサ―が単一障害点になるのでここも冗長化しないといけません。
また、普通は冗長化したいからといって同じ内容のファームを2つ作るようなことはしません。
維持運用管理が面倒臭いことになるからです。
通常は、単一のファームで、SQL DBを上手く冗長化しつつ構成します。

私自身は設定したことないですができるみたいですね。

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

HTTPアクセスを禁止することが出来ました！
Reppaさん、ありがとうございました！

NetScaler MPXの話ですよね？

Ethernet Portsはいわば「サービス用」のNetwork Portですが
Management Portsは「NetScalerの(物理)管理用」のNetwork Portです。
NetScaler自身に対して、直接接続して諸般の運用操作をする際に用います。

サービス用のネットワークに問題が起きた際も、この物理管理用のネットワークが
切り離されており、利用が可能であれば色々障害対応などで有益です。

ブラウザ経由でこのNetwork PortにアクセスするとGUIの管理画面が利用できて
例えば、ネットワークの設定だったり、ヘルスステータスを確認したり
電源をオンオフしたり、工場出荷時にリセットしたりできます。

こちらのページが詳しいです。
http://docs.citrix.com/en-us/netscaler/11/netscaler-hardware-installation/netscaler-mpx-lights-out-management-port-lom.html

言葉足らずで申し訳ありませんでした。ご指摘の通り、NetScaler MPXの話です。

頂いた回答やページ情報を閲覧し、Management Portsについての理解が深まりました。
ご回答ありがとうございました。

頂いた回答から考えるに、普段はEthernet PortsのみにLANケーブルを接続して運用するのが
一般的なのでしょうか。というのも、Management Portsは管理用の通信、Ethernet Portsは
サービス用通信というようにポートごとに用途を持たせようと思っていました。
ちなみに、可用性を考慮し、Ethernet Portsの方はLAGを組もうと思っています。

NetScaler MPXの管理画面を確認したのですが、NSIP、VIP、SNIPなどのIPアドレスと
ポート（Interface）をBindする設定が見当たりませんでした。そうすると、Management Ports
とEthernet Portsの使い分けができず、上記要件が満たせないのではと考えております。

Management PortsとEthernet PortsにIPアドレスをBindさせることは可能なのでしょうか。

>普段はEthernet PortsのみにLANケーブルを接続して運用するのが一般的なのでしょうか
いいえ、普通はEthPortにもMgmtPortの両方にLANを接続した状態で運用します。
必要な時だけMgmtPortにLANケーブルを挿すなんて運用は普通しません。

どうも根本的な誤解がありそうな気がします。

機種によって違うかもしれませんが、NetScaler MPXのNICコネクタ部分をみれば分かるはずです。
MgmtPortsとEthPortは物理的に別のNICで、根本的に用途が違います。
http://docs.citrix.com/content/dam/docs/en-us/legacy-edocs/netscaler-hrdwre-installation-111/Rome-1Gfrontpanel.png

MgmtPortsにはサービス用のIP(SNIPやVIP)を振って利用することはできません。
振れるのはNS(NetScaler)IPだけです。

EthPortsの内のどのポートにどのIPを振る(Bind)するかはちゃんと設定箇所がありますし、
LAGを設定する箇所もあります。詳細はマニュアルやらをお調べください。

大変に分かりやすいご回答、誠にありがとうございます。

恥を忍んでお聞きしますが、EthPortsにIPをBindする方法を教えていただけますでしょうか。
また、「このマニュアルのここに書いてある」という情報だけでも構いません。

他ツリーでも書きましたがNSGはそこまで詳しくないんですよね。
確か
System-Network-IPs
System-Network-Interfaces
System-Network-VLANs
辺りだったと思いますが。

マニュアルはNetworkの所読み込んでいただくしかないでしょう。
日本語版が用意されてなくてアレですが。
http://docs.citrix.com/ja-ja/netscaler/11/networking.html

Sさん、ご回答ありがとうございました。

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

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

NetScaler Gatewayを使うと実現できるんじゃないでしょうか。

StoreFrontを直接WANに晒す事を良しとするかどうか…って話もありますね。

Storefrontに代替アドレスの機能はないので、現時点ではWebInterfaceかNetScalarなどを
利用するしか方法が無いと思います。

ここまで確認したこと。

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

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

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

とりあえず、成功。

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

以上でした。

社外からNetscaler経由で接続する場合って確かNetscalerが設定を基に
Netscaler→Storefront→XenDesktopでリダイレクトしますよね。
単純にNetscalerでStorefrontへのリダイレクトを設定しなければ接続されないんじゃないですかね。
旧AccessGatewayの考え方なので間違ってたらすみません。

Reppa様

ご指摘の通りなのですが、AさんはNetscaler経由接続可。BさんはNetscaler経由で接続不可。
社内からは、AさんBさん共にstorefrontに接続可の設定なのですが。
舌足らずで申し訳ありません。

あぁ、そういうことですか。
今のNetScalerがバージョン5のAccessGatewayと仕様が変わってなければ
ユーザーによってNetScalerのログインの可否というのは制御できないと思います。
NetScalerはLDAP認証等を使用してADサーバーに認証しに行くので、
NetScaler自体はユーザー制御というものはしてません(多分
要はADのユーザーとパスワードが合ってれば通します。
立ち位置としてはStorefrontと同じような感じですね。

Reppa様

やっぱりそうでしたか。
うー残念です。

AD上にNSからアクセスを許可させたいユーザーをまとめたグループを作成して、NS側でこのグループに対応したポリシーを設定すると、実現可能だと思います。
AccessGatewayで指定するポリシーは、空にしておいて、グループの設定で、ポリシーを指定することになります。

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

こちらが参考になると思います。

wahoo様
moumou様

一生懸命?やっていますが未だ制限かけられず、やろうとすると全員が資格情報がない
と言われています。

NSのSystem-Authentication-LDAP-ServersをOpenして
Other Settings内の
Server Logon Name Attribute:sAMAccountName
Serch Filter:memberOf=CN=Users,ou=nsmember,dc=**,dc=co,dc=jp
Group Attribute:memberOf
Sub Attribute Name:CN

この定義で、nsmemberに接続させたいユーザーを参加させました。
ちなみにADの木構造のドメイン配下のUsersの下にセキュリティグループ名nsmemberを
作っています。

汝をお助け下さいませ。

ここまでで、わかったこと。

ADの木構造OUが会社組織別に編成されている関係で、Base DN(location of users)の内容を
dc=*****,dc=co,dc=jpと単にドメインだけの構成でした。

この値の頭にOU=netscalerなるダミーの組織を入れて、AD側に接続させたいuser名を入れて
試したところ、OUに入れたuserはログオンに成功し他のuserは拒否されました。

>この定義で、nsmemberに接続させたいユーザーを参加させました。
>ちなみにADの木構造のドメイン配下のUsersの下にセキュリティグループ名nsmemberを
>作っています。

その場合、
memberOf=CN=Users,ou=nsmember,dc=**,dc=co,dc=jp
ではなくて、
memberOf=cn=nsmember,cn=Users,dc=**,dc=co,dc=jp
が正しいと思います。

Base DNがユーザーが存在している場所に正しく設定されていれば問題無く動作すると思います。

moumou様
Reppa様
wahoo様

感謝感激です。一発で成功しました。
ありがとうございました。

おめでとうございます！！

CTX125364、CTX136914 を確認してみます。

iOSとアンドロイドにルート証明書をインストールしてもサーバーに接続出来なかった。
ネットスケーラーの定義を直しても改善されない。

とりあえず、証明書の有効期限を確認してみてください。
WindowsPCのブラウザとかで見れるハズです。

Citrixにおける証明書の種類
ルート証明書→Windowsの証明機関 or 有料証明書
サーバー証明書→Netscallerの証明書(IISの証明書ではなかった気がします)
中間証明書→忘れた(多分、2要素とかで使うRSAとかの証明書？)

Reppaさん、こんにちは

確認しましたことを下記します。
1.プラウザからNetscalerに接続した場合
　(1)サーバー証明書の有効期限は十分ありました。
　(2)しかしこのウェブサイトの識別情報は、Cybertrust Japan Public CA G3により
　　　確認済ですが、公開監査記録がありまん。
　(3)Cybertrust社のHPでサイトの検証を確認すると中間証明書がありません。
　　　よくよく見るとGoogleVhromeの仕様であることは理解しました。
　　　今度からSHA-1ではなくSHA-2にすることを促しているようでした。
　(4)ただ、仮想アプリは問題なく起動できます。

2.iOSでプラウザを起動してNetscalerに接続した場合
　(1)認証はしてくれます。
　(2)貸与されたアプリのアイコンは表示されます。
　(3)起動を掛けると、サーバーに接続できません。とでます。
　(4)CitrixDirectorで見たエラーメッセージは
　　　クライアント接続エラー、接続タイムアウトと記録されていました。

3.iOSに搭載のCitrixReceiver(最新バージョンX1マウス対応)で接続した場合
　(1)アカウント作成のプロセスでhttps://?????を入力後
　(2)ユーザー名、パスワード、ドメインをセット
　(3)アカウントの追加エラー(ゲートウエイ設定が無効です)


結果として証明書が原因か?タイムアウトのしないよう長さを調整すればこと足りるのか
まったくわかりませんでした。

何卒、ご教示の程宜しくお願い致します。

タイムアウト値はNS側にもXD側にも設定があるようで、設定してみないと効果はわからないかもしれません。
下記を参照して設定してみてください。

http://support.citrix.com/proddocs/topic/netscaler-getting-started-map-10/nl/ja/ns-lb-config-per-cook-tsk.html?locale=ja
http://support.citrix.com/search?searchQuery=%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%A2%E3%82%A6%E3%83%88%E5%80%A4&lang=ja&sort=relevance&prod=&pver=&ct=Technotes

Reppaさん
ありがとうございます。
XD側のレジストリには値がありませんでしたので追加してみましたが変化はありませんでした。
NS側が頂いた資料と実際のWEBコンソールとではメニュー体系が違うみたいで設定変更が
できませんでした。
結果変わっておりません。

別の角度で調べていく方法はありませんでしょうか。

CitrixReceiverの挙動はクライアント毎の設定による物なので別として、
ブラウザからの接続はPCからの物が成功しているのでNetscalerの設定の問題は薄そうですね
(PCとモバイルで同じNetscalerの設定(接続サイト？)を使用してるのであれば)。

ただ、PCとモバイル端末で全く挙動が同じかは微妙ですが、
モバイル端末側の証明書を疑った方がよさそうですね。

///////////////////////////////////////////////////////////////////
注： 接続時にリモートゲートウェイの証明書を検証できない場合
（ローカルのキーストアにルート証明書が含まれていないため）、
信頼されていない証明書の警告が表示されます。
ユーザーが警告に対してそのまま続行することを選択した場合は、
アプリケーションの一覧が表示されますがアプリケーションが起動しません。
///////////////////////////////////////////////////////////////////
http://support.citrix.com/proddocs/topic/receiver-android-36/nl/ja/android-receiver-admin-requirements.html?locale=ja


選択肢としては下記があると思います。
まぁ、下手にイジってPC側も繋がらなくなるのも怖いので、
Citrixに問い合わせた方が安牌かもしれませんね。

1.端末のルート証明書(SHA-1)を更新してみる
　https://www.cybertrust.ne.jp/sureserver/support/download_ca.html

2.要件漏れが無いかNetscaler・StoreFront・XDの設定を見直してみる。
　http://support.citrix.com/proddocs/topic/receiver-ios-59/nl/ja/mobile-receiver-admin-config-client-cert.html?locale=ja

3.Citrixの既知のバグを確認して製品にパッチを当ててみる。
　http://www.citrix.co.jp/support.html

4.SHA-2の証明書に移行してみる。
　https://www.cybertrust.ne.jp/sureserver/productinfo/sha1ms.html#chrome

5.Citrixの有料サポートに問い合わせしてみる。

症状からして、証明書に起因する問題である可能性が濃厚かと。
NetScalerで中間証明書（Cybertrust Japan Public CA G3）の更新と
証明書間のリンクの再設定でうまくいかないでしょうか。

すでにご確認済の際はご容赦ください。

sig様
未解決のままで、意気消沈しておりました。

中間証明書のインストールはできていましたが、証明書間のリンクの再設定は
どのようにすればよいでしょうか。

Netscalerのバージョンは、NS10.1-124.13です。

sig様
Reppa様

中間証明書とサーバー証明書のLinkをやり直したところ
成功し解決できました。

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

わーい
よかったよかった＼(^o^)／

＞　① 既に恒久ライセンスが30台のPCに発行されている状況で、1つのライセンスサーバダウンが発生した場合、
＞　　 そのダウンしたサーバより発行された15台のPCからの接続はできなくなるという認識でよろしいのでしょうか。

有効期限が切れてない限りそれはありません。


＞　② そもそも「各ライセンスサーバに15CALずつ登録」という構成は、冗長化という点で有効なのでしょうか。

CALが発行できるサーバーが存在するという点では有効じゃないですかね。


Citrix関係無さそうなので、詳細はMicrosoftの掲示板までお願いします。
http://social.technet.microsoft.com/Forums/ja-JP/home