Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.11.1 available

The official documentation can be found on http://wiki.ocsinventory-ng.org. Read it before asking your question.

Problème de remontée d'infos du plugin Winupdate [closed]

Bonjour,

je n'ai aucune remontée d'info du plugin WinUpdate dans mon serveur, et en forçant un inventaire en local sur un client je trouve ceci dans le fichier XML :

  <WINUPDATESTATE>
            <AUOPTIONS />
            <SCHEDULEDINSTALLDATE />
            <LASTSUCCESSTIME />
            <DETECTSUCCESSTIME />
            <DOWNLOADSUCCESSTIME />
  </WINUPDATESTATE>

Sinon, lorsque j'exécute "winupdate.vbs" sur une station, les commandes "Wscript.Echo" m'affichent correctement les informations (bien formaté).

J'ai eu beau revoir les syntaxes utilisées dans le fichier VBS et aussi refaire ce fichier en passant par une autre méthode (WMI - class StdRegProv), mais rien n'y fait : Cette zone du fichier XML reste désespérément "mal formatée"... Quelqu'un aurait une idée SVP ?

PS : Les informations provenant des autres plugins sont bien récupérées par le serveur
closed with the note: Problem fixed, improvements available on Github
in OCS Inventory NG agent for Windows by (1.2k points)
closed by

18 Answers

0 votes
Bonjour,

J'ai exactement le même problème que vous. Les autres plugins fonctionnent correctement, et en lançant le script en local il semble fonctionner. Mais le fichier XML est désespérément vide.

Avez-vous pu trouver une solution ?
Merci d'avance,
by (680 points)
+1 vote
Bonjour Nicokwak,

non, pas de solution de mon côté.

Comme je l'écrivais dans mon post initial, je suis allé jusqu'à refaire le fichier vbscript avec une autre méthode, sans davantage de succès (!!).

Plus précisément, cette section WINUPDATESTATE de mon fichier XML est mal formatée (voir post initial) et vous indiquez dans votre cas que c'est vide, alors nous n'avons peut-être pas tout à fait le même problème.

Contrairement aux autres plugins, l'installation de celui-ci dans l'interface du serveur OCS (sous Debian) m'a demandé de finaliser moi-même car plusieurs fichiers n'étaient pas copiés aux bons endroits (map.pem, winupdate.conf) ainsi que les droits qui vont avec, alors même si ce n'est pas lié je soupçonne globalement une mauvaise conception de ce plugin.

Pour répondre à votre question et en attendant mieux, la solution provisoire que j'ai trouvé pour la 1ère info (AUOPTIONS) du vbs est de passer par le registry du serveur OCS qui retourne le statut de Windows Update (1:Désac. / 2:Me laisser choisir / 4:Auto).

> D'ailleurs chose étrange, il semble qu'il n'y ait aucun champ de prévu pour afficher ce statut par le plugin dans l'interface du serveur OCS...
by (1.2k points)
edited by
+2 votes
Je me suis mal exprimé, je retrouve bien la même chose que vous dans mon fichier XML :
<WINUPDATESTATE>
            <AUOPTIONS />
            <SCHEDULEDINSTALLDATE />
            <LASTSUCCESSTIME />
            <DETECTSUCCESSTIME />
            <DOWNLOADSUCCESSTIME />
        </WINUPDATESTATE>

Je ne me rappelle pas avoir eu de soucis dans l'installation du plugin concernant ces fichiers.

Pour afficher AUOPTIONS dans l'interface, il faut modifier le fichier cd_winupdate.php et rajouter la colonne dans $list_fields.
by (680 points)
0 votes

Merci pour votre ajout de AUOPTIONS dans l'interface du serveur OCS, essayé et adopté (j'en ai profité pour franciser les entêtes de colonne) ! smiley

Après de nouveaux tests, il semblerait que le soucis provient des variables (AutoUpdateLevel, ScheduledInstallDate, etc.) dont les valeurs ne s'intègrent pas correctement avec la méthode proposée.

> En by-passant la lecture du registre (par ex. remplacement de la ligne 15 par "AutoUpdateLevel = 2"), les balises sont maintenant à leur place dans le fichier XML.

by (1.2k points)
edited by
0 votes
Quand le script est lancé manuellement en double cliquant dessus, les informations sont correctes.

Le problème intervient quand le script est exécuté par l'agent OCS.

Je me demande si le soucis ne provient pas des droits, l'accès à ces infos ne serait il pas protégé en lecture ?
by (680 points)
0 votes

Super bien vu... En effet, en essayant une autre branche du registre (par ex. celle récupérée dans le vbs du plugin Teamviewer), ça fonctionne du 1er coup !

Faut qu'on bosse ensemble wink !

by (1.2k points)
0 votes

Par contre là je ne vois vraiment pas comment faire frown

by (680 points)
0 votes
Pour le moment, je cherche du côté de l'élévation de privilèges ou forcer l'exécution du script par le compte système, mais mes tests ne changent rien.

Nous ne devons pas être les seuls à avoir ce problème...
by (1.2k points)
0 votes
Après avoir deployé environ 130 postes, je me rend compte que 26 remonte les informations du plugin Winupdate.
Je n'ai cependant rien modifié au script ni à la configuration de ces machines.
Je cherche un point commun entre ces postes et je vous tiens au courant !
by (680 points)
+2 votes
Bonjour Nicokwak,

ces 26 PC n'auraient-ils pas une version 32 bits de Windows ?

D'après mes tests et avec le script original, ces informations de registre ne sont pas correctement récupérées sous Windows 64 bits.

Cordialement, Stéphane
by (32.6k points)
edited by
 
Powered by Question2Answer
...