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

Question

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

Answer 1

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,

Answer 2

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

Answer 3

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.

Answer 4

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) !

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.

Answer 5

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 ?

Answer 6

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  !

Answer 7

Par contre là je ne vois vraiment pas comment faire 

Answer 8

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

Answer 9

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 !

Answer 10

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