Problème de DPI entre deux écrans

Comme vous le savez sûrement, la difference de DPI entre deux écrans lors de connection HDX n’est pas supporté par Citrix (Different zoom or DPI level in XenDesktop and XenApp).

 

Au moins c’est clair 😉

 

Bon ok ce n’est pas supporté,  mais on a une population qui utilise deux écrans de taille différante et qui joue avec des DPI différents entre les deux écrans, ce qui engendre des problèmes de scintillements sur les applications publiées.

Une solution pour contourner (voir l’article Some desktop applications may appear blurred on high-DPI displays de chez Miscrosoft) ce problème est de modifier les propriétés des binaires wfcrun32.exe et wfica32.exe (C:\Program Files (x86)\Citrix\ICA Client) afin de “désactiver la mise à l’échelle de l’affichage pour les résolutions élevées” (Disable Display Scaling On High DPI Settings).

 

Une fois “la mise à l’échelle de l’affichage pour les résolutions élevées” désactivée, nos utilisateurs n’ont plus rencontré de problème de scintillement sur les applications publiées.

 

Post to Twitter

Chrome : fichier ica qui ne se lance plus avant son enregistrement

Suite à la mise à jour du navigateur chrome en version 57.0.2987.133, certains utilisateurs ne pouvaient plus lancer d’applications publiées où de bureau sans avoir au préalable enregistré le fichier ica (une fois le fichier ica enregistré ce dernier se lançait automatiquement).

 

 

Outre le message d’avertissement ci-dessous, nous remarquons que  le fichier ica est téléchargé dans le mauvais dossier.

 

Certaines fonctionnalités de la bibliothèque ne sont pas disponibles car des emplacements ne sont pas pris en charge

 

Some library features are unavailable due to unsupported library locations

 

 

Direction le menu de Chrome, Paramètre-Afficher les paramètres avancé.. – Téléchargement.


Une fois le chemin modifié vers le bon dossier, les fichiers ica étaient lancés sans problème

 

 

 

 

Post to Twitter

Receiver : Erreur de client inconnue 0

Suite à une mise à jour de client Receiver 3.4.300.10 vers 4.4.0.8014 sur des serveurs XenApp 6.5 R06 (W2K8 R2 sp1 Us), certains de nos utilisateurs nous ont remonté une erreur lors de connexion sur des bureaux publiés (se connecter à un bureau publié via un bureau publié….. ça se passe de commentaire 🙂 ) .

The connection to “Desktop………..” failed with status (Unknow client error 0).

La connexion à “Desktop………..” a échoué avec l’état (Erreur de client inconnue : 0) .

 

error_receiver02Comment ça Unknow 🙂


Afin de bypasser cette erreur il faut supprimer la valeur ci-dessous :


HKEY_CURRENT_USER\Software\CITRIX\Program Neighborhood Agent\Resource Cache


On va être honnêtes avec vous, ça a pris pas mal de temps avant d’arriver sur cette valeur 🙂 .

Post to Twitter

StoreFront : activez le SSO (Pass-Through) sur le PNAgent

Comme vous le savez sûrement, sous StoreFront la configuration d’un site PNAgent diffère de celle de Web Interface. En effet sous Web Interface il fallait créer un site de type “XenApp Services Sites” alors que sous StoreFront le “site” PNAgent est créé automatiquement dans chaque Store.

 

site_pna1Ça fait Time Machine de voir ce screenshot 🙂

 

site_pna2Pour configurer le PNA sous StoreFront il faut dans votre STORE cliquer sur “Configure XenApp Service Support” puis choisir le “Default store”

 

Bon ok, mais quand on veut faire du SSO on fait comment, (comme d’hab à l’ancienne 😉 ) , direction le dossier C:\inetpub\wwwroot\Citrix\VotreStore puis ouvrez le ficher web.config. Recherchez la chaine logonMethod=”prompt” puis modifiez la en logonMethod=”sson”.

Bien sûr vous pouvez aussi passez par la case PowerShell, voir le billet de nos collègues de chez kylewise.

Post to Twitter

Citrix HDX Engine a cessé de fonctionner

Suite à un déploiement de receiver 4.4.0.8014, notre support nous a remonté un problème de connexion entre un de nos utilisateurs et une ferme XenApp 5.0 Fr.

 

14_4HDXerror12Ok ok on ferme le programme 🙂

 

Sur le poste de l’utilisateur l’event 1000 ci-dessous nous a permis de résoudre rapidement l’incident notamment la partie “Chemin d’accès du module défaillant: C:PROGRA~2\CITRIX\ICACLI~\gfxrender.dll“.

 

14_4HDXerror11Un event comme on les aimes 😉 .

 

Pour rappel Gfxrender.dll permet le décodage matériel via le client 4.4 (14.4), du coup afin de rétablir le service pour notre utilisateur nous avons désactivé la partie “Client graphics settings” via une GPO filtrée sur le poste de l’utilisateur du poste de l’utilisateur (en attendant un correctif de chez Citrix).

 

14_4HDXerror1

Une fois le “Client graphics setting” désactivé l’accès à l’application hébergé sur une ferme XenApp 5 était de nouveau possible.

 

Si vous souhaitez en savoir plus sur le décodage matériel nous vous conseillons la lecture du post Improved User Experience: Hardware Decoding for Citrix Windows Receiver.

Post to Twitter

Citrix Receiver : Plug-in update désactivés

Si vous installez un client Citrix Receiver 1.2/1.2 (qui pointe sur un serveur Merchandising) sur un serveur XenApp/TS, vous constaterez que les updates de Plug-in sont désactivés (Plug-in updates are disabled).

Afin de le vérifier, faite un clique droit sur le client Receiver, puis Préférences-About.


Afin de pouvoir récupérer les clients disponibles sur votre serveur Merchandising, il faut en ligne de commande sur votre serveur XenApp/TS exécuter la commande :

“C:\Program Files\Citrix\Receiver\Receiver.exe -autoupdate -allowadminTSupdates”

http://support.citrix.com/proddocs/index.jsp?topic=/receiver-windows-11/mer-dep-xa-desktops.html

Une fois la commande exécuté, les updates sont activés sur votre client Receiver.

Post to Twitter