検索結果｜シトリックス炎の掲示板｜株式会社ピー・ビーシステムズ

公開アプリケーションに接続できない

YC 2019/11/27 10:29:53

手元のPCから社内PCへRDP接続を行い、社内PC上でCitrix　Receiverの公開アプリケーションが正常に動くのかを検証しています。

任意の公開アプリケーション（エクスプローラーなど）を開くと、画面上に「接続しています...しばらく時間がかかることがあります」とメッセージが表示されて、最終的には「Citrixi　Receiverはサーバーに接続できません」とエラーが表示されてしまいます。

またエラー原因を探るためCitrix　Directorを確認したところ、クライアント接続エラーが発生し、エラーの理由としては「接続タイムアウト」が原因であると表示されていました。

ただ、他のPCでも同様のことが起きるのかを確認しようと、確認したところ別のPCでは上記のようなエラーは発生せず、公開アプリケーションが利用できました。

こちらの、解決策をご存じの方いらっしゃいましたら、解決方法のご教授いただければと思います。

ぎんぎつね 2019/11/28 12:25:07

タイムアウトの場合、以下のようなKBがありますので、参考にされてはいかがでしょうか。

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

公開アプリが起動できない

Citrix初挑戦 2019/11/25 11:18:11

新しくVirtualAppsを導入しようとしています。
事前に検証環境で構築した際は問題なく公開アプリを起動することができたのですが
いざ本番の環境に構築したところ公開アプリが起動できませんでした。

公開アプリを起動しようとするとCitrixRecieverのプログレスバーが途中で止まって消えてしまいます。
画面には「アプリケーション"Notepad"を起動することができませんでした」と出てきます。
たぶん起動できなかった同じタイミングでイベントビューアにソース：Tdlcaで警告が出てきます。
「Citrix ICA Transport Driver の xxx.xxx.xxx.xxx:50997 からポート 2598への接続が、SSL ハンドシェークフェーズで不正なパケットを受信しました。」というメッセージです。

ポートの問題かと思いファイアウォールを無効にしてみましたが状況は変わりませんでした。

公開デスクトップの起動はなぜかデスクトップ画面が開く前にWindowsのログイン認証の画面が表示されます。
ID、パスワードを入力すると起動はできます。

本番と検証のユーザーやグループ、ファイアウォールを見比べて見ても違いが見つけられず困っています。

ほかに見るべき項目をアドバイスいただけないでしょうか。

ALT+F4でXenDesktopを閉じない方法

東北コアラ 2019/11/17 10:26:44

XenDesktopでリモート先接続中に、なんらかのアプリケーションを開いているときに、
ALT+F4を押すと、ローカルの端末と同様に、開いているアプリケーションを閉じようとします。
この動きはよいのですが、なにもアプリケーションを開いていない状態でALT+F4を押すと、
XenDesktop自体を閉じてしまいます。
（リモート操作を終了し、ローカル端末に戻ってしまう）
ALT+F4でXenDesktopを閉じないようにすることは出来ないでしょうか。

Reppa 2019/11/18 09:42:00

ADのポリシーでホットキーを無効にできるようです。
ADMファイルはクライアントのインストール先とかにあったと思います。

https://www.citrix.com/blogs/2016/01/17/xendesktop_hotkey_configuration/
https://support.citrix.com/article/CTX140219

東北コアラ 2019/11/19 17:38:40

回答ありがとうございます。
ALT+F4自体を無効にすることはできるのですが、その場合には通常のアプリケーションを閉じるときにも無効になってしまいます。
リモートであることを意識せずに使いたいので、XenDesktopのみ閉じないようにしたい形です。
アプリケーションを開いていないときに、ALT+F4を押すと切断状態になってしまい、次のログイン時にも影響がでる状況です。

Reppa 2019/11/20 11:48:36

