CITRIX

Raccourcis clavier (mac) dans une session à distance de type windows

Dans ce billet (qui va nous servir de post-it 😉 ) nous allons énumérer les principaux raccourcis clavier Mac (certains de ces raccourcis sont compatibles sur clavier windows) au sein d’une session à distance sur un os de type windows.

Commande	Raccourci clavier
ctrl-alt-del	ctrl + +
Imprimer	ctrl + p
Affichage du menu démarrer	⌘
Afficher l’explorateur	⌘ + e
Démarrer-Exécuter	⌘ + r
Verrouiller la session	⌘ + l
Basculer la langue sur le clavier	ctrl + maj
Copier	ctrl + c
Couper	ctrl + x
Coller	ctrl +v
Tout sélectionner	ctrl + a
Annuler	ctrl + z
Rétablir	ctrl + y
Ouvrir une nouvelle fenêtre	ou ctrl + n
Actualisé	fn + F5 (ou ctrl + r)
Réduire toute les fenêtres	⌘ + d
Passer d’une fenêtre à une autre	+ tab
zoomer/dé-zoomer	ctrl + roulette souris
Touche F1 à F12	fn + touche F1 etc…
symbole {	+ (
symbole }	+ )
symbole [	ctrl + + (
symbole ]	ctrl + + )
symbole \	ctrl + + !
symbole \|	ctrl + + §

Big news : rachat de NORSKALE

Comme vous le savez nous suivons NORSKALE depuis sa création (voir notre billet de 2012 ici), donc pour ceux qui ne le savent pas encore (pourtant ça a pas mal buzzé) NORSKALE a été racheté par CITRIX (le 08 septembre 2016).

Il était temps que CITRIX réagisse face à la concurrence (notamment VMware avec le rachat d’Immidio en 2015) , nous allons suivre avec attention l’intégration de NORSKALE au sein de l’offre CITRIX 😉 .

Au passage Pierre devient “Principal Architect” chez CITRIX (on devrait peut-être plus se croiser du coup 🙂 ).

Désolé on a pas résistez

Web Interface erreur : 404 – File or directory not found

Suite à une mise à jour de Web Interface 5.4.059 vers 5.4.2.59 (OS : 2008 R2 sp1 US), des sites affichait un message “404 – File or directory not found” après l’authentification.

Bien que non bloquant pour lancer une application publiée, ça fait moyen en prod.

Comme le message est explicite, nous avons regardé dans le WebInterface.conf et avons constaté que la partie AppSysMessage_fr pointait sur un chemin incomplet (au passage ce chemin passait en 5.4.059) :

AppSysMessage_fr=<iframe src=’Msg_Info.html’ width=’650′ height=’200′ align=center seamless frameborder=0></iframe>

En corrigeant le chemin de l’ifram src comme ci-dessous l’erreur 404 n’apparaît plus.

AppSysMessage_fr=<iframe src=’..\site\Msg_Info.html’ width=’650′ height=’200′ align=center seamless frameborder=0></iframe>

Une fois le WebInterface.conf corrigé

StoreFront 3.0 : perte des icones

Sur un groupe de StoreFront 3.0 de qualif nous avons rencontré un problème d’icônes. En effet toutes les icônes des applications publiées et bureaux publiés ne s’affichaient plus.

SF3_Error3 Sympa les carrés blancs…

En regardant les events des StoreFront impactés on a vite trouvé la cause dans l’event ID 2 :

Log Name:      Citrix Delivery Services
Source:        Citrix Receiver for Web
Event ID:      2
Task Category: (3003)
Level:         Error
Description:
There was an error during an icon request.
System.UnauthorizedAccessException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b66a5c561874e091
Access to the path ‘C:\inetpub\wwwroot\Citrix\VotreStoreWeb\App_Data\CtxsWebProxyIconCache\L0NpdHJpeC9WRFhBL5Jlc291cmNlcy99Mi9RamxEUVRBeE8UZ3pSVFF9T1RoRFJVVTNOMF

En modifiant les permissions NTFS le problème subsistait

Afin de résoudre ce problème d’affichage nous avons supprimé le contenu du répertoire C:\inetpub\wwwroot\Citrix\VotreStoreWeb\App_Data\CtxsWebProxyIconCache.

On peut retourner à la custo de nos StoreFront (custo qui fera prochainement l’objet d’un billet)

PVS : mise à jour des exclusions anti-virus Citrix

Et oui tout arrive, nous faisons du PVS 🙂 , ce qui nous amène à mettre à jour nos exclusions anti-virus (Le billet sur les exclusions anti-virus est ici).

C’est un poil exagéré mais bon ça nous fait marrer 🙂

PVS serveur

%windir%\System32\drivers\CvhdBusP6.sys
%windir%\System32\drivers\CfsDep2.sys
%ProgramFiles%\Citrix\Provisioning Services\BNTFTP.EXE
%ProgramData%\Citrix\Provisioning Services\Tftpboot\ARDBP32.BIN
%ProgramFiles%\Citrix\Provisioning Services\StreamService.exe
%ProgramFiles%\Citrix\Provisioning Services\StreamProcess.exe
%ProgramFiles%\Citrix\Provisioning Services\soapserver.exe
%ProgramFiles%\Citrix\Provisioning Services\PVSTSB.exe
%ProgramFiles%\Citrix\Provisioning Services\BNAbsService.exe
%ProgramFiles%\Citrix\Provisioning Services\Notifier.exe (à partir de PVS 6.0)
%ProgramFiles%\Citrix\Provisioning Services\MgmtDaemon.exe (à partir de PVS 6.0)
%ProgramFiles%\Citrix\Provisioning Services\Inventory.exe (à partir de PVS 6.0)
…\Store (chemin du répertoire hébergeant les vDisk store)

Poste cible

%ProgramFiles%\Citrix\Provisioning Services\drivers\CNicTeam.sys
%ProgramFiles%\Citrix\Provisioning Services\BNDevice.exe
%ProgramFiles%\Citrix\Provisioning Services\drivers\BNIStack6.sys
%ProgramFiles%\Citrix\Provisioning Services\drivers\CVhdBusp6.sys
…\.vdiskcache (emplacement du fichier de cache vdisk)
%ProgramFiles%\Citrix\Provisioning Services\TargetOSOptimizer.exe
%ProgramFiles%\Citrix\Provisioning Services\drivers\CFsDep2.sys

Une histoire de route

Lors d’une installation d’une nouvelle ferme XenApp 7.6 (Wk2K12 R2 US) nous avons rencontré l’erreur “XDDS:17647403” lors de la Connection (Add Connection and Ressources) à un de nos vCenter (5.1.0).

Ca fait un bail qu’on avait pas une ferme XenApp à la mano

Un peu plus de détails sur notre erreur

En regardant l’erreur de plus près on constate que le vCenter n’est pas joignable :

Error Id: XDDS:17647403
Exception:
Citrix.Console.Common.CitrixAggregateException One or more parallel operations failed
at Citrix.Console.Common.CitrixParallel.InternalForEach[TIn](IEnumerable`1 items, Action`1 operation, Int32 maxSimultaneous)
at Citrix.Console.PowerShellSdk.HypervisorService.Scripts.TestHypervisorConnectionScript.RunScript()
at Citrix.Console.PowerShellInteraction.PowerShellScript`1.Run()
at Citrix.Console.Hypervisors.UI.Pages.HypervisorDetailsPageViewModelBase.ValidatePage()
at Citrix.Console.CommonControls.Wizard.PageContainerViewModel.<>c__DisplayClass3.<ValidateAndMoveToPage>b__2()
DesktopStudio_PowerShellHistory : TestHypervisorConnectionScript
…….
…….
DesktopStudio_ErrorId : HypervisorNotContactable

Effectivement on constate qu’un telnet sur le port 443 à destination de notre vCenter ne passe pas à partir du futur Controller (DDC).

En regardant de plus près (pour être honnête on vous passe les différentes étapes qui nous ont amené là) nous avons constaté dans une trace Wireshark que l’IP de notre Vcenter n’apparaissait pas, vu que nous avons deux cartes réseaux sur notre VM (une pour le backup sur une VLAN différent et l’autre pour la prod) nous changeons l’interface dans Wireshark et relançons une trace et nous constatons que l’IP de notre Vcenter apparaît bien dans notre trace.

En lançant un route print nous constatons que ça ne risquait pas de fonctionner notre histoire :), au passage on vous conseille NetRouteView pour afficher via une GUI les routes d’un serveur.

On constate que la destination 0.0.0.0 à deux routes avec chacune un carte réseau différente renseignée.

Une fois la route 0.0.0.0 pointant sur la carte réseau de backup supprimée nous avons pu joindre notre vCenter (au passage, en comparant avec d’autres serveurs seules les nouveaux serveurs livrés avait ce problème de route).

On va allez papoter avec la DDE 🙂

StoreFront 3.0 erreur MMC (sous Windows 2008 R2)

Comme vous le savez surement StoreFront 3.0 est disponible depuis le 30 juin 2015.

Lors de nos tests nous avions rencontrés une erreur (ou une feature 🙂 ), en effet sur un serveur 2008 R2 Sp1 Fr, nous avions configuré un magasin Web (Store) avec “L’expérience Receiver Classique” (vous savez celle avec le fond d’écran vert), lorsque nous avons voulu activer “L’expérience unifiée” sur le magasin en question nous avons rencontré l’erreur ci-dessous.

SF3_Error1 Ça commence pas bien la 🙂

En regardant du côté des events nous avons trouvé l’erreur ci-dessous.

SF3_Error3

Nom du journal :Citrix Delivery Services
Source :       Citrix Delivery Services Admin
ID de l’événement :1
Catégorie de la tâche :(2850)
Description :
Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. <<<< SiteId -VirtualPath $site.VirtualPath
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.

Citrix.DeliveryServices.PowerShell.Command.RunnerInterfaces.Exceptions.PowerShellExecutionException, Citrix.DeliveryServices.PowerShell.Command.RunnerInterfaces, Version=3.0.0.0, Culture=neutral, PublicKeyToken=e8b77d454fa2a856
Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. <<<< SiteId -VirtualPath $site.VirtualPath
<Data>Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. <<<< SiteId -VirtualPath $site.VirtualPath
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. <<<< SiteId -VirtualPath $site.VirtualPath

Afin d’éviter cette erreur il faut désactiver l’expérience Receiver Classique 🙁 .

Ce problème n’est pas apparu avec un StoreFront 3.0 sous Windows 2012.

Erreur HTTP : Error 503 sur Web Interface

Suite à une mise à jour sur nos Web Interface (5.4 us /2008 R2 us) de prod (suppression de sites XenApp Web) nous avons rencontré sur deux Web Interface une erreur HTTP 503 (Service Unavailable).

Vu que seuls les sites XenApp Web étaient impactés (IIS était ok, la création d’un site et son accès répondait bien), nous avons regardé du coté de IIS, et en cliquant sur l’application Pools (bien sur nous ne sommes pas tombés directement dessus 😉 ), nous avons constaté que “CitrixWebInterface5.4.0AppPool” était arrêté.

Http503_2 C’est sûr que ça risquait de marcher la

Une fois l’application pool “CitrixWebInterface5.4.0AppPool” démarrée, l’erreur HTTP 503 n’apparaissait plus.

Afin de checker les sites XenApp Web de nos différentes Web Interface, nous avons mis en place un script PowerShell permettant de vérifier si les différentes url répondent bien. Dans un second temps en parcourant l’outil de supervision (Zabbix) de notre client actuel, nous avons remarqué que le check d’URL est possible via un scénario web qui lui même va checker les différentes url de nos sites Web Interface (avec un trigger afin de générer une alerte dans Zabbix).

Dans notre cas nous avons créé le scénario web dans un template que nous appliquons à nos Web Interface

Une fois l’étape du scénario créée le check d’url est réalisé

Le trigger que nous avons associé à notre scénario Web, si le dernier check est différent de 0 (check ok) alors une alerte avec un statut haut remontera dans Zabbix

Le résultat de la supervision Web dans Zabbix

Concernant le script Powershell, il faut au préalable :

Modifier en ligne 2 du script les Web Interface à checker
Modifier l’url à checker en ligne 7 du script

Pour la partie PowerShell, si vous avez pas d’outil de surpervision ou autres solution alors à l’ancienne une tache planifiée (en dernier recours)

Check_Url_Webi.ps1

Citrix Logoff Sessions

MAJ : 04/05/10 La version 2.2 est disponible depuis le 19/04/10
Citrix Loggoff Sessions 2.2

MAJ :21/08/09.

L’utilisation de Citrix Logoff Sessions ne nécessite pas d’être admin de la ferme XenApp.
Une version 1.5 comprendra le shadowing

Voici un petit outil qui va vous permettre sans ouvrir d’AMC, de rechercher une session au sein de votre ferme XenApp.

Un fois la session trouvée vous pourrez effectuer les actions suivantes :

Logoff
Disconnect
killer des process
Envoyer un message.

Citrix Logoff Sessions 1.2.1 est dispo ici

Nous joignons à ce billet les fichiers nécessaires pour Citrix Logoff Sessions 1.2.1 (au cas où ):

msstdfmt.dll
mscomctl.ocx
mscomctl.ocx

Vérifiez au préalable que ces fichiers ne sont pas déjà déclarés sous votre OS.

Bien que l’outil soit sympa, il manque la possibilité de faire du shadow sur la session sélectionnée .

Script pour remonter les principales informations d’une ferme XenApp

——————
MAJ : 24/03/10
——————

Rajout dans le script du filtre des stratégies :

—————————————————–
—————————————————–

Suite à un besoin de remonter via un fichier texte les principales informations d’une ferme XenApp, nous avons réalisé un script qui récolte les informations suivantes :

Nom de la ferme
Information sur le Datastore (lecture du fichier MF20.dsn, sur lequel est exécuté le script)
Serveur de licence (avec sa version)
Stratégie(s) : liste toutes les stratégies de la ferme et leur description et leurs état.
Zone(s) : liste toutes les zones de la ferme et leur ZDC respectif.
Calculateurs de charge

Liste tous les serveurs de la ferme avec les informations suivantes

* Ip du serveur
* Zone du serveur
* Type system Exploitation
* Installé le : (date d’installation de l’OS)
* Modèle : (modèle du serveur)
* Produit : (Type du produit XenApp)
* Version : (Version Xenapp)
* Service Pack : service pack Xenapp
* Installé le : (Date d’installation Xenapp)
* HotFixe(s) installé(s)

Le fonctionnement du script est simple (renommer FarmInfoFull.txt en FarmInfoFull.wsf), double cliquer sur le fichier “FarmInfoFull.wsf”, le script va créer à la racine du C: un fichier nommé “XenApp_NOM de votre Ferme.txt”.

Une fois le script terminé, un popup avec le message “fin du traitement, cliquer sur Ok” s’affiche.

Le script a été testé sour XenApp 4.5 R03 et R04 (Windows 2003 Fr Ets – Sp2).

Le code n’est pas très propre 🙁 (nous allons l’amélioré dans la semaine), soyez indulgent.

L’exécution du script sur une ferme de 80 serveurs a pris 1 mn et 10 sec..

Ce script est inspiré de scripts disponibles sur Citrix Community (XenApp Developer NetWork), ainsi que du Google (pour la partie WMI)