既知の問題
-
このリリースで確認されている問題は以下のとおりです。
-
複数のDelivery Controllerが構成された環境で、オンプレミスハイパーバイザー上にドメインに参加していない仮想配信エージェント (VDA) をプロビジョニングするためにMachine Creation Services (MCS) を使用すると、
ctxsetupプロセスが失敗する可能性があります。このエラーは、ターゲットVDA上の/var/log/ad_join.logファイルで確認できます。この問題を回避するには、次の手順を実行します。
- マスターイメージ上で、
/var/xdl/mcs/mcs_util.shを見つけて編集します。- マスターイメージ上でターミナルまたはコマンドプロンプトを開きます。
-
/var/xdl/mcs/ディレクトリに移動します。 - テキストエディターを使用して
mcs_util.shファイルを開きます。 - 1.read_websocket_ddc_info()関数を見つけます。- 約297行目にある
log_debug "Exit read_websocket_ddc_info"の行を見つけます。この行の前にDDCS=$(echo "${DDCS}" | tr ',' ' ')という行を挿入します。
- 約297行目にある
-
- 新しいスナップショットを作成し、新しいスナップショットでVDAをプロビジョニングします。
[LNXVDA-19141]
- スマートカードサービスは、スマートカード認証中にファイルディスクリプターをリークし、新しいスマートカードアクセスをブロックします。この問題は、デフォルトでほとんどのLinuxディストリビューションが各プロセスに対して開くことができるファイルの最大数を1,024に制限しているために発生します。スマートカードサービスがこの制限を使い果たすと、新しい接続を確立できなくなり、その後のスマートカードアクセスが効果的にブロックされます。
この問題は、スマートカードログオンが有効になっているVDAに影響します。症状としては、/var/log/xdl/hdx.log に多数の 新しい接続を受け入れられませんでした: 開いているファイルが多すぎます エラーが表示され、/proc/${pid}/fd/ にファイルディスクリプターが蓄積されます。ここで、${pid} は ctxscardsd のプロセスIDを表します。PIDを特定するには、
systemctl status ctxscardsd\|grep PIDコマンドを使用します。-
この問題を軽減するには、スマートカードサービスの最大オープンファイル制限を増やすか、スマートカードサービスを再起動します。サービスを再起動する前に、アクティブなセッションがないことを確認してください。制限を増やすかサービスを再起動するには、次のコマンドを使用します。
-
スマートカードサービスを再起動するには：
systemctl restart ctxscardsd <!--NeedCopy--> -
現在のサービスの最大オープンファイルを照会するには：
cat /proc/${PID}/limits <!--NeedCopy--> -
スマートカードサービスの最大オープンファイルを設定するには：
-
ctxscardsd.service ファイルを読み取り専用モードで開き、現在の設定を確認します。
vim -R /lib/systemd/system/ctxscardsd.service <!--NeedCopy-->
-
-
-
制限を増やすには、ctxscardsd.service の Service セクションに次の行を追加します。
LimitNOFILE=65536 <!--NeedCopy--> -
systemd デーモンをリロードし、ctxscardsd サービスを再起動します。
systemctl daemon-reload systemctl restart ctxscardsd <!--NeedCopy--> -
新しい制限を確認します。
`cat /proc/${PID}/limits` <!--NeedCopy-->
-
注:
最大オープンファイル数を増やすことで、ファイルディスクリプターが不足するまでの時間を延長できますが、最終的には ctxscardsd の再起動が必要になる場合があります。
[LNXVDA-17768]
GNOMEの問題により、RHEL 8.X、Rocky Linux 8.x、RHEL 9.x、およびRocky Linux 9.xで **samba-winbind** をバージョン4.18.6にアップグレードした後、Linux VDAが期待どおりに動作しません。詳細については、<https://issues.redhat.com/browse/RHEL-17122> を参照してください。 PostgreSQLで設定された最大接続数が同時セッションを処理するのに不十分な場合、セッション起動の失敗が発生します。この問題を回避するには、**postgresql.conf** ファイルの **max_connections** 設定を変更して最大接続数を増やします。 **/var/log/xdl/jproxy.log** で次のLDAP例外がスローされるため、VDA登録が失敗する可能性があります。javax.naming.NamingException: LDAP response read timed out, timeout used: 10000 ms. <!--NeedCopy-->この問題を回避するには、次の手順を実行します。
-
LDAPタイムアウト値を変更します。たとえば、次のコマンドを使用してLDAPタイムアウト値を60秒に変更します。
ctxreg create -k "HKLM\Software\Citrix\GroupPolicy\Defaults" -t "REG_DWORD" -v "LDAPTimeout" -d "0x000EA60" --force <!--NeedCopy-->検索ベースを設定してLDAPクエリを高速化します。
ctxsetup.shのCTX_XDL_SEARCH_BASE変数を使用するか、次のコマンドを使用して検索ベースを設定できます。ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "LDAPComputerSearchBase" -d "<specify a search base instead of the root of the domain to improve search performance>" --force <!--NeedCopy-->
- マスターイメージ上で、
-
[CVADHELP-20895]
-
Microsoftは、2022年11月にWindows 10用の累積更新プログラムKB5019966およびKB5019964をリリースしました。これらの更新プログラムは、ドメイン参加と登録の失敗を引き起こします。この問題を回避するには、Knowledge Centerの記事 CTX474888 を参照してください。
-
Kerberosで RC4_HMAC_MD5 暗号化タイプが許可されている場合、Linux VDAがControllerに登録できず、次のエラーメッセージが表示されることがあります。
エラー: GSS-APIレベルで指定されていない失敗 (メカニズムレベル: HMACを使用した暗号化タイプRC4はサポートされていません/有効になっていません)
この問題に対処するには、Active Directoryドメイン全体（または特定のOU）で RC4_HMAC_MD5 を無効にするか、Linux VDAで弱い暗号化タイプを許可します。その後、
klist -li 0x3e4 purgeコマンドを使用してControllerおよびCitrix Cloud Connector™上のキャッシュされたKerberosチケットをクリアし、Linux VDAを再起動します。Active Directoryドメイン全体で RC4_HMAC_MD5 を無効にするには、次の手順を実行します。
- グループポリシー管理コンソールを開きます。
- ターゲットドメインを見つけて、Default Domain Policy を選択します。
- Default Domain Policy を右クリックし、編集 を選択します。グループポリシー管理エディターが開きます。
- コンピューターの構成 > ポリシー > Windowsの設定 > セキュリティの設定 > ローカルポリシー > セキュリティオプション を選択します。
- ネットワークセキュリティ: Kerberosで許可される暗号化の種類を構成する をダブルクリックします。
- DES_CBC_CRC、DES_CBC_MD5、および RC4_HMAC_MD5 のチェックボックスをオフにし、AES128_HMAC_SHA1、AES256_HMAC_SHA1、および 将来の暗号化の種類 を選択します。
Linux VDAで弱い暗号化タイプを許可するには、次の手順を実行します。
注:
弱い暗号化タイプは、展開を攻撃に対して脆弱にします。
- Linux VDA上の
/etc/krb5.confファイルを開きます。 -
[libdefaults] セクションに次のエントリを追加します。
allow_weak_crypto= TRUE
-
Linux VDAは、暗号化にSecureICA 1.0をサポートしていません。Linux VDAでSecureICA 1.0を有効にすると、セッション起動が失敗します。
-
Ubuntuグラフィック: HDX™ 3D Proでは、Desktop Viewerのサイズ変更後にアプリケーションの周囲に黒いフレームが表示されたり、背景が黒く表示されたりする場合があります。
-
Linux VDA印刷リダイレクトによって作成されたプリンターが、セッションログオフ後に削除されない場合があります。
-
ディレクトリに多数のファイルとサブディレクトリが含まれている場合、CDMファイルが欠落します。この問題は、クライアント側にファイルまたはディレクトリが多すぎる場合に発生する可能性があります。
-
非英語言語ではUTF-8エンコーディングのみがサポートされています。
-
Citrix Workspace™アプリfor AndroidのCAPS LOCKの状態が、セッションローミング中に反転する場合があります。既存の接続をCitrix Workspaceアプリfor Androidにローミングすると、CAPS LOCKの状態が失われる可能性があります。回避策として、拡張キーボードのShiftキーを使用して大文字と小文字を切り替えます。
-
Citrix Workspaceアプリfor Macを使用してLinux VDAに接続すると、ALTキーを使用したショートカットキーが常に機能するとは限りません。Citrix Workspaceアプリfor Macは、デフォルトで左右のOption/Altキーの両方に対してAltGrを送信します。この動作はCitrix Workspaceアプリの設定内で変更できますが、結果はアプリケーションによって異なります。
-
Linux VDAがドメインに再参加すると、登録が失敗します。再参加により、新しいKerberosキーセットが生成されます。しかし、Brokerは以前のKerberosキーセットに基づくキャッシュされた古いVDAサービスチケットを使用する可能性があります。VDAがBrokerに接続しようとすると、BrokerはVDAへの戻りセキュリティコンテキストを確立できない場合があります。一般的な症状は、VDA登録の失敗です。
この問題は、VDAサービスチケットの有効期限が切れて更新されると、最終的に解決される可能性があります。しかし、サービスチケットは長期間有効であるため、解決には長い時間がかかることがあります。
回避策として、Broker のチケットキャッシュをクリアします。Broker を再起動するか、管理者としてコマンドプロンプトから Broker で次のコマンドを実行します。
```
klist -li 0x3e4 purge
<!--NeedCopy--> ```
このコマンドは、Citrix Broker Service が実行されている Network Service プリンシパルによって保持されている LSA キャッシュ内のすべてのサービスチケットをパージします。これにより、他の VDA や、場合によっては他のサービスに対するサービスチケットが削除されます。ただし、これは無害です。これらのサービスチケットは、必要に応じて KDC から再取得できます。
-
オーディオのプラグアンドプレイはサポートされていません。ICA® セッションでオーディオの録音を開始する前に、オーディオキャプチャデバイスをクライアントマシンに接続できます。オーディオ録音アプリケーションの開始後にキャプチャデバイスが接続された場合、アプリケーションが応答しなくなる可能性があり、再起動する必要があります。録音中にキャプチャデバイスが取り外された場合も、同様の問題が発生する可能性があります。
-
Windows 向け Citrix Workspace アプリでは、オーディオ録音中にオーディオの歪みが発生する可能性があります。