ICA接続でホットキーを無効にする方法はICAファイルをイジるか、ポリシーorレジストリでイジるかぐらいです。
あとはリモートデスクトップでも同じ事象であれば端末側ローカルのキーが効いてるのが原因でしょう。
もしRDPでも出るのであればXenDesktopは多分関係無いです。

ワークスペースの自動ログオフ

森山 2019/11/07 17:56:18

端末からStoreFrontに接続した際に、ユーザ名＆パスワードを入力した際に、自動的にリモートデスクトップサーバに接続し、リモートデスクトップ側のサーバでログオフした場合には、自動的にStoreFrontのログイン画面に戻る環境を構築したいと考えています。
（ワークスペースでの操作をなくしたい）

StoreFrontの設定で、デスクトップが１つだけの場合には自動起動するの設定をすることで、StoreFrontにユーザ名＆パスワードを入力することで、自動的にリモートデスクトップに接続することはできました。
しかし、リモートデスクトップ側でログオフし、ワークスペースに戻った際に、手動でメニューからログオフをしないとStoreFrontのログイン画面にもどりません。
ワークスペースに戻ってきたさいに自動ログオフすることはできませんでしょうか。
または、Javascriptでワークススペースからログオフするコマンドはありまでんでしょうか。

ぎんぎつね 2019/11/07 18:40:50

実現したい内容と会わないかもしれませんが、storeFrontのセッションにはタイムアウトの設定が可能なので、
20分から1分へ変更すれば1分でログオン画面には戻ると思います。ただ、この場合セッションが切れたのでログオン画面に戻りますというような画面になるかと思います。

https://docs.citrix.com/ja-jp/storefront/current-release/manage-citrix-receiver-for-web-site/configure-receiver-for-web-sites.html#%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%A2%E3%82%A6%E3%83%88%E3%81%AE%E8%A8%AD%E5%AE%9A
セッションのタイムアウトの設定

森山 2019/11/08 11:08:19

回答ありがとうございます。
タイムアウト時間を１分にしたところ、自動ログオフになりましたので、
Javascriptで画面をリロードするようにしたところ、目的の動きとなりました。
ありがとうございました。

XenDesktopへの暗号化接続で動作が非常に重い

tune 2019/11/07 09:30:31

Citrixの環境をイントラ内に置くシステムを構築しています。

VDAサーバ：Windows2016
VDAバージョン：1909
端末：Windows10

検証環境ではVDAのバージョンは1906を利用しており、端末とStorfront間はSSL、VDA間は暗号化無しで行っており、とくに動作上の問題はありませんでした。
しかし、本番環境では同様の構成で動作させると、XenDesktopの起動時にエラー「CTX134123」という暗号化にかかわるようなエラーメッセージが表示され、VDAへの接続ができなくなりました。
VDAへの接続を暗号化通信にしたところ、CTX134123は表示されなくなり、一応利用はできるようになったのですが、CPU負荷が非常に高くなり、youtubeなどの動画を小さいサイズで再生するレベルでもマウスの動きも苦しくなるほど重くなっています。
可能であればVDAへの接続を非暗号化のまま行いたいのですが、CTX134123が表示されるようになった原因はなにか考えられますでしょうか。
なお、StorFront、DeliveryController、VDAはいずれも同じスイッチハブに接続されており、間にファイアウオール等の制御はありません。
また、２４コアXeon、メモリ４８GのVDAサーバに１アカウントのみ接続した状態で、上記のような負荷となっており、暗号化以外の要因もあるのではないかと思っておりますが、処理が高負荷になった暗号化以外の要因は考えられますでしょうか。

ぎんぎつね 2019/11/07 11:56:31

イントラだけのシステムであれば、StoreFrontをSSLにする意味もないと思いますが、何か理由がありますか。

暗号化による負荷なのか切り分けのためにSSL無しのストアに接続して問題ないか確認したほうがいいと思います。

Reppa 2019/11/07 14:03:35

