Console Horizon : Incorrect credentials were entered

Cela faisait longtemps qu’on n’avait pas rencontré le fameux “bug ou feature”. C’est chose faite avec cette erreur rencontrée sur la Console Horizon VIEW (VMware Horizon 2111.1) que nous a partagé un de nos collègues sysadmin. Lorsque nous essayons de nous authentifier sur la console  Horizon VIEW, juste après le timeout de session de la Console, nous obtenons systématiquement l’erreur :

Incorrect credentials were entered

Afin de by-passer cette erreur un refresh de la page d’authentification suffit 😉

En regardant dans les logs du Connection Server (C:\ProgramData\VMware\VDM\logs\debug-yyyy-mm-dd-xxxxxx.txt) on observe plusieurs erreurs de type “[RestApiAuthFilter] Authentication failed” :

<ajp-nio-127.0.0.1-8009-exec-4> [RestApiAuthFilter] Authentication failed,  Unexpected fault: encrypt: Cannot decrypt: Key not supplied

On comprend que le call de l’API “RestApiAuthFilter” est à l’origine de notre erreur d’authentification et que ce dernier n’a pas de ticket valide pour exécuter la requête (c’est pour cela que le refresh de la page d’authentification permet de résoudre le problème).

Allez dans le Menu Settings- Global Settings et cliquez sur le bouton modify afin de pouvoir modifier le time-out de session API

Une fois la modification enregistrée, cette dernière est prise en compte immédiatement. Le problème d’authentification  après le timeout de session de console n’apparait plus (sauf au delà du timeout de session API 🙂 ). 

Comme nous sommes curieux, nous avons testé cette feature avec la version VMware Horizon 2212.

Y a du mieux avec la 2212, désormais on nous demande de refresh la page 🙂

Après “quelques” échanges (qui ont duré quatre semaines) avec le support VMware la réponse finale tombe (et honnêtement on ne l’avait pas vu) “RTFM” : https://docs.vmware.com/en/VMware-Horizon/8-2111.1/rn/vmware-horizon-8-21111-release-notes/index.html

2852439: When administrators try to access the Horizon console without closing the browser or opening a new session in another tab or reloading the page after leaving the interface idle on the Login Page for an extended period of time (longer than the value for Global Settings Timeout), they are not able to login even with correct credentials.

    Workaround: Open a new session in another tab or reload the login page.

Vous avouerez cette feature est vraiment super sympa 🙂 .

Post to Twitter

Horizon VIEW 2212 : Impossible de charger les domains sur la console d’administration

Sur une infra Horizon VIEW 2212 fraîchement installée, nous avons rencontré l’erreur ci-dessous, sur la page d’authentification de la console d’administration.

Page failed to load. Please refresh the browser to reload the page.

Outre l’erreur nous n’avons plus de Domains, sûrement une Feature 🙂

L’erreur se produit en utilisant l’IP ou un alias DNS du Connection Serveur, dans l’url de la page de la console d’administration Horizon VIEW (en localhost ou via le nom DNS du Connection Server le problème ne se posait pas). 

Au départ, on pensait à un problème d’Origin checking qu’on avait déjà traité dans le billet Horizon 7.10 error : warning Echec de la connexion, au final le problème venait du CORS (Cross-Origin Ressource Sharing), même si dans notre cas nous ne sommes pas derrière un LB, le problème reste identique 🙂 . Comme VMware fait bien les choses, la KB85801 permet de résoudre facilement cette erreur via la modification (et ou la création) du fichier “locked.properties” (situé dans c:\program files\vmware\VMware View\Server\sslgateway\conf\).

Rajoutez “portalHost=” avec l’entrée qui vous intéresse (dans notre cas l’IP du Connection Serveur), puis redémarrez le service “Composant VMware Horizon View Security Gateway”
On retrouve bien nos Domains 😉

Post to Twitter

ESXi : Host TPM attestation alarm

Sur plusieurs hosts PowerEdge R7515 nous avons constaté après l’installation d’ESXi 7.0.2 (17867351) une erreur TPM sur un de nos vCenter de test (notre fameux POC VCF)  :

Host TPM attestation alarm

L’erreur se produisant uniquement sur des PowerEdge R7515 il semblerait que nous ayons oublié de paramétrer correctement la partie TPM dans la config de nos serveurs DELL 🙂 . Direction l’ IDRAC pour vérifier ça.

  • Aller dans le BIOS (F2)
  • BIOS Settings-System Security
Dans un premier temps on fait un clear avant de paramétrer la suite
  1. Cliquer sur  Clear (confirmer en cliquant sur le bouton Ok  lors de l’affichage du popup).
  2. Cliquer sur TPM Advanced Setting.
Cliquez sur SHA256 (voilà pourquoi on avait l’erreur)
Cliquez sur le bouton Yes
Cliquez sur bouton Ok
Cliquez sur le bouton Back
Cliquez sur le bouton Finish
Cliquer sur le bouton Finish
Cliquez sur le bouton Yes
Cliquer sur Reset To Green (et dans notre cas on pourra relancer l’upgrade de ce Workload Domain dans VCF 🙂 )

Post to Twitter

VCF : Premier BriengUp

Dans le cadre d’un POC VCF 4.3.0 (VMware Cloud Foundation) nous avons rencontré une erreur (ou plutôt nous avons retenu celle-là 🙂 ) lors de l’installation du Cloud Builder.  Lors de l’étape “Validate Configuration” tout se passait bien jusqu’à l’apparition d’un Failed associé à l’erreur “Error connecting to ESXi host xxxx. SSL certificate common name doesn’t match  ESXi FQDN” sur les quatre host de notre POC.

C’est sur que si le Cloud Builder ne peut pas se connecter aux ESXi ça va être dur pour la suite 🙂

Le message d’erreur “Error connecting to ESXi host xxxx. SSL certificate common name doesn’t match  ESXi FQDN” est explicite, le certificat par défaut des ESXi ne convient pas au Cloud Builder pour se connecter aux ESXi, du coup impossible pour Cloud Builder d’aller plus loin. En relisant les pré-requis on s’aperçoit que depuis la version 4.2 de VCF, il faut que le certificat de l’ESXi soit au format host.FQDN (et corresponde bien sûr à ce qui est rentré dans votre fichier de configuration Cloud Builder).

RTFM 🙂 c’est ici

Comme indiqué  par VMware les étapes pour régénérer le certificat sont très simples :

  1. Connectez-vous en SSH sur chaque hôte ESXi.
  2. Lancez la commande “esxcli system hostname get” et vérifiez que Host est bien au format Host.FQDN dans la section “Fully Qualified Domain Name: “, si c’est bien le cas passez directement à l’étape 6.
  3. Lancez la commande “vi etc/hosts” puis ajouter votre Host.FQDN et enregistrer (touche “echap” puis “:wq!”.
  4. Lancez la commande “esxcfg-advcfg -s Host_FQDN /Misc/hostname” (remplacer Host_FQDN par le nom de votre host et son FQDN).
  5. Lancez la commande “reboot” 
  6. Lancez la commande “/sbin/generate-certificates“puis validez
  7. Lancez la commande “/etc/init.d/hostd restart && /etc/init.d/vpxa restart

    Il ne vous reste qu’à faire un “retry” dans le Cloud Builder 😉 .

    Et voilà 🙂 la suite dans un prochain billet (on vous promet c’est fun)

    Post to Twitter

    Error : A specified parameter was not correct……

    Lors d’un Storage vMotion en masse nous avons rencontré sur certaines VMs l’erreur ci-dessous.

    A specified parameter was not correct: ConfigSpec.files.vmPathName

    En regardant de plus près même la suppression d’une des VMs en question n’était pas possible non plus (au préalable on a bien vérifié qu’on avait un backup récent 🙂 ).

    Afin de pouvoir terminer notre Storage vMotion nous avons dû faire un “Remove from Inventory”sur les VMs qui posaient problème puis les inventorier dans le vCenter (6.7.0.48000)

    Ci-dessous la commande pour afficher les VMs d’un vCenter avec leurs clusters, dossiers et le chemin du vmx.

    Get-VM | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, @{N="vmx Path";E={$_.ExtensionData.Config.Files.VmPathName}},@{N="VM Folder";E={$_.folder}}

    Ci-dessous un exemple de commande pour inventorier une VM qui causait problème.

    New-VM -VMFilePath "[datastore0] FolderVm/MyVM1.vmx" -VMHost (Get-Cluster "MyCluster" | Get-VMHost | Get-Random) -Location (Get-Folder MyFolder) -RunAsync

    Comme vous savez faire vos boucles, il vous reste plus qu’à….. 😉

    Post to Twitter

    Erreur :vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured

    Suite à une sortie de maintenance de plusieurs ESXi 6.7 (dans un vCenter 6.7) nous avons rencontré les erreurs ci-dessous :

    vSphere HA Host status

    vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured

    En faisant un “Reconfigure for vSphere HA” sur un des ESXi, cette fois nous avons eu droit à l’erreur :

    The object ‘vim.Datastore:datastore—–‘ has already been deleted or has not been completely created 

    Sur ce cluster nous savions qu’il y avait une “migration de datastore” il y a quelques temps, ce qui nous a amené à effectuer les actions ci-dessous afin de résoudre cette problématique :

    • Désactivez HA sur le Cluster (onglet Configure – Edit)
    • Activez HA sur le Cluster (onglet Configure – Edit)
    • Sur le cluster, onglet Configure – Edit – Edit Cluster Setting – Heartbeat Datastore
    • Cliquez sur “Use datastores only from the specified list”
    • Cliquez sur le bouton Ok
    • Allez sur le cluster, onglet Configure – Edit – Edit Cluster Setting – Heartbeat Datastore
    • Cliquez sur “Use datastores from the specified list and complement automatically if needed”
    • Cliquez sur le bouton Ok

    Sur l’ESXi faite un « Reconfigure for vSphere HA », l’erreur devrait disparaitre.

    Post to Twitter

    Horizon View : cacher un/des domaine(s)

    Ce que l’on apprécie dans Horizon View c’est la simplicité de mise en oeuvre (nous ferons prochainement un billet dessus), par contre certains détails comme par exemple cacher un domaine en 5x, 6.0x et 7x  (sur la fenêtre d’authentification du client View ou de la console View ) passe par la case ligne de commande uniquement (pourquoi ne pas continuer à faire simple pour un simple paramétrage ….) . La commande permettant de cacher un ou plusieurs domaine(s) est “vdmadmin”, c’est un peu la commande couteau suisse sous Horizon View au passage.

    Dans le cas présent le but est de ne présenter qu’un seul domain lors de l’affichage des fenêtres d’ authentification

    Ouvrez une console sur un des Connection Server et entrer la commande ci-dessous :

    vdmadmin -N -domains -exclude -domain VotreDomain -add

    Exécutez la commande autant de fois que vous avez de domains à cacher
    Il ne reste plus qu’un seul domain de visible

    Si vous souhaitez plus de détails sur les exclusions/inclusions de domain avec la commande vdmadmin :

    Post to Twitter

    Horizon View 7.10 : Access denied en PowerCli

    Toujours dans la série des “problèmes” de permission sous Horizon View 7.10, cette fois-ci c’est via PowerCli qu’on nous a remonté l’erreur ci-dessous.

    Access denied, user must have Direct interaction privilege


    Afin de permettre les connections via PowerCli à Horizon View, il faut rajouter l’utilisateur (le mieux étant le groupe de l’utilisateur) dans le rôle “Local Administrators (Read only) dans la console Horizon View (dans notre exemple la console Flash).

    Post to Twitter

    Horizon View 7.10 : Probème d’accès console Flash

    Récemment un de nos collègues admin nous a remonté un problème d’accès sur les consoles Flash (Horizon View 7.10). Le message d’erreur “Votre compte n’est pas autorisé à fonctionner via cette console” (“Your account is not allowed to operate through this console”) s’affichait systématiquement lors des tentatives de login via la console Flash, en HTML5 cela passait sans problème.


    Sur le Connection Server où l’authentification a eu lieu nous avons constater dans le journal d’events (Application) l’event ID 104 : ADMIN_LOGIN_FAIL 

    User login attempt has failed to authenticate to View Administrator with username and password
    Attributes:
    UserName=username12
    ForwardedClientIpAddress=
    Node=——–
    ClientIpAddress=—–
    Severity=AUDIT_FAIL
    Time=Thu Aug 20 14:50:37 CEST 2020
    Module=Admin
    Source=com.vmware.vdi.admin.ui.LoginBean
    Acknowledged=true
    The specified resource type cannot be found in the image file


    Après plusieurs recherches infructueuses (au niveau des groupes AD notamment) nous avons fait des tests au niveau des permissions et avons réalisé qu’en rajoutant le groupe (ou le compte) de notre collègue admin dans  le rôle “Inventory Administrators (Read only)” cela permettait de corriger le problème.

    Une fois le groupe rajouté l’accès à la console Flash était de nouveau possible

    Post to Twitter

    Horizon View : activer le “timingProfiler”

    Apparut avec la version 7.2, le “timingProfiler” permet d’afficher au sein de l’outil “Help Desk” le temps de chargement d’un profil avec certains détails comme les temps pour l’Authentification, Brokering, protocol connection, GPO Load, Logon Script, Profil Load et l’intéractive.

    C’est toujours pratique ce type info pour les collègues du support


    Pour activer le “timingProfiler” il faut passer la commande ci-dessous sur tous les Connection Server afin d’avoir accès à la section “Logon Segments” dans le HelpDesk

    vdmadmin -I -timingProfiler -enable
    


    Il est dommage que cela ne soit pas activé pas défaut lors de l’installation d’un Connection Server standalone (ou replica).
    Ci-dessous la définition de certains des  items remontés dans le “Logon Segments” (en 7.10).

    https://docs.vmware.com/en/VMware-Horizon-7/7.10/horizon-administration/GUID-F14767BD-738F-494D-8DF0-AD955C22EEB1.html

    Si vous souhaitez avoir plus de détails sur le logon de vos users, c’est possible via Logon Monitor (qui est inclus dans l’agent View depuis la version 7.1, au passage on parlait déjà de Logon Monitor en août 2016 dans le billet “Logon-monitor-cest-gratuit-foncez” 🙂 .

    Post to Twitter