Page 4

Horizon 7.10 error : warning Echec de la connexion

Suite à la migration d’un environnement Horizon view 7.3 vers 7.10, on nous a remonté une erreur de connexion à la console d’administration HTML5 avec les navigateurs Chrome (79.0.3945.117 – Build officiel – 32 bits ) et Firefox (72.0.1 – 32 bits).

Le problème se produit uniquement avec Chrome et Firefox… qui a dit que Internet Explorer était un mauvais navigateur 🙂 .

Ce problème de connection peut-être résolu en modificant le fichier “locked.properties” (dans le cadre d’un problème d’affichage HTML5 via le navigateur Edge et en passant par des F5 nous avions deja eu l’occasion de jouer avec le fichier “locked.properties”). Revennons à nos moutons, la KB2144768 chez VMware nous donne la liste des actions à réaliser afin résoudre ce problème de connexion.

Créer le fichier C:\Program Files\VMware\VMware View\Server\sslgateway\conf\ locked.properties
Ajouter la ligne : checkOrigin=false
Redémarrer le service « Composant VMware Horizon View Security Gateway” (wstunnel)

Voila ça c’est fait (il nous reste encore quelques bugs qui feront l’objet d’autres posts 🙂 )

vCenter error : interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

Sur un vCenter 6.5 Version 6.5.0.10000 Build 5973321 nous avons rencontré l’erreur ci-dessous dans l’onglet “Update manager – Attacher une ligne de base”

interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

Mais comme on est pressé et que VMware fait bien les choses la KB 60640 répond pile-poil à notre problème

Allez en SSH sur le vCenter
Lancez la commande service-control –stop –all
Lancez la commande service-control –start –all

Horizon View 7.8 : vmware view error during provisioning initial publish failed fault type is VC_FAULT_FATAL

Lors de l’intégration d’un serveur composer dans une infra Horizon View 7.8 on nous a remonté l’erreur ci-dessous lors du déploiement de machines au sein d’un pool de postes de travail en “Automated, instant clone, floating”.

vmware view error during provisioning initial publish failed fault type is VC_FAULT_FATAL

Au départ nous pensions à un problème de permissions sur le Vcenter, mais en regardant de plus près sur la configuration du vCenter/Composer dans la console “Horizon 7 Administrator” nous avons constaté que le vCenter était configuré avec un compte local

Et si on configurait l’accès au vCenter avec un compte de service du domaine 🙂

Une fois le compte local remplacé par un compte de service du domaine (avec les permissions adéquates) le déploiement de machines a pu se faire sans problème.

Nous avons mis le même compte de service pour le vCenter et le Composer 😉

VIP injoignable sur NetScaler VPX

Sur des NetScaler VPX (11.0.71.18 qu’il faudra mettre à jour ASAP) nous avons créé des VIPs qui étaient pingables mais injoignables sur les ports sur lesquels elles étaient configurées (dans le cas présent TCP 443 et TCP 8085).

En regardant du côté firewall (ASA) nos collègues du réseau ont remarqué des time-out et drop.

01/09 07:37:35 <182>Sep 02 2019 20:37:17: %ASA-6-106015: Deny TCP (no connection) from xx.xxx.xx.xxx/80 to xx.xxx.xx.xxx/59968 flags SYN ACK  on interface cag_VIP978

En googlelant nous sommes tombés sur la CTX205292 extrêmement intérressante, en effet activant le MBF sur les Netscaler, les VIPs étaient joignables sans problème.

Pour activer le MBF il faut se connecter en SSH sur le Netscaler et lancer la commande ci-dessous.

enable ns mode mbf

Le problème dans notre cas était bien un problème de routage asymétrique et pas question de toucher à la conf des firewall, donc on a activé le mode MDF sur les Netscaler.

vSAN : Rechercher un disque

La lecture du titre de ce post vous laisse dubitatif avouez le 🙂 .

Dernièrement nous avons dù identifier physiquemebt un disque (au sein d’un disque group) qui rencontrait de grosses latences (entre 15000 ms et 45000 ms), un remplacement rapide s’imposait donc.

Le problème est que nous avons pu identifier le disque au sein du disque groupe via son naa, mais comment l’identifier physiquement sur l’ESXi (serveur CISCO UCS-C240-M4SX) ? Dans UCS Central aucune alarme ne remontait côté disque (normal il n’y a pas de problème hardware vous nous direz) et en ESXCLI on ne remonte pas d’informations de type PID permettant de faire le lien entre le naa. et le disque dans UCS. Dans le Vcenter, sur l’ESXi dans l’onglet “Configure” – “Storage-Storage Device” vous avez un bouton qui permet (logiquement) d’allumer la led d’un disque selectionné (le fameux “turn on ou turn off disk locator”), mais dans notre cas cela ne fonctionnait pas.

En googlelant nous sommes tombés sur la commande ci-dessous qui permet d’allumer (ou clignoter) la led d’un disque.

esxcli storage core device set -d naa.50000397885347bd -l=locator -L=600

Après avoir trouver une âme charitable dans le Datacenter, le collègue a pu nous donner la position du disque dans le serveur en vue de son prochain remplacement.

vSAN : Supprimer un objet dans le “Resyncing Component”

Dans un Vcenter 6.5.0 (build 5318154) au sein d’un cluster vSAN (version : 6.6) nous avons remarqué la présence d’un objet orphelin dans l’onglet “Resyncing Components”.

L’objet avait été supprimé il y a quelque temps, mais visiblement vSAN ne l’entend pas de cette oreille 🙂

Nous avons constaté que le vSAN Health était en jaune en GUI et via la commande ci-dessous.

esxcli vsan health list

Le problème en l’état, c’est que nous ne connaissons pas l’objet récalcitrant, afin de le retrouver nous avons lancé la commande ci-dessous.

esxcli vsan debug resync list

Voila notre objet est désormais identifié.

Afin de supprimer un objet récalcitrant il existe une commande qui permet de supprimer des objets, cependant cette commande est à utiliser avec parcimonie 😉 .

/usr/lib/vmware/osfs/bin/objtool delete "your object" -f -v 10

Et là, mauvaise nouvelle, la commande se termine par un failed 🙁 .

Du coup on décide de lancer les commandes ci-dessous au cas où.

esxcli vsan debug resync list

esxcli vsan health cluster list

Et voila tout est en green, la commande objtool a visiblement quand même fait un petit nettoyage 🙂

Installation/Configuration d’un VDA sur Ubuntu 16.06.1 LTS

Celà faisait longtemps (très) que nous souhaitions faire un billet sur l’installation et la configuration d’un VDA sur un OS Linux (dans notre cas une Ubuntu 16.06.01 LTS). Il faut être honnête Citrix nous a bien simplifié la vie depuis les premières version de VDA sous Linux, ou il fallait faire mille et une manips afin de pouvoir configurer correctement son VDA, maintenant c’est simplifié au possible.

Concernant le VDA nous avons choisie la version 7.15.0.404 (LTSR) disponible ici, n’oubliez pas de lire le pdf sur la 7.15 qui vous évitera de partir à l’aventure si vous souhaitez utiliser une autre distribution (au passage vous noterez que la version 16.06 n’est pas mentionnée dans le pdf 😉 ).

Continue reading “Installation/Configuration d’un VDA sur Ubuntu 16.06.1 LTS”

Vcenter error : esx.problem.hyperthreading.unmitigated

Si comme nous, vous rencontrez l’erreur “esx.problem.hyperthreading.unmitigated” sur un host ESXi dans votre Vcenter (dans notre cas un Vcenter 6.5) après l’application de patch, alors là KB57374 va vous aider a supprimer rapidement cette erreur et à comprendre son origine.

On va quand même pas désactiver l’hyperthreading quand même 🙂

Comme l’explique la KB57374, il suffit de forcer la valeur “UserVars.SuppressHyperthreadWarning” à 1 afin de supprimer ce message dans les options avancées (Onglet Configure, puis aller dans System-Advanced System Settings) de l’ESXi, mais comme on est sympa on vous donne aussi la version en CLI.

Get-VMHost MyESXi | Get-AdvancedSetting -Name 'UserVars.SuppressHyperthreadWarning' | Set-AdvancedSetting -Value 1

StoreFront : Lancement d’applications impossibles

Lors d’une partie de troubleshooting avec un collègue Sysadmin nous sommes tombés sur un problème peu banal, en effet les utilisateurs pouvaient s’authentifier sur les StoreFront (environnement Citrix virtual apps and desktops 7.15 LTSR avec du SQL AlwaysOn) et voir les applications publiées mais ne pouvaient les lancer (toutes les applications de la ferme étaient impactées). Lors du click sur une application le message d’erreur “Impossible de démarrer l’application……” apparraissait systématiquement.

Sur les StoreFront nous avons constatés les events ci-dessous (aucun event sur les Controllers).

Script : Supprimer les applications d’un utilisateur ou d’un groupe

Dans Citrix Virtual and Desktops supprimer un utilisateur ou un groupe de toutes ses applications ou bureaux publiés peut vite s’averer fastidieux.

Le fameux Testdf1 qui nous suit depuis tant d’années 🙂

Comme on est sympa on ne va pas vous laisser supprimer à la mano tous ces utilisateurs/groupes. Le script Powershell “Xa7x_Unpublished” va juste vous demander de rentrer le nom de l’utilisateur ou groupe que vous souhaitez supprimer (ou visualiser) des applications et bureau publiés.

Lancez le script
Entrez le nom de l’utilisateur ou groupe
Entrer 1 si vous souhaitez supprimer l’utisateur/groupe ou 2 si vous souhaitez uniquement visualiser le resultat
Un fichier de log ( Xa7x_Unpublished.log) est disponible dans le répertoire d’exécution du script.