端末とVDA間を443にしたということであればSSLにしたことが関係あるかもしれませんが、現行は端末とStorfront間は80→443にして、端末とVDA間は443ではなく1494/2598ってことですかね？
端末とVDA間(仮想マシン起動)まで来ると以降は端末とStorfront間の通信は発生しないはずなので、多分暗号化は関係ないと思います。
それよりかはセッション保持機能のオン/オフじゃないですかね。

通信処理の詳細は下記を参照してください。

XenDesktop Connection Process and Communication Flow
https://support.citrix.com/article/CTX128909

ぎんぎつね 2019/11/07 15:13:50

リソースの負荷が高いということなので、どのプロセスの処理が重いのか調べたほうがいいと思います。

公開アプリのアイコンをクリックするとエラー

りんこ 2019/11/06 10:45:03

下記環境でクライアントから公開アプリをクリックすると、エラーメッセージが表示され、アプリケーションが起動しません。
【XenApp環境】
　Windows Server 2016 Standard
　XenApp 7.15 LTSR
　Storefront 3.15
【クライアントＡ】
　Windows7 Pro SP1（32bit）
　Citrix Receiver 4.12
　Internet Explorer 11
【クライアントB】
　Windows10 Pro（64bit、Ver 1803）
　Citrix Receiver 4.12
　Microsoft Edge

【エラーメッセージ①】
　Citrix Receiver
　　受信したICAファイルが破損しています。
　　ICAファイルに[ApplicationServer]セクションがありません。
【エラーメッセージ②】
　エラー番号 2312
　　受信したICAファイルが破損しています。
　　ICAファイルに[ApplicationServer]セクションがありません。

公開アプリをクリックするとすぐに【エラーメッセージ①】が表示され、このメッセージを表示したまましばらくすると【エラーメッセージ②】が表示されました。

以下を試しましたが、解消されません。
①CitrixReceiverを再インストール。
　（CitrixReceiver.exeを手動インストールではなく、Citrix/StoreWebよりインストール）
②IEのインターネットオプションより、閲覧の履歴を削除。

解決方法、ご教授願います。

ぎんぎつね 2019/11/07 12:11:15

海外の掲示板に似たような事例がありましたが、その方は接続するユーザのプロファイルの削除で改善されたようです。

Reppa 2019/11/07 13:08:25

4.3で修正されているようです。最新版で試してみてください。

Error: "Citrix Receiver Received a Corrupt ICA File" on Receiver 4.3 with XenDesktop 7.6
https://support.citrix.com/article/CTX202488

ぎんぎつね 2019/11/07 15:04:07

Citrix Receiver 4.12を使用中とのことなので、4.3の修正であれば含まれているかと思います。ただ、Receiverによって当たり外れがあるので、最新版のReceiverを使うというのはありかと思います。

WorkspaceAppというのが最新のモジュールなので、そちらの最新版を使うか、
CitrixReceiver4.9CU8という長期サポート版のモジュールを使うかの2択になるかと思います。

ただ、先程もいいましたが、一旦プロファイルを削除するか新規のユーザでの
確認をして結果が変わるか確認したほうがいいと思います。

りんこ 2019/11/08 10:41:16

ぎんぎつねさん
Reppaさん

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

ユーザープロファイルの削除は検討しましたが、
業務に支障が出るためすぐに実施することができず、
結局、代替PCを用意することになりました。
PC環境が完全に移行することができればプロファイル削除を
試してみたいと思います。

WorkspaceAppなどの最新版が既存XenApp環境に対応しているか確認し、
プロファイル削除同様、PC環境が完全に移行することができれば、
試してみたいと思います。

ぎんぎつね 2019/11/11 16:42:59

私の過去の事例だと役に立ったことがないのですが、接続した際の動作がおかしいときにはClean-Up Utilityを使うことで改善されるケースはあるようです。

https://www.ashisuto.co.jp/citrix_blog/article/201812-cleanup.html

