Forum Tranquil IT

Bonjour à tous,

Contexte:
WAPT version : 2.1 Entreprise
OS serveur : Debian 11
OS console d'administration : Win10pro
OS poste dev de paquets : Win10pro

Nous avons certains utilisateurs qui éteignent rarement leur poste de travail et ne se voient pas appliquer les mises à jour Windows nécessaires.

Nous souhaiterions que les mises à jour Windows ne s'installent donc pas à l'extinction du poste mais plutôt dès que le poste est en ligne (mises à jour Windows sans redémarrage) et cela de façon automatique moyennant une fréquence.

Pour cela, nous avons configuré un agent WAPT ainsi:
[waptwua]
enabled=true
default_allow=true
install_at_shutdown=false
install_delay=7d
install_scheduling = 1d
download_scheduling = 1d

Les mises à jour apparaissent en pending (bien que certaines avaient un statut DISCARDED malgrè le paramètre default_allow=true) mais ne semblent pas s'installer selon la fréquence déclarée (elles restent en status pending, malgrè un redémarrage manuel du poste 3 semaine après pour bien laisser passer le délai de 7 jours).

Normalement cette configuration scannera pour les mises à jour tous les jours, installera les mises à jours nécessaires quotidiennement (qui doivent toutes être en statut pending du fait de default_allow=true) en laissant passer un délai de 7 jours depuis la publication de cette mise à jour, c'est bien ça ou je fais une erreur d'interprétation ?

Quelles grandes catégories de risques (cf DOC WAPT) à utiliser le paramètre install_scheduling = 1d , par exemple si l'utilisateur éteint son poste lorsqu'une mise à jour en attente Windows s'installe?

En gros que préconiseriez-vous pour une installation sûre des mises à jour Windows ne dépendant pas d'un redémarrage du poste, et ce de façon aussi transparente et automatique que possible (dans l'idéal, nous ne voudrions pas intervenir dans la console WAPT pour appliquer des mises à jour Windows aux postes) ?


Les mises à jour Windows via WUA à l'extinction du poste prennent un certain temps (à ce propos, un pourcentage d'exécution de ces mises à jour rendrait les utilisateurs moins prompts à éteindre sauvagement leur poste le vendredi soir ! (bien que cela dépende de divers facteurs (pairing opérateurs, débit reverse-proxy ...) ).

Est-ce que WUA supporte une extinction sauvage à l'extinction (je pense que cela doit arriver ) et permet une reprise propre ?


Cordialement.

C.R

install_scheduling me semble dans votre cas le plus adapter.
On le déconseille dans le sens ou installer des mise à jour en pleine journée consomme du cpu et cela peu poser problème pour l'utilisateur qui bosse d'évoir un ordi qui est lent mais si pour vous cela ne pose pas de problème pas de soucis.

Mais sinon cela pose problème. (attention après l'utilisateur devra tout de même redémarrer son poste pour terminer correctement la mise à jour).

Par contre si vous utilisez install_scheduling inutile de mettre download_scheduling puisque qu'un install_scheduling fait un scan.

Pour ce qui est de l'extinction sauvage, si waptexit voit une mise à jour windows en cour alors il stoppera l’arrêt du poste pour terminer la mise à jour.
Par contre si un utilisateur coupe a l'arrache son poste là forcément on en garanti rien ...

Pour ce qui est du calcule de temps c'est possible mais difficile a implémenter car comme vous l'indiquez il y beaucoup de paramètre a prendre en compte.

Pour les status DISCARDED qui persiste il faudrait regarder c'est étrange, la date était bonne ?

Bonjour,

Mes excuses pour le retour tardif.
J'ai un poste en test restant allumé (Machine virtuelle W10) avec les paramètres WUA suivants:

enabled=true
default_allow=true
install_at_shutdown=false
install_scheduling = 2h

La directive install_scheduling = 2h ne semble pas être honorée car:
- aucune trace d'un ordre de scan dans le fichier de logs du client waptservice.log
- dans la console d'administration WAPT, la date de dernier scan est au 2022-07-06T12:06:18.064877 et celle du dernier fichier wsusscn2.cab sur le client 2022-04-11T22:46:16, alors que la date du dernier fichier wsusscn2.cab sur le serveur est : 2022-07-12T12:28:21 (cf PJ: wapt_wua_not_launched.png).

Avez-vous une piste pour investiguer la cause du non déclenchement ?

D'autre part, si une mise à jour Windows est est cours, que l'utilisateur ferme sa session et/ou ferme son portable et passe en veille, est-ce que la mise à jour en cours d'application reprend là ou elle en était lors de la mise en veille ?

sfonteneau a écrit : ↑07 juin 2022 - 10:25 install_scheduling me semble dans votre cas le plus adapter.
On le déconseille dans le sens ou installer des mise à jour en pleine journée consomme du cpu et cela peu poser problème pour l'utilisateur qui bosse d'évoir un ordi qui est lent mais si pour vous cela ne pose pas de problème pas de soucis.

Mais sinon cela pose problème. (attention après l'utilisateur devra tout de même redémarrer son poste pour terminer correctement la mise à jour).

Par contre si vous utilisez install_scheduling inutile de mettre download_scheduling puisque qu'un install_scheduling fait un scan.

Pour ce qui est de l'extinction sauvage, si waptexit voit une mise à jour windows en cour alors il stoppera l’arrêt du poste pour terminer la mise à jour.
Par contre si un utilisateur coupe a l'arrache son poste là forcément on en garanti rien ...

Pour ce qui est du calcule de temps c'est possible mais difficile a implémenter car comme vous l'indiquez il y beaucoup de paramètre a prendre en compte.

Pour les status DISCARDED qui persiste il faudrait regarder c'est étrange, la date était bonne ?

Bonjour

Suite a votre message la dernière fois j'ai regarder le code et effectivement le scan est obligatoire pour que cela fonctionne ce qui n'était pas très logique.

En gros l'install ne se lançait que si le status précédent est en pending mais si on ne lance pas de scan ça ne sera jamais en pending

Dans la dernière version (wapt-2.2.2.12388-10e35aa7) j'ai supprimer cela et donc le scan n'est nécessaire puisque l'install va lancer un scan

Pouvez-vous mettre à jour pourvoir si c'est mieux ?

Simon

Bonjour Simon,

Je vais (normalement) faire la mise à jour demain après-midi, je vérifie le comportement et te fais un retour.

Par contre, si une mise à jour Windows est est cours, que l'utilisateur ferme sa session et/ou ferme son portable et passe en veille, est-ce que la mise à jour en cours d'application reprend là ou elle en était lors de la mise en veille (je sais, j'insiste, mais il y a toujours des utilisateurs très pressés qui vont la faire) ?

Christophe.

sfonteneau a écrit : ↑01 août 2022 - 11:07 Bonjour

Suite a votre message la dernière fois j'ai regarder le code et effectivement le scan est obligatoire pour que cela fonctionne ce qui n'était pas très logique.

En gros l'install ne se lançait que si le status précédent est en pending mais si on ne lance pas de scan ça ne sera jamais en pending

Dans la dernière version (wapt-2.2.2.12388-10e35aa7) j'ai supprimer cela et donc le scan n'est nécessaire puisque l'install va lancer un scan

Pouvez-vous mettre à jour pourvoir si c'est mieux ?

Simon

Bonjour,

Après mise à jour (-> 2.2.2), le scan et l'install se lance bien à la fréquence voulue, merci.
Reste à tester le comportement sur reprise lorsqu'un PC est passé en veille (fermeture portable ...) alors qu'il est en cours d'install d'une mise à jour Windows.

Cordialement.

croquebert a écrit : ↑03 août 2022 - 14:52 Reste à tester le comportement sur reprise lorsqu'un PC est passé en veille (fermeture portable ...) alors qu'il est en cours d'install d'une mise à jour Windows.

Bonjour

Le réponse est délicate, wapt demande au service windows update d'installer la cab (techniquement wapt ne lance pas l'installation il lance windows update et demande a celui-ci de lancer l'installation.

Donc le comportement dans ce cas ... au redémarrage je pense que tout va continuer mais c'est a tester

Simon

Bonjour Simon,

Merci pour le retour. Je pense aussi qu'il y a reprise, mais je vais quand même le vérifier à l'occasion.
Comment modifier le topic pour le marquer résolu ?

Cordialement.

sfonteneau a écrit : ↑03 août 2022 - 17:44

croquebert a écrit : ↑03 août 2022 - 14:52 Reste à tester le comportement sur reprise lorsqu'un PC est passé en veille (fermeture portable ...) alors qu'il est en cours d'install d'une mise à jour Windows.

Bonjour

Le réponse est délicate, wapt demande au service windows update d'installer la cab (techniquement wapt ne lance pas l'installation il lance windows update et demande a celui-ci de lancer l'installation.

Donc le comportement dans ce cas ... au redémarrage je pense que tout va continuer mais c'est a tester

Simon