vROps : No Data

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”.

On sent qu’on va adorer la suite… 🙂

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

On commence à comprendre notre “No data” dans vROPs”

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.

Avec un password sans certains caractères spécifiques ça passe sans problème 🙂

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”

Nickel 🙂

Un petit aparté au sujet de SexiGraf, Horizon View devrait faire son apparition dans SexiGraf très prochainement.

c’est dans le pipe on nous dit 🙂

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

La KB à lire jusqu’au bout… mais vraiment jusqu’au bout

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.

Donc pas besoin 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

On avait remonté ça à VMware il y a quelques mois.. mais ils préfèrent les KB type “Escape Game” 🙂



L’attribut alt de cette image est vide, son nom de fichier est EscapeGame.jpg.
Bienvenu dans la KB1027217 🙂

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 7.3 : event id 2091/2093

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.
 
FSMO Role: CN=Schema,CN=Configuration,CN={F82E0D4A-16B0-44B1-91B7-5F5A08BD619A}


Nous comprenons rapidement que nous n’avons pas de schema master, pour confirmer cela on ouvre un “Active Directory Schema” (via une mmc)

Et voila la source de notre problème


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”).

  1. To open the command prompt:
    • Click Start.
    • Right-click Command Prompt and then click Run as administrator.
  2. In the command prompt, run this command:
    dsmgmt
  3. In the dsmgmt command prompt, run this command:
    roles
  4. In the fsmo maintenance command prompt, run this command:
    connections
  5. In the server connections command prompt, run this command:
    connect to server computername: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.
  6. In the server connections command prompt, run this command:
    quit
  7. In the fsmo maintenance command prompt, run this command:
    seize schema master
  8. (Etape rajoutée) In the fsmo maintenance command prompt, run this command:
    seize naming master
  9. 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

Server “Server01:389” knows about 2 roles


Schema – CN=NTDS Settings,CN=Server01$VMwareVDMDS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={F82E0D4A-16B0-44B1-91B7-5F5A08BD619A}

Naming Master – 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}

Post to Twitter

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.

  1. Créer le fichier C:\Program Files\VMware\VMware View\Server\sslgateway\conf\ locked.properties
  2. Ajouter la ligne : checkOrigin=false
  3. 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 🙂 )

Post to Twitter

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 😉

Post to Twitter