[Wapt] Problème déploiement GPO

MORILLO Jordi j.morillo at educationetformation.fr
Wed Jul 4 17:43:37 CEST 2018


Bonjour tout le monde,

Nous rencontrons un soucis sur le déploiement de la 1.5 (en écrasement de la 1.3) par GPO.
Voici notre architecture :

-          Postes clients en Windows 7, dans un domaine Samba AD, et avec wapt 1.3

-          2 serveurs distincts wapt 1.3 et 1.5

-          « Toujours attendre le réseau lors du démarrage de l'ordinateur et de l'ouverture de session » activé par GPO

-          Nouvelle GPO que l'on applique à qq OU de tests : --hash=665[...]391 --minversion=1.5.1.23 --wait=15 --waptsetupurl=waptagent.exe --setupargs=/dnsdomain=educationetformation.fr --setupargs=/wapt_server= --setupargs=/repo_url= --setupargs=/hiberboot_enabled=0 --setupargs=/pre_shutdown_timeout=180 --setupargs=/max_gpo_script_wait=180

-          Waptagent et waptdeploy sont tous les 2 dans le dossier startup script de la GPO

Notre problème : les postes ne se mettent pas à jour en 1.5
Par tâtonnement, voici les différents tests que nous avons effectué :

-          Plusieurs redémarrage des postes

-          Ajout de « > C:\wapt\upgrade.txt » à la fin des paramètres waptdeploy ... sauf que windows n'est pas Unix, et que le fichier upgrade.txt n'est écrit que si la commande waptdeploy se termine.. ce qui n'est pas le cas

-          Ajout de GPSvcDebugLevel en base de registre afin d'être un peu plus verbose sur l'application des GPO mais malgré la taille du fichier Gpsvc.log, rien de probant pour nous aider à debug

-          On a joué avec les GPO « Spécifier la durée d'attente maximale pour les scripts de stratégie de groupe », « Executer les scripts de démarrage de manière asynchrone », « Spécifier le temps d'attente de traitement de stratégie de démarrage » mais le problème persistait

-          On a viré le « --wait=15 » des paramètres de waptdeploy, qui d'après le code source, correspondrait a faire un --wait=0, et donc à ne pas attendre

Au niveau des processus, on a noté qq chose de bizarre : un process waptagent.tmp (correspondant au fichier %windir%\temp\is-fdsfgsdqgfq.tmp) qui ne fait pas grand-chose (0% CPU, 4Mo de Ram utilisé)
Sinon, on a bien un processus waptdeploy qui lui provient de \\mondomain\[...]\Polices\[...]\startup\<file://mondomain/%5b...%5d/Polices/%5b...%5d/startup/> et également un processus waptagent.exe (l'exécutable se trouve dans %windir%\Temp)
Jusque l'a rien d'anormal si ce n'est le waptagent.tmp qui ne fait rien...

Cela nous a amené a regardé du côté des services  et à voir que le service WAPTService (nssm.exe) était arrété (type de démarrage automatique).
A ce stade, si on redémarre le poste, le problème se reproduit. Si on kill les taches de l'installeur (waptdeploy, agent) et qu'on lance le waptdeploy avec les paramètres à la main, l'installation fonctionne !

Dernier essai qui nous amène sur une piste intéressante :

-          On démarre un poste en Wapt 1.3 mais sans GPO WApt

-          On change le type de démarrage de WAPTService en désactivé

-          On éteint le poste, et on met la GPO Wapt 1.5

-          On rallume le poste, l'installation fonctionne...

Du coup, nous constatons que le « waptagent.tmp » arrive bien à stopper le service WAPTService mais qu'ensuite l'installation ne va pas plus loin...
Auriez-vous rencontré des cas similaires ? avez-vous quelques pistes à nous suggérer ?
Bien évidemment, on pourrait faire cette migration 1.3 -> 1.5 de mille manières (au shutdown, par tache planifiée ou meme par un paquet provenant de la 1.3) mais pour le coup, on essaie simplement d'utiliser les préconisations du Wiki.
En vous remerciant d'avance pour toutes les précisions que vous pourrez nous apporter.
Bien cordialement
Jordi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tranquil.it/pipermail/wapt/attachments/20180704/70caf771/attachment.html>


More information about the WAPT mailing list