使わないほうがいい場合などの条件の記載もあるようですので、参考にしてみてください。

りんこ 2019/11/27 14:48:05

ぎんぎつねさん、ありがとうございます。
返信に気付かず、すみません。

Citrix Receiver for Windows ですが、以前は4.6を使用しており、XenApp 7.15 LTSR の新環境への移行に合わせて 4.12 に変更しました。

上記URLと CTX137494 を見ましたが、4.6 ⇒ 4.12 の場合は Receiver Clean-Up Utility は使用できないようでした。

-----(CTX137494から一部抜粋)-----
Receiver cleanup utility is not required while upgrading to the Receiver for Windows 4.4 or newer. Receiver for Windows 4.4 or newer can upgrade from anyolder version of Receiver without the need of using the cleanup utility.
Windows 4.4 以降のレシーバにアップグレードする場合は、レシーバクリーンアップユーティリティは必要ありません。Windows 4.4 以降のレシーバは、クリーンアップユーティリティを使用しなくても、古いバージョンの Receiver からアップグレードできます。

The Receiver Clean-Up Utility removes components, files, and registry values of Online Plug-in 11.x, 12.x, and Receiver for Windows 3.x, 4.x (Online Plugin-in 13.x, 14.x). This includes the Offline Plug-in component if installed and HDX RealTime Media Engine if installed.
レシーバクリーンアップユーティリティは、オンラインプラグイン 11.x、12.x、および Windows 3.x 用レシーバ (オンラインプラグインイン 13.x、14.x) のコンポーネント、ファイル、およびレジストリ値を削除します。これには、オフラインプラグインコンポーネントがインストールされている場合は含まれ、HDX RealTime メディアエンジンがインストールされている場合は、そのコンポーネントが含まれます。

※日本語訳は「Bingで翻訳」を使用しました。
------------------------------------------------

現状では「Clean-Up Utility」は使えませんが、対応策の一つとして覚えておきます。

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

ぎんぎつね 2019/11/27 20:19:09

りんこさん

なるほど、4.6からのアップデートだとこのツールは効果はないですね。失礼しました。

運用中の環境で「Delivery Controllerアドレスが変更されました」と表示される

づか 2019/10/08 11:13:53

現在運用中の環境でCitrix Studioを起動したところ、
「Delivery Controllerアドレスが変更されました」と表示され、
接続ユーザやアプリケーションが操作できなくなりました。

【環境】
Windows Server 2016 Standard
Citrix XenApp 7.17
※同構成の端末が存在し、現在２台で負荷分散設定
　もう一台同じ構成の端末を追加し、３台で負荷分散をする予定

対象サーバ全てを再起動→同じ現象
サーバマネージャで赤く表示されるサービスの有無→なし
Citrix StoreFrontで確認できるDelivery Controllerのアドレスを再登録→「全てのサービスが構成されていません」と表示され、冒頭と同じ状況

この状況ですが、現在公開しているアプリケーションは問題なく利用できています。
どのタイミングで操作できなくなったかは判りません。
コンピュータ名の変更や、ネットワーク情報の変更もないため、アドレスが変更されることはありません(念のため確認しましたが、初期設定のままです)。

同様の現象、何か思い当たる部分があるなど、些細なことでも結構ですのでアドバイスいただければと幸いです。

s 2019/10/18 14:16:08

まずはこの内容に従ってトラブルシューティングをどうぞ

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

Reppa 2019/10/31 11:35:00

報告はちょいちょいあるようですが、よくわかんないです。
IPが重複してipconfigから見ると変わってたとかはないんですかね。

Valid Delivery Controller Services Not Found XenDesktop
http://www.kylewise.net/citrix/xendesktop/xd-valid-delivery-controller-services-not-found/

づか 2020/10/30 16:45:05

投稿から１年近く経過してしまったのですが、試行錯誤した結果、先日完了しましたので結果をお伝えします。

Citrix StoreFrontならびにDelivery ControllerがインストールされているメインサーバのCitrix関連ソフトを全て再インストールしました。
※他２台は再インストールなどは発生せず、マシンの一覧に追加して負荷分散して動くようになっています

お二方のアドバイスから見直しをしたのですが全く問題らしいところが見つからない状態でした。
(トラブルシューティングに関しては英語が堪能ではないため、完全に理解できてはいないと思いますが…)
IPアドレスの重複もありませんでしたし、原因は現時点でも不明です。
解消方法が見えなかったため、再インストールする流れになりました(業務都合でシステム停止が出来なかったため、再インストール実行まで期間が開いてしまいました)。

USBリダイレクトでの暗号USBメモリ

Tune 2019/09/20 09:49:53

XenDesktop7.6+Windows Server 2016の環境で暗号化されたUSBメモリを利用しようとしています。
メモリはバッファローのRUF3-HSTVです。
メーカーによる発表では管理者権限では利用できるが、一般ユーザでは利用不可能とのこと。
https://www.buffalo.jp/product/other/usb-memory-security-kensyo-vdi.html

実際にUSBリダイレクトの環境で利用してみたところ、Administratorでログインすると
利用可能であるが、一般ユーザでは利用できません。
AdministratorでUSBメモリを接続すると、「リムーバブルディスクドライブ」「Utilites」
の二つのUSBメモリがマウントされ、そのままだと「リムーバブルディスクドライブ」は
アクセスできないのですが、Utilitisの中の「OPEN_HS」という実行ファイルを実行する
と「認証画面を開いています」の画面表示後にパスワード画面が表示され、
パスワードを入力すると「リムーバブルディスクドライブ」が利用可能になります。

一般ユーザで同様の処理を行うと、同様に「リムーバブルディスクドライブ」「Utilites」
の二つのUSBメモリがマウントされるとこをは同じなのですが、
Utilitisの中の「OPEN_HS」を実行しても、「認証画面を開いています」のまま先に
進めません。
おそらくは一般ユーザで暗号化USBメモリを利用すると、途中でPIDが変更になる機器が
あるらしく、これに該当しているのではないかと想定していますが、一般ユーザになんら
かの権限を付与するか、VDA側のグループポリシーの変更で対応できないかと考えて
いますが、XenDesktop+Windows Server2016の環境で、暗号化USBメモリを利用でき
ている方はおりませんでしょうか。
別の暗号USBメモリであれば利用できる場合には、USBメモリの変更も考えています。

Reppa 2019/09/24 10:11:24

ハードウェア絡みは確かなことが言えませんが、XD7 1808以降＋MSのパッチがいるようです。
あとは　AutoRedirectStorage　のレジストリをイジってみるとかですかね。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Citrix Virtual Apps and Desktops 7 1808で実施された新しい機能強化により、
汎用USBリダイレクトを使用して、デスクトップOS VDAセッションやサーバーOS
VDAセッションにハードウェア暗号化機能のあるUSBフラッシュドライブを
リダイレクトできるようになりました。
デバイスがリダイレクトされると、そのドライブはローカルクライアントに表示されません。
このため、ドライブのロックを解除する必要がある場合は、セッション内で実行してください。
この機能を使用するには、Windows更新プログラムKB4074590が必要です。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
https://docs.citrix.com/ja-jp/citrix-virtual-apps-desktops/policies/reference/ica-policy-settings/usb-devices-policy-settings.html

Tune 2019/09/27 16:53:13

>>Reppa様

回答ありがとうございます。
XenAppは1906で、Windows Server 2016側には最新のパッチが適用済みです。
ご教授いただいた情報をもとにレジストリ修正等をこころみたのですが、制限ユーザでは利用できませんでした。
XenDesktop+Winodws7の環境で利用できたとの情報があったエレコム社の「MF-PUVT308GA」を購入してためしてみましたが、こちらも管理者ユーザでは利用できても、一般ユーザでは利用できませんでした。
一般ユーザにドメインのAdministratorやDomain Adminの権限を与えても利用できませんでした。（権限を与えても管理者権限と異なる？）
なんらかのセキュリティ設定によるものと思いますが、設定により回避できたかたか、XenDesktop7（1906）+Windows Server 2016の環境で、セキュリティUSBメモリの利用できたことのある方はいませんでしょうか。
なお、端末側のOSはWindows 10 Embeddedです。

Reppa 2019/09/30 10:17:10

エレコムの物は確認できませんでしたが、バッファローの物はXenDesktopが物理や仮想で条件が変わるそうです、参考までに。

仮想環境動作検証結果
https://www.buffalo.jp/product/other/usb-memory-security-kensyo-vdi.html

Tune 2019/10/03 23:02:46

>>Reppa様
回答ありがとうございます。
エレコムも利用できませんでした。
まだ解決はできていないのですが、ひとまず端末のWindows 10 Embedded側でパスワード解除を行い、XenDesktopからマッピングすることで利用可能になるように設定しました。
引き続き、制限ユーザでも利用可能なセキュリティUSBメモリを探したいと思います。

Windows10 1903 Update直後からエラー

TEXT 2019/08/28 14:09:18

Xenserver 6～7でOSを仮想化して運用しています。
先日、Windows10を1903にアップデートしてから、リモートデスクトップに不具合が
発生しており大変困っております。
状況としては、起動後最初のリモートデスクトップには正常に接続されるのですが、
一度切断して再接続を行うとCPU使用率100%の状態になり、一切接続できなくなります。
(XenCenterのコンソールからも入れません。)
普通の再起動も受け付けなくなり、仕方なく強制再起動して使用しています。

ネットではマイクロソフトの不具合であるような情報もあるようですが、今のところ回避策は無いように思われます。

同様の症例や対策情報等ありましたらよろしくお願いします。

Reppa 2019/08/30 11:29:23

環境について書いて貰わないと状況がよくわからないのですが、
CPU100%が接続先で起こってるのか繋ぎ元(Win10)で起こってるのかで状況が変わる気がします。
あと、仮想マシン上のXenToolsとかVDAとかアンインストールして発生するのであればCitrixは関係無い気がします。

TEXT 2019/09/01 14:13:50

HPのサーバーにXenserverをインストールし、ゲストOSはWindows10を運用しています。CPU100%を確認したのはXenCenterで、ゲストOSのCPU使用率を指しています。暫定処置として1903を1809へロールバックしたところ問題は解消されました。また、Xenserverを使用せず仮想化無しでリモートデスクトップを使っている他のPC(3台)には、問題の症状は発生していません。また蛇足ですが、ゲストOSをWindows7からWindows10(1903)へUpgradeした場合でも問題は発生しました。XenToolsは再インストールしましたが問題解消しませんでした。
アンインストールした状態は確認していません。

Citrix Workspace appのソケットエラーについて

糸 2019/08/21 17:22:51

仮想化基盤VMware
ADサーバ　windows server 2016
AP・RDサーバ　windows server 2016

クライアント
Windows10＋Citrix Workspace app

上記の構成で構築し稼動テストをしております。

クライアント展開をして接続テストをしておりましたが、数拠点で展開し、動作検証をし、
問題なく動作しましたが、本日展開作業をしていたところ、ソケットエラーとなり、
接続ができなくなりました。動作検証で問題がなかったところでも同様なエラーがでるようになり、対応に苦慮しております。

AP・RDサーバ上では、特に問題なく動作します。

どなたかソケットエラーが出る理由等ご存知でしたら教示ください

Reppa 2019/08/23 10:57:27

Workspace appについてはわかりませんが、
既知の不具合にソケットエラーについて書いてあるので最新版で出るかですかね。

https://docs.citrix.com/ja-jp/citrix-workspace-app-for-windows/about.html