Forum Tranquil IT

Bonjour,

J'utilise WAPT Community 1.8.2, avec bonheur

Toutefois, je souhaitai vous faire part de ma mésaventure lors de l'installation d'un nouveau poste Windows 10 équipé avec l'agent WAPT.
J'ai installé l'agent, puis est déployé mes logiciels.
Tout allait bien... jusqu'à ce que je joigne ma nouvelle machine à mon domaine AD (server 2012 R2).
Et là depuis ma consolé WAPT, le poste apparaissait d'un coup en "DISCONNECTED"...

Du coup, je me gratte la tête, et me dit "tiens, ça viens du parefeu windows lorsque j'ai joins ma nouvelle machine au domaine peut-être". Je désactive le parefeu, et arrête Kaspersky...
Idem...
Je relance mon service windows WAPT sur le nouveau poste, et tant qu'à faire je relance mon serveur WAPT sur centos 7.
Idem...

Mince, je pige plus rien

En fait, ça vient du nom de machine enregistré dans le serveur WAPT.
Avant de joindre mon nouveau poste au domaine AD, mon poste s'appelait "nomduposte" tout court.
Après jonction au domaine, le nom est devenu "nomduposte.mondomaine.truc"...

Je pensais que WAPT travaillait par ip... Surtout que j'ai la version "Community" et pas Entreprise (donc pas de prise en charge de l'AD et pas la possibilité de faire des groupe de machines).

Du coup, j'ai :
- Supprimé mon nouveau poste du registre du Serveur WPAT,
- Désinstallé et réinstaller l'agent WAPT sur mon nouveau poste,
- Ré enregistré le nouveau poste à l'installation de l'agent sur le serveur (cette fois avec le nom "nomduposte.mondomaine.truc"),
- relancer le déploiement de mes logiciels qui se sont réinstallés par dessus les installations initiales.

Au passage, j'ai parcouru le forum pour trouver une solution à mon problème.
Le post viewtopic.php?f=10&t=1091 est intéressant, mais ça n'est pas mon antivirus qui bloquait ma connexion, ni l'histoire des horloges désynchronisées viewtopic.php?t=1635

Donc, il faut se rappeler quand on gère une domaine AD :
- Installer l'agent WAPT seulement après avoir joint une nouvelle machine au domaine

Ed

Bonjour,
retour très intéressant.
Pour notre part nous faisons tomber l'agent via GPO, donc forcément lors de l'ajout au domaine.
Cela pourrais résoudre le soucis pour votre parc je pense.

Normalement, par défaut, les postes s'enregistrent avec un identifiant unique (UUID) provenant du BIOS donc indépendant du nommage du poste.
Sauf si vous avez choisi de l'identifier avec son nom FQDN dans la configuration de l'agent.

L'authentification de l'agent sur le serveur utilise cet idenfiant UUID, donc mettre le poste dans le domaine ou changer son nom ne devrait pas entrainer la déconnexion que vous mentionnez.

Avez-vous utilisé le paramètrage "use_fqdn_as_uuid" (Utiliser le nom FQDN comme identifiant unique) ?