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.
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
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” :
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).
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.
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 🙂 .
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.
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\).
Nous voilà de retour avec vROps (vous allez croire qu’on est fan à force), cette fois-ci ce sont des vms de type dekstop qui ne remontaient plus d’infos dans vROps depuis leur Desktop Agent. Le message d’erreur dans le dashboard “Horizon Help Desk” était :
Not receiving data from the Desktop Agent
En collaboration avec notre collègue de l’équipe “Poste de Travail” (Christophe Mazzardis) nous avons regardé sur plusieurs vms impactées et avons remarqué que dans la log de l’agent View (C:\ProgramData\VMware\vRealize Operations for Horizon\Desktop Agent\logs\v4v-vrops-rmi-YYYY-MM-DD.log) nous avions l’erreur ci-dessous :
0x00002e70 ERROR Failed to initialize RMI in the Java client. java.io.IOException: Invalid keystore format
Vous l’aurez compris le “Invalid keystore format” nous a permis rapidement de faire la liaison avec le fichier “v4pa-truststore.jks” (ce fichier contient le magasin de confiance que l’adaptateur utilise pour authentifier le certificat du broker agent) situé dans “C:\ProgramData\VMware\vRealize Operations for Horizon\Desktop Agent\conf”. En remplaçant le fichier “v4pa-truststore.jks” par un fichier d’une vm ne posant pas de problème et en relançant le service “v4v_agent” (Vmware vRealize Operations for Horizon Desktop Agent) nous avons pu à nouveau obtenir la remontée des métriques view dans vROps.
On regarde vite fait dans le fichier de log Agent\logs\v4v-vrops-rmi-YYYY-MM-DD.log pour voir si ça se passe bien.
7:14:46 0x00000a68 INFO Using message server ‘rmi://vROPsIP:3091′. 17:14:46 0x00000a68 INFO UnregisterDataDumpCallback success: (, , ) 17:14:46 0x00000a68 INFO RegisterDataDumpCallback success: (rmi:// vROPsIP:3091, 539dc7df8b99f2fbddfe841c9332b8dabe1426eee73b449c3b3bfd7fc3d4c1ba, 0500304531153013060355040A130C564D776172652C20496E632E312C302A060355040313237643656E746572204F7065723656E746572204F706573656E746572204F706573656E7B83E986FD33AC301EE104FC25C1DE7435495A………………) 17:14:46 0x00000a68 INFO Using message server ‘rmi:// vROPsIP:3091’. 17:14:46 0x00000c0c INFO Using JRE from ‘C:\Program Files\VMware\VMware View\Agent\jre\’. 17:14:47 0x00000c0c INFO SUCCESSFULLY initialized the Message Logger. 17:14:47 0x00000c0c INFO Initialized communication manager. 17:14:47 0x00000c0c INFO Updated the message server URL in the Java client to rmi:// vROPsIP:3091.
Le “SUCCESSFULLY initialized the Message Logger” confirme que tout est ok.
Retournons côté vROps afin de voir si notre vm a bien ses métriques View qui remontent.
Maintenant que le problème est résolu, on va essayer de lire le fichier “v4pa-truststore.jks” (qui causait problème) via “KeyStore Explorer” (le mot de passe du fichier “v4pa-truststore.jks” est contenu dans le fichier “msgclient.properties” (truspass =……..).
Maintenant nous allons regarder ce qu’il y a dans un fichier “v4pa-truststore.jks” sain.
Retournons côté vROps pour voir si notre vm remonte bien les métriques View.
Dans un vROps (8.01) dédié à une infra Horizon View (ver 7.10) nous sommes tombés sur un “No Data” dans le Dashboard “Horizon Adapter Self Health” dans la section “Horizon Broker Agent Event DB Collection Statistics”.
Direction le Connection Server où est installé le Broker Agent afin de vérifier que tout est bien configuré (pour la partie Event DB). Allez dans le menu Démarrer – Executer et tapez la commande ci-dessous afin de lancer le “Broker Agent Config Utility for Horizon”.
C:\Program Files\VMware\vRealize Operations for Horizon\Broker Agent\bin\v4v_brokeragentcfg.exe
Passez les étapes de Pairing et de Connection Server, nous arrivons à l’écran “Configure the Envent DB and Pool Filters”, lors du test username/password nous obtenons l’erreur ci-dessous :
Event DB username and password cannot be validated Format of the initialization string does not confirm to specification starting at index 104 An error has Occurred Operation Validate DB Credential has Failed
Là ou ça devient intéressant c’est que le username/password utilisé est déjà utilisé dans la console View (dans la partie Configuration d’événements). Côté SQL les logs ne font même pas apparaître un problème d’authentification. Vu que l’association username/password fonctionne via la console view et ne fonctionne pas via l’agent broker, nous avons testé avec un mot de passe moins complexe.
Reste à voir dans le vROps ce que ça donne pour notre problème de “no data” dans le Dashboard “Horizon Adapter Self Health” dans la section “Horizon Broker Agent Event DB Collection Statistics”
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.
Ouvrez une console sur un des Connection Server et entrer la commande ci-dessous :
Juste un petit warning, si vous faîtes un update d’un infra Horizon View (dans notre cas 7.1 vers 7.10 avec des replica server) n’oubliez pas d’ouvrir le port TCP 32111 entre vos Connection Server et les Réplica. Si vous lisez la la KB1027217, notamment la section “TCP Ports for View Connection Server and Replica Server Instances” vous remarquez l’absence du port TCP 32111.
Par contre si on lit la KB1027217 jusqu’au bout (notamment les notes en bas de la KB ) on tombe sur :
In Horizon 7.2 and later, TCP 32111 is required between Connection Servers in a replica group
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).
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.
Comme vous le savez Horizon view repose sur une base ADAM repliquée entre les divers Connections Servers, c’est bien… c’est beau tant que ça se réplique bien, le jour où vous rencontrez des problèmes de réplication alors il sera grand temps de vous souvenir de votre expérience AD. De notre côte sur une infra 7.3 avec 3 connections Servers nous avons rencontré les event id 2091 et 2092.
Ownership of the following FSMO role is set to a server which is deleted or does not exist.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
FSMO Role: CN=Partitions,CN=Configuration,CN={F82E0D4A-16B0-44B1-91B7-5F5A08BD619A} FSMO Server DN: CN=NTDS Settings\0ADEL:8f620d83-00d8-4b15-87fc-97430126a71e,CN=Server01$VMwareVDMDS\0ADEL:b5ebd2b8-1345-48ab-bb4c-554090afca20,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={F82E0D4A-16B0-44B1-91B7-5F5A08BD619A}
This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
Afin de pouvoir forcer un schema master, nos amis de VMware nous ont pondu la KB2083758 qui va nous permettre de configurer un nouveau Shema Master (attention l’étape 8 n’est pas obligratoire, nous l’avons rajoutée car dans notre cas il fallait forcer le “naming master”).
To open the command prompt:
Click Start.
Right-click Command Promptand then click Run as administrator.
In the command prompt, run this command: dsmgmt
In the dsmgmt command prompt, run this command: roles
In the fsmo maintenance command prompt, run this command: connections
In the server connections command prompt, run this command: connect to servercomputername:portnumber where computername:portnumber is the computer name and communications port number of the AD LDS instance that you want to use as the new schema master.
In the server connections command prompt, run this command: quit
In the fsmo maintenance command prompt, run this command: seize schema master
(Etape rajoutée) In the fsmo maintenance command prompt, run this command: seize naming master
Type exit and press Enter
Une fois les commandes passées nous avons bien un nouveau schema master et plus d’erreurs dans les events log de nos Connection Server