Pourquoi se limiter à ce point?
La remontée d'inventaire est totalement transparente. Ca ne provoque pas de lenteur sur le poste ni sur le réseau.
Ici aussi, il y a pas mal de laptop qui se baladent. L'inventaire est bien mis à jour malgré tout.
Sur ce, je n'ai pas de jugement de valeur et je ne connais pas le contexte, j'essaye juste de comprendre
Merci de ta réponse mais j'ai surement dû louper une étape.
]]>A choisir, je resterais sur une config Fusion et je ne passerais pas sur de l'OCS (mais c'est un choix perso).
Si le serveur et l'agent sont correctement configurés, c'est un système qui est performant, complet et efficace (et peu gourmand en ressources).
]]>J'ai configuré un petit réseau avec contrôleur de domaine sous Windows Server 2016 pour le déploiement automatique via GPO de l'agent fusion inventory, pour un seul poste pour tester, le poste ne remonte pas automatiquement, j'ai du forcer pour obtenir le premier inventaire en regardant les logs de l'agent sous mon client windows les dernière lignes son
[Tue Apr 9 14:53:44 2019][info] sending prolog request to server server0
[Tue Apr 9 14:53:44 2019][info] running task Inventory
[Tue Apr 9 17:50:11 2019][info] sending prolog request to server server0
[Tue Apr 9 17:50:11 2019][info] running task Inventory
[Tue Apr 9 18:03:36 2019][debug] FusionInventory Agent (2.4.3)
[Tue Apr 9 18:03:36 2019][debug] Configuration directory: C:\Program Files\FusionInventory-Agent\etc
[Tue Apr 9 18:03:36 2019][debug] Data directory: C:\Program Files\FusionInventory-Agent/share
[Tue Apr 9 18:03:36 2019][debug] Storage directory: C:\Program Files\FusionInventory-Agent/var
[Tue Apr 9 18:03:36 2019][debug] Lib directory: C:\Program Files\FusionInventory-Agent/perl/agent
[Tue Apr 9 18:03:36 2019][debug] [target server0] Next server contact planned for Tue Apr 9 18:50:14 2019
[Tue Apr 9 18:03:36 2019][debug2] getAvailableTasks() : add of task Inventory version 1.6
[Tue Apr 9 18:03:36 2019][debug2] getAvailableTasks() : add of task Maintenance version 1.1
[Tue Apr 9 18:03:36 2019][debug2] getAvailableTasks() : add of task WMI version 0.3
[Tue Apr 9 18:03:36 2019][debug2] isParamArrayAndFilled('tasks') : false
[Tue Apr 9 18:03:36 2019][debug] Available tasks:
[Tue Apr 9 18:03:36 2019][debug] - WMI: 0.3
[Tue Apr 9 18:03:36 2019][debug] - Inventory: 1.6
[Tue Apr 9 18:03:36 2019][debug] - Maintenance: 1.1
[Tue Apr 9 18:03:36 2019][debug] server target: http://192.168.122.21/glpi/plugins/fusioninventory/
[Tue Apr 9 18:03:36 2019][debug] Planned tasks:
[Tue Apr 9 18:03:36 2019][debug] - WMI: 0.3
[Tue Apr 9 18:03:36 2019][debug] - Inventory: 1.6
[Tue Apr 9 18:03:36 2019][debug] scheduler target: scheduler0
[Tue Apr 9 18:03:36 2019][debug] Planned tasks:
[Tue Apr 9 18:03:36 2019][debug] - Maintenance: 1.1
[Tue Apr 9 18:03:36 2019][debug] Provided by Fusioninventory
[Tue Apr 9 18:03:36 2019][debug] Installer built with Appveyor on Fri Feb 22 20:47:41 UTC 2019
[Tue Apr 9 18:03:36 2019][debug] Running in foreground mode
[Tue Apr 9 18:03:36 2019][info] server0 is not ready yet, next server contact planned for Tue Apr 9 18:50:14 2019
[Tue Apr 9 18:03:36 2019][info] scheduler0 is not ready yet, next server contact planned for Tue Apr 9 18:04:06 2019
Je précise que mon serveur GLPI avec le plugin FusionInventory est sous Debian stretch, je n'ai pas configurer de tache ni de communauté snmp, je suis en train de le faire mais je demande dans le cas ou l'erreur ne viendrais pas de là.
j'utilise les dernières version du plugins et de l'agent et un script VBS pour le déploiement et j'ai régler les paramètres pour que les remontées s'effectue toutes les heures
Dans l''attente de vos réponses