過去スレに同じような質問がありますが、サーバー側でウィンドウサイズを制御すればいいと思います。
さすがにやってみないと分かりませんが、シームレスをオフにしてScreenPercent=100が最大の状態かもしれません。

StoreFrontを構成してウィンドウモードでアプリケーションおよびデスクトップを起動
https://docs.citrix.com/ja-jp/storefront/current-release/user-access/windowed-mode.html

2つ下(2019/02/26 12:15:33)言い方を変えただけで全く同じ質問がありますが
同じ方ですか？
だとしたらあんまりお行儀よくないですが……万一違う方なら失礼

リソース を直接起動させるショートカットを作成する手順は
その手順で公式のガイドに書いてあるとおりなので問題ありません

リソースのショートカットをホストするWebサイトのURLを追加する
意味については下のURLの「リソースのショートカット」の所に書いてあります
https://docs.citrix.com/ja-jp/storefront/current-release/plan/user-access-options.html

s様

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

＞2つ下(2019/02/26 12:15:33)言い方を変えただけで全く同じ質問がありますが
＞同じ方ですか？
＞だとしたらあんまりお行儀よくないですが……万一違う方なら失礼

→
2つ下の方とは別の者となります。
2つ下の質問と類似していることはわかっておりましたが、回答がなかったため記載させて頂きました。申し訳ありません。

記載頂いたURLにてリソースのショートカットの設定の意味が理解できました。
ありがとうございました。

管理者以外の一般ユーザの場合、VDAを導入したOSのローカルにDirectAccessUsersというユーザグループが作成されていると思うので、そこに対象のユーザを追加してみてください。

この掲示板でもよくいらっしゃるのですが
「XenApp7.6をインストールしたサーバー」というのはあまり意味のない文言です。

具体的に、サーバーにいずれのコンポーネントをインストールしたかを書くべきです。
常識的に考え推測すれば、最低でもDDCは入ってるのは間違いないとして
「VDAは入れましたか？」とかとても低レベルなことも聞かなくてはならなくなります。

仰るCitrixポリシーは

[ICA]-[デスクトップの起動]

ポリシーのことだと思いますが、これはICAコネクションを使った
VDAが導入されたOSへの非管理者による接続を許可または禁止するポリシーで
RDP接続には関係がありません。別の原因です。

単に管理者以外にRDP接続の権限を与えてないんじゃないでしょうか。
OS側のRDP許可ユーザーの設定など確認してください。

また、管理者権限のないユーザーからRDP接続できないというのが
「具体的」にどのような現象が起こるのか教えてください。

BrokerAccessPolicyRuleで設定されていると思いますが、IPアドレスでフィルターを掛けた場合には機能しますか？

トムじい様

早速のレスありがとうございます。
IPアドレスでフィルターした場合には出しわけできるようです。

確認した結果IPであれば、制御が効くということであれば、
おそらくですが、通常ICAファイルに含まれる情報はIPアドレスになるので、
以下のKBのコマンドでDNSで接続するようにしたら意図したとおりに動作しないかなと。

https://support.citrix.com/article/CTX135250

ちなみに接続時の動作が変わるので、切り戻しなどは確認されてから
適用してもらったほうが良いと思います。

トムじいさま

レスが遅れてすみませんでした。
教えていただいたＵＲＬ、大変参考になりました。

コマンド試してみましたが、駄目でした。（変化無し）
ＩＰだといけるんですが、ホスト名ではできないのですかね。。。

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

以下を参考に「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様

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

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

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

ここまで確認したこと。

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様

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

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

よくこのナレッジ使われてる気がしますが、設定しても変わりませんか？

Access管理コンソールの起動に時間がかかる
http://support.citrix.com/article/CTX120824

下記2つの実施で、2分→30秒に短縮されました。
環境によりますが、インターネット接続しているサーバでは実施前に
セキュリティ面を考慮する必要がある設定変更になると思いますが…。

1.
http://docs.citrix.com/ja-ja/xenapp-and-xendesktop/7-1/cds-71-about-whats-new/cds-71-known-issues.html
上記の中のこちら→http://support.citrix.com/article/CTX120115

２．
Citrix Studioをインストールしたマシンにて、
IEの[ツール]→[インターネットオプション]の「詳細設定」で
"セキュリティ"の「発行元証明書の取り消しを確認する」のチェックを外す

まずは、OracleサーバへODBC接続（ファイルDSN）できるように設定する必要があります。
ここまでは出来ていますか？

Pさん

返信ありがとうございます。

現在は以下の状況です。
①Oracleクライアント（9iR2）を管理者としてインストール。
②Oracleサーバへの接続テストまで完了。（tnsnames.oraに設定済）
③ODBCデータソースでは、[システムDSN]タブでシステムデータソースを作成。
④XenApp5.0のメディアを使ってインストールを実施。

質問：
上記③は不要で、[ファイルDSN]タブにて、
データソースのドライバをOracleを指定して（例えばOracle in OraHome92）
データソースを追加する必要があるということでしょうか。

SQLはMSの製品なのでデフォルトでドライバがインストールされていますが、
Oracleは手動でインストールしないとDSNには表示されません。

データソース？という物を手動で作成した記憶は無いのですが、
インストールの際にインストーラーが勝手に作ってくれませんか？

Reppaさん

返信ありがとうございます。

①Oracleクライアント（9iR2）を管理者としてインストール。

上記の作業を行った後に、
[ODBCデータソースアドミニストレータ]の[ドライバ]タブに
[Oracle in OraHome92]が追加されたことは確認できました。
しかし、[ユーザDSN]、[システムDSN]、[ファイルDSN]の
いずれにも接続情報が作成されていませんでしたので、
インストールの際にインストーラによって自動的に作成された形跡はありませんでした。

とりあえず、Access形式のデータストアを作成した後、
dsmaintコマンドで、データソースをOracleへ移行する事も可能です。

私は何時もこの手順で実施していたので、
ファイルDSNを作成すると記載してしまいました。

Pさん

返信ありがとうございます。

ご教示いただいたとおり
dsmaintコマンドでデータベースの移行を実施しました。

１．dsmaint migrate （oracleのデータベースに移行）
２．dsmaint config　（ファイルdsn(oracle用)を指定）

上記２を実施後にIMAサービスの再起動を実施したのですが、
IMAサービスが起動しなくなってしまいました。

このような事象が発生したことはなかったでしょうか。
対処方法があれば教えていただきたいです。

DSNの接続パスワードが間違っていると起動しないことがありました。
確かデフォルトはユーザーとパスワードが「citrix」でしたね。
ただ、DBサーバーだと接続先のユーザーとパスワードになるのかな？(詳細忘れました)

それか単純に別の事象が発生したかですね。
MFCOMは開始中になっていれば怪しいです。

Reppaさん

返信ありがとうございます。

１．dsmaint migrate （oracleのデータベースに移行）
２．dsmaint config　（ファイルdsn(oracle用)を指定）
上記ともにDSNの接続に誤りはなさそうでした。
※上記２の実行後、以下のメッセージが表示されました。
　『データストアに接続されました。設定が変更されました。
　このサービスを有効にするために、IMAサービスを再起動してください。』

また、IMAサービスが起動しない件で、
サービスのログオンユーザを『NetworkService』→『Local System』に変更してみると
起動するようになりましたが、そもそも変更自体行って良いのかわからず、根本的解決に至っていない状況です。

＞サービスのログオンユーザを『NetworkService』→『Local System』に変更してみると
＞起動するようになりましたが、そもそも変更自体行って良いのかわからず、根本的解決に至っていない状況です。
やられた手順はCitrix関係無く、一般的なサービスが起動しない場合の回避方法になります。
こういう場合はADのグループポリシーで起動が妨げられている場合が多いです。
ワークグループで発生してドメインで発生する場合はAD側を疑った方がいいかもしれませんね。