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. 

CommandeRaccourci clavier
ctrl-alt-delctrl + +
Imprimerctrl + p
Affichage du menu démarrer
Afficher l’explorateur⌘ + e
Démarrer-Exécuter⌘ + r
Verrouiller la session⌘ + l
Basculer la langue sur le clavierctrl + maj
Copierctrl + c
Couperctrl + x
Collerctrl +v
Tout sélectionnerctrl + a
Annulerctrl + z
Rétablirctrl + y
Ouvrir une nouvelle fenêtreou 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é-zoomerctrl + roulette souris
Touche F1 à F12fn + touche F1 etc…
symbole { + (
symbole } + )
symbole [ctrl + + (
symbole ]ctrl + + )
symbole \ctrl + + !
symbole |ctrl + + §

Post to Twitter

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

VMmark 3.1.1 erreur lors du lancement de notre premier “Tile”

Dernièrement nous avons testé VMmark 3.1.1 (pour rappel VMmark permet de bencher et mesurer l‘évolution des plates-formes virtuelles) afin de bencher des serveurs DELL (PowerEdge R7515). On vous passe les étapes douloureuses (nous ferons un billet sur l’installation de VMmark 3.1.1 très prochainement) de l’installation et la configuration. Une fois l’installation terminée on lance notre premier Tile et là une belle erreur (ce n’est pas comme si c’était la première en plus…) mais celle-là aurait pu être évitée (genre RTFM) : “Error : machine = client0: Invalid Trust Level (3).

Ca commence pas bien notre affaire 🙂

La seule info qui nous intéresse dans le message d’erreur est “Client0”, comme tout bon Sysadmin on fait un ping de notre fameux “Client0”, comme nous n’avons pas de retour, direction le vCenter.

Sans IP elle ne risque pas de répondre notre CLIENT0 🙂

En allant plus loin on constate que l’IP du CLIENT0 (192.168.1.2) a été attribué à la VM DeployVM0 (le conflit d’IP explique notre message d’erreur). Direction le fichier VMmark3.properties (situé dans /root/VMmark3 de la VM “PrimeClient”) afin de voir si on n’a pas un problème de configuration sur la VM “Client0” ou  DeployVM0. Après une recherche dans le fichier VMmark3.properties on comprend d’où vient le problème, le deploy/DeployVMinfo est égal à DeployVM0:192.168.2 soit l’IP de de notre VM “CLIENT0”. 

Il ne reste plus qu’à mettre la bonne IP

Quand on lit le commentaire “Specifies the name and IP address of the deployed VMs. Ex DeployVM0:192.168.1.245,DeployVM1:192.168.1.246” on se dit qu’on a raté quelques chose 🙂 .

Une fois l’IP de la VM “DeployVM0” passer sur 192.168.1.245 notre Tile est passé sans encombre

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

    vRLI : reset du mot de passe utilisateur cassandra

    Récemment sur un vRLI 4.8.0-13036238, nous avons constaté que le compte par défaut de Cassandra (user : cassandra) avait un mot de passe qui ne respectait pas  les critères de sécurité de notre entreprise. Pour faire un  reset du mot de passe du compte user “cassandra” dans Cassandra (vous nous suivez ? 🙂 ) , il faut ouvrir une console SSH sur votre vRLI puis entrer dans Cassandra et lancer deux commandes.

    Une fois connecté en SSH sur votre vRLI, lancer la commande ci-dessous afin de rentrer dans Cassandra.

    /usr/lib/loginsight/application/lib/apache-cassandra-*/bin/cqlsh -u cassandra -p YourPassword
    
    Il ne reste plus qu’à faire un reset du password 😉

    Entrer la commande ci-dessous afin de faire le reset du password du compte cassandra.

    ALTER USER cassandra WITH PASSWORD 'NewPassword';
    
    Taper exit puis valider.

    Quelques liens utiles :

    Post to Twitter

    VM avec deux Datastores appartenant à deux Clusters de Datastores différents

    Lors d’un dernier check de routine avant une decomm de Datastore nous avons eu l’agréable surprise  de tomber sur une VM qui avait deux Datastores qui eux-mêmes appartenaient à deux clusters de Datastore différents (jusqu’a là pourquoi pas… mais vu que la dite VM n’avait rien à faire là, nous avons voulu en savoir plus.)

    Là où c’est rigolo c’est que le premier Datastore est complètement vide et que le deuxième Datastore contient bien tous les fichiers de notre VM 🙂

    On s’aperçoit aussi que toute modification de la VM est impossible (ce qui nous étonne qu’à moitié) et que notre VM a une ISO attachée (ça donne une bonne piste vous l’aurez compris.)

    En googlelant nous sommes tombés sur la KB2105343  qui explique en détail comment procéder pour supprimer le Datastore “intrus”.

    1. Vérifier l’emplacement du fichier vmx de la vm
    2. Faire un “Power Off” de la vm
    3. Faire un “Remove from Inventory” de la vm
    4. Inventorier la vm dans le vCenter
    5. Faire un clique droit sur la vm, Edit Setting, dans “CD/DVD drive 1*” choisir “Client Drive” puis cliquer sur le bouton “OK”
    6. Vous pouvez “Power On” la VM si vous le souhaitez
    Nous avons désormais un seul Datastore et on va pouvoir décommissionner notre Datastore vide 🙂

    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

    vROPs : Not receiving data from the Desktop Agent

    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

    Ne soyons pas médisants on a déjà le protocole qui remonte 🙂

    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.

    Après quelques minutes tout est ok

    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 =……..).

    Comme nous sommes sur du mot de passe, nous optons pour “le fichier magasin de certificats est corrompu”….on va cliquer sur Ok comme on est joueur
    Et en cliquant sur le bouton Détails ?
    Nous ne sommes pas plus avancés pour l’instant…..

    Maintenant nous allons regarder  ce qu’il y a dans un fichier “v4pa-truststore.jks” sain.

    On a bien la liste des certificats 🙂

    Retournons côté vROps pour voir si notre vm remonte bien les métriques View.

    Nickel

    Post to Twitter