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

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

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

説明だけ読むとCitrixと殆ど関係ないトラブルに見えます。
XenAppサーバーにRDS使ってDomainAdminsでログオンできないって話であれば板違いでしょう。

サーバーOSにVDA入れただけでRDS接続できなくなるなんてことは普通ありません。
単にRDS接続の権限がないだけじゃないですか？
システム管理者であればそのぐらいはご自分でお調べの上、ご相談ください。

Sさんの言うとおりそもそもRDPでログオンできないのであれば、Windows側の設定やポリシーなどを確認されたほうがいいかと思いますが、そういった切り分けも難しいのであれば、該当の機器へリモートでログオンしなくても作業用のクライアントへStudioを導入すれば利用できないでしょうか？

通常はAdministratorsに属していれば気にすることなくRDPで接続できるはずです。
Administratorでログインできないとなると、ポリシーでドメインのAdministratorを
拒否しているとか。一度管理者の方に問い合わせてみてはいかがでしょうか。

Studioを利用したいのであればRDPで接続しなくても公開アプリとしてStudioを登録
したり、RDPで接続しなくても公開デスクトップで接続するとか色々と方法があると
思います。

後はVNCをローカルのAdministratorで導入してクライアントから接続するとか。
これだと直接コンソールへログインできますから。

いろいろとありがとうございました。
確かにCitrixに直接関係ないトラブルでした。

要はStudioの操作が出来ればよいので、
ご意見を参考にさせて頂きます。

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

細かい話ですが記載されている内容はXenAppではなく以下のVM Hosted Appsかと思います。

https://docs.citrix.com/ja-ja/xenapp-and-xendesktop/7-6/xad-build-new-enviroment/xad-deliver-vmhosted.html

とは言うもののクライアントOSかサーバーOSかの違いしか無いとは思いますが、
切り分けのため、サーバOSで動作するか確認されてはいかがでしょうか。

イレギュラーな(＝あまり一般的ではない)構成なように読めて色々疑問があります。
記載を省略されているのでしょうが、それでは確認すべきことが膨大にあって大変です。

例えば、StoreFrontはDDCと同居なんでしょうか？

XAサーバとしてWin8.1を指定ということはVM hosted Apps構成となりますが、
Citrixライセンスは適切なものが構成されていますでしょうか？

Windows8.1でUACは無効になっていますか？

Studio上でWin8.1は「登録済み」になっていますか？

「このアプリケーションは現在使用できないため起動できません」という
メッセージは本当にその文面の通りだったでしょうか？

Win8.1にCitrix Receiverで認証に用いたユーザーで
対面ログオンすることができますか？
その上で公開したいアプリケーションを起動することができますか?

アプリケーション公開ではなくデスクトップ公開にしても
現象は変わりませんか？

パケットキャプチャーの前に各OSのイベントログをよく確認ください。
(特にDDCと8.1)

上記の補足ですが、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の情報も参考に検討させていただきます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ご質問の意図がどこまで深いかわかりませんが、一般的な回答とするならば、オートクリエイトプリンタを利用するのが普通なのではないでしょうか？
オートクリエイトプリンタはデフォルトでONなので、セッション内に自動作成されたプリンタへ印刷をかければよいだけかと思います。
参考：http://www.slideshare.net/citrixkoji/xendesktopxenapp
ただ、これをONにすると、想定していないプリンタドライバがXenAppサーバに登録され、ドライバメーカーによっては動作が不安定になることもあります。
その場合は、自動生成をOFFにし、セッションプリンタを使って回避するのが、次に一般的な手だと思います。

回答ありがとうございます。
参考URLを設定し、印刷検証してみます。

APサーバ：Win2003 R2
Citrix Presentation Sever 4.0
の環境で10年近く利用しています。

この環境で最近、突然印刷ができなくなるという事象が発生しており困っています。
事象としては、クライアントに登録されているプリンタが今までは問題なく
自動作成機能でサーバ上に作成され、問題なく作成されていました。
ところが最近になって、突然自動作成機能でプリンタドライバが作成されなくなり
印刷できなくなるという事象が発生しています。
作成されるとしても、Microsoftだったり、PDFだったり通常使うプリンタがマッピングされません。
サーバの再起動をかけるとそのタイミングでは印刷できるのですが、その日の途中から利用できなく
なるという事が続いています。
サーバに変更は全く入っていません。
もし、ご存知の方がおりましたら教えていただけないでしょうか。

すみません、間違えて返信してしまいました。
迷惑掛けてすみません